chunky pixel mode

[Hattig]

A chunky pixel mode would have helped with the early-style 3D games which used software rendering, especially ray-casters like Doom.

But other things would have been better - fast RAM as default on the CD32, a SIMM slot in the A1200 for easy Fast RAM addition. Hardware changes include a faster, 32-bit-wide blitter and explicit polygon rendering acceleration hardware.

[Hattig]

And the reason we had the insane architecture of 8 bitplanes not byte per pixel in 256 colour displays was...........

Commodore cheaping out.

It probably wouldn't even have been much logic to implement (compared to the rest of the logic). Instead of reading up to 8 words from bitplanes at different addresses, just read 8 words sequentially, and interpret the data differently.

I'm guessing the data from each bitplane was read (32 bits at a time) into shift-registers (one per plane) on the chip, and that the data was shifted out (at the pixel clock rate) as a number that was fed into the colour palette (CLUT) to get the RGB display value for that pixel.

So to implement a byteplane you would just need to feed those 8 shift-registers differently, or have an chunky shift-register that shifted 8 bits at a time.

[Hattig]

More sprites would have made a real difference. Check out Neo Geo games. These are 2D only but impressive anyway. CBM*should have added more sprites or a 32bit blitter and that would have made a lot of difference in the quality of Amiga games. Chunky games usually looked like sh*t anyway.

Although challenges are always fun (doing chunky games on Amiga) I think more effort should have been done in taking advantage of AGA+fastram and doing some great neo-geo like games.

Adding more sprites would have been difficult due to the nature of Amiga sprites - a scanline of each sprite is loaded into the chip during HBLANK, and there's only so much bandwidth available, which coincides with the AGA sprite size and count. Sprites were an after-thought on the Amiga. To do them like the NeoGeo/etc there would have had to be a separate sprite memory, scanline buffer and memory bus so that accesses to sprite data could be done at any time.

The best option would have been a 32-bit blitter and a faster chipram bus. The latter would have helped the sprite count too.

[Hattig]

Chunky mode would have helped, but processing power was more of a bottleneck in my opinion. 030's vs 486's isn't really any reasonable comparison for a CPU intensive game.

But the 486s were in £1000+ systems, and the A1200 was a £400 (then £300) system.

Which brings us onto the other failing: No £600 A1230 with 40MHz '030 and 4MB RAM at release. Upselling - Commodore hadn't heard of it, apart from that hard drive included SKU.

At Release:
A1200 2MB '020 14MHz: £399
A1200 4MB '020 14MHz: £479
A1200 4MB '030 25MHz: £549
A1200 4MB '030 40MHz: £599
A2200 4MB '030 40MHz: £799 (A1200 in desktop case w/ separate keyboard)

People would have easily been persuaded to get a higher level A1200 in shops because the price increments aren't too shocking.