Well, for video, there's a couple cost and engineering related issue:
Crazy fact: prior to its release the STE was rumoured to have an 8bpp low-resolution colour mode and a 2bpp 640x400 mode, according to old-computers.com this was even announced by Atari themselves. Wonder why they didn't do it - working with 64K of video RAM should have been an easy task even for the humble 68K and blitter, and would have given the STE a real edge over the Amiga. The STE sound is OK though, even if the YM2203 seems a more natural choice. The 16MHz upgrade was already offered by many 3rd parties for the ST and Mega ST lines (at least on this side of the pond) and should of course have been implemented into the design - so FULL ACK! I also miss the expansion bus from the Mega STs (a similar bus can be found in the F030, but not in the STE for whatever reason).
Two points where Atari completely failed: instead of selling off their stock of STfms and replacing them with the STE (like they did with the ST(m)s when they introduced the STf(m)s, they continued to produce the STfm, hampering the development of STE enhanced software. And they denied the problem with the DMA chip inside the first batch of STEs, blaming third party HDDs instead.
1. 256 colors would mean more color registers (CRAM) for indexing all of those colors . . . or perhaps a more limited 256 color mode that used the added 4 bits to modify the base set of 16 colors. (ie using 4 levels of luminance/intensity/shading or RGB control -or perhaps using 4-bits for RGBI control)
2. you don't just need more framebuffer address space, but also more bandwidth for the SHIFTER to scan the buffer . . . which would either mean a wider bus and/or faster RAM, but the latter case would also generally imply moving away from the interleaved memory set-up and instead using serial bus sharing. (since that sort of speed would need FPM accesses, which only work for consecutive/serial accesses, so the 68k -and other bus masters- would need to wait while video was being scanned . . . and/or a separate CPU bus would need to be added -a la fastRAM . . . or a dedicated video bus -though adding fastRAM would add to cost over a single-bus design)
And if they DID design the SHIFTER to make use of fast page DRAM accesses, that would generally mean adding line buffers on-chip to facilitate reading long chunks of memory at a time, or perhaps specifically limited to scanning an entire scanline within hblank (more like the A8's video mechanism). And the latter would allow very consistent DMA timing and no need for double buffered line buffers (scanline would be read in hblank and then displayed -rather than needing 1 display buffer and 1 back buffer being filled while the other displays), but would limit bandwidth to what's available within hblank (which would be especially limited in 31 kHz mode). Though, given the existing ST resolutions (and considerable hblank area), it should have been practical to support 640x400 at 4 colors on a 16-bit bus (or 320x400 16 colors or 640x400 16 colors or 320x400 256 colors on a 32-bit bus). Or higher vertical resolutions than that since hblank bandwidth would only limit scanline width.
I'm also assuming they simply used 8 MHz (125 ns) FPM DRAM for simplicity and cost reasons. (if they allowed video DMA to act asynchronously from the video/pixel clock, you could have RAM -or general CPU/system- clock speeds of various other options like 10 or 12.5 MHz -100 or 80 ns- or 16 MHz, but that would be 62.5 ns, which would be relatively expensive DRAM even in the early 90s)
However, those changes (added CRAM, buffering, and wait state management) should have been quite realistic in the late 80s, let alone early 90s. (especially if they hadn't even bothered with the blitter and stuck more to CPU resource . . . or added rather basic hardware acceleration like basic block/line fill -and screen/line scrolling obviously).
As for the faster CPU, shifting to serial bus sharing would have been the most cost effective route to facilitate that as well. Adding a fastRAM bus more like the Amiga (or other systems with dedicated CPU buses) would be more straightforward in some respects, but also more costly. (and such cost could be better put into other areas like wider buses and/or faster CPUs, or coprocessors, etc)
A unified bus is one of the most significant cost saving measures of a computer or console, and in terms of having fast CPUs on a shared bus, high peak bandwidth with serial bus sharing tends to make the most sense.
For example: adding a 16 MHz 68k to a vanilla ST (with slow/interleaved RAM accesses) would need wait states to match the slow bus speed and relatively moderate added performance over an 8 MHz CPU (some internal operations would be faster -especially multiplication and such- but actual memory-bound operations would be no faster -including software rendered graphics).
OTOH, with serial bus sharing, a 16 MHz CPU could have virtually full access to the bus at full speed with more moderate waits for video DMA (or floppy, etc), and actual DMA overhead for video would be lesser at lower resolutions/color depths.
Or, a (potentially earlier) simpler compromise would have been a faster CPU running nearly full bore on the slow ST bus (with old ST video modes) in hblank and vblank, but adding waits during active video. (and additional waits for floppy/HDD access -so something perhaps more useful around the time of the MEGA's initial release)
Another option (which some accelerators and the MSTE took) would be an external CPU cache along with slow ST style interleaved memory . . . that still limits the external performance of the CPU (including software rendering to some extent) and is almost as costly as adding a fastRAM bus. (and in terms of utility, a full fastRAM bus would be much more worth the cost)
A modified fast bus sharing scheme would be a much more efficient option, and something that would become even more useful with faster CPUs, especially ones with on-chip caching. (ie if a 68020 or 030 -let alone 040- were used, actual FPM accesses could be used for some things -particularly cache-related operations- )
Of course, accelerator boards couldn't modify the entire system to be more efficient, so caching was the only real option there.
This is the sort of bus sharing that the Jaguar uses, and it allows far, far more bandwidth than the ST/Amiga style interleaving schemes. (it's more or less the same route taken on newer shared bus systems like the N64, Xbox, 360, etc -though with faster and faster memory and processors with more and more buffering to more efficient bus sharing . . . or for that matter, same thing for PCs with integrated graphics using shared system RAM)
So, given Atari's general market position to aim at the optimal cost to performance ratio, continued use of a unified bus would have been the obvious route to take. (albeit they'd need good engineers to really make that work well, especially on a tight budget and reasonable timeline)
And rather than offering fastRAM at all on even high-end models, it might make more sense to just rely on faster system memory and wider buses (and faster CPUs) . . . maybe with some external CPU caching as well. (which would become more important with faster and faster processors to complement FPM DRAM accesses/bus sharing -unlike caching of a 68000 on the slow old ST bus, which is relatively inefficient and wasteful)
It would have been more complex/R&D intensive than the likes of the MEGA or STe, but still not to much different from the TT (let alone falcon), and should have been a far, far simpler undertaking than the likes of the Jaguar. (and even backwards compatibility would have been relatively simple due to the generally clean and simple design of the original ST . . . especially if they hadn't added the blitter)
In hindsight at least, it's fairly obvious that Japanese companies didn't really manage to compete in until much later -and even today more towards laptops and tablets than dektop PCs . . . aside from within Japan/Asia itself. (which had always been dominated by domestic computers -in Japan, particularly with NEC's computers until the shift to PC clones in the early/mid 90s)
Actually, the Atari PCs are another thing that fell apart after Jack left . . . I wonder if he would have had any impact on that had he postponed retirement.
According to the "Atari: Beginning to End" panel here, it was Jack's call to get out of computers because he saw no way to compete with the Taiwanese. He was apparently not too big on Jaguar, so I'm not sure what he wanted the company to be doing. (Maybe he would have sold the company sooner had he still been CEO?)
I could see how Tramiel would have seen the possibility of Asian companies jumping ahead in the western markets, but it would have been rather premature to assume that was the case without any hard evidence on the actual market. (ie just because the potential was there doesn't mean it would have materialized as an actual threat)
Perhaps Jack didn't have a good grasp on this concept (though it'shard to imagine that he didn't have at least some understanding of it), but there's a hell of a lot more to a successful consumer product than having the cheapest product out there (cheapest relative to similar performance, that is), especially in the US market where marketing/PR/perception/brand recognition can be so powerful. (a massive part of IBM's success in the consumer market . . . or Commodore's, Nintendo's, or Sony's, or Atari Inc's, or Microsoft's, etc)
That, and catering to specific market niches if you don't have the raw clout to push massive marketing. (which is what the ST, 2600 Jr, and 7800 ended up doing in the US)
Again, Europe is a bit of a different story, though brand-recognition/loyalty was still quite significant there too . . . and having the right product for the market at the right price. (something no Asian computer manufactures ended up doing, regardless of marketing)
So, from Atari/Jack's perspective, Asian manufactures clearly could have threatened their niche in the value end of the market (and perhaps higher-end systems as well), but it's hard to imagine him not realizing that poor management/marketing (even towards that niche) would still prevent entry to that market.
For raw components, yes, lower manufacturing costs will almost always win (which is what happened with much of the semiconductor/LSI fabrication industry moving overseas), but actual technology/R&D, let alone consumer products have a lot more than just cheap labor/production facilities to consider. (and in those respects, Atari -or any similar company- could potentially remain competitive by maintaining competent R&D, marketing, and overall management personnel while very likely taking advantage of cheap overseas manufacturing )
But after all that, there's still the much bigger issue that Jack didn't actually do any of that . . . ie he retired in 1988 and Sam took over as president/CEO (though Jack remained on the board of directors). So it wouldn't have been his decision on how to manage the Atari PC line, STe (and later ST line in general), or Jaguar (or Panther or Lynx for that matter) as all of those were after Jack left. (or rather the PC line was launched prior to Jack leaving, and continued to introduce new machines into the early 90s, but the actual management/presence of that line on the market seems rather questionable and it was shut down in the early 90s along with the ST -if not earlier than that)
And Jack did shut down the Jaguar in 1996 . . . but by that point, that was really the most financially responsible course of action. (and their home console market had already taken a massive hit from the total absence between the 7800 and Jaguar . . . and general decline in management and decline of the computer market as well, so the Jag was starting out on the market under pretty terrible circumstances in '93/94)
That, and Curt and Marty's own comments don't seem to match the claim of Jack wanting to get out of computers in general . . . and such interviews have shown inaccuracies before too. (after all, the perspective is relatively limited)
Hell, several such speeches/interviews that Curt was directly involved in turned out to have significant errors after the fact (things that Curt and Marty only uncovered more recently), like the 7800 history account from Steve Golson from a few years back. (including a lot of inaccuracies/common myths about Tramiel/Atari Corp in particular)
Edited by kool kitty89, Wed Nov 16, 2011 6:41 PM.