Dedicated CHUNKY MODE on Amiga: How feasible is it?

[Foebane]

By the early 1990s, bitplane computers like the Amiga were (or should've been) going the way of the dodo, and smooth scrolling in all its forms and varieties were being superceded by textured 3D graphics.

It's been said many times that the Amiga should've incorporated a dedicated chunky mode to accommodate this upcoming trend within AGA, or the AAA chipset, and for it to be at least 256 colours in 8-bits.

What I'm wondering is, how much of a redesign would this have meant for the AAA equivalent of Denise, which was the chip that managed the bitplane display?

I'm just guessing here, but I would imagine the following would have to occur:

The sprites should be unaffected, and so should the Copper, but the Blitter would have to be totally redesigned, and so would HAM, if it were still to be implemented. And of course, there could no longer be as few as 1 bitplane up to as many as 8, as it would be strictly byte-per-pixel.

However, the palette registers would, I imagine, also be unaffected, and overscan would also work as normal.

A chunky mode was a necessity in 1994 or even 1993, because the Amiga's bitplane system would require as many as eight separate operations in screen memory to write to eight bitplanes, to change ONE pixel, which would (and did) slow down Amiga graphics to one-eighth of the speed of a 1-bitplane mode. Faster processors and direct writing (bypassing the Blitter) can yield some good results, but the fast speed was needed on the standard "stock" Amiga A1200, and it was already underpowered compared to 386 and 486 PCs as it was, and that's even before the separate bitplane writes I mentioned before.

I've programmed on PC in chunky modes, and it really is very neat and easy and simple how each pixel can be plotted with 1 out of 256 colours with just one byte written to memory - no wonder programmers switched to PC as soon as they could.

In fact, looking at fancy 3D pre-rendered animation scenes on Amiga, it makes me cringe how much extra work is required by the custom chips just to draw the graphics on screen, compared to the lighter workload the PC does.

So what do you think? Be as technical as you like, how would the Amiga custom chip designs be modified to include a dedicated 8-bit chunky mode?

[roondar]

I don't think the Blitter would need all that many changes to be honest, it makes no difference to it whether it's copying planar or chunky data - memory is memory. The real change would be the data you offer it

Of course, you could make a few small improvements to the Blitter to make your life a bit easier, but it shouldn't really be all that necessary.

[drHirudo]

There are some fake chunky modes for AGA amigas, which just use the copper http://aminet.net/package/dev/misc/chopper
These modes were used in Amiga games - Ambermoon used hybrid chunky mode for the floor/ceilings.
Also check this thread - http://eab.abime.net/showthread.php?t=88990

[defor]

Originally Posted by roondar

I don't think the Blitter would need all that many changes to be honest, it makes no difference to it whether it's copying planar or chunky data - memory is memory. The real change would be the data you offer it

Of course, you could make a few small improvements to the Blitter to make your life a bit easier, but it shouldn't really be all that necessary.

Originally I thought the same but then it occurred to me how much the Amiga blitter works with bits and the binary logic. Barrel shifter will have no use, for example. Also what about masking and logic-functions (minterms)? What about fill mode or line mode? Also, I don't think that programmers would be satisfied if the AAA blitter would have been just a DMA copier. Some per-pixel operations would have been needed as well. Therefore it leads to a very different design.

I'm looking forward to read some elaborate analysis what that AAA blitter would be like.

P.S.: I think that bitplane graphics was not necessary already in late 80s, and definitely not in 90/91 as memory was getting cheaper and larger. I don't think 64kB per screen was such an issue for 1MB chip-RAM ECS machines. It's sad that ECS/AGA Amiga didn't have support for chunky graphics at least for low-res pixels.
P.P.S.: Atari fans got chunky mode in 1993 in Falcon. Too late as well ;-)

[oRBIT]

I was hyped for chunky pixels back in the day.. But now, I'd probably have prefered tile-based screenmodes (a'la NES/SNES).

[Foebane]

I clean forgot about c2p routines when I started this thread, but then I was thinking of "what if" scenarios.

But if we're forced to use c2p routines, for any given specification of Amiga, how many frames per second do we lose if we use a c2p routine?

[roondar]

Originally Posted by Foebane

I clean forgot about c2p routines when I started this thread, but then I was thinking of "what if" scenarios.

But if we're forced to use c2p routines, for any given specification of Amiga, how many frames per second do we lose if we use a c2p routine?

It'd depend a bit on the CPU used. But in most cases (not counting 68060/vampire/etc), c2p has an upper limit of around 25FPS.

[defor]

Originally Posted by Foebane

I clean forgot about c2p routines when I started this thread, but then I was thinking of "what if" scenarios.

But if we're forced to use c2p routines, for any given specification of Amiga, how many frames per second do we lose if we use a c2p routine?

I believe it was asked and answered many times in the past.
For example, see this discussion.

[pipper]

You lose in the ballpark of 11-20ms per frame, which is a whole frame worth of time and added latency.

I imagine that the needed changes for Denise would actually be small-ish. What we have in AGA is a regime fetching of up to 64 bit of data from up to 8 pointers in memory. Then the hardware does essentially a planar-to-chunky operation to determine the palette entries to be fetched from for each pixel. If this part would be instead changed to interpret each fetched byte directly as palette entry, then we’d have a chunky screen. A 4bit chunky screen would probably also be possible this way.

[eXeler0]

@foebane You probably heard about SAGA and its chunky modes without breaking compatibility with legacy stuff (Apollo core / Vampire).
For a deep technical dive you could probably ask this guy ;-)
http://www.apollo-core.com/knowledge.php?b=4&note=369

[roondar]

Originally Posted by defor

Originally I thought the same but then it occurred to me how much the Amiga blitter works with bits and the binary logic. Barrel shifter will have no use, for example. Also what about masking and logic-functions (minterms)? What about fill mode or line mode? Also, I don't think that programmers would be satisfied if the AAA blitter would have been just a DMA copier. Some per-pixel operations would have been needed as well. Therefore it leads to a very different design.

Surely, you can simply see 1 chunky pixel as the same as 8 planar pixels in a row on a single plane?

So the barrel shifter then shifts between 0-1 pixels rather than 0-15 (which allows pixel by pixel addressing and in an easier way than currently as you only need to choose between odd/even). Minterms can mostly stay the same, though you can then use A+B+D blits rather than A+B+C+D blits to achieve transparancy, etc.

However, I didn't consider line/fill mode - those would indeed need some changes (or need multiple calls in a row to function). Then again, fill mode might still be possible if you can combine it with a mask (which I don't know) and I'm not that certain how many things really used line mode (apart from intuition which I'd guess does use it).

[Bruce Abbott]

Originally Posted by Foebane

I've programmed on PC in chunky modes, and it really is very neat and easy and simple how each pixel can be plotted with 1 out of 256 colours with just one byte written to memory - no wonder programmers switched to PC as soon as they could.

'As soon as they could', would be when VGA appeared - and only in one resolution (320x200) with no blitter, no sprites, no copper etc. The CPU had to do it all - which made it much easier to program because all you needed to do (or could do) was set pixels one at a time.

So what do you think? Be as technical as you like, how would the Amiga custom chip designs be modified to include a dedicated 8-bit chunky mode?

If the goal is simply to provide the Amiga with an 8-bit chunky screen mode similar to VGA then it should be relatively easy. The blitter doesn't need to be modified because you won't be using it. All you need to do is rearrange the video DMA so that it reads the screen memory linearly rather than taking it from separate bitplanes. This might be incompatible with sprites, split screen resolutions etc., but you won't be using those. In chunky-pixel mode the screen will locked be into 320x200 with no fancy features - just like a PC is with VGA.

Another option would be to have a completely separate frame buffer and converter (like Akiko but full screen instead of only 32 bytes) that acts as a bridge between the CPU and ChipRAM busses. On the CPU side you would have fast chunky access, while the ChipRAM side would be read as bitplanes through the normal video DMA. This could be compatible with sprites, copper lists etc., as it would look like normal bitplanes to the custom chips.

Finally there is the solution that could have been applied to any Amiga 'back in the day' - a card which produces a dedicated 320x200 chunky display whose output is combined with the Amiga's RGB video output. It could be switched in via a transparent color like a genlock does, allowing overly of sprites etc., and even take part in screen dragging. Of course the blitter can't touch it, but you don't need it because you will be doing all rendering via the CPU.

A 320x200 8-bit frame buffer only needs 64kB. 128kB would give you double buffering, and is still a piddling amount of RAM. The controller could easily be implemented in a medium scale CPLD, which would probably be much easier than trying to redesign the AGA chipset to do it. In effect you would be integrating an RTG card which only has one screen mode. Next step after that is hardware texture-mapped 3D - imagine the Amiga with PlayStation graphics!

[AmigaHope]

Already explained this in another thread, but the whole chunky pixels issue was a bit of a red herring. Yeah c2p did slow things down, but the biggest problem was that chipmem is just plain slow. Converting to planar was only a problem for less CPU-intensive games like Wolf3D where the framerate could've potentially been very high on a slow CPU.

With Doom, you were not gonna get a playable framerate fullescreen on the 14Mhz 68020, even with a graphics card with chunky pixels. You needed a faster CPU. That CPU could then do fast c2p in fastmem, with the conversion being relatively less intensive compared to creating the image in the first place. The problem is that the CPU is stuck waiting half the time just copying the image into chipmem.

AGA (and especially OCS) was never designed to have CPU-driven video. The idea was always to preload graphics into chip memory and then display them, with motion coming from sprites or small blitter objects, and scrolling around the playfield in memory. AGA is barely fast enough to do reasonable fullscreen video, but that's only if the CPU is doing not very much beyond copying into chipmem, leaving much fewer cycles for executing game code.

This could have been fixed with some sort of fast writeback buffer on the bridge to the chipmem bus, but this was not implemented. Most of AGA was unchanged from ECS and still had its limitations. Consequently on a fast CPU you get stuck with tons of wait cycles just waiting for the copy to finish.

The reason CPU-driven games performed much better on graphics cards was because it bypassed the chipmem bus. The faster the CPU, the more apparent it becomes. That's why even with an 040 Doom still sucks on an A2000 with a chunky graphics card -- Zorro 2 slows it down even worse than doing c2p to A3000-ECS/AGA chipmem. If you have a Zorro 2 graphics card in an A3000 or A4000, Doom will run faster using ECS/AGA rather than the graphics card. This is mentioned specifically in the ADoom readme:

https://aminet.net/package/game/shoot/ADoom-1.3

[Toffee]

The AAA chipset had a native 16bit colour chunky mode and upto 16 bitplanes.

The Blitter was 8x faster than AGA and also had a pixel addressing mode.

There are a large variety of pixel types supported in AAA. Along with the traditional bitplane-generated pixels (including HAM8 and HAM10), we have several kinds of chunky and compressed pixels.

Half-Chunky
Half-chunky pixels come in 2,4, or 8-bit depths. These indirect through the color lookup table like most planar modes do.

Chunky
Chunky pixels are 16-bits deep. They bypass the CLUT, providing 5 bits of red, S-bits of green, 5-bits of blue, and one genlock overlay directly.

Hybrid
Hybrid pixels are 24-bits deep, composed of separate chunky planes for Red, Green, and Blue. The genlock overlay is fixed at (R,G,B) = 0 for this mode.

PACKLUT
These compressed pixels are stored at 2 bits per pixel and decompress to 8-bit half-chunky pixels. This is done by dividing the screen into 4 x 4 pixel regions. Each region
contains two colors (8-bit values indexed through the CLUT) and sixteen pixels.

PACKHY
These compressed pixels are stored at 4 bits per pixel and decompress to 24-bit direct pixels. This is done by dividing the screen into 4 x 4 pixel regions. Each region contains two colors (24-bit direct values) and sixteen pixels

https://web.archive.org/web/20171229...x/docs/AAA.pdf

The next Amiga chipset Hombre abandoned bitplanes altogether. It had 4 separate chunky playfields of 8 bit colour. They could be combined though for a 32bit colour screen.

[TEG]

Originally Posted by AmigaHope

This could have been fixed with some sort of fast writeback buffer on the bridge to the chipmem bus, but this was not implemented.

For those who like me wonder what is exactly "writeback buffer", here is a definition I found here:

Write Back:
The data is updated only in the cache and updated into the memory in later time. Data is updated in the memory only when the cache line is ready to replaced (cache line replacement is done using Belady’s Anomaly, Least Recently Used Algorithm, FIFO, LIFO and others depending on the application).
Write Back is also known as Write Deferred.

Another explanation from here:

What does Write-Back Cache mean?

Write-back cache is a caching technique common in most processor architectures since Intel 80486. When required, it copies data to higher level caches, backing store or memory.

Write-back cache is also known as write-behind cache and copy-back cache.

Techopedia explains Write-Back Cache

Write-back cache is designed to improve or reduce write operations from and to a cache and its data source (RAM, in most cases). It enables control of the time and the frequency at which data is written or copied into the source backing store.

In a write-back operation, any new, requested processor data is written to the cache, but not in the memory. The memory write process is only performed when the cache data needs to be edited or purged for new content.

Write-back cache works in contrast to write-through cache, which simultaneously writes on cache and memory.

[snowpile79]

Just adding that EGA graphics was planar with a chunky mode so not counting all the discussion of agnus feature changes implementing chunky and planar existed in EGA iir.

[Thomas Richter]

Originally Posted by snowpile79

Just adding that EGA graphics was planar with a chunky mode so not counting all the discussion of agnus feature changes implementing chunky and planar existed in EGA iir.

Yes, but the way how EGA solved it is unsuitable for Amiga. EGA changed the apperture to the EGA frame buffer. That is, the way how the RAMDAC accesses memory remains unchanged - it is a planar mode all the way. What does change is the interface between the frame buffer and the ISA bus. It reads the bits from the CPU, and redirects the bits to the various bitplanes, thus it makes the memory appear as if it is chunky, though one write modifies multiple bitplanes.

The reason why this is not suitable for the Amiga is that it makes the entire memory contents look different once the aperture map is changed. That is, all the structures that are held in chip memory (i.e. the vector table, and AbsExecBase) would be broken.

[Bruce Abbott]

Originally Posted by Thomas Richter

The reason why this is not suitable for the Amiga is that it makes the entire memory contents look different once the aperture map is changed. That is, all the structures that are held in chip memory (i.e. the vector table, and AbsExecBase) would be broken.

Which is why the easiest way to do a fast chunky mode would have been to use separate video memory like PCs did. If that means no sprites, blitter, copper etc. in chunky mode then too bad. PCs didn't have any of that stuff, so why would we want it?

Already explained this in another thread, but the whole chunky pixels issue was a bit of a red herring... With Doom, you were not gonna get a playable framerate fullescreen on the 14Mhz 68020, even with a graphics card with chunky pixels. You needed a faster CPU.

Which was the same problem faced by PCs when 3D games first appeared. A typical 386SX PC wasn't able to run Doom full-screen at reasonable frame rates either, despite having chunky graphics.

[dreadnought]

Originally Posted by Bruce Abbott

Which was the same problem faced by PCs when 3D games first appeared. A typical 386SX PC wasn't able to run Doom full-screen at reasonable frame rates either, despite having chunky graphics.

386SX in 1994 was an outdated machine. Pentiums have already appeared and 486s were getting more and more affordable.

Even so, you can play DOOM on a 386. In a medium window with low detail you can get about ~17 fps, which for the time wasn't so bad.

[jotd]

I remember 486/66 was perfect for doom. But my 060 was also perfect for doom. I completed it on the 060/50. I had a Pixel64 (Picasso like board) but I don't remember if I used native graphics or RTG.