3 ms·

Yes, I think some of that complexity was due to interference by Atari, they definitely took a dump on the Handy/Lynx by changing the power circuitry and the siz

Yes, I think some of that complexity was due to interference by Atari, they definitely took a dump on the Handy/Lynx by changing the power circuitry and the size of the unit. From what I've read, the joypads were lifted straight from the panther, as were the launch games, rather than be redesigned. The CPU was always meant to be 32bit with a cache, Atari chose the 68000 for ease of porting games over, but cheaped out rather than choose an EC68020 which would have increased the bus bandwith by 4 times. Same with a lack of a CD unit which if it had come with one would have helped attract developers - the costs of ROM carts made it very unattractive for most dev houses. Additionally, having the designers do a proper SDK would have helped, especially with the direct memory access bug which would be mitigated with an official workaround. Lastly, the chipset was designed to be able to use 2 memory banks, so having 1meg+512K would've been better than 2meg on one bank. Obviously having more time to develop the chipset would have been benficial. I believe Atari insisted on the object processor in addition to the DSP and blitter, which the designers were not keen on, and really by that time had been demonstrated to be a bit of a dead end (Atari GTIA->MARIA->Copper vs tile/sprite-based VDPs or blitter-based processors). If they'd not put one in maybe the chips would've been ready earlier/better, or could've had some cache/registers for the blitter. Even without the chipset improvements, a handful of changes would've made things a lot easier for developers, and faster to boot.

to11mtm 7y ago
> EC68020 which would have increased the bus bandwith by 4 times. I thought it was only 2x (16 bit bus on the straight 68k). It did also have a cache though which likely would have helped muchly. Wikipedia does indicate the EC68020 was considered for the Jaguar 2. My gut would be that the EC68020 was considered 'too expensive'; back then 130k extra transistors still meant a few bucks from a cost standpoint, and Atari was already cutting odd corners in a desperate stupor. That bus is terrifyingly bad IMO, I remember developers lamenting it in interviews I've read over the years. One of the -smartest- things Sony did with the Playstation was picking an architecture that was known to be capable of 'pushing graphics' and licensed/reused what they could from SGI's system designs. Probably a big part of why, while still challenging for it's age, it was at least -sane- compared to what was involved on the Saturn (lol, quadratics) or the Jaguar. Nintendo, while late to the 32 bit party, also went with an SGI based architecture, but stuck with ROM carts which still cost them a bit of business. Funny, the TG-16 suffered from many of the same problems as the Jaguar (specifically, questionable CPU bus sizes and quirky hardware design). Alas, it seems nobody from Atari payed attention to that lesson.
- alexisread 7y ago
  Yes you're right, technically it's 2x bus speed moving 16->32 bits, but I was guestimating the effect of the cache to allow the 020 to stay off the bus ie. interleave cache and bus access. What would have made more sense would be for the object processor be dropped, so Tom and Jerry could be placed on the same chip with some scratchpad ram to share amongst the processors. You'd have a big cost saving on a single chip system, and you could also move to 1.5mb dual bank ram probably at price parity. 020 probably would've been too expensive, but you needed to go large or go home in the console world, I'd have gone with CD to drop the ROM costs so hopefully over a year projection the upfront hardware cost would amortise with the CD savings. A single chip might have allowed an 020+CD at a $300 launch price rather than $250. The Saturn architecture is a completely bizarre kettle of fish even vs the Jaguar! I can see where the pinch points were for the Jag, but the Saturn looks as though they redesigned the machine twice, and without actually having any input from the AM2 team (Virtua fighter). Certainly from a systems perspective there's a lot of scope for making it more efficient. I kinda of thought the TG-16 was straightforward from a programmer perspective? The custom chips had a few things they could do and that's it. The demos I've seen (pouet) basically seem to use the hardware as it was intended ie. no fancy tricks that you can coax out of it. I'd say the SNES was more crippled by bottlenecks, probably stemming from the initial backwards NES compatibility that never materialised?

to11mtm 7y ago

> EC68020 which would have increased the bus bandwith by 4 times. I thought it was only 2x (16 bit bus on the straight 68k). It did also have a cache though which likely would have helped muchly. Wikipedia does indicate the EC68020 was considered for the Jaguar 2. My gut would be that the EC68020 was considered 'too expensive'; back then 130k extra transistors still meant a few bucks from a cost standpoint, and Atari was already cutting odd corners in a desperate stupor. That bus is terrifyingly bad IMO, I remember developers lamenting it in interviews I've read over the years. One of the -smartest- things Sony did with the Playstation was picking an architecture that was known to be capable of 'pushing graphics' and licensed/reused what they could from SGI's system designs. Probably a big part of why, while still challenging for it's age, it was at least -sane- compared to what was involved on the Saturn (lol, quadratics) or the Jaguar. Nintendo, while late to the 32 bit party, also went with an SGI based architecture, but stuck with ROM carts which still cost them a bit of business. Funny, the TG-16 suffered from many of the same problems as the Jaguar (specifically, questionable CPU bus sizes and quirky hardware design). Alas, it seems nobody from Atari payed attention to that lesson.

alexisread 7y ago
Yes you're right, technically it's 2x bus speed moving 16->32 bits, but I was guestimating the effect of the cache to allow the 020 to stay off the bus ie. interleave cache and bus access. What would have made more sense would be for the object processor be dropped, so Tom and Jerry could be placed on the same chip with some scratchpad ram to share amongst the processors. You'd have a big cost saving on a single chip system, and you could also move to 1.5mb dual bank ram probably at price parity. 020 probably would've been too expensive, but you needed to go large or go home in the console world, I'd have gone with CD to drop the ROM costs so hopefully over a year projection the upfront hardware cost would amortise with the CD savings. A single chip might have allowed an 020+CD at a $300 launch price rather than $250. The Saturn architecture is a completely bizarre kettle of fish even vs the Jaguar! I can see where the pinch points were for the Jag, but the Saturn looks as though they redesigned the machine twice, and without actually having any input from the AM2 team (Virtua fighter). Certainly from a systems perspective there's a lot of scope for making it more efficient. I kinda of thought the TG-16 was straightforward from a programmer perspective? The custom chips had a few things they could do and that's it. The demos I've seen (pouet) basically seem to use the hardware as it was intended ie. no fancy tricks that you can coax out of it. I'd say the SNES was more crippled by bottlenecks, probably stemming from the initial backwards NES compatibility that never materialised?