Hi guys.

One of the most common discussions in the past few decades is the Amiga bitplane graphics and the possibility of integrating packed pixel modes into the design. We know this was planned post AGA with AAA but could it been possible with a hardware revision? I avoid terms like chunky because it's such a PC term. I am discussing Amiga here.

I've known about how the Amiga design works for a number of years like we all have. But one thing has stood out that lacks detail which I think could have been the key to adding a packed mode without major changes. That is the bitplane data registers known as BPLxDAT:

These registers receive the DMA data fetched from
RAM by the bitplane address pointers described
above. They may also be written by either
microprocessor. They act as a six-word parallel-
to-serial buffer for up to six memory bitplanes
(x=1-6). The parallel-to-serial conversion is
triggered whenever bitplane #1 is written,
indicating the completion of all bitplanes for
that word (16 pixels). The MSB is output first,
and is, therefore, always on the left.

http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node0023.html

Little else is said but it's obvious here that parallel chunks of 16 pixels are read in from the planes and then converted into some serial data stream for CLUT reference. Or, to put it another way a planar to chunky conversion. This, I believe, is the clue to adding packed pixel modes.

It's not explained greatly here but each pixel bit is reversed from being atomic elements to becoming a whole quantity. It doesn't specify if it is one pixel at a time or a whole stream of 16 pixels. But what is certain is that planar bits go in one end and packed bits come out the other.

So the hardware read 16 bits at once for the parallel to serial conversions. One word for each plane which is stored in BPLxDAT. I don't know how this was stored as there are no public registers with the result but this I believe would have been the key to adding packed modes.

Taking the above into consideration I think the best way to achieve it and be easily engineered into the design was a direct mode that skipped the parallel to serial conversion altogether and read it directly from the plane. This would have placed a direct colour index into the hardware. For 1 bitplane this would have been direct anyway with a 1:1 conversion. For more it just becomes multiples of 16 bits so two bytes per plane. So up to 6 planes the max pixel data is 96 bits wide or 12 bytes. 6 individual parallel 16 bit reads then become sequential 16 bit reads. Depending on hardware configuration a group of 16 bits could be read in parallel or serial. The point here is it could read the data directly and skip the conversion since the CLUT value is ready o go.

It makes sense if it would be restricted to powers of two so only supporting 2, 4 or 16 colours. Since that is also easier to manage in software. But, what's interesting is if you do the math, oddly enough, any odd bpp like 3 and 5 can fit in the same space. That is, 16x3 bpp is 6 bytes and 16x5 bpp is 10 bytes. Even 6 bpp, with 16x6 is 12 bytes. No matter what is the pixel width it's always aligned to 16 bits.

It's been said an A500 could have displayed a 256 colour chunky screen. That the bandwidth was there. In this case though it would have needed 128 bits or 16 bytes to read in a max group of 16 pixels.

The implementation would have used one plane in linear format as each pixel is wider and spread across one plane. But still would have allowed modes such as dual playfield to exist as normal. As well as copper and sprites working as normal. The blitter modes would likely have been unchanged but would have needed extra width to accommodate for wider blits due to wider pixel data per line. A mask could work as usual but would have needed to be wider and be packed out to pixel width.

So, what do you guys think? Does that look like something that would have been feasible? Or is there something I have missed such as reading in blocks of 16 bits but still only processing each pixel one bit at a time? In any case that data is some where.

Comments will appear below.

@Hypex

An 030/50 board with EDO Ram and AGA ADoom modes ran Doom 1 just fine. They needed to bump CPUs across the AGA machines as well as including a multi button controller, 1.76MB full speed disk drive and upgraded 8 channel Paula! Chunky Pixel was a bridge too far for AGA!

Last edited by BigD on 25-Nov-2024 at 05:31 PM.

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@Hypex

given how simple the c2p logic in akiko was it would likely have been easy to implement into an AGA+ chip or something, would they have ever made such a thing.

_________________

@BigD

They could've should've a lot of things most not realistic with the constraints in place.

They did have AAA going and opening up Paula (and the CIA?)to double the floppy data rate was rather pointless as even in 92 floppies really shouldn't have been anything but install media.

Sure AIKIO was simple but also so slow that barely anything used it.
There might also be a good reason why they choose to not integrate into Alice was had already borderline timing.

If they had waaaaaay back decided to push the Ranger chipset and if they had designed that with chunky in mind, sure but in the AA timeframe just pointless.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada