Subject: RE: Ideas on new Atari |
Author: Evan Langlois (67.187.51.187)
Date: 03-12-2005 07:36
Actually I've found its the people who are "into computers" that look at Ghz, and then only the desktops and laptops. For embedded systems like PDAs and tablets, there is much more varied market. People know that a PalmOS device doesn't need a 4Ghz CPU, and they also realize that if they wanted a laptop with a 4Ghz processor they'd buy one. They bought a Palm instead because it filled the need they had.
You say the only market for an Atari compatible device is existing ST users that are only interested in emotional attachment and not how well the machine can be of technical value. I don't know what percentage of users would upgrade. How many sales did previous super-Ataris like the Milan get? I say its the exact opposite - target a mass market with a really great product that leverages a great OS and existing application base with the small code size, great speed, and low power consumption of the 68K/Coldfire, and if existing Atari users can use it, so much the better.
As for drivers, the Linux and freebsd code bases can provide most of the documentation required for writing new drivers. Too bad you can't just cut-n-paste them :/ Perhaps enough of the USB subsystem can be ripped from Linux and ported so that the USB modules think they are running on Linux. The rest of the system wouldn't need a huge number of drivers since in an embedded system, you don't replace/upgrade the hardware .. so you only have to support what is on the board.
As for well-written software, that one is rough as you have to decide how much compatibility with older machines you want to retain and which flavor of the OS to support when writing any new software. How many programs still use 8.3 filenames? MiNT has been out for YEARS. How many apps are mono only? Existing standards guides on what well-written means in the Atari world are still kinda wanting. Even Linux has some problems in this area as new APIs for "better" ways of doing things come out so quickly, and yet require ever more horsepower to do well. The Jack API comes to mind ... great piece of software, awesome flexibility, but not all apps support it yet, and it still has trouble with overruns when recording on a slow machine.
|