chunky pixel mode

[Zac67]

Which could multiple them up to 64 IIRC provided the scan line had enough to work with.

Actually, the Amiga's sprites are channels which are limited to 8 sprites per scanline. So, theoretically you could use up to 512*8 = 2048 on PAL interlaced with no more than 8 overlapping on any scanline.

[Mrs Beanbag]

In fact you can re-use a sprite several times on a scanline with clever use of the copper.

[zioben1976]

I never realized why Commodore dosen't make a chunky mode for AGA. AGA is born to support more than 5 bitplanes. Simply designers could add a bit in some register to switch to 8-bitplanes and 256 colors chunky mode when set ( like the bit to switch to real 6-8 Bpl mode and EHB-Ham-6/8 mode...).
I think it costs nothing to design the ciruitry in Agnus.
With 8BPL chunky mode, Fetch 4X, and 32 bit access Bandwidth to the ram was theorically 8MB/sec in Lo-Res and and 6.3MB/sec in HiRES, enough to obtains 100FPS in lo-res and 20FPS in hi-res.
What really think is that AGA is an old designed OCS upgrade and no more.
I think Commodore had AGA chipset ready a lot time before launch of A1200 and 4000. I think those machine were forcedly launched too early in response to the growing market of PC and Consoles.

[Themamboman]

Wasn't the Akiko chip in the CD32 there to provide chunky mode conversion for CD32 games?

I wonder how much performance impact it had?

[guest11527]

Wasn't the Akiko chip in the CD32 there to provide chunky mode conversion for CD32 games?

I wonder how much performance impact it had?

Akiko? Next to nothing. Akiko hat a series of registers into which the CPU could write a sequence of chunky data, and a second set of registers where the converted planar data could be obtained. This avoids a lot of shifting and masking for the C2P transformation, but the CPU still has to touch each pixel manually.

In particular, there is no DMA channel that could automate the process, C2P is still a CPU hog. If Akiko could be feed by the blitter, or would have been part of the blitter, or part of Agnus as part of the bitplane DMA - this would have helped. But the given design is a minimalistic solution that does not help much.

[SamuraiCrow]

Thanks for the clarification. So by the time we're talking 256 colours, there's no savings involved in planar?

Correct.

[itix]

Akiko? Next to nothing. Akiko hat a series of registers into which the CPU could write a sequence of chunky data, and a second set of registers where the converted planar data could be obtained. This avoids a lot of shifting and masking for the C2P transformation, but the CPU still has to touch each pixel manually.

I recall on 020 Akiko was faster than the software C2P, on 030 they got roughly even and on 040 the software C2P was always faster...

In particular, there is no DMA channel that could automate the process, C2P is still a CPU hog. If Akiko could be feed by the blitter, or would have been part of the blitter, or part of Agnus as part of the bitplane DMA - this would have helped. But the given design is a minimalistic solution that does not help much.

Could be I remember wrong, it has been so many years since this information was relevant... but I recall C2P was not great bottleneck on faster CPUs. Fast 68060 and C2P was a non-issue again.