Were the Atari ST's big for gaming or just the 8 bit line?

[Crazyace]

As I said though, there were practical ways to break the closed box design even after the fact, if Atari Corp was willing to do so. (simplified modules with minimum soldering to clip onto the board and installed at Atari Service centers) But otherwise it depends on how common the feature becomes and how easy it is to use/add to a game. (if it's a standard across the board feature and a significant advantage in several aspects, that's important)

I dont think a closed box was a problem - the ST ( and Amiga ) were succesfull as 'games' computers as much as serious computers, and partial upgrades would have fragmented the market for the ST before it became estabilished.

 

But yes, scrolling would have been a big thing early on, but might have compromised their tight release date... though I think packed pixels vs planar was probably more a general engineering decision than time related. (in the lack of a blitter especially, Packed Pixels made a lot more sense and probably would have made a 160x200 8bpp 256 color mode more practical as well via linear pixel accumulation like GTIA used)

Scrolling shouldn't have made much difference to the development of shifter. 256 colours would have though ( I dont think any GTIA comparisions would be viable - shifter is actually a lot simpler than Antic/GTIA )

Packed pixels vs planar is a minor inconvenience for programmers - but it has no effect on capabilities, so it's not really that important - and for non game use planar is actually better ( monochrome to colour expansion is easy via duplication of bitplanes for example )

 

The 9-bit RGB palette was OK for the time (the MD and PCE pushed that years later and into the early/mid 90s).

I agree - but for a TT in '90 with a VGA connector it should have had a 18bit pallette to match VGA

 

 

And they could have tweaked audio a bit too: there was the YM2203 in 1985 already, but it might have been pricier than what they were willing to spend at the time (would have extended the life a fair bit if they had though) and on the in-house side some simple DAC/PCM mechanism would have been really nice: preferably a good bit more than just a bare 8-bit DAC (though that would at least have advantages over hacking though the YM) and probably more than a small resistor array as well, perhaps a very basic DMA audio set-up like the early Macs had, or conversely a small IC with embedded DAC and simple FIFO buffer for loading PCM maybe even mixing multiple channels to a single 8-10 bit DAC and perhaps some rudimentary volume control as well, plus a timer input to set the sample rate and interrupt generation along with full/empty flags for the buffer. (either polling full/empty flags or triggering loading with interrupts, but cutting down resource significantly compared to loading every single sample manually with the CPU -even using the stack pseudo DMA trick it was heavy on the 68k -though on CPUs like 650x you could get away with interrupt driven PCM due to the very fast interrupt handlers: hence the PCE managing a 7 kHz channel with 5% CPU resource of a 7.16 MHz 65C02)

Sound wasn't as much of an issue as scrolling - and adding any sound h/w would have a far greater impact on the design time and cost

 

The jump in design for a more VGA competitive machine in '89/90 would be nice too, but I think from the beginning (sans other upgrades) they should have offered faster CPU models (12 MHz if 16 MHz wasn't readily available in '85) thus developers could avoid timing sensitive routines and allow games to take advantage of the higher CPU speeds when available.

I'm not sure 12MHz was practical in '85 - 10MHz would have been top in terms of keeping the same memory model. ( 200ns memory compared to 250ns )

 

 

In fact, even without a video upgrade a packed pixel display with 9-bit RGB and 320x200x4-bit (16 color indexed) and 160x200x8-bit (semi-indexed or direct RGB) along with hardware scrolling would already put it close to competitive with VGA and much more competitive with the Amiga. (still lacking the added color capabilities of VGA and possibly some of the added acceleration -iirc VGA added simple copy/line fill operations and such to aid software blits, unless the original ST added that as well)

VGA offered 640x480x16 colours at 18 bits , and 360x480x256 colours via direct register hacks. The Amiga had 640x480ix16 colours and 320x480ix64 colours ( and HAM of course ) - so a real upgrade would be needed for the base ST in '90 - and the TT modes almost had it ( the Falcon modes were better )

 

The DSP of the Falcon was an interesting addition, and especially could have meant some neat possibilities for 3D if pushed for such. (vertex calculations, aid in rasterization, or for pseudo 3D with scaling effects, ray casting, or even affine texture rendering) Was the 56k a significantly cheaper component than a 68881/2? (it seems like a far smaller chip -and package- and for general use could offer a good deal of acceleration that an FPU wouldn't be that useful for -FPU could be more useful as an option and/or for higher end machines specifically and obviously for various workstation uses -which could lead back to the mid 80s MEGA models probably meriting FPU sockets)

I think just having a faster CPU would be much better than a DSP - it may not be as fast, but it's much more general.

[oky2000]

At least in the UK I think a large Problem for Commodore, Atari & maybe even Acorn was that they were focussing there attention on their perceived competition i.e each other when the real threat were the rising dominance of PCs for serious stuff and consoles for gaming. They didn't help by splitting scarce resources to compete in the PC market when what they needed to do is focus on there strengths and weaknesses. In some respects I think Commodore UK towards the end new what needed to be done and it was unfortunate they weren't successful in their buyout proposal.

 

 

Barnie

 

(this is not a dig at you)

 

The PC (and Mac) are actually a bit of a red herring to be honest as far as the 80s go. The problem was simple, Commodore sat on their fat asses with the A1000, did a cheap and nasty rebuild 2 years later called the A500 which added nothing in 1987 to the A500 spec, and the A500plus/A600/A3000 chipset update in 1990 was useless as far as the core market for Amiga went (games and home multimedia machines....whoop de doo you could do 4 colours in 1280x256....hardly useful and dog slow anyway).

 

Atari's problem was they came in with an insufficient design for a 16bit replacement to the C64 (like it or not the money was in a successor to the C64) with worse sound and slower jerky scrolling. And then to add insult to injury they fragmented their userbase (as far as games developers go) with a weak upgrade in the STE which required just as much effort to extract performance out of the chipset as Amiga games developers would need to do, but for a fraction of the Amiga userbase size and so you didn't even get 10 exclusive STE games written to take full advantage of the system.

 

See if you release something that is technically advanced in 1985 (Amiga 1000) or just good enough for some game styles to improve on the C64 ie 3D games like Carrier Command or Starglider and you do nothing to keep ahead then eventually that $5000 286 EGA dinosaur will turn into a 40mhz VGA 386 bargain bucket machine in less than a decade you can't compete with.

 

The key was continued development for C= and Atari, and neither really did enough. The Falcon had a terrible 16bit bus but some sexy custom hardware and off the shelf stuff like DSP, Amiga had a lovely 32bit bus but a kludge of an upgrade to their chipset which was not enough. Falcon and AGA both were weak for 1992/3 for different reasons but just made the ever increasing march of PC development inevitable really.

 

By 1995 with cheap Pentiums producing texture mapped games left right and centre it is game over because there wasn't a single design for 3D custom chipsets in 1994 by either Atari or Commodore.

 

And then they both released flawed overpriced consoles as a last ditch attempt and both died a quick death as Sega/Nintendo wiped the floor with those £300 machines with their own £99 machines with superior quality games (I'd rather shell out £99 to play SF2 on a SNES than shell out £350 to play Fightin Spirit CD32 or Kasumi Ninja on Jaguar thanks).

 

By 1989 ST and Amiga needed full screen parallax, powerful and large hardware sprites, minimum 64 colours on screen, minimum 6 channel Amiga quality sound. By 1994 they both needed machines capable of producing 256 colour (so that's byte per pixel not 8 blood bitplanes to manipulate for EVERY pixel) FPS games identical to Doom technically and running as well as a 40mhz AMD 80386DX.

 

Sad thing is Commodore almost made it for a 2nd chance, the last machine to complete prototype stage was the Amiga 1400. This machine was a 28mhz 020 (no slower than a 28mhz 030 in reality) with 4mb RAM spread out into 2mb chip ram and 2mb fast ram. This machine also had a nice 3 box design like mega ST and had CD drive built in AND had a special planar to chunky pixel custom chip which reducing the number of reads/writes per pixel from 8 to 2 or 3 so 66% speed of a real byte per pixel screen mode speed but none of the incompatibility with Amiga 500 or 1200 games WIN. £499 RRP. They went with CD32 piece of shit instead and went bust...go figure. As for the management buy out, David Pleasance was a big fan of CD32 so they also would have gone bust.

 

Atari also had an 040 based Falcon (32bit chipset?) prototype in a Mega ST style case, but also went with their overly complex Jaguar console which was a flawed design unworkable memory design meaning half the performance is lost and the other half only accessible via the most tortuous programming you can imagine and so promptly people wrote badly written games on it (that looked same as the SNES and played worse) and then gave up, as did the potential buyers.

 

Before you all laugh, think back to how useless Windows 3.11 was on a PC and Mac OS 8 or 9? Multitasking? ha ha no chance. Desktop video? Behave! Creative and friendly reliable OS to use? You mean inbetween blue screen of death!! Musicians dream machine? Only if you are a sap with money to burn!

 

If Apple survived with their crap OS, (pre OS X) and overpriced hardware and only one niche (DTP) the Falcon 040 and Amiga 1400 would have wiped the floor with the Mac LC III/LC4 with better business/creative software,better OS and better games.

 

Back to reality lol, I'm off to price up some i7 machines for a client

[Christos]

Its ok you were not the first person to use the incorrect term, I guess you just copied it

 

Ναι είδες; Καμια φορά μου ξεφευγουν τέτοια λαθάκια. Δεν πειράζει, συμβαίνει

[oky2000]

As I said though, there were practical ways to break the closed box design even after the fact, if Atari Corp was willing to do so. (simplified modules with minimum soldering to clip onto the board and installed at Atari Service centers) But otherwise it depends on how common the feature becomes and how easy it is to use/add to a game. (if it's a standard across the board feature and a significant advantage in several aspects, that's important)

I dont think a closed box was a problem - the ST ( and Amiga ) were succesfull as 'games' computers as much as serious computers, and partial upgrades would have fragmented the market for the ST before it became estabilished.

The problem was lack of development worth a shit for 7 years from Commodore and Atari fracturing their fragile ST userbase into ST and STE and the games development companies not wishing to spend months writing two versions of the same game with radically different code (they didn't even do it for Amiga 500/1000 users which outnumbered STE users 10:1 already!)

 

 

But yes, scrolling would have been a big thing early on, but might have compromised their tight release date... though I think packed pixels vs planar was probably more a general engineering decision than time related. (in the lack of a blitter especially, Packed Pixels made a lot more sense and probably would have made a 160x200 8bpp 256 color mode more practical as well via linear pixel accumulation like GTIA used)

Scrolling shouldn't have made much difference to the development of shifter. 256 colours would have though ( I dont think any GTIA comparisions would be viable - shifter is actually a lot simpler than Antic/GTIA )

Packed pixels vs planar is a minor inconvenience for programmers - but it has no effect on capabilities, so it's not really that important - and for non game use planar is actually better ( monochrome to colour expansion is easy via duplication of bitplanes for example )

For 16 or 32 colour graphics in mid 80s planar is fine and does have some serious advantages for games programming too. All those lovely shadow effects on Extra Half Brite (64 colour mode) Amiga games are only possible due to the 6th bitplane being manipulated.

 

256 colour before 1988/89 is difficult to ask for when Sega only gave you 64/512 in 1990. Total colours is meaningless, it is massively powerful sprite hardware you want (none on ST weak as hell on Amiga) superb multi-layer full screen parallax and increase in sound channels (4 is not enough!). They needed Sharp x68000 type scrolling/parallax/sprites/audio AND a fast blitter with automatic hardware background masking. 128 colour was in a Commodore chipset (Ranger) but relied on incredibly expensive VRAM in 1988 so was never used as it wasn't feasible to put in a replacement for a £500 machine if the ram cost £500 alone in 1988!

 

 

The 9-bit RGB palette was OK for the time (the MD and PCE pushed that years later and into the early/mid 90s).

I agree - but for a TT in '90 with a VGA connector it should have had a 18bit pallette to match VGA

 

MD had 512 colours, PC only 256 colour palette. Both have more colours on screen and ludicrously superior sprite/scrolling/audio hardware to the ST (and Amiga in all but sound)

 

And they could have tweaked audio a bit too: there was the YM2203 in 1985 already, but it might have been pricier than what they were willing to spend at the time (would have extended the life a fair bit if they had though) and on the in-house side some simple DAC/PCM mechanism would have been really nice: preferably a good bit more than just a bare 8-bit DAC (though that would at least have advantages over hacking though the YM) and probably more than a small resistor array as well, perhaps a very basic DMA audio set-up like the early Macs had, or conversely a small IC with embedded DAC and simple FIFO buffer for loading PCM maybe even mixing multiple channels to a single 8-10 bit DAC and perhaps some rudimentary volume control as well, plus a timer input to set the sample rate and interrupt generation along with full/empty flags for the buffer. (either polling full/empty flags or triggering loading with interrupts, but cutting down resource significantly compared to loading every single sample manually with the CPU -even using the stack pseudo DMA trick it was heavy on the 68k -though on CPUs like 650x you could get away with interrupt driven PCM due to the very fast interrupt handlers: hence the PCE managing a 7 kHz channel with 5% CPU resource of a 7.16 MHz 65C02)

Sound wasn't as much of an issue as scrolling - and adding any sound h/w would have a far greater impact on the design time and cost

Not really by 1989 16bit and 8bit DAC costs had plummeted, even putting 3 stereo DACs with no DMA on the ST bus wired to give 6 channel mono or 3 channel stereo would have been fine. But after the STE disaster they didn't want to mess about with the ST and went down to £299 for ST RRP. A ludicrous price for such a machine really...a C128 plus disk drive cost more I think in 1989!

 

PC-Engine only has 5bit sound and the max frequency is 33% that of an Amiga, nothing special at all really and samples are pathetic on it (play SF2 and see)

 

The jump in design for a more VGA competitive machine in '89/90 would be nice too, but I think from the beginning (sans other upgrades) they should have offered faster CPU models (12 MHz if 16 MHz wasn't readily available in '85) thus developers could avoid timing sensitive routines and allow games to take advantage of the higher CPU speeds when available.

I'm not sure 12MHz was practical in '85 - 10MHz would have been top in terms of keeping the same memory model. ( 200ns memory compared to 250ns )

 

Certainly was the option, launch with 8mhz, and then 12mhz + DAC for audio in 86/87. And 16 mhz in 88/89. The Amiga 500 didn't even start selling in appreciable numbers until 1988 anyway.

 

In fact, even without a video upgrade a packed pixel display with 9-bit RGB and 320x200x4-bit (16 color indexed) and 160x200x8-bit (semi-indexed or direct RGB) along with hardware scrolling would already put it close to competitive with VGA and much more competitive with the Amiga. (still lacking the added color capabilities of VGA and possibly some of the added acceleration -iirc VGA added simple copy/line fill operations and such to aid software blits, unless the original ST added that as well)

VGA offered 640x480x16 colours at 18 bits , and 360x480x256 colours via direct register hacks. The Amiga had 640x480ix16 colours and 320x480ix64 colours ( and HAM of course ) - so a real upgrade would be needed for the base ST in '90 - and the TT modes almost had it ( the Falcon modes were better )

 

Amiga is slower than a couch potato running a marathon in 320x256 in 64 colour mode (only 32 of which you can choose, the other 32 being half as bright replicas of the first 32 colours you have selected). Slow slow slowwwww! In 320x512 (480 is for PC aspect ratio of 5:4...Amiga was 4:3 aspect pixels as it was designed for TVs not spreadsheets and DOS screens) in extra half bright 64 colour mode would be slower than a zx81 probably as far as arcade games code goes!

 

The Amiga was effectively stuck with 320x200x32 colours if you wanted to write games, try it and see if you don't believe me. And PC games thanks to the pathetic ISA bus bandwidth all stuck with 320x200x256 before VESA or PCI came about with 486-66mhz or Pentium 60mhz respectively. ISA was a real bottleneck, try playing Galaxians in MAME on a P120 with an ISA card and then a PCI card...you will be lucky to get 10fps out of the ISA VGA card...more like a frame buffer!

 

The DSP of the Falcon was an interesting addition, and especially could have meant some neat possibilities for 3D if pushed for such. (vertex calculations, aid in rasterization, or for pseudo 3D with scaling effects, ray casting, or even affine texture rendering) Was the 56k a significantly cheaper component than a 68881/2? (it seems like a far smaller chip -and package- and for general use could offer a good deal of acceleration that an FPU wouldn't be that useful for -FPU could be more useful as an option and/or for higher end machines specifically and obviously for various workstation uses -which could lead back to the mid 80s MEGA models probably meriting FPU sockets)

I think just having a faster CPU would be much better than a DSP - it may not be as fast, but it's much more general.

 

Maybe a faster CPU, on a 32bit bus and with a 68881 @ something like 33mhz. The DSP is the only thing that worked, and it was intended for sample playback/recording tricks like direct to disc or echo/reverb effects etc NOT as a replacement for the 68881 or as an aid to 3D games. And there is no point putting a 33mhz 68030 on a 16bit bus anyway let alone a 33mhz 68881 FPU. DSP is there because the bus is 16bit and it's the only way to make the Cubase/Steinberg dream machine they wanted.

 

A 32bit design bus version of Falcon with an 040 or faster 030 is what Atari needed (which they cancelled in favour of Jaguar!) and Commodore needed to push with the Amiga 1400 with 28mhz 020 and CD-ROM as standard and chunky to planar hardware conversion, in the same Mega style case as 040 Falcon prototype, which they couldn't do because they wasted money on the CD32 project which bombed...surprise surprise!.

 

A1200 and Falcon looked like bloody STFM and A600 toy cupboard (by 1993) level machines...this did them no favours sitting next to Apple and PC 3 box designs which conveyed a certain amount of professionalism. They both chose not to go with their last prototype home machines in favour of games consoles and promptly went bankrupt!

[Crazyace]

The problem was lack of development worth a shit for 7 years from Commodore and Atari fracturing their fragile ST userbase into ST and STE and the games development companies not wishing to spend months writing two versions of the same game with radically different code (they didn't even do it for Amiga 500/1000 users which outnumbered STE users 10:1 already!)

 

Can't argue with that

 

 

For 16 or 32 colour graphics in mid 80s planar is fine and does have some serious advantages for games programming too. All those lovely shadow effects on Extra Half Brite (64 colour mode) Amiga games are only possible due to the 6th bitplane being manipulated.

 

256 colour before 1988/89 is difficult to ask for when Sega only gave you 64/512 in 1990. Total colours is meaningless, it is massively powerful sprite hardware you want (none on ST weak as hell on Amiga) superb multi-layer full screen parallax and increase in sound channels (4 is not enough!). They needed Sharp x68000 type scrolling/parallax/sprites/audio AND a fast blitter with automatic hardware background masking. 128 colour was in a Commodore chipset (Ranger) but relied on incredibly expensive VRAM in 1988 so was never used as it wasn't feasible to put in a replacement for a £500 machine if the ram cost £500 alone in 1988!

MSX2 offered 256 colours in 1986. - so having a TT-lite in 89-90 as a succesor to the ST instead of the STe would make sense.

Sprites are overrated. A 256 colour screen with a faster processor will make up for the lack of sprites - and 3D titles would perform way better on a faster machine.

 

 

Sound wasn't as much of an issue as scrolling - and adding any sound h/w would have a far greater impact on the design time and cost

Not really by 1989 16bit and 8bit DAC costs had plummeted, even putting 3 stereo DACs with no DMA on the ST bus wired to give 6 channel mono or 3 channel stereo would have been fine. But after the STE disaster they didn't want to mess about with the ST and went down to £299 for ST RRP. A ludicrous price for such a machine really...a C128 plus disk drive cost more I think in 1989!

PC-Engine only has 5bit sound and the max frequency is 33% that of an Amiga, nothing special at all really and samples are pathetic on it (play SF2 and see)

The sound comment is related to the original ST. If there was sound support a 16 bit version of the STe sound would have been the best for a TT in 89-90, and 4/6/8 channel mixing would just be software.

 

I'm not sure 12MHz was practical in '85 - 10MHz would have been top in terms of keeping the same memory model. ( 200ns memory compared to 250ns )

 

Certainly was the option, launch with 8mhz, and then 12mhz + DAC for audio in 86/87. And 16 mhz in 88/89. The Amiga 500 didn't even start selling in appreciable numbers until 1988 anyway.

 

That would be splitting the market again - forget the Amiga , just have a single , more competitive model of the ST - and games would be better

 

 

Amiga is slower than a couch potato running a marathon in 320x256 in 64 colour mode (only 32 of which you can choose, the other 32 being half as bright replicas of the first 32 colours you have selected). Slow slow slowwwww! In 320x512 (480 is for PC aspect ratio of 5:4...Amiga was 4:3 aspect pixels as it was designed for TVs not spreadsheets and DOS screens) in extra half bright 64 colour mode would be slower than a zx81 probably as far as arcade games code goes!

 

The Amiga was effectively stuck with 320x200x32 colours if you wanted to write games, try it and see if you don't believe me. And PC games thanks to the pathetic ISA bus bandwidth all stuck with 320x200x256 before VESA or PCI came about with 486-66mhz or Pentium 60mhz respectively. ISA was a real bottleneck, try playing Galaxians in MAME on a P120 with an ISA card and then a PCI card...you will be lucky to get 10fps out of the ISA VGA card...more like a frame buffer!

In 89 Amiga's were running from slow+fast memory - and I think you must be referring to 640x200x16 being slow - 320x200x64 still left a good number of cpu memory slots free.

The point is that a 'new' Atari machine in 89-90 that would be TT spec would offer performance to compete with both cheap PC's and game consoles.

 

I think just having a faster CPU would be much better than a DSP - it may not be as fast, but it's much more general.

 

Maybe a faster CPU, on a 32bit bus and with a 68881 @ something like 33mhz. The DSP is the only thing that worked, and it was intended for sample playback/recording tricks like direct to disc or echo/reverb effects etc NOT as a replacement for the 68881 or as an aid to 3D games. And there is no point putting a 33mhz 68030 on a 16bit bus anyway let alone a 33mhz 68881 FPU. DSP is there because the bus is 16bit and it's the only way to make the Cubase/Steinberg dream machine they wanted.

 

A 32bit design bus version of Falcon with an 040 or faster 030 is what Atari needed (which they cancelled in favour of Jaguar!) and Commodore needed to push with the Amiga 1400 with 28mhz 020 and CD-ROM as standard and chunky to planar hardware conversion, in the same Mega style case as 040 Falcon prototype, which they couldn't do because they wasted money on the CD32 project which bombed...surprise surprise!.

 

A1200 and Falcon looked like bloody STFM and A600 toy cupboard (by 1993) level machines...this did them no favours sitting next to Apple and PC 3 box designs which conveyed a certain amount of professionalism. They both chose not to go with their last prototype home machines in favour of games consoles and promptly went bankrupt!

 

93 was too late - A new machine should have been there to replace the STFM in 89, with the 'power without the price' philosophy. A 16-20MHz(if earlier the ST had been 10MHz) 68030 would be enough if the price was less than $999

[kool kitty89]

 

 

For '89/90 something between a STe, TT, and MEGA STe would be nice for sure, but a lot of different routes to potentially take.

The DSP of the Falcon was an interesting addition, and especially could have meant some neat possibilities for 3D if pushed for such. (vertex calculations, aid in rasterization, or for pseudo 3D with scaling effects, ray casting, or even affine texture rendering) Was the 56k a significantly cheaper component than a 68881/2? (it seems like a far smaller chip -and package- and for general use could offer a good deal of acceleration that an FPU wouldn't be that useful for -FPU could be more useful as an option and/or for higher end machines specifically and obviously for various workstation uses -which could lead back to the mid 80s MEGA models probably meriting FPU sockets)

 

Both the MSTE and Falcon have an option for an FPU. It's standard on the TT.

I know that, but I meant back in the mid 80s it should have been an option of the original MEGA (if not in '85/86 -if they pushed the MEGA sooner especially) as well as faster CPUs. (again, faster CPUs optional from the start and standard on high-end models -by 1987 the MEGA should have been 16 MHz with optional FPU -that also would have simplified things over using a blitter)

[kool kitty89]

As I said though, there were practical ways to break the closed box design even after the fact, if Atari Corp was willing to do so. (simplified modules with minimum soldering to clip onto the board and installed at Atari Service centers) But otherwise it depends on how common the feature becomes and how easy it is to use/add to a game. (if it's a standard across the board feature and a significant advantage in several aspects, that's important)

I dont think a closed box was a problem - the ST ( and Amiga ) were succesfull as 'games' computers as much as serious computers, and partial upgrades would have fragmented the market for the ST before it became estabilished.

I guess so, but there's other trade-offs too and certain add-ons could have been more feasible than others. (just add an audio in line and you'd very easily have sound expansion carts like the MSX) Sound and RAM expansion were probably more important or at least flexible than other cases, though it's probably a good think the 256 kB version of the ST was canceled.

It's always a factor to cater to the lowest common denominator, but upgrades can be significant depending how they're managed and how standard they become. (the PCE ended up getting the card format being left in the dust in favor of CD only a couple years after the add-on was released and in spite of the cost -it's a matter of context of market conditions and corresponding user and developer response)

Sound is probably the least risky as it's fairly easy to cater to the base standard and then add to it as was usually the case across the board on such cases. (MSX and SMS games supporting the YM2413 always had PSG only support as well, DOS games supporting later/higher-end standards kept Adlib/SB support for a very long time and for quite a while many developers were even supporting Tandy/PCJr modes -not all developers but several notable ones like Sierra)

 

 

Scrolling shouldn't have made much difference to the development of shifter. 256 colours would have though ( I dont think any GTIA comparisions would be viable - shifter is actually a lot simpler than Antic/GTIA )

Packed pixels vs planar is a minor inconvenience for programmers - but it has no effect on capabilities, so it's not really that important - and for non game use planar is actually better ( monochrome to colour expansion is easy via duplication of bitplanes for example )

So you don't think in the case of packed pixels that a 1/2 res mode would be relatively realistic to add given the timeline? (the BBC Micro did that too with 1/2/4-bit per pixel modes, albeit only 8 colors in 4-bit mode due to the 3-bit RGB palette) Using fixed direct RGB probably would have been the simplest set-up palette wise (using a hybrid of variable level RGB using the 16 indexes would be nice though). Would adding support for more bitplanes be easier? (not getting into hardware dual playfield stuff, though that would have been extremely useful -ie 6 bitplanes allowing dual 8 color layers like the Amiga, or 8+7 colors rather as you needed the transparent value for the overlaid plane)

 

And yes, there are workarounds for bitplanes (preshifting objects to align to 8 pixel wide increments to allow single writes for 8 pixels per plane at a time) or simply sticking to choppy 8-pixel stepped movements (like done with character based "software sprites" on some machines or the ZX Spectrum to avoid/reduce clash -being bitmap+attribute based rather than character based), though not so much an issue for vertical movements. (but horizontal movement is highly prevalent to games of the time)

 

And of course if the dot clock had directly aligned with an integer multiple of colorburst (ie 7.16 MHz or 14.32 MHz) you could have reliable color artifacts usable as well, for NTSC at least, PAL would need multiples of 4.43 MHz which is far less feasible. (with the 8/16 MHz dot clock in SDTV res modes that didn't fit either of course, and the point would be moot in RGB anyway)

 

 

The 9-bit RGB palette was OK for the time (the MD and PCE pushed that years later and into the early/mid 90s).

I agree - but for a TT in '90 with a VGA connector it should have had a 18bit pallette to match VGA

Not necessarily the TT exactly (I'm not sure about the TT SHIFTER but the available resolutions seem inflexible -is there a 320x240 256 color mode? -and is it using packed or planar pixels?), but something in that area with a lower cost range as well (probably the baseline unit would be 1 MB, 16 MHz 68k, and standard TT audio/video). 12-bit RGB would be acceptable as a minimum, 15-bit RGB would be fine against VGA. (even later with SVGA stuff, tons cater more to plain highcolor rendering, though sometimes bumping up to 6-5-5 RGB rather than 5-5-5 -18 bit would of course facilitate the former but 15-bit plain highcolor rendering is very close to that in any case, so even if a later successor to the TT more in the falcon's range stuck to 15-bit RGB that wouldn't be too bad)

By 1990, something more like the falcon's audio would be really nice, even an 8-bit version (ie limited to 8-bit PCM -which would be common due to RAM limits anyway): does the Falcon's audio allow variable sample rates more like the Amiga or steps like the STe? (simply having 4-8 STe channels would be OK, but having to software scale for notes added a bit of overhead -for fixed pitch playback the high sample rate was great, especially for interleave based mixing great for sfx and percussion samples and beat loops: ie 2 25 kHz channels, 3 ~16.7 kHz, 4 12.5 kHz, 6 ~8 kHz, etc interleaved to 50 kHz vs the Amiga stuck at ~28 kHz normally -and if you were going to have to scale instruments anyway, that would be a simple route to software channels in general but of course limiting panning to the hardware channel basis -so you could have 4 25 kHz channels, 6 ~16 kHz, etc -circuitry to offer interleaving in hardware as such would probably be a simple way to add more channels at minimal cost as well -no added DACs, no hardware adding, no hardware upsampling, just interleaving with samples at integer divisions of the playback rate)

 

If there'd been any standard audio upgrade prior to that, it would be standardized with the new revision, otherwise the YM2203 would still be a nice option and with that and even the plain STe sound it would be pretty decent for 1990. (compared to the Sound Blaster 2.0 or even Pro you had fewer but more powerful FM channels with the PSG to still back that up, plus 2 PCM channels sampling to 50 kHz and with individual stereo toggling vs 44 kHz Mono on the 2.0/Pro, and 22 kHz fixed stereo of the Pro, not until the 1992 SB16 did you get 44 kHz 16-bit stereo -the PAS was in 1991 though and had some other advanced features and I think employed the same CODEC DAC/ADC chip as the Falcon)

 

With waiting until 1990 for the BLITTER and standardizing it, perhaps it could have been 16 MHz from the start and/or have other added features (hardware masking like the Amiga perhaps, and/or buffering for generally higher performance and use of fast page accesses, especially if working on 64-bits like -and more optimization for packed pixels specifically, if not line buffers for efficient fast page use within a single RAM bank, phrase buffers would be nice -and if they added separate main and video banks to allow separate source and destination it would allow more fast page use without buffering, not even separate buses like the Amiga's fast+chip RAM separation but just separate banks to reduce page breaks -phrase buffers and dual banks could be very useful though and much simpler than line buffers -which would have meant more R&D and silicon- and not the cost of actual separate buses like the Amiga's fastram)

 

Sound wasn't as much of an issue as scrolling - and adding any sound h/w would have a far greater impact on the design time and cost

Yes, unless they went for pure off the shelf options (and again, a simple mono audio input on the car slot would have been really useful for an audio expansion cart). But yeah, even simpler PCM acceleration would add to development time... maybe just a bare 8-bit DAC (resistors on the PCB or 10-12 pin DIP) at least to allow playback without hacking the YM and allowing simultaneous music with careful programming. (or even a single MOD channel alongside the PSG by varying the sample rate -ie no scaling)

The YM2203 very well may have been unattractively expensive back in '85 (it was brand new alongside the YM2151, though it was quickly adopted in the 1985 updated models of the Z80 based PC-8801). The board space used would have been almost identical, it had the same I/O hardware and 40 pin DIP (but needed an external 8-pin serial DAC), it also added 2 interval timers (and IRQ), so that might have been a consideration to displace other off the shelf chips on the board. (with the parallel ports and timer/interrupts, the only thing left to replace would be a serial interface and you could drop the 68901 entirely)

 

But other than the AY8910, Yamaha chips (YM2151 definitely wouldn't be an option), and even simpler SN76489 there wasn't really anything left for off the shelf audio besides bare DACs, Amy was apparently a bust (adding significantly to board space even if it was functional, so not good for low-end models or a standard feature early on -maybe a cartridge), and POKEY might have been an interesting option depending on how tough it was to interface in the system. (much more so if the I/O functionality could be utilized, at least keyboard plus interval timers -you'd need dual POKEYs to displace the dual hitachi scanners though, but maybe even serial I/O depending how much SIO could be tweaked usefully)

But maybe RBP was too far along for any of that to be attractive in mid 1984, and the YM2203 didn't actually appear until 1985, so with the ST being developed in 1984 by and large that would have been a deal breaker as well. (still an attractive option for the successor to the ST though, especially if no audio add-ons had emerged in the interim -and the more advanced YM2608 would probably be unattractive compared to simpler DMA audio added on top of the YM2203)

 

 

The jump in design for a more VGA competitive machine in '89/90 would be nice too, but I think from the beginning (sans other upgrades) they should have offered faster CPU models (12 MHz if 16 MHz wasn't readily available in '85) thus developers could avoid timing sensitive routines and allow games to take advantage of the higher CPU speeds when available.

I'm not sure 12MHz was practical in '85 - 10MHz would have been top in terms of keeping the same memory model. ( 200ns memory compared to 250ns )

It would only have been for the higher end models initially though, so faster RAM could be possible. But with fast page accesses you wouldn't even need faster memory to benefit (but with some wait states from page breaks), unless FPM DRAM was too expensive at the time.

Even with plain 250 ns random accesses, doesn't the 68k only need the data on the bus by the end of the 3 cycle (so long as the DMA controller made sure that occurred or generated waits), so 250 ns random accesses should have been fine for a 12 MHz 68k, though you'd lose the consistent 50% wait-less DMA sharing of the 8 MHz ST and Amiga. (more wait states for bus sharing, though unlike the Amiga you have far less contending for DMA -with FDD and anything on ASCI at idle the SHIFTER and 68k would pretty much have exclusive bus use) Unless such waits would knock performance so close to 8 MHz fully interleaved (even with only the SHIFTER contending DMA) that it would be pointless. (not sure how much bus time the SHIFTER uses, but I doubt it's enough to put that much hurt on the 68k)

 

For pure random accesses I'm not even sure 200 ns would be feasible for 1985. (random access times not having a linear relationship with faster CAS times, hence the Amiga's 150 ns CAS DRAM giving 280 ns random accesses but the Jaguar's 75 ns CAS was still only 175 ns for random accesses, and I'm not sure of the exact curve but it would seem like you'd need better than 120 ns CAS to manage 200 ns random accesses -perhaps 100 ns CAS)

12 MHz would definitely be impossible with a 50/50 split in DRAM as such as you'd need 166 ns random accesses, and even in 1993 the DRAM in the Jaguar couldn't manage that. (so going upwards of 10 MHz you'd definitely have to switch to a different DMA set-up more like what the Lynx does for example, especially with fat page accesses -though the 68k itself might not need fast page accesses in any case just as the 65C02 in the lynx doesn't but is maxing out the random access speed -the Jag's 68k wouldn't even be maxing out the random access speed either, but still too fast to even allow 1 waitless random access interleaved between accesses -you'd need to knock the 68k down to 11.4 MHz to allow that in the Jag)

 

Maybe that's the reason neither CBM nor Atari boosted CPU speeds as such until later (differing DMA management), though 7/8 MHz modes would have solved any such compatibility problems in any case, and with fastram it didn't matter for the Amiga. (and simply force the lower clock speed when the CPU accessed chipram)

 

Going with 8 MHz and allowing the DMA set-up and price point they had was probably smart in any case, scrolling (for the majority of popular genres) would have been more important. (even the CoCo II added hardware V/H scrolling just a year later and as a lower-end machine using 256x192 16-color packed pixel graphics and a 1.79 MHz 6809 -added interval timers to help with use of the DAC more too, still no sound chip though and only 6-bit RGB)

 

 

 

The DSP of the Falcon was an interesting addition, and especially could have meant some neat possibilities for 3D if pushed for such. (vertex calculations, aid in rasterization, or for pseudo 3D with scaling effects, ray casting, or even affine texture rendering) Was the 56k a significantly cheaper component than a 68881/2? (it seems like a far smaller chip -and package- and for general use could offer a good deal of acceleration that an FPU wouldn't be that useful for -FPU could be more useful as an option and/or for higher end machines specifically and obviously for various workstation uses -which could lead back to the mid 80s MEGA models probably meriting FPU sockets)

I think just having a faster CPU would be much better than a DSP - it may not be as fast, but it's much more general.

It would depend on the cost for sure, and I forgot about the dedicated DSP SRAM chips (that would significantly add to cost beyond the small DSP chip), and of course discounting any hypothetical use of any of Flare's chipsets (from the Flare 1/Slipstream or the Jaguar -though the latter wouldn't be until '93/94 anyway). The Flare1 DSP might have been interesting, or the fast ALU for that matter (embedded 4x4-bit bit slice derived multiplication unit), of course depending on resulting licensing or royalties (Flare was more or less sitting on the older chips though and the main problem might have been the little endian emphasis of the intended CPUs -Z80/8088-), and it's even stranger that they didn't seem to consider the Slipstream as an alternative to the Panther for the years leading up to the Jag, but that's another topic.

Hmm, the Pather OPL might have been an interesting inclusion to the ST line, but probably wouldn't mesh very well cost wise on top of the SHIFTER and due to the requisite 32-bit SRAM. (aside from games it could have made for some super fast windows in GEM though... and with zooming ... OTOH a more conventional blitter would be far more realistic and friendly to existing developers -let alone a blitter adding affine rendering in hardware like the MCD did in 1991, something like that would have been far more flexible for a DRAM based game console in general as well as computer -I think the Jaguar blitter texture mapping feature worked much the same but with high/truecolor support -I think the MCD also used a buffer to read 4 4-bit pixels per single 16-bit read/write though it was also only 12.5 MHz)

 

 

Hmm, that's another thing to think on in general though: efficient parallel development of components to enhance the ST line AND be useful in a game console. (doing that might have resulted in something more realistic for 1990 than the Panther )

Edited November 25, 2010 by kool kitty89

[kool kitty89]

The PC (and Mac) are actually a bit of a red herring to be honest as far as the 80s go. The problem was simple, Commodore sat on their fat asses with the A1000, did a cheap and nasty rebuild 2 years later called the A500 which added nothing in 1987 to the A500 spec, and the A500plus/A600/A3000 chipset update in 1990 was useless as far as the core market for Amiga went (games and home multimedia machines....whoop de doo you could do 4 colours in 1280x256....hardly useful and dog slow anyway).

Yes, in Europe, but not in the US. PCs were rapidly expanding in market share even before clone appeared and exceeded the C64 in the mid 80s in overall sales in the US, clones pushed that more and more as well.

The nature of the computer market was different though: the C64 took over a short term niche of consoles during the 1983-85 period with the crash in North America, but even by '85 that was shifting and by '86 the games market was heavily shifting towards consoles again (as Japan was already favoring similarly). The NES took over the game market in gerneral and the relative console/computer markets shifted to more like the pre-crash period and more like in Japan (niche gaming computers, popular gaming-poor hardware less cost effective business computers with strong game support due to sheer market share -PC8801 and PC9801- and all mass market gaming dominated by consoles).

 

Maybe if Amiga and/or Atari opened up licensing it could have put more of a dent in things, but PCs were really a force to be reckoned with and gaming/multimedia stuff was more niche in general. (they'd need powerful and successful marketing to get established as PC competitive business machines -the lack of a desktop form factor ST at launch hurt it there and the keyboard probably did as well, but marketing was key -having a PC compatible file format could have been a point to stress)

The Mac was niche too, and the Apple II was still outselling it for a chunk of the mid 80s. If it wasn't IBM, it probably would have been the Apple II to push in as the market standard with clones proliferating and 3rd party enhancements. (they could coast along on 65C02/65816s up to the early 90s when either a more powerful 650x successor would be needed or a total architectural shift would be needed -maybe to ARM due to the low coast and recent opening to mass market sales of their chips in the early 90s)

 

 

In Europe it could have been a different story though and in Japan it might have been as well if NEC's PC9801 did't offer a rather smooth transition to DOS PCs. (they were very PC lien and all x86 -even late PC8801s were x86 using NEC's Z80 compatible 8088/86 derivatives). Still, to fully combat PCs in the long run, a more open licensed/clone standard would need to be established even in Europe. (the ST was moving that direction at one point -at least with unlicensed clones- but interest in that dropped off before it could reach critical mass -as with the Apple II with the PC coming in before apple II clones could go critical)

 

See if you release something that is technically advanced in 1985 (Amiga 1000) or just good enough for some game styles to improve on the C64 ie 3D games like Carrier Command or Starglider and you do nothing to keep ahead then eventually that $5000 286 EGA dinosaur will turn into a 40mhz VGA 386 bargain bucket machine in less than a decade you can't compete with.

Yeah, but in either case without smart planning they wouldn't be able to compete with PCs any better than they did by that point (early 90s). Without broad licensed production the only possibility of ever doing that would be getting enough sales early on to expand to the point where economies of scale would remain competitive with PC clone hardware. (licensed production would make that much more realistic)

 

The key was continued development for C= and Atari, and neither really did enough. The Falcon had a terrible 16bit bus but some sexy custom hardware and off the shelf stuff like DSP, Amiga had a lovely 32bit bus but a kludge of an upgrade to their chipset which was not enough. Falcon and AGA both were weak for 1992/3 for different reasons but just made the ever increasing march of PC development inevitable really.

16-bit bus was almost certainly a cost saving measure, though they probably could have dropped some other features and gone 32-bit as a compromise.

A 68EC020 would be a cost savings as well, but there's more trade-offs there too. (last time this came up it was explained why a 16 MHz 020 on a 32-bit bus would be worse than a 16 MHz 030 on a 16-bit bus, I think JamesD was the one to bring that up)

 

By 1995 with cheap Pentiums producing texture mapped games left right and centre it is game over because there wasn't a single design for 3D custom chipsets in 1994 by either Atari or Commodore.

Not left right and center, but a handful of texture mapped games, several of which were ray casters and tus using a very different technique than texture rendering on polygons (columns vs lines -hence why the PSX version of doom had a totally new polygon renderer rather than forcing slow CPU ray casting) you had a few games like Wing Commander IV using polygonal 3D with textures but those were high-end games and even in '95 pentiums weren't cheap. (a Cyrix or AMD 5x86 might be a more realistic option)

3D costom chipsets would still be a good way off (and again, save for the Jaguar, worsthless for Doom and Duke 3D), but remember the falcon had the DSP to use which could have helped a great deal with 3D rendering and wouldn't be limited to polygons either, but also accelerating ray-casting. (the Jaguar's GPU was useful in the same way, hence the performance of Doom on the Jag using the original ray casting renderer with the GPU RISC -the only thing the blitter did was shade, texture mapping of the Jaguar/Saturn/PSX/3DO was worthless for Doom)

 

It's not like they had a crystal ball that they could guess where 3D was going. It wasn't until 1994 that it even became reasonably clear that texture mapped polygonal 3D was going to be the dominant method used (arcades mainly pointing to it, on the PC it wasn't until 1996 that it was definitive -in part due to 3D accelerators pushing that way) and it takes time to develop such chipsets. The only other options were faster CPUs and DSPs general purpose enough to cover all bases, anything else would be up to chance. Hell, it could have ended rather badly even IF they used what the arcades were demonstrating as 1/2 of that was using quadrilaterals (all of Sega's 3D which did that and got away with good performance by using pure floating point coprocessing against Namco's fixed point DSPs -which is also what consoles and computers generally used for 3D and was a mis-match on the Saturn and 3DO with quads+fixed point math -quake was the first to push FPUs as required in 1996 but was all triangle based).

NVidia DID go the quad route in 1995 with one of the first 3D accelerators on the market in the NV-1 chipset used with Diamond's EDGE 3D card, but that would never gain favors and Nvidia later cancelled the NV-2 successor to that. The 2 other 1995 entries to the industry were triangle based with the S3 ViRGE chipset used in Diamon's Stealth 3D cards (notorious for poor 3D performance later on with anything beyond bare unfiltered PSX like rendering being slower than software rendering) and the first RAGE card from ATi which would have a legacy of very notable 3D/2D accelerators all featuring MPEG acceleration (in 1995 MPEG-1, the RAGE 2 and Pro added MPEG-2 acceleration later on). The high-end VooDoo add-on card wasn't released until 1996.

From a practical standpoint, triangles make a lot more sense (especially in the context of fixed point math), and that was the standard for software renderers and 3D workstations, but as the arcade/console/accelerator markets show, it was hardly clear for hardware designers of the time. And while triangles were fairly clear over quads (at least without FPUs), you still had other rendering techniques like ray-casting based height maps prevalent on software rendered systems.

They could have simply tossed in a fast RISC CPU as a coprocessor (which did later happen with PPC accelerators), but that would be costly even for low-cost optimized architectures like ARM or Hitachi's Super H. (off the shelf DSPs or DSP like chips -TI had some graphics oriented coprocessors- could be more efficient but still relatively costly, perhaps worth it though -an in-house solution would be preferable and a custom DSP like coprocessor would be the most foolproof in the early 90s -a combination of such a coprocessor and a blitter adding affine rendering -for scaling, rotation, and texture mapping- would be nice and the MCD added such a blitter back in '91, but that would also sort of be up to chance though the scaling/rotation/warping would be attractive features feasible in 1990/91)

 

Remember Atari started with the Jaguar chipset back in 1989 and it took 3 years to complete: the design points made back in '89/90 had to be made with a good deal of guesswork and Flare got some things right and others wrong. Luckily they made it extremely cost effective and flexible enough to apply to a broad number of purposes rather well. (lack of hardware polygons meant triangles or quads would be up to the programmer and the powerful GPU core provided much needed resource for rasterization, 3D math, and the flexibility of doing other rendering like ray-casting and height maps which were still popular on the PC. (and ma have continued to be popular if 3D accelerators and consoles hadn't pushed for pure polygons so quickly) Flare actually hadn't taken ray casting into account as a prominent concern with more focus on high-end 2D and next generation polygons (they'd always been focused on polygons from the beginning with their 1986 start of Flare 1 design -and I think the DSP from the flare/slipstream chipset may have ended up in the Super FX ASIC perhaps along with the flare ALU -Ben Cheese designed the super FX just after leaving Flare and he was the designer of the DSP)

With a few tweaks to address the bugs the Jag chipset (mainly TOM) would have been a fairly competitive mass market 3D accelerator, and even with the bugs (namely the MMU bug) it could have been significant (the barrier to mass market being trouble with compiled code necessary for high-level API use).

Of course by then the ST market was more or less dead... but hypothetically, if they'd launched a nice VGA competitive ST successor back in '90 (a "Super ST") and the line was still strong in Europe (at least), they could have pushed the Jag chipset into a successor to the Super ST though in that context they probably would have had the funding and time to fix all the bugs in the Jag and launch it in a realistic manner in 1994 rather than rushed in general. (or again, had they focused on efficient parallel development of many components that would be useful for both the ST line AND newer home consoles, they might have had something worthwhile rather than the Panther back in '89/90 and been better off on both fronts)

The Jag chipset would be a big leap, but probably practical to integrate if it was jumping from the 1990 machine and not a falcon-like machine. (and meshing much better with minimal redundant hardware)

 

I think the decline may have largely tied into the shift in management with Sam taking over, but there were some problems while Jack was there of course. (wgungfu explicitly stated a while back that he couldn't picture Jack ever just giving up on the computer business like that and dropping to a single product company -and the TT certainly didn't scream "power without the price" but then again the Transputer was there during the Jack years too iirc)

 

And then they both released flawed overpriced consoles as a last ditch attempt and both died a quick death as Sega/Nintendo wiped the floor with those £300 machines with their own £99 machines with superior quality games (I'd rather shell out £99 to play SF2 on a SNES than shell out £350 to play Fightin Spirit CD32 or Kasumi Ninja on Jaguar thanks).

Let's not get into another jag argument... The design was extremely impressive for the time and better than anyone could reasonably have expected for CBM or Atari to have in 1993. Under better circumstances it could have been a monster and gone hand in hand with the ST line as mentioned above.

The Jag was also far cheaper than the CD32 and they could have sold it at tighter prices had they not been so stuck with funding. One problem was sheer limited supply and not enough emphasis on Europe (the market they had the most chance in). The CD32 was a pretty good deal with the CD drive for the time but CBM definitely should have pushed a console earlier if ever and waited longer for CD ('95/96 is when it became more affordable on the mass market). A 1990 Amiga based cart console could have been very significant though.

 

Really it's the same thing as with the Amiga early on getting ST ports without taking advantage of the hardware. Some things are purely being lazy, not the console being difficult to work with (and compared to previous consoles it was not really difficult to work with until you tried pushing advanced 3D -otherwise the 68k bus sharing was OK and so was high-level programming for the CPU -C compilers for 68k were common and you didn't need to touch the GPU for most 2D stuff -it would help with warping texture effects though).

The PlayStation sure didn't help that laziness and the PS2 was a massive shock to developers with FAR, FAR more difficult problems and bare bones development tools to work through than the Jaguar or Saturn (or PS3), but they found a way to suck it up and push ahead due to Sony's market position and hype. (many developers ended up finding their own workarounds and developing their own tools and libraries for the system... the same thing Carmak did on the Jaguar, but he was an exception to those who weren't lazy if not pushed -and developers were obviously pushed to develop for the PS2 whether it was easy or not)

 

The architecture was sound but with some tweaks to work though if they really wanted to push 3D stuff, but far less so for amazing 2D performance beyond the arcades of the time and not difficult to program for that but simply lacking in strong developer interest and 1st party software investment capital. Being off the market for a generation hurt things and the lack of overall funding made that far worse and just like the 7800 days they were a bit stuck in getting any Japanese support or licenses for some popular arcade games though not quite for the same reasons. (lack of funding more so and less of the Nintendo blockade of the 80s)

 

The low-cost configuration with the 68k made shared bus usage a bit tight but it was still far more efficient than bus sharing on pretty much any previous console or home computer (high degree of buffering and fast page use). In hindsight they probably should have made different trade-offs though. (like dropping TOM entirely in favor of simple DMA audio more like the Falcon and a faster 32-bit CPU with a cache or maybe just the 68k on a separate bus shared with audio and I/O)

 

In the ST incarnation of the Jag chipset you'd probably have it configured with dedicated video DRAM (perhaps 1-2 MB initially expandable to more) with a separate main bus. (again probably in 1994)

Hell, that could have made the ST attractive as a multimedia/3D workstation as well, especially if they'd pushed for genlock already with the 1990 update. A bug fixed Jaguar supercharged Atari computer could give the video toaster a run for its money too. (which was falling out of favor by 1994 anyway) Not even need for high-end 68k CPUs with that much acceleration and unlike contemporary PC accelerators the GPU could handle the 3D math and not offload that on the CPU. (or share tasks more evenly)

 

By 1989 ST and Amiga needed full screen parallax, powerful and large hardware sprites, minimum 64 colours on screen, minimum 6 channel Amiga quality sound. By 1994 they both needed machines capable of producing 256 colour (so that's byte per pixel not 8 blood bitplanes to manipulate for EVERY pixel) FPS games identical to Doom technically and running as well as a 40mhz AMD 80386DX.

No, no hardware sprites ever, stick with blitters but beef them up. Sprites were not the future and all consoles and they died with the 16-bit machines: the PSX and Saturn used blitters (labeled GPU or VDP) to drive their 2D and 3D and the Jaguar's object processor was a bit different but not like normal hardware sprites either. Faster blitters on wider buses and buffering for fast page accesses was the way to go from the early 90s onward.

 

And yeah, chained bitplanes (or some other form of packed to planar conversion) would have been needed. The CD32 got it with Akiko chip to do just that and you had the blitter to help in either case (ie CPU render as 8-bit chunky and blitter convert to planar, especially useful with fast RAM -and in that sense software rendering on an AGA amiga wouldn't be much different than a VGA PC of similar CPU power regardless of Akiko) Having chunky to planar in hardware from the release of AGA along with a much more powerful blitter and beefed up audio (at least doubled paula) would have been huge. (if the blitter was fast enough and added affine rendering like the MCD, you'd have a nice route to texture mapped 3D as well as scaling and rotation even with a A1200 class CPU and fast RAM -no Doom though, again that's a different kind of rendering -maybe a polygonal derivative of Doom- unless they added a DSP coprocessor as well thus the blitter would handle scaled objects and 2D stuff while the DSP would do the height mapping -and also accelerate 3D considerably for polygonal stuff) You'd want chipram to have 32-bit if not 64-bit modes though. (16-bit EDO or SDRAM could be fast enough but very expensive, wider FPM DRAM buses would be preferable)

 

 

Sad thing is Commodore almost made it for a 2nd chance, the last machine to complete prototype stage was the Amiga 1400. This machine was a 28mhz 020 (no slower than a 28mhz 030 in reality) with 4mb RAM spread out into 2mb chip ram and 2mb fast ram. This machine also had a nice 3 box design like mega ST and had CD drive built in AND had a special planar to chunky pixel custom chip which reducing the number of reads/writes per pixel from 8 to 2 or 3 so 66% speed of a real byte per pixel screen mode speed but none of the incompatibility with Amiga 500 or 1200 games WIN. £499 RRP. They went with CD32 piece of shit instead and went bust...go figure. As for the management buy out, David Pleasance was a big fan of CD32 so they also would have gone bust.

Sure but that would have been far more expensive for sure. (a 33 MHz 68020 would be a big jump in cost over a 16.7 MHz rated 68EC020 and probably not much different from a 33 MHz rated 68030 or at least 68EC030, 68EC020s only came in 16.7 and 25 MHz versions and the latter would still have been fairly expensive for a mass market machine in 1992)

AGA should have come earlier or the jump should have been much bigger by 1992. Better blitter full packed pixel support, highcolor, onboard chipRAM and fastRAM. (1 MB fast+chip split would have offered much better performance)

They also should have been more flexible about the CPU clock speed as with the A3000, have a lower end 16 MHz 68EC020 model and an higher end 25 MHz 68EC020 with professional box form factor machines offering 030s and 040s. (so not just the corresponding A4000 but something in-between as well)

 

And even without anything better than AGA (especially with Akiko) there wasn't enough middleground from the A1200 to the A4000, they needed higher end console form factor machines and lower end desktops as well. (like a counterpart to the 4000 more like the 3000 but with AGA and the FPU being optional) Atari screwed up that way with the TT as well and the Falcon: TT too high-end with no low-end alternatives, and no higher-end Falcon models.

 

Atari also had an 040 based Falcon (32bit chipset?) prototype in a Mega ST style case, but also went with their overly complex Jaguar console which was a flawed design unworkable memory design meaning half the performance is lost and the other half only accessible via the most tortuous programming you can imagine and so promptly people wrote badly written games on it (that looked same as the SNES and played worse) and then gave up, as did the potential buyers.

;P Those are the sorts of trade-offs that all designs have to make to have realistic cost/performance. It wasn't a flawed memory design though, and the MMU bug had nothing to do with the bus sharing problem (it only prevented the GPU from running code from DRAM) and those flaws were natural to occur with a lack of funding.

 

It was Sam's management that likely hurt both things, especially if the Falcon/ST line was still viable to push ahead with in '93/94 let alone the Lynx (which also seems to have gotten pulled back with the shift to the Jaguar), but that's not a problem with the Jaguar but Atari management for a long time coming. The ST, Jaguar, Lynx and Atari as a whole would have been much better off with better managment from 1989 onward. (not only had Jack left, but so had Michael Katz -who'd done an amazing job with the game/entertainment division given the funding limits in 1985-1988 be he left just before the Lynx, Panther, and Flare came into play and at the same time as Jack retired)

1989/1990 was go time for Atari to push ahead and they screwed up... by 1991 they were pretty much screwed no matter what without a miracle. With the Jaguar they hung on longer than they may have otherwise but ended up pulling out in '96. (the company may have gone bankrupt in '93 or '94 otherwise though)

 

Before you all laugh, think back to how useless Windows 3.11 was on a PC and Mac OS 8 or 9? Multitasking? ha ha no chance. Desktop video? Behave! Creative and friendly reliable OS to use? You mean inbetween blue screen of death!! Musicians dream machine? Only if you are a sap with money to burn!

Yes, but you forget other superior options that also got left behind just as the ST and Amiga. GEM would have been very nice on the PC if not for Apple's lawsuit (not getting into the stupid decision DR's attorney made by blocking the CP/M deal with IBM years earlier... DR with IBM, GEM on the PC with IBM backing them up and scaring apple off, etc, etc). You had OS/2 as a very capable option on the PC with Warp especially later on still superior to Win9x (at least early on), but IBM screwed it up as they did with the PCJr and PS/2 lines of computers. (and from IBM's perspective, they also screwed up with the PC design in the first place, but that's another story )

Edited November 25, 2010 by kool kitty89

[The Usotsuki]

I shall add that the PC98 ran MS-DOS and later Win9x.

[kool kitty89]

For 16 or 32 colour graphics in mid 80s planar is fine and does have some serious advantages for games programming too. All those lovely shadow effects on Extra Half Brite (64 colour mode) Amiga games are only possible due to the 6th bitplane being manipulated.

Not quite though as you could do even more flexible software shading effects with a 256 color packed pixel display rather easily. (the simplest being 16 banks of 16 colors for each shade level or fewer shades with more colors, but you could have more complex indexing taking human color perception into account with a bit more redundant use of things but that would take more resource) That's how you get 256 color shading effects in games like doom. (8 light levels)

And of course if you wanted to use shadow colors as normal colors in the Amiga (ie for a 62 color/shade display) you'd loose that shading effect too. You could design a blitter to do that sort of index based shading in hardware too. (and far more as happened with highcolor acceleration, alpha blending, etc -the SNES did actual highcolor averaging to 15-bit RGB for its translucency and that had nothing to do with its use of planar pixels)

 

The Mega Drive used packed pixels and could do the very same thing with shadow as halfbright does, but that's due to the use of multiple hardware layers (2 packed pixel BGs and sprites all with the ability to use shadow and for sprites you can also hilight and double the colors in both cases extending into 12-bit RGB colorspace beyond the native 9-bit RGB unlike the Amiga which can only use shadow within 12-bit RGB so colors have to be chosen even more carefully than on the MD to not be redundant). But for a bitmap based system using packed pixels, a shading mechanism using indexing would be far more efficient (in software or hardware). On the ST if you had a 256 color mode or a shading bitplane, that would be limited by the 9-bit RGB and without the MD's extensions to higher color depth dedicated to shading. (using Crazyace's suggestion of 16 indexed colors -same amount of CRAM- with the remaining 4 bits controlling RGB levels would be extremely useful in that sense though as you'd immediately have 2 shades of 16 colors, though a bit more consideration to use more shades than that -probably tied to the human sensitivity to green so one shade bumping up green intensity then then next red and blue, then green again, or not using shading for a full 256 colors -using direct 3-3-2 RGB could work OK too for that but would have some trade-offs against the indexed method -neither would be as flexible as indexed 256 colors from higher depth RGB -like 12, 15, or 18-bit -with VGA you could easily have any palette of 64 colors possible on the amiga with 4 exact shades thereof -or 8 shades of any 32 colors possible on the ST)

 

Packed pixels are also far better for compression than planar, though planar itself can be used as a rudimentary form of lossy compression by varying color depth. (the PCE and SNES were at a significant disadvantage to the MD because of that once real lossless compression started being used -to the point of some PCE and SNES games using chunky to planar conversion for better compression -the SNES's SA-1 chip did that and decompression in hardware)

 

 

256 colour before 1988/89 is difficult to ask for when Sega only gave you 64/512 in 1990. Total colours is meaningless, it is massively powerful sprite hardware you want (none on ST weak as hell on Amiga) superb multi-layer full screen parallax and increase in sound channels (4 is not enough!). They needed Sharp x68000 type scrolling/parallax/sprites/audio AND a fast blitter with automatic hardware background masking. 128 colour was in a Commodore chipset (Ranger) but relied on incredibly expensive VRAM in 1988 so was never used as it wasn't feasible to put in a replacement for a £500 machine if the ram cost £500 alone in 1988!

Out of context right there. The MegaDrive was 1988 hardware.

Remember back in 1987 NEC had the PCE giving 512 colors on-screen in the same sense Sega gave 64 and the SNES 256. (and the same way the C64 gave 16 colors or the NES with "32 colors" or SMS with "32 colors") In no case was it a bitmap and all using characters and sprites with 15 color subpalettes, so not apples to apples as with the ST. (technically speaking it's 2x 16x 15 color palettes plus one solid BG color for the PCE, 2x 8x 15-color palettes on the SNES -aside from the nearly unused 256 palettized mode- and 4x 15 color on the MD)

All of that disregards scanline interrupts to re-load colors (which the Amiga and ST can both do), but also the SNES's alpha effects and the MD's as well.

If you're going to consider the Amiga's halfbright, then consider the MD's hilight and shadow (actually used in notable cases unlike the SNES's 256 colors -more like the SNES's translucency). It had shadow and hilight used as standard hardware features and no more a trick than halfbright thus allowing 192 colors on-screen in 1988 and not 64, though in a practical sense just as it's really 61 colors (and distributed among different tiles) max it's technically only 183 colors max using hilight and shadow.

But again, that's not a practical system for a bitmap based console as such unless you have multiple hardware layers (the amiga had the ability to separate bitplanes in dual playfield mode as such), lots of trade-offs. And of course shadow doesn't even work on sprites on the Amiga, but it most definitely does on the MD and hilight can only be used by sprites (but on sprites or BGs -hilight enabled pixels can only be on sprites but will hilight any sprite or BG pixel they overlay with).

 

Technically speaking you could do a pseudo shadow/halfbright effect on the ST as it is by dropping to 3 bitplanes and using the 4th to toggle bright/dark shades (so 8 colors at 2 shades rather than shades of 31 or 15 or 7 colors or less depending how many Amiga bitplanes are enabled, using dual playfield you'd have 1 8 color layer and 1 7 color layer and the ability to shade either). And that would be easier to do with bitplanes in many respects than packed pixels as you could treat the shading overlay separately (moot if you're doing shading effects as in Doom, but useful for shadows or some other things in 2D especially) And you could attach that 4th plane to some of the objects to have a shaded translucent portion of them. But such effects seem to have been rather uncommon on the ST, perhaps due to 8 colors being felt to be unacceptable. (with a packed pixel oriented blitter you could add hardware features to aid in shading too, but that's added complexity and still a great deal more overhead for pixel manipulation than with packed pixels -for cases where single pixel manipulation and cases where you don't mind being stuck with rows alligned to 8 pixel increments then planar is not at a disadvantage)

 

 

VGA was released in 1987 and you started seeing game support rather quickly with it becoming mainstream for higher-end games by 1988 and with full support by 1990 with the exception of budget/shareware stuff. (far more rapid than EGA from '84 to '87) Any competitor needed to make that shift soon enough or dramatically enough to get the necessary support soon enough as well.

 

MD had 512 colours, PC only 256 colour palette. Both have more colours on screen and ludicrously superior sprite/scrolling/audio hardware to the ST (and Amiga in all but sound)

Sound on the PC was getting rather competitive with Soundblaster in 1989 and with a decent machine you could very reasonbly have multi-channel MOD AND FM in-game due to the DMA channel, or single channel mode at the very least. Then came the 44 kHz mono 2.0 version, the stereo Pro and finally the stereo 44 kHz 16-bit SB16 along with the OPL3 in 1992. The SB1.0 already made in-game samples for music more realistic than software MOD in title demos on the ST. (you didn't see PC developers pushing that very often though, regardless of the feasibility and never using it in combination with FM unfortunately)

 

And MD had 512 colors just like the ST they used the exact same 9-bit RGB palettes with the only difference being the MD was character based and could assign any of 4 15 color indexes to any 8x8 tile or any sprite (of variable sizes) but that's not the same as a 61 color bitmap display with more color limits due to the tile division. (and there's the shadow and hilight effects too) Pretty much all consoles and arcade machines of the time were doing that and many computers as the TMS9918 and C64 (among others) had used much earlier with indexed colors on a character/sprite basis. The NES and C64 both only got up to 4 colors per tile and up to 3 colors per sprite which is why even though the NES had 32 colors indexed they didn't stretch as far as the 32 indexes of the SMS in spite of the NES's superior color palette. The SMS was 15 colors per tile/sprite like the Arcades, PCE, MD, SNES, etc, a step ahead but sticking to limited 6-bit RGB and with only 2 subpalettes and only 1 could be applied to sprites. (graphics took up 2x the space though due to the higher color depth with 4-bpp rather than 2 like the C64 or NES -MSX/CV/TI99 used 1bpp as did the speccy though the latter with a bitmap and not tile based -a rare case of an attribute plane being applied over a framebuffer rather than character graphics)

 

VGA had way, way more colors than the MD, PCE, or SNES could display and many more than they could feasibly display on-screen in a useful manner. (the PCE had 512 indexes for 481 max colors, but the practical limit as with the MD's 61, SMS's 31, SNES's 241, etc is far lower than that if you want to have nice smooth graphics without clash due to the redundant colors and the limited 9-bit RGB palette of the PCE and MD made the selections more limited as well compared to the SNES but the added palettes of the PCE still often gave it an edge over the SNES in color count -SNES games average below 100 colors, MD games generally about 30-50, and PCE has a huge range depending on the case -the SNES and PCE also have 4-color modes to use less ROM space -the SNES also stores them as 2-bit in VRAM and expands the number of paettes from 8 to 32 for the BGs in those modes, but they were rarely used -the limited number of palettes on the MD often meant using far less than 15 colors per tile or sprite, in many cases to the extent that highly optimized 4-color graphics could look very similar -there's a demo using Thunderforce IV's background in the 4-color mode on the PCE)

 

Even Neo Geo games averaged below 256 unique colors much of the time. (ie used 15 color sprites with 256 subpalettes) The PSX, Jaguar, and Saturn could index colors far more flexibly, especially the Saturn which had 4 kB of CRAM which could index 2048 15-bit RGB colors (less in 24-bit) and an offset to select a 15/255 color palette from anywhere within the index. Most 2D games on the PSX and Saturn continued to use 4-bit graphics (15 colors per tile/object) unfortunately the Jaguar lacks 4-bit indexing I think, only 8-bit for 256 color sprites/objects. (which uses 2x the memory and it had less RAM to work with) I'm not positive on that but I seem to remember that being a complaint by some programmers. (another being lack of support for indexed textures in truecolor making truecolor rendering generally impractical as textures would be huge -though CRY offset that disadvantage to some extent)

 

Not really by 1989 16bit and 8bit DAC costs had plummeted, even putting 3 stereo DACs with no DMA on the ST bus wired to give 6 channel mono or 3 channel stereo would have been fine. But after the STE disaster they didn't want to mess about with the ST and went down to £299 for ST RRP. A ludicrous price for such a machine really...a C128 plus disk drive cost more I think in 1989!

Again, without DMA it would be relatively pointless, though yes a simple 8-bit DAC would at least have allowed better sounding PCM at similar resource than hacking the YM chip and allow sfx without halting music, so that could have been a bare minimum (somethign adlib probably should have done too). But don't think you'd get anything remotely close to the STe or Amiga.

 

 

PC-Engine only has 5bit sound and the max frequency is 33% that of an Amiga, nothing special at all really and samples are pathetic on it (play SF2 and see)

Wrong, the PCE used a simple synth chip with bare DACs for the CPU to use. The only sample rate limit was that of the programmer, you could push 44 kHz PCM on the system and still only use about 1/3 the CPU resource. You can also manage 44 kHz playback on the MD, but the DAC only allows ~27 kHz without missed writes. (it's very possible to stream 22 kHz ADPCM though -few developers pushed the Z80 and many used it poorly -the lack of interrupts didn't help and the crappy bank switching and the slow speed, and Z80 is not as good at interrupts as the 650x arch anyway but ints would at least cure the problem of sloppy programmers who can't mange tight Z80 code)

Using only hardware interrupts on the PCE (not software timed loops like the MD uses) you have 3.58 kHz, 7.16 kHz, and 15.7 kHz PCM playback and at 7 kHz 5-bit is almost as good as 8-bit, the difference gets bigger at higher rates though, but you also save space with the lower depth: a lot of MD games should have used 4-bit rather than 8-bit PCM in favor of double the sample rate. (8 kHz 4-bit sounds much better than 4 kHz 8-bit, a bigger trade-off with 16 kHz 4-bit vs 8 kHz 8-bit though let alone other resolutions with middleground -4-bit is nice as it packs for higher bandwidth while 5-7 bit unpacks to byte sized words though stores nicely in ROM packed)

The 68k is far worse at software based PCM playback than a 6502 type CPU which is why you don't see MD games using it for PCM in-game. (Z80 is pretty good compared to the 68k for ints, but 6502 is significantly better still -to the point where you gain very little in performance with software timing rather than ints while the MD's Z80 would choke at ~16 kHz with interrupts vs higher than 44 KHz using tight software timing while a 3.58 MHz 6502 could easily meet 44 kHz with ints and only ~60% CPU time used)

 

We've discussed this at length on Sega-16 . (a 2 MHz 6502 and POKEY could very reasonably manage a 4 channel MOD player at 8 kHz or a bit higher even and varying the rate to control pitch -and thus sounding better than pretty much any MOD player done on the ST with the usual 4 kHz software mixing)

 

But a bare DAC would have been something at least. (for software MOD 4 4-bit DACs would be far more useful, but for in-game use a single 8-bit DAC would be fine and better for many things as you'd interleave 2 fixed rate channels if you did multi-channel stuff ever anyway and allowing variable playback rate wouldn't matter unless you were doing a single MOD channel) A dedicated CPU/MCU would solve that but wouldn't be a cheap option.

 

Amiga is slower than a couch potato running a marathon in 320x256 in 64 colour mode (only 32 of which you can choose, the other 32 being half as bright replicas of the first 32 colours you have selected). Slow slow slowwwww! In 320x512 (480 is for PC aspect ratio of 5:4...Amiga was 4:3 aspect pixels as it was designed for TVs not spreadsheets and DOS screens) in extra half bright 64 colour mode would be slower than a zx81 probably as far as arcade games code goes!

You're thinking as a PAL user. For NTSC you only get 224/448 lines at best on normal TVs (240/480 ideally -but you don't get 288/576 on PAL sets either), but horizontal resolution is fully variable and only dependent on the dot clock. You don't get a very big boarder on the SMS, Amiga, ST, etc on the top/bottom in NTSC, but you do in PAL.

The ST and Amiga have way too tall pixels for NTSC but near perfectly square in PAL. (and 320 wide is a misnomer, it's more like 340 or a bit more for the ST in actual screen area) With the 256 wide modes of the MD, SMS, NES, etc it's almost square in NTSC but slightly wide while way too wide in PAL, with the Neo Geo and N64 it's pretty much perfect in NTSC with a practical ~288x224 resolution but it's a bit wide in 50 Hz PAL.

The MD was nice with the 30 wide mode being a happy medium of PAL and NTSC with both ~10% off but reasonably close to square (too tall in NTSC and too wide in PAL but reasonable and also filling 320 pixels to the edge of the screen with little to no overscan and never a boarder without custom calibration -or in my case I've got a TV with slightly off calibration of the vertical which makes the MD's 320-wide mode perfectly square so Sonic is round and not egg shaped )

 

320x512 PAL would have double wide pixels though, so also a pain. (256-320x192-240 was industry standard for games from the mid 80s up through the mid 90s in any case and only with the Dramcast did you commonly see that being broken -with PC you saw 640x480 much earlier with nice square pixels though also many games catering to non-square pixels for 4:3 monitors -quake has some really broad resolutions)

 

The Amiga was effectively stuck with 320x200x32 colours if you wanted to write games, try it and see if you don't believe me. And PC games thanks to the pathetic ISA bus bandwidth all stuck with 320x200x256 before VESA or PCI came about with 486-66mhz or Pentium 60mhz respectively. ISA was a real bottleneck, try playing Galaxians in MAME on a P120 with an ISA card and then a PCI card...you will be lucky to get 10fps out of the ISA VGA card...more like a frame buffer!

Well, Amiga was stuck with 320x200 for ANY games in NTSC. (unless you dropped to 15/16 colors only)

And with VGA you weren't just stuck because of ISA, but VGA only supported 320x200 in hardware and you had to tweak it to do anything else in 256 colors and you couldn't double buffer in VRAM (of course with low-end 64k MCGA/VGA cards that's what you were stuck with anyway) and in those tweak modes (mode X) you COULD double buffer in VRAM and thus avoid tearing as well as use other resolutions: 320x240 was very nice with a proper 4:3 square pixel aspect ratio.

 

EISA was common though and a good bump up from ISA (8.33 MHz 32-bit), so don't forget that, and an EISA VGA card with 256 kB and games using mode X would be fine for 320x240 at 30 FPS (or more conveniently 35 FPS to match the VGA sync rate -1 frame every 2 refresh cycles) without mode X you're stuck with tearing for any bus not fast enough to copy the whole frame in vblank. (with double buffering in VRAM you can take multiple vblank periods to copy to VRAM before swapping the buffers in VRAM -I think EISA might be fast enough, 8 MHz 16-bit ISA probably wouldn't be though -not sure how long vblank is, unless you had a card with dual ported RAM and could thus access it any time and not only in vblank -maybe in hblank, unless VGA cards had better DMA managment allowing more even access times)

 

CPU speed and main RAM speed would be bigger factors in framerate for most cases... unless you had an 8-bit ISA VGA card. (especially a slow one)

 

Maybe a faster CPU, on a 32bit bus and with a 68881 @ something like 33mhz. The DSP is the only thing that worked, and it was intended for sample playback/recording tricks like direct to disc or echo/reverb effects etc NOT as a replacement for the 68881 or as an aid to 3D games. And there is no point putting a 33mhz 68030 on a 16bit bus anyway let alone a 33mhz 68881 FPU. DSP is there because the bus is 16bit and it's the only way to make the Cubase/Steinberg dream machine they wanted.

No, that's wrong, it wasn't to aid playback or recording, that's simple ADC/DAC and what the CODEC chip handled, but on the fly compression/decompression, mixing, resampling, and many far more advanced effects for audio could be done (filter effects, echo, additive synthesis, real wavetable synthesis, subtractive synthesis, reverb, q-sound, etc, etc).

 

But the chip was very well suited to accelerating 3D as well and far more cost effective than faster CPUs. It had performance fairly close to DSPs used in some 3D arcade games (albeit the higher-end boards were using multiple powerful DSPs). And would be very useful in raycasting, scaling, rotation, texture mapping, and a variety of other things.

Atari may not have included it for such, but it was very useful for all those things and would kick the crap out of Nintendo's Super FX 2 or Sega's SVP.

 

In terms of off the shelf offerings, powerful DSPs were the only option for 3D acceleration (ie better than fast CPUs) until the mid/late 90s. Though for the time they probably could have gone a cheaper route with an older, lower-performance DSP, or some of the more graphics oriented DSPs from TI (still useful for audio as seen in Hard Drivin's use for graphics and sound) though Atari's long-time use of Motorola components probably gave them a more favorable position on the 56k.

[kool kitty89]

Oh, and in the context of any blitter type coprocessor (sometimes "GPU" sometimes "VDP" etc) released in the early/mid 90s with 256/high/true color support, regardless of features like texture rendering, rasterization, etc, one important thing would be variable indexed color depth input for a common output. (using lookup tables either in dedicated CRAM or held in video RAM) That's something shared by most of the better early/mid 90s consoles and accelerators and sort of merges the old tilemap/character based graphics systems with the bitmap/framebuffer/blitter based systems using indexed colors on a character/sprite basis or the Spectrum's attribute system in some respects as well. (it's not really comparable to what could be done with planar graphics as that's tangent to the issue and you could have planar graphics used in such casses as they were on the NES, SMS, SNES, PCE and others and many of those also employed the simple plane dropping "compression" method though many also had to pad that data before sending it to the VDP as some only accepted fixed bit depths regardless of being planar -most consoles were like that and it weakens the utility of planar graphics, the TMS9918 and Spectrum both used 1bpp graphics so packed/planar doesn't apply, just the attribute/indexed color -same for the C64 and A8 320 wide modes using 1bpp or others)

 

So yes, it could apply to planar graphics systems as well, but by the time such hybrid set-ups started appearing in number, they were all packed pixel based and the normal input depths supported were 4, 8, 16, and sometimes 24 or 32-bits per pixel (some truecolor systems only accepted 32-bit sources for 24-bit non-indexed graphics, so it was a bit wasteful, though the framebuffer was at least 24-bit) and depending on the case the framebuffer outputs were usually 8, 16, or 24-bit with 4-bit or 8-bit sources to 8, 16, or 24-bit framebuffers, and usually 16-bit sources used directly with 16-bit destinations only depending on the circumstances: sometimes you had indexed 16-bit to 24-bit color but that takes up a lot of space for just the lookup tables (192 kB if the full 16-bit range is used) but I think there were some other cases of flexible partial indexes with direct color control over the remaining bits as crazyace described doing for the ST or others that simply toggle through different RGB levels rather than sticking to 5-5-5 or 5-6-5 RGB. (ie any combination of RGB ranges up to 8 bpits each for a total of 16 bits like 8-4-4, 6-6-4, etc) Some others also used other colorspaces internally and then output them as RGB, the MSX2+ did that and the Jaguar did that with a custom CRY colorspace optimized for smooth shading. (256 colors by 256 shades, except they were optimized to shade only towards black from the brightest intensity of color, not shading towards white -so it's great for shadow and normal lighting effects, but not good for bright reflections and cases where you'd want a washed out appearance with lighting effects -it works expertly well in Doom with silky smooth shading, though it would have been even more impressive at full 320x192 resolution rather than the low-detail 160x192 -192 pixels plus the status bar if I'm not mistaken, though the PC version was more like 320x176 or 320x168 unless you removed the status bar as it only ran in mode 13h 320x200)

 

That's a very important feature to have in leu of actual texture compression (and sometimes in addition to compression). 2-bit textures (4 colors indexed) usually aren't supported in hardware, but a software renderer could technically take advantage of that. (or pad it in software on the fly to the lowest acceptable depth used and apply the desired LUT)

Early on 4-bit textures were very important to save memory and, again it's unfortunate that the Jaguar lacked that feature (unless I'm mistaken).

 

 

 

 

And in the context of 1990/91 and planning for a new/upgraded machine in 3-4 years aimed at advanced 2D and capable 3D performance, a flexible architecture would be most preferable. Even in the mindset of the time it could have made sense to focus on an affine texture rendering blitter offering normal rectangle blitting, scaling, and rotation, and if used on a line by line basis could be made useful for warped 3D textures as well (that's exactly what the Sega CD did in 1991 and one of the features of the jaguar's blitter 3 years later -albeit only a little less primitive than the MCD while the Saturn and 3DO built a little further and allow the rectangles to be warped in 3D to quads by the blitter itself while Sony took the opposite direction and worked backwards with an emphasis on triangle rasterization with affine rendering and smooth shading and then offering a high-speed sprite mode as well but that being limited to plain scaled textures like the Jag's OPL and not like the scaling/rotation based blitter "sprites" of the Saturn, 3DO, MCD, or Jag blitter -the PSX had to use the 3D mode for rotation effects but just with all the same Z coordinates and moderately slower than the sprite mode -which operates at roughly the max fill rate of 133 MB/s).

They wouldn't have necessarily known just what direction polygons would take, let alone other forms of rendering like ray casting (Doom, Wolf3D, Star Wars Dark Forces, Duke 3D, Amok, Commanche, etc) and so sticking with the 2D scaling/rotation and line rendering part of the blitter and optimizing that would be wise and being sure to add indexed texture support. Then focus on a flexible DSP-like coprocessor for rasterization and 3D calculations, an off the shelf DSP or similar chip could be used (and definitely much more cost effective than pushing a fast CPU -even a RISC CPU, let alone common CISC- for that purpose) but an in-house chip might be ideal for the long-run unless a very favorable licensing or royalty agreement could be negotiated with the vendor (Motorola and TI would be prime examples of suppliers though there might have been some Japanese companies to look at -Sega licensed a low-cost Samsung SSP-1601 for their SVP and I believe it was also used in the Saturn's SCU -Nintendo/Argonaut used a custom/licensed chip for the Super FX though I think that was a bit weaker and I suspect it was the old Flare DSP or at least related to it -the initial 10.74 MHz clock speed even matches the 12 MHz rating of the flare chipset while it wasn't until 1995 that the 21.48 MHz SFX2 was released)

 

DSPs can even be pushed into the role of blitters though they're generally inefficient at it compared to dedicated blitters of similar cost but a good deal better than software blitting in most cases compard to contemporary CPUs.

Texas Instruments had their TMS340 series of DSP-like graphics coprocessors introduced in the mid 80s with the 34010 and the later 34020 in the late 80s. Notable Atari Games' Hard Drivin' boards (includign Steel Talons and STUNN Runner) used one or multiple 34010 coprocessors to calculate 3D math, rasterize, and in some cases for audio processing (the original hard drivin that that, STUNN Runner actually used the common YM2151 for music though) all with 8 MHz 68010s as the main CPUs.

Namco's System 21 and 22 used TMS320 series DSPs (mainly 320C25s -fairly similar in performance to a 56000) and the System 21 used a pair of 12.5 MHz 68000s while the System 22 (ridge racer, etc) used a ~25 MHz 68EC020. (Sega's Model 1 used a 16.1 MHz NEC V60, a mid 80s 32-bit CISC CPU with a 16-bit data bus -Sega also used FPUs rather than fixed point DSPs, thus facilitating practical use of quad based renderers -a shame they didn't push for a FPU in the Saturn -for that matter a shame the 3DO didn't use a floating point coprocessor rather than the fixed point DSP -the PSX's fixed point GTE was well suited to its triangles though)

 

Hell, even going back to the very earliest 3D arcade board with I Robot you had a fast fixed point coprocessor, albeit with bit slice multipleication coprocessors rather than a DSP. (the Flare chipset actually did both with a fast single cycle multiplication ALU derived from bit slice units and the custom harvard architecture DSP made by Ben Cheese -intended for 3D and audio processing: interestingly their demos back in '89 focused on FM synthesis and some other sound synthesis rather than sample based stuff other than sfx -interesting that the Jaguar DSP also had a push in that direction with an FM driver included in the dev kits and a small 4 kB wave ROM intended for wavetable, granular, additive, or subtractive synthesis)

 

 

 

General purpose CPUs and FPUs are not cost effective in those roles at all and if anything a cheaper CPU with just enough performance for the game logic and AI needed for such games would be preferable with more powerful coprocessors. (in the case of the existing falcon, if you wanted any sort of decent polygonal or ray-casting pseudo 3D or scaling or texture mapping, the DSP would be the last thing you'd want to remove and in that sense dropping to a plain 16 MHz 68000 with no FPU would have been fine)

[OldSchoolRetroGamer]

What Hath I Wrought? LOL! Well this thread has taken an interesting turn.......

[Crazyace]

I was going to write a long reply - but then I thought that this has moved from the original topic to more of a 'what should the ST have been' - and the answer to that is obvious - the ST should have been the Amiga!

No competition would have meant that all games would be written to use the hardware fully from day one - and Jack would price an ST/Amiga at the mass market rather than the high end that Commodore originally pushed it.

Then, it would be interesting what form a STe/A1200 would be in 89-90 to compete more with VGA PC's and consoles.

 

( Or in a perfect would Jay Miner would stay at Atari and engineer the Amiga as a new console/computer to replace the A8/5200 machine - no 7800 , just a 256k Amiga with Rom cartridges to outclass the NES )

[Tickled_Pink]

Initially the ST had more games than the Amiga. It was more popular with developers because it had a better learning curve. It was simpler to develop for than the Amiga. I remember Jeff Minter commenting on just how easy it was to program on it. If you spend time looking through the developer documentation of the ST and the Amiga, you'll see why. It took developers a while to get to grips with the Amiga. But once they did, and the Amiga platform itself stabilised and matured, the ST didn't stand a chance.

[frank1974]

I was going to write a long reply - but then I thought that this has moved from the original topic to more of a 'what should the ST have been' - and the answer to that is obvious - the ST should have been the Amiga!

No competition would have meant that all games would be written to use the hardware fully from day one - and Jack would price an ST/Amiga at the mass market rather than the high end that Commodore originally pushed it.

Then, it would be interesting what form a STe/A1200 would be in 89-90 to compete more with VGA PC's and consoles.

 

( Or in a perfect would Jay Miner would stay at Atari and engineer the Amiga as a new console/computer to replace the A8/5200 machine - no 7800 , just a 256k Amiga with Rom cartridges to outclass the NES )

 

Nah I'd rather keep them separate. Both truly awesome computers with great character!

[kool kitty89]

I was going to write a long reply - but then I thought that this has moved from the original topic to more of a 'what should the ST have been' - and the answer to that is obvious - the ST should have been the Amiga!

No competition would have meant that all games would be written to use the hardware fully from day one - and Jack would price an ST/Amiga at the mass market rather than the high end that Commodore originally pushed it.

Then, it would be interesting what form a STe/A1200 would be in 89-90 to compete more with VGA PC's and consoles.

 

( Or in a perfect would Jay Miner would stay at Atari and engineer the Amiga as a new console/computer to replace the A8/5200 machine - no 7800 , just a 256k Amiga with Rom cartridges to outclass the NES )

Except it would have been positioned differently and not as cheap as the ST... Atari Inc already had their own chipsets that were more powerful than the Amiga and while back in 1983 they were largely configured as (very) high-end workstations, that didn't mean they couldn't be configured differently at a more reasonable cost. (the Amiga itself probably could have been pushed that way too depending on the circumstances -the form factor and RAM of the A1000 obviously inflated the price) They also had their own BSD UNIX based OS and Snowcap GUI being developed for the 68k machines.

 

Those got shelved back in '83 with the start of the desperately needed (and very promising) reorganization of Atari Inc by James Morgan and were among the projects being reconsidered during the reorg process into mid 1984 (when Warner threw that all away in a very sloppily managed split and sale of the consumer assets and Atari brand name to Trammel Technologies).

In the mean time Atari Inc had the contract for the Loraine (Amiga) chipset to be used in a high-end "MICKEY" game console for 1984. The wirewrap protos had been demonstrated and test PCBs were made ready to install the Lorraine LSI chips in late spring of 1984. Amiga then defaulted on the contract and blatantly lied to Atari Inc stating that they couldn't get Lorraine to work and sent Atari's investment back with interest in an attempt to void the contract: that was never an option in the original contract and Atari didn't want that at all but it ended up a big mess as Amiga pulled that stunt just a day or so before the split went though at the beginning of July and Atari Inc was liquidated.

If Warner had stuck with it, it seems very likely that James Morgan could have turned AInc around in a big way and what he was doing in '84 was very promising given the accounts from Curt and Marty (Wgungfu). They certainly would have sued Amiga/CBM over the breech of contract (as Atari Corp later did, and won) and may have switched to one of the in-house chipsets. (Rainbow was apparently looked at as a potential game console).

 

The 5200 was being phased out and the 7800 and 2600 Jr were to launch in the fall, and prior to the breech of contract, the Amiga based MICKEY was planned for a fall/winter rollout as well. (and a 128k computer in '85 then a full computer in '86)

[oky2000]

I think we are going off topic so please keep off topic points to 1 or 2 sentences from now. Essentially the ST was a far bigger success than the A8 as far as Europe goes. The only big A8 sales in the UK were due to Jack dumping 800XL stock at suicidal margins....XE had no such sales success compared to ST in UK/EU.

 

It's clear everyone has different ideas of why Atari/Commodore died but overpriced useless Macs survived....comes down to better asset/cashflow management. A4000 was superior to any Mac and cheaper but idiots bought Macs with their crappy OS akin to Windows 3.1

 

What I will say is the ST was far easier to start programming, although Jeff Minter failed to write a single 16bit game above PD software quality on Amiga or ST so don't bother with his comments, but at the same time doing a game of arcade quality worth £19.99 on ST took a lot of technical skill to squeeze out enough performance from the 8mhz 68000 to make up for no blitter or DLI/Copperlist/DACs/Sprites/hardware pixel scroll in all 4 directions. Doing them all at the same time on 8mhz was the holy grail. With another month 2bit Systems would have improved the horizontal scroll for Gauntlet 1 to be honest, not silky smooth but better and more acceptable when the screen is busy.

 

The A8 by comparison was very easy to write smooth arcade games for using Antic/GTIA/Pokey if you stuck with the original design limitations of a handful of colours at 160x192 and mono sprites etc. The difficulty in coding for the A8 was overcoming the 70s limitations of total on screen colours to match 16+ colours on screen at once in any 4x8 pixel block anywhere type games for Commodore/Amstrad at the time. This was also a special kind of talent rare in most developers....leading to really bad ports of some games like Gauntlet for A8!

[kool kitty89]

I think we are going off topic so please keep off topic points to 1 or 2 sentences from now. Essentially the ST was a far bigger success than the A8 as far as Europe goes. The only big A8 sales in the UK were due to Jack dumping 800XL stock at suicidal margins....XE had no such sales success compared to ST in UK/EU.

Yeah, and we don't need to rehash the reasons for the A8's lack of establishment in the market again (or why they declined in the US either).

 

Though thinking on the comment you made about "needing to made a replacement for the C64" there's a lot more on the market (especially thinking Europe-centric) than the C64 with the Spectrum, MSX, and CPC in particular and if focusing on the UK alone you've got the Spectrum most significantly. The Spectrum was obviously the most affordable machine on the market with the minimal capabilities necessary and even advantages for some things (like an actual framebuffer for software rendering things the character based consoles couldn't in hardware) and it still wasn't cheap for the time looking at the actual prices in '84/85 but no tech was, especially in parts of Europe with higher taxes and other overhead. (albeit if you include the ZX81, by that time it was fairly cheap)

 

So that would definitely be something to fill too, not the C64's role alone, but also the Spectrum's and the masses of computers in general in Europe. You could argue the ST more or less filled that role, relatively speaking though it also got a good bit more of the business market than the spectrum ever managed from what I understand. (though the Speccy was initially launched as more of a business machine) In that sense the C64 and Spectrum market competition was somewhat like the ST and Amiga later on. (albeit in some parts of Europe you had different trends pushing for various 8-bit platforms in different ratios than Europe)

 

It's clear everyone has different ideas of why Atari/Commodore died but overpriced useless Macs survived....comes down to better asset/cashflow management. A4000 was superior to any Mac and cheaper but idiots bought Macs with their crappy OS akin to Windows 3.1

Not just management of the business side of things (which I think Atari Corp at least managed very efficiently up until Tramiel retired ~1988/89), but marketing and generating hype in mass media and in a viral manner.

That's one thing Commodore screwed up and Atari never managed either. (the ads and such they did have seem to have been fairly competitive but they were far too few and without definitive placement)

A bit part of that was almost certainly the limited budgets (definitely early on) regardless of having in-house marketing prowess, with more money they could have outsourced.

 

That's something that Atari Inc managed rather well OTOH but the business side was a bit shaky with management issue growing. (with Morgan it could have been the best of both worlds perhaps)

 

Good marketing and generating hype and PR is something Apple was/is very good at most of the time going back to the Apple II even (compare its price and capabilities with the competition from 1977 up into the mid 1980s). Steve Jobs definitely took notes from Nolan Bushnell back in his Atari days.

 

 

The A8 by comparison was very easy to write smooth arcade games for using Antic/GTIA/Pokey if you stuck with the original design limitations of a handful of colours at 160x192 and mono sprites etc. The difficulty in coding for the A8 was overcoming the 70s limitations of total on screen colours to match 16+ colours on screen at once in any 4x8 pixel block anywhere type games for Commodore/Amstrad at the time. This was also a special kind of talent rare in most developers....leading to really bad ports of some games like Gauntlet for A8!

What is the flexibility like for the character modes on the A8? I know there's 5 color registers for the playfield, but how does that work in terms of indexing? (ie for 4:8 character cells -or 8x8 in the highres mode)

DLIs shouldn't have been any big issue though as it was related to the same common practice used on game consoles of the time (not just VCS but also CV and IV in some cases)

 

And the C64 didn't have full 16-color use, it used indexed colors for characters rather like the TMS9918 and various consoles (NES in particular with 2-bit pixel graphics like the C64, but later 4-bit arcade/consoles apply as well). The C64 had one common BG color and 3 indexed colors per 4x8 cell (or 2 indexed colors for any 8x8 cell in highres) selected from the rather limited 16 color palette (good for some games but weak for others) compared to the very nice palette of the VCS/A8 but with the latter's limitations making it tougher to show off. (if the C64 had used a palette more like the Astrocade, 7800, Plus/4, VCS, or A8 it would have been no contest against the A8 and even have some advantages over the NES at times due to the large number of indexed palettes vs the 8 sets of palettes of the NES -which otherwise has an advantage due to the C64's color palette and in either case you have resolution limits on the C64 unless you bump to highres and 2 colors per tile -still rather nice with any 2 colors per tile out of 128/256 -granted that would require 8-bit CRAM rather than 4-bit and more cost unless they cut the number of unique indexes down -for practical use it's overkill on the C64 and a broader palette with less CRAM entries would be a very nice trade-off against adding another 1024x4-bit SRAM chip -then again the VIC20 dedicated the same to CRAM so it wouldn't be totally unreasonable to bump it to dual CRAM chips and 8-bit entries -by the same note the A8 could have been far more attractive if it used indexed colors like that rather than internal registers -even using the 128 bytes of RIOT for that purpose would be great with 32 sets of 4 colors or 64 sets of 2 colors or even more flexibility if an offset system was used to define the palette, but you'd still have the weaker sprites in the A8's case)

[oky2000]

The Spectrum died quite a sudden and brutal death because it was cheap and nasty and only really sold while the C64 was expensive. The Amstrad had better success in places like Spain but overall none of those machines came close to the C64 sales of hardware or software from around 1987 onwards. The time the ST vs Amiga fight really began with STFM vs A500. Spectrum fan boys may well insist it was amazing but it was a useless pile of crap and only sold because it was 175 bucks less than a C64 early on...and the huge catalogue of games got you to the mid 80s ish really. Spectrum and Amstrad games were dropped by the big software companies well before the C64 versions were dropped in reality.

 

MSX again had good sales in one EU country but overall got its ass kicked all the way back to Japan as the games were really quite dire as was the hardware. Slightly superior to a Spectrum but cost much more.

 

The C64 officially did have limits on MC1 and MC2 colour being universal for all char cells, but this was quickly overcome in the late 80s with various tricks and bugs. The C64 was pretty much still a sellable product up to just before Amiga AGA (A1200/4000/CD32) era to be honest. With sprites that wasn't really overcome and this is why doing something like SF2 on C64 is very difficult, multi-colour sprite palette is hindered.

 

The point is that for arcade games with masses of sprites/smooth scrolling/awesome soundtrack there was actually only one machine selling in huge numbers. The ST had no problem improving on dodgey arcade scrolling games for Spectrum/Amstrad but if you had a C64, and by 88/89 most people did overall, the ST did have a real problem with piddly sound, small software sprites, jerky scrolling...so aside from screen shots and resolution it was usually worse. Game screen shots were fantastic, but in reality when playing the game you knew only certain game types NOT 2d arcade scrollers would actually be better in motion/sound than a C64 sadly.

 

Even Uridium/Salamander/Armalyte would be nigh on impossible to do better on an ST than a C64 if you want that sort of sound and smoothness of movement frame locked to full pal/NTSC speeds.

 

As for everything being better on Amstrad/A8 neither of those machines ever remotely approached the C64 game engine on Enforcer II with triple parallax layers or even Armalyte. So clearly it is quite possible to have a massive total colour resolution for the full screen without imposing a single wasted clock cycle or sprite multiplexing bandwidth of the system. Some of us like our games to scroll properly like arcade machines

[kool kitty89]

The Spectrum died quite a sudden and brutal death because it was cheap and nasty and only really sold while the C64 was expensive. The Amstrad had better success in places like Spain but overall none of those machines came close to the C64 sales of hardware or software from around 1987 onwards. The time the ST vs Amiga fight really began with STFM vs A500. Spectrum fan boys may well insist it was amazing but it was a useless pile of crap and only sold because it was 175 bucks less than a C64 early on...and the huge catalogue of games got you to the mid 80s ish really. Spectrum and Amstrad games were dropped by the big software companies well before the C64 versions were dropped in reality.

Yes, I was specifically talking about the context of the early period where it was popular because it was the most affordable with reasonable capabilities (still not cheap though, the ZX81 being the only thing that really came close to cheap cost-wise for the time, and even then it's still not that cheap by modern standards) the VIC-20 actually could have been better in some ways (mainly audio and hardware character modes) but the RAM was lacking in all standard configurations and the resolution was low.

 

By the time the C64 became the mainstream lower-end option, the 16-bit machines were already there and the ST had the same advantage over the Amiga as the Spectrum did over the C64 back in '82-86 (cost and available software). From what I understand ~1985/86 the C64 really went mainstream in Europe due to falling costs and got the major support from then on while the same sort of thing happened with the Amiga around 1988/89. (by '85/86 in the US the C64 was falling out of favor to game consoles -mainly the NES- while the remaining computer gaming market moved over to the ST, Amiga, and PC as the 8-bit market declined -with Apple and C64 hanging on longer than the A8 or some others but that faded fast into the late 80s and you had the intermediate shift to ST/Amiga with PCs ever growing on the mass market and pushing into the gaming niche with the ST being more or less displaced from 1987 onward and the Amiga falling further behind as time went on -though not really being technically exceeded in any way until 1989 with VGA games and not overall until the early 90s you had PCs gaining popularity with developers and users in the US regardless of hardware capabilities -in the vast majority of cases you had C64 users moving on to PCs or back to game consoles -and computer gaming didn't hit mainstream again until the mid '90s -ie to the extent of actually rivaling game consoles in popularity)

At least that's the general impression I've gleaned from what I've read and the accounts I've seen online.

 

 

The C64 officially did have limits on MC1 and MC2 colour being universal for all char cells, but this was quickly overcome in the late 80s with various tricks and bugs. The C64 was pretty much still a sellable product up to just before Amiga AGA (A1200/4000/CD32) era to be honest. With sprites that wasn't really overcome and this is why doing something like SF2 on C64 is very difficult, multi-colour sprite palette is hindered.

OK, but there's still the 4 color per cell limit and resolution limit in multicolor mode as well, but on top of that there's the rather limited palette of the C64 in general (it could have been a little more balanced but wasn't too bad for most things as far as 16 fixed colors can go, but that's just it: 16 colors is really limiting for the entire palette -a shame they didn't use a larger palette with 8-bit CRAM rather than 4-bit, or a table/palette look-up system in RAM more like the TMS9918 or for textures in modern consoles/computers -starting in the early/mid 90s with the likes of the Jaguar and 3DO).

The resolution and large master palette are the main advantages of the NES... that and the hardware sprite multiplexing and faster CPU meaning some things can be done with less slowdown issues or software solutions. (combined with more memory in later games -compared to single-load C64 games, any multi-load games would generally have an advantage by comparison)

 

As for games like SFII on the C64, the resolution was a pretty notable problem too though they could have opted for highres 320x200 BG with dithered 2 color cells (given the limited color selections and the fact you can have any 2 colors per cell, use of high-res with dithering would probably be preferable), and for sprites you could easily overlay sprites to get more colors and in that respect you're a fair bit better off than the NES due to the larger sprite sizes and color optimization on a per sprite basis as well -when multiple sprites are laid side by side or top to bottom regardless of using overlaying as well. (there's at least 1 SFII pirate game on the NES that looks rather good due to ovelaid sprites but also suffers from more flicker -something the 12 pixel wide sprites would be less of a problem with in the C64, probably with occasional flicker with some wider animation frames and both sprites on the same line) So you could have 6 colors using paired sprites overlaid and 2 sprites wide for the 2 characters and no flicker (6 colors per overlaid sprite set, so you could have another set of colors on a different 12x21 area of the composite sprite -for standing position sprites, you'd probably want to multiplex to allow a composite 24x42 sprite)

 

I'm not sure how the colors are limited for C64 sprites though, so if you're limited to fewer palette indexes than that, that mechanism is less useful anyway. (the NES has 8 3 color palettes that can be applied to sprites or BG tiles)

Plus you could at least use scanline interrupts to increase that in the same way you can on the VCS, Colecovision, or A8. (even if only to reload the palettes for the top and bottom 21 pixel halves of the sprites)

Edit: nevermind it's only 1 unique color per sprite, so you'd only get 4 colors from 2 overlaid multicolor sprites... probably better to use 4 monochrome sprites in that case and have 4 totally unique colors per sprite and also reload sprite palette on the multiplexed line. (so for the 2 fighters you have each at 24x42 when in standing position and different sets of 4 colors per 24x21 segment: too bad the 8-bit systems didn't allow amiga like sprite attachment, but then again none of those used planar bitmaps either -some like the TMS9918 used 1bpp exclusively so they technically used either planar or packed pixels as there's only one bitplane)

The point is that for arcade games with masses of sprites/smooth scrolling/awesome soundtrack there was actually only one machine selling in huge numbers. The ST had no problem improving on dodgey arcade scrolling games for Spectrum/Amstrad but if you had a C64, and by 88/89 most people did overall, the ST did have a real problem with piddly sound, small software sprites, jerky scrolling...so aside from screen shots and resolution it was usually worse. Game screen shots were fantastic, but in reality when playing the game you knew only certain game types NOT 2d arcade scrollers would actually be better in motion/sound than a C64 sadly.

Up until good software rendering was managed by better developers, yes there were major trade-offs against the ST, though the audio also greatly depended on the case and whether the programmer/composer was making full use of the AY's capabilities (same for MSX, Speccy128, and CPC). Some used it as plain square waves and noise like the SMS's SN76489, but it could be pushed a fair bit further than that chip and had a bit more flexibility in general. (wider frequency range, hardware ADSR envelope, more flexible noise generation mixed into one or more of the other channels, etc) Of course one common problem with many EU computer games was lack of simultaneous sfx AND music... and the rather dumb option of SFX OR music rather than Music or Music+SFX. (ie having normal music or that same music with some instruments cut-out to use sfx as needed -and making sure to cut the supporting instruments or percussion rather than the lead as some games oddly did) That problem extended into the Amiga as well. (Japanese and IS developers rarely ever did that if ever, though there were far too many PC speaker only games which should have had those options ironically enough -interleaved PC speaker music and sfx can get pretty nasty)

 

For 1985, the ST's audio was middle of the road and pretty standard (pretty much the best common off the shelf sound chip available in 1985), the poorer software rendering early on was at least partially due to packed pixels (tricks like preshifted objects and such coming into play for better games, but 8-pixel wide offsets would be the simplest rendering style). Though with the lowest resolution still stuck at 320x200 and no hardware scrolling, that was pushing it with the CPU resource the ST had. In that respect a 160x200 mode could have been quite useful and have color flexibility well beyond that of the ST or Amstrad (the latter had a generally better palette than the C64 but far weaker than 9-bit RGB plus a weak CPU to drive the display -and far too many 4-color mode 1 games). And I'm talking a plain 16 color (4-bit packed or 4 bitplane) low-res mode, so technically it could probably be set up as an extension of the 320x200x16 color mode but with 1/2 the dot clock and thus also the ability to overscan. (for most TVs a 4 MHz dot clock would give a visible ~192 pixel wide display or a bit less on some sets with more overscan -you could probably depend on 184x200 in such a mode).

That would even be useful with hardware scrolling still present in cases where you'd want to do more things on-screen at higher speed than 320x200 would allow and where the lower res was still acceptable. (a 160x200 256 color packed pixel mode would have been really nice, but that's a lot further from what they were doing at the time)

 

Once the tricks to overcome the planar bitmap issues were in common use the main limit was still lack of hardware scrolling (packed pixels would have had a bigger impact on early games and some 3D-ish games), and given Crazyace's comments that definitely does seem to be the biggest oversight from the initial release. (something that would have had little impact on time or overall cost but a huge impact on performance and longevity of the original system) An 8-bit DAC would have made very little difference other than more carefully managed games allowing simultaneous PCM playback and music/PSG usage and without the other issues of hacking the AY chip for playback over a plain DAC. (maybe occassional use of a single sample channel for music, but at low rates and not too often due to the heavy CPU use -with hardware scrolling that would open up a fair amount of CPU time though, more with faster CPUs being offered)

And either incremental upgrades and/or a definitive replacement model. (some things really do seem attractive to upgrade -and had they added an audio input on the cart slot it would have been rather easy to mix into main audio) Any such common upgrades should be integrated into the successor in any case.

 

As for everything being better on Amstrad/A8 neither of those machines ever remotely approached the C64 game engine on Enforcer II with triple parallax layers or even Armalyte. So clearly it is quite possible to have a massive total colour resolution for the full screen without imposing a single wasted clock cycle or sprite multiplexing bandwidth of the system. Some of us like our games to scroll properly like arcade machines

If you mean simple line scroll, the A8 would be just as capable at such "parallax" as the C64 (and if the divisions for different scroll lines also fell on lines for DLI color swaps, that's even more convenient), but the A8 simply lacked the support needed to be pushed like the C64 was otherwise you'd see games that were far more competitive. (the sprites were the biggest limitation on the A8 overall with the rest having trade-offs with a much better palette with more limited on-screen use, a nice sound chip with more channels but limitations on what sounds it could do in hardware -some things the SID couldn't do either though in respects to noise/sound generation and some other things- the possibilities of PCM on the A8 were not really pushed at all and the number of C64 games that catered rather well to the A8's color and sprite capabilities are rather numerous -the Ghosts n' Goblins port being a big example -and back to sound there were lots of software tricks to expand POKEY's default capabilities as well, but even with chiptunes sticking to the hardware capabilities there's some very nice stuff the chip could push against the SID or NES for that matter)

 

The A8 certainly had some disadvantages, but the general problems with marketing and understanding market needs in some cases along with competitive pricing and 3rd party support really hurt it in the long term. (-Kassar, Tramiel, and even Morgan limited it in different ways -though in the latter case probably most so due to the unfortunate timing of the halt of all Atari production for several weeks in fall of 1983 meaning they largely missed the holiday sales season and delayed the full introduction of the 600 and 800XL and opened the market to the C64, but much of the damage had already been done with missed opportunities from 1979-1982) That and with the popularity of the A8 and initial support in the US, North America would have been the primary selection of strong support had the lien remained popular alongside the C64... at least unless things had been done differently in 1980-1982 in Europe. (not only better marketing and pricing with tailor made machines for the market, but better 3rd aprty development support and documents detailing the common tricks used on the system)

 

Hell, you'd have a hard time managing similar smooth scrolling games on the ST to A8 in some cases as well. (but the smaller/fewer hardware sprites simplifies that somewhat)

 

 

 

 

 

But back to the main point with the ST is that you couldn't go crazy with something on the Amiga's hardware level given the timescale and price point aimed with the ST. If they DID go with Amiga-like hardware (or Atari Inc's own 16-bit computer designs), there would need to be other compromises to push the low-cost angle. (ie models missing some of the custom chips, less RAM, etc)

In the same respect the Amiga COULD have been more like the A500 back in 1985 is managed as such (which would indeed make sense), but it would still be more expensive than the ST in similar memory configuration. (the ST could have even been cut down a bit more by removing some of the standard interface/peripheral ports and the keypad in favor of a general purpose expansion slot for adding such capabilities and leaving only the bare minimum of onboard ports -joystick/mouse and floppy ports obviously being mandatory -and in some cases you could even remove entire chips from the motherboard and move them to optional expansion modules)

But then again, with the Amiga chipset you might have had some other middle ground at CBM like an earlier incarnation of the C65 (especially in place of the C128) and perhaps moreso if the full Amiga integrated compatibility with such a C65 as well as the C64 (at some additional cost but it would be the high-end machine anyway). That would have been really interesting and if any of the 8-bit computers merited a backwards compatible successor (for reasons of sheer popularity) it would have been the C64. (you'd definitely want to address the floppy drive speed issues with such a system though, maybe expand to using the normal 360 kB IBM type DSSD 5.25" format as well as being backwards compatible)

 

Adding hardware scrolling wouldn't have compromised the ST's low cost as such though. (and the other cuts were still technically possible too, though using less than 512 kB of RAM ended up being impractical for a commercial release -given the number of lower-end users who'd never even bother with many of the peripheral ports or really need the keypad, dropping closer to a 130XE/Amiga 600 like form factor might have made sense for a low-end version -and with composite/RF adapter from the start)

Edited November 29, 2010 by kool kitty89

[oky2000]

The Spectrum was launched as 16kb and 48kb models and the 16kb was discounted early on down to £110 which is peanuts compared to the cost of A8/TI/VIC-20 etc. It really was the bare minimum for a home computer and pretty damned disgusting most of the time with migraine inducing colour clash, sounds like flatulence and some dog slow scrolling/software sprites. And typing in listings on a rubber keyboard is terrible. So it was all down to being first and being 1/3 price of the only option for C64 ownership (remember it was £330ish AND £40 for the datasette!!)

 

Anyway sound chip wise the crappy YM may have been popular with everyone else and Pokey in obscurity in EU due to low sales of Atari 400/800/800XL (excluding JT's stock dumping @ £99 prior to 65XE launch) but everyone in the industry knew if it wasn't better than the SID it was not worth mentioning technically.

 

The Enforcer II game engine runs two levels of full screen overlaid parallax not variable speed raster based scrolling, and then another layer of multicolour (sprites) objects on top to make 3. There is no way you can do that AND produce something like 32 sprites and 20+ animated chars on either Spectrum/Amstrad or MSX (bullets + missiles). Even Salamander on the C64 would be hard for an ST to do in all areas except still image/screenshot quality. Fast arcade games were a real problem I remember, and 3 colour graphics of Goldrunner did NOT impress me at all, looked terrible like a Spectrum or BBC Micro game really.

 

Things did improve but I suspect the lack of hardware sprites/scrolling is why Nemesis (Gradius) or Salamander (Lifeforce) were never ported to the ST....and hence neither to the Amiga as this would have been a chop shop port of it.

 

I have no problem with the ST's ability to display still images it had good colour palette and 16 colours was good if you knew what you were doing, hell I bought one to play with Neochrome for the princely sum of £469 via STM+SF354 package and I never regretted it. The difference is when I got my Amiga 1000 a year later the C64 went back in the box for most of the time (hey it was all new to me and exciting! lol even if some games were a HUGE disappointment due to ST ports/crap coding not even coming close to making 50% use of the system there was the odd gem like Marble Madness).

 

But what I will say is before 1988 the ST definitely was not selling mass market levels to worry anyone in the C64 manufacturing business and ditto for Amiga before 1989 due to high prices and some pretty crap games generally. Amstrad and Spectrum died quick deaths in the UK (Spain loved the CPC I think though hence all those games from DiNamic via Ocean/Imagine). As far as the UK was concerned it was a slow cautious adoption to the ST and Amiga, plenty of people made do with a £99 C64 with OK sorta games for £9.99. And actually playing Defender of the Crown or Rocket Ranger on C64 was a damned fine experience, a fine fine example of the C64 going right to the bitter end and probably still able to sell as an alternative to the NES/Master System had they adopted say 3.5" disk drive in a C64 games console (like the Konix Multisystem that was never released).

 

edit: Thanks to the STM I bought I am a pretty good pixel artist now, I was even asked to do a logo for a software package produced by the company I work for lol but that's boring corporate stuff really. Still credit where credit is due, an ST and a copy of Neochrome free in the box is where many 16bit artists started (or Degas but I don't like the jerky mouse response on Degas for freehand) I guess. Maybe in the USA people could afford Dpaint and Amiga 1000 but until 1989ish it was an early adopters machine even in the form of the £575 A500 + £25 TV modulator/SCART cable. That's £600!!!!

Edited November 29, 2010 by oky2000

[kool kitty89]

Anyway sound chip wise the crappy YM may have been popular with everyone else and Pokey in obscurity in EU due to low sales of Atari 400/800/800XL (excluding JT's stock dumping @ £99 prior to 65XE launch) but everyone in the industry knew if it wasn't better than the SID it was not worth mentioning technically.

The only off the shelf options besting the SID at the time would have been the YM2203 and YM2151, and I don't think either were withing the desired price bracket for the ST or perhaps the supply wasn't high enough. (the 2203 would be the way to go in place of the YM2149 for sure) Plus they wouldn't have even been on the market until 1985, so it would have been a bit presumptuous on Atari's part to push for those. (I think the original OPL may have appeared shortly after and that would have been a lower-cost option but lacking the I/O and timer features of the YM2203)

A bare DAC would be OK as an addition but crap for all as a general sound chip and would need to be used extremely sparingly due to the CPU resource it would take. (you could have a dedicated CPU/MCU driving a DAC, but that's hardly a cost effective solution either -and that's really going back to the whole POKEY+6502 set-up)

 

One other option would be dual YM2149s, or more realisticaly dual AY8912s (same I/O functionality and double the sound channels/ADSR/noise in dual 28 pin DIPs rather than a single 40 pin DIP). Custom audio hardware wouldn't be practical for the timescale though adding an audio input line to the cart slot would really have helped. (a lot of inexpensive add-on possibilities there)

 

The Enforcer II game engine runs two levels of full screen overlaid parallax not variable speed raster based scrolling, and then another layer of multicolour (sprites) objects on top to make 3. There is no way you can do that AND produce something like 32 sprites and 20+ animated chars on either Spectrum/Amstrad or MSX (bullets + missiles). Even Salamander on the C64 would be hard for an ST to do in all areas except still image/screenshot quality. Fast arcade games were a real problem I remember, and 3 colour graphics of Goldrunner did NOT impress me at all, looked terrible like a Spectrum or BBC Micro game really.

That's a combination of a simple raster effect and animation along with tactful use of the character based graphics. So it's something the likes of the NES or even A8 could have pulled off reasonably (given the rather limited color use, the A8 wouldn't take a big hit either, aside from sprites), but the ST, Amiga, and other bitmap based systems would need to do things very differently, plus the ST lacked hardware scrolling.

 

Lack of hardware sprites wasn't a big problem on the ST and sprite logic really tends to eat up chip surface anyway... hardware scrolling would be the first thing (and really the definitive thing for most games) while hardware character modes might have been rather significant as well, especially if additional color indexes could be used rather than a plain 16 color display. But western computers moved away from that (PCs kept charmodes but hardwired in ROM unfortunately -not sure about VGA but definitely CGA and EGA... a shame really as CGA or EGA charmodes would have been exceptionally useful early on even with only 2 color per character -imagine the relatively smooth scrolling of a 640x200 16 color CGA display using 80x25 text, let alone the artifact color possibilities that would allow).

 

Things did improve but I suspect the lack of hardware sprites/scrolling is why Nemesis (Gradius) or Salamander (Lifeforce) were never ported to the ST....and hence neither to the Amiga as this would have been a chop shop port of it.

Software blitting would have a lot offloaded by hardware scrolling. Hardware sprites would have added a lot more to cost and development time of the SHIFTER.

 

But what I will say is before 1988 the ST definitely was not selling mass market levels to worry anyone in the C64 manufacturing business and ditto for Amiga before 1989 due to high prices and some pretty crap games generally. Amstrad and Spectrum died quick deaths in the UK (Spain loved the CPC I think though hence all those games from DiNamic via Ocean/Imagine). As far as the UK was concerned it was a slow cautious adoption to the ST and Amiga, plenty of people made do with a £99 C64 with OK sorta games for £9.99. And actually playing Defender of the Crown or Rocket Ranger on C64 was a damned fine experience, a fine fine example of the C64 going right to the bitter end and probably still able to sell as an alternative to the NES/Master System had they adopted say 3.5" disk drive in a C64 games console (like the Konix Multisystem that was never released).

In that respect they probably could have afforded to beef it up a bit more early on at the expense of a higher initial price point. (but being selective to allow further integration later on) But, in any case, scrolling would have been a must and the simplest and less cost/time consuming missing feature.

[barnieg]

I seem to recall when Software Houses started to drop support for the Amiga (& ST?) They blamed piracy in the UK. how true was that?

 

 

Barnie

[The_Laird]

Going back a previous comment made:

 

I was always under the impression the Spectrum sold well in Spain not the CPC as there are loads of Spanish Speccy games and the upgraded 128k machine was first released in Spain and funded by a Spanish company. The CPC's big market was France where it was produced by Schneider.

 

The Spectrum was still going into the 90's, with support from people like Ocean, but most of the games being released were 128k only. And for the person who called the Spectrum crap it certaily wasn't. Sales figures don't lie and there were many games that were better on the Speccy than the other 8-bits, anything in 3D for a start where it was much quicker.

 

I upgraded to an ST after my Speccy and I was working in a major games store in 1994 through to early '95 and we still had a small ST games section. I remember buying stuff like Zool and the latest Sesible Soccer with my staff discount verty cheap even though by then I owned a Jag.

[Christos]

I seem to recall when Software Houses started to drop support for the Amiga (& ST?) They blamed piracy in the UK. how true was that?

 

 

Barnie

 

Neither true nor false. The situation was that. Piracy allowed for more sales of machines and thus fuelled more software production. After the sales curve reached it's maximum point there was a decline in active ST/Amiga users and thus less demand for software. If there was no piracy, that would have halted the software sales drop a bit but not enough to have any real impact. Perhaps ST support from larger software houses wouldn't be dropped in 1992 but perhaps in early 1994 but no more than that.

 

Unfortunately this isn't covered by numerical data but only by certain observations. There weren't for example more active cracking groups in 1992 than there were in 1989 so you can't infere more pirate releases during that time period. Also the average user would get a percentage of original and a higher percentage of pirated titles. There is no reason why would that change in 1992 vs 1989 since the UK didn't experience a recession during that time period. If we had sales numbers for that era then we could draw the relative lines and reach a better conclusion.