Hi guys.

I've just been reading up on CGA, EGA and VGA graphic modes. What I found was interesting. CGA had a standard 2-bit packed pixel format. But EGA used planar graphics and VGA was natively planar as well! Well except for Doom Mode 13h.

I found something else. On EGA it had bitmasks and different write modes. And one write mode in particular allowed it to write packed pixel data that the EGA hardware split up internally and write to all bitplanes! That's write. EGA had built in chunky to planar hardware almost ten years before Commodore could say Akiko. And it was superior!

What's more, EGA could even do split screens similar to the Amiga. And colour cycling. Even the C16, with a superior palette and split screen raster interrupts, is looking under a shadow.

Given these hardware tricks were known about it makes me wonder, why didn't they include them in the Amiga? The Amiga would have benefited greatly with a packed to planar hardware register. Including allowing the blitter to blit to parallel planes. Though a CPU only mode would have sufficed. Workbench would have been fast. 3d and all games could just written pixels in linear fashion. By comparison, the Akko hardware is an inferior design, as data must be written to it then read out again and finally written to chip ram. The EGA way is one way where you write data and the EGA hardware does the rest itself in the bitplanes.

I actually wonder if this was why particular PC games weren't released on the Amiga or ran slowly. For example, in the early 90's, Wolfenstein 3d. Basic looking game, not as pretty as most Amiga games. I read it initially had been planned to be EGA then they changed it to VGA. No wonder, it would have needed VGA, and only AGA could match the closest.

I've heard arguments that he Amiga should have had VGA instead of AGA. Now I used to dispute that because of lack of copper, sprites, blitter, 24 bit RGB and the like. We know the C16 almost killed Commodore because it lacked sprites, Commodore had enough blunders. But after finding out that VGA is in fact natively planar, up to four bitplanes as it may be, I'm softening to the idea. It doesn't look so bad after all. I think it may have been a good idea to include some VGA features. Packed write mode for a start. And packed pixel mode to finish it off. Now that would have finished off the Amiga on a higher note!

@Hypex

Both Wolfenstein 3D and Doom used the unchained "Mode-X" which has 4 planes, but these are not bitplanes. It's completely different from EGA. Imagine every 4th pixel being on a different memory plane. Here are some images to help visualize it:
http://www.brackeen.com/vga/unchain.html#4
As for EGA you are right, it has a chunky write mode 2, that does c2p conversion on the fly. This is what Catacomb 3D used for the 3D view area.

_________________
This is just like television, only you can see much further.

@BSzili

Thanks. I must say, after hours of reading, I'm still confused!

The term bitplane must be burned into my head from the Amiga understanding. I have disputed the term bitmap being used before when the data was packed with linear bytes, which would constitute a bytemap, not a bitmap. However, it looks like there were PC graphic modes in the past where they used true bitmaps with bitplanes. And formats like PCX supported this where they include both a pixel width and plane depth. A planar bitmap would have a pixel width of 1 and a depth used, just like on the Amiga. A packed bitmap would have a depth of 1 and pixel width used. This would allow for multiple planes of varying pixel width, though I don't know if that was used.

The Mode-X term looks confusing, as if to imply it uses mode Ah. Aha, but looks to be based on mode 13h. But offering 256KB over 64KB. 64KB looks fine to me if you can double buffer it or in VGA terms page flip.

I don't know what Doom was doing but I think it has caused confusion. All the talk I read of how the Amiga wasn't good for it because it didn't have a linear chunky mode now look like non-sense. Because if I understand how the VGA framebuffer is setup, it doesn't exactly offer you a linear frame buffer either. What I'm seeing, is pixel bytes, but not mapped in linear fashion. But instead mapped to these byte planes that makes even less sense. So, for 320 pixels across, Doom was unable to write 320 bytes in a row because it had to offset each pixel by each plane size and mask if off? I have no idea! But that looks like a pain needing ASM to loop it through fast.

The Amiga may not have packed modes, but at least when you write 40 bytes in a row to place 320 pixel bits on screen, you write 320 pixels across in linear fashion. VGA is looking more like C64 MCM where you get chunky, in this case 2-bits with four pixels per byte, but every 8 byte sequence went down instead. Normal bitmap being a bitplane like the Amiga, but an 8 byte sequence where 8 pixels went down as well. Since C64 modes are character matrix based this makes sense.

Okay. So the Amiga, linear bitplanes, they make sense. C64, non linear bitmap or packed map, that makes sense. VGA, non linear bytemap, that makes no sense!

Just to clarify, by linear I mean a consecutive row of pixels, represented by a sequential block of bits, packed array of bits or byte.

Last edited by Hypex on 03-Apr-2020 at 05:27 PM.

@Hypex

The thing is, Doom spent most of its time drawing columns (walls, sprites) and not horizontal lines (floor/ceiling spans), which is why Mode-X was a good match. It also allowed for setting multiple pixels with a single write. For example the low detail mode used this to draw double width columns for free. In Wolfenstein 3D they also used it in the wall/sprite scaler to draw wide columns. Doom could have also used this, but I'm not sure because the DOS source code was never released, and I haven't looked at the reverse engineered version.
Again, it's not a question of linear vs non-linear, but chunky pixels vs bitplanes.

_________________
This is just like television, only you can see much further.

@BSzili

Quote:

The thing is, Doom spent most of its time drawing columns (walls, sprites) and not horizontal lines (floor/ceiling spans), which is why Mode-X was a good match.

How does this work? I assume the walls and sprites are drawn into an off-screen buffer first, and then the buffer it written to the screen.

_________________
"Unix is supposed to fix that." -- Jay Miner

@bison

That would defeat the purpose, on DOS they are drawn directly into the VGA memory. There are 3 screen buffers, and the game alternates between them. By the way, there's a very good book on how it works:
https://fabiensanglard.net/gebbdoom/index.html

_________________
This is just like television, only you can see much further.

@BSzili

Thanks for the link. I probably won't get to it, at least not soon. I've already got several projects going, and it takes all my time.

_________________
"Unix is supposed to fix that." -- Jay Miner

Parallel write was trick used in good old times of 80 by almost every hardware company that use bitplanes.
SGi, Apollo Workstations ... And of course IBM in EGA.
It allows to have all bitplane advantages like less memory used simpler hardware with drawing almost as fast as on chunky pixels.
640x480 16 colors EGA mode use 4 bitplanes but is very fast.
Unfortunately Commodore after buying Amiga does not invest in R&D and Amiga chipset was almost unchanged after its initial design in 1983.
Parallel write will help a lot but we don't have it on Amiga.

@BSzili

Okay, I understand now, finally.

Still, writing columns wouldn't be the fastest, since you need to add a line offset. That is, compared to using a CPU instruction optimaised for sequential bytes.

I see here the Amiga would really have no hope. I can only imagine what would have happened if the vertical drawing routine or'ed a byte into all the bitplanes for each texture line it was doing. LOL.

Even if the had chunky it stil lacked this duplication trick. Likely this helped with zooming up close to the wall and creating blocks of colour. Something I thought was lame at the time since Amiga 2d games were always perfectly clear.

I see that being able to write each pixel by the byte makes all the difference regardless.

@ppcamiga1

Funny as some people think using bitplanes is strange and others think they are bad for games. But it looks like they were more common in the 80's than it seemed so using them in the Amiga was a logical choice.

But what I wonder now is, since Jay was an engineer who would know these things, why the parallel write wasn't included in the hardware? EGA was released a few years before the Amiga. Did they look into the features and was it too late for such a useful operation to be added I wonder?

Given the Commodre track record I'm surprised they brought AGA out. It's unfortunate that the A500 remains the most popular and supported Amiga. Because in the same year they brought it out VGA was to leave the Amiga in the dust. Sure it had the copper, ham and sprites were useful. But a lot of games didn't use any Amiga special tricks and just used the basic palette modes. On this basis, fast chunky, 18-bit RGB depth and a 256 colour palette left the Amiga in the dust. The A500 needed AGA, period, with a chunky mode!

However, there is "chuky" data if sorts read in each line. The audio data is packed as chunky, with its signed bytes, but isn't read as fast as the screen. Then something more close to the video data, copper lists. So, this becomes interesting, each copper instruction is a long word or 4 bytes. It takes four pixels to execute an instruction in low res. That means it has read in 4 bytes every 4 pixels. You can see where I am going with this. That one byte per pixel! That is the speed of an 8-but chunky buffer. Why then wasn't this bandwidth used to provide a chunky mode? Even if it could only be 4 bits it would have been a boon. AGA, being able to execute copper at 2 pixel speed would have done 8-bit easily. They could have allowed to disable bitplane fetches, freeing up bandwidth, where CLUT data would be read from inside the copper list instead. Well, one can dream!

@Hypex

OCS was designed in 1983 and sell in 1985.
Everybody use bitplanes in 80's so use bitplanes in OCS was logical choice.
OCS has very good graphics better than others.
OCS was designed before EGA was avaible so it is ok that it has not EGA features .

After buying Amiga C= should spend some money on R&D and add features like parallel write.
And of course at end of 80's switch to chunky like everybody else.

@Hypex

There is a trade-off when drawing columns instead of rows, but drawing scaled textured columns is still faster than triangles with perspective correct texturing. Being able to write up to 4 pixels with a single write is useful, but it's an edge case. If you look at a typical Doom screen, most of it is filled with distant walls made up by 1 pixel wide columns. I'm also sure it made drawing the visplanes a bit more complicated, because those are made up of horizontal spans. So yes, chunky pixels is the most important thing for graphics like this. The main benefit of Mode-X was access to all of the 256 KB video memory, which allowed for 3 screen buffers and about 64KB of "latch" memory, that can be used to store frequently drawn graphics.

_________________
This is just like television, only you can see much further.

Quote:

ppcamiga1 wrote: Everybody use bitplanes in 80's so use bitplanes in OCS was logical choice. OCS has very good graphics better than others.

ACK!

RAM was expensive and in an aera where GFX cards had 128kB RAM or less, a flexible system using bitplanes was a logical solution.

The original Amiga used the same RAM for GFX, Sound and programs (ChipRAM), programmers could chose freely if the want to use the precious RAM for GFX, Sound or GFX. They could reduce colours and resolution if they needed more RAM for code or sound.

The downside of bitplanes GFX is the complicated procedure when writing single dots or drawing irregular shapes, but that's something the Amiga could handle perfectly with its built in Blitter.

Later when PCs got faster CPUs, better GFX cards and when RAM became cheaper, the benefits of the bitplane GFX became unnecessary and the Blitter could not help much either.

Last edited by OneTimer1 on 05-Apr-2020 at 04:05 PM.

@BSzili

So what would be faster to draw using a doom-style engine: 320 x 400, or 640 x 200?

I said I wasn't going to read the book you linked, but I'm stuck at home, so I started. There's really not much in there about VGA -- I think I have to go back to the Wolfenstein book for that.

Edit: When I say "faster to draw", I mean on ideal hardware, not VGA or Amiga. In other words, for which mode is the Doom drawing algorithm better suited?

Last edited by bison on 05-Apr-2020 at 03:56 PM.

_________________
"Unix is supposed to fix that." -- Jay Miner

@OneTimer1

RAM was expensive, but low-resolution mode only has 64K pixels, so I think the missing chunky mode is due to lack of foresight more than expense.

_________________
"Unix is supposed to fix that." -- Jay Miner

@bison

320x400 should be faster. Drawing the columns is relatively straightforward once you've done the clipping.

_________________
This is just like television, only you can see much further.

@bison

Quote:

bison wrote: RAM was expensive, but low-resolution mode only has 64K pixels, so I think the missing chunky mode is due to lack of foresight more than expense.

A picture 320x240 pixels needs 76800 Bytes
for fast GFX you will need double buffering, that's 153600 Bytes
For 8 sprites with 16x64 you will need 16384 Bytes
So You may end up with 160kB wasted just for the video buffer.

And there is still no reserves to place the GFX source or sound.

Not much for a 2MB AGA system, but to much for the original 256KB Amiga 1000.

---

It was around the time of AGA, when 8 Bit planar meant the same resources like a 8-Bit chunky GFX had been.

This is why I used to say: AGA was an expansion done in the wrong way.

But in OCS times, planar was absolutely OK.

Last edited by OneTimer1 on 05-Apr-2020 at 04:39 PM.

(Sorry for yet another wall of text)

VGA was designed for PCs which at the time had little directly accessible memory especially in real mode running MS-DOS. The video memory was mapped into a 64KiB window and normally for EGA and VGA modes only one bitplane was visible at the time, this meant that software rendering would have extra overheads as operations would have to be repeated for each bitplane. At the same time there were a cost optimization factor which made something like the Amiga blitter out of reach.
The solution was to enable some parallel processing on the video card while keeping it dumb, the intelligence was to be provided by the CPU triggering bitwise operations. The Amiga was absolutely superior not only in simultaneous visible colors (even ignoring HAM and copper effects) for higher resolution modes but also for having the blitter capable of doing faster raster operations and this while the 68000 could do other thing at the same time.

Mode-X (don't like the name) is due to how IBM retrofitted MCGA support onto an extended EGA design. As each bitplane access is nominally byte size into a (hidden) bitplane shifter (like on the Amiga) they decided to keep the 4 bitplanes but use each bitplane access as one color pixel byte skipping the bitplane shifter. Now if all pixels would be store on on a single bitplane things would be easy with 64Ki pixels directly addressable by the CPU however for some reason I can't remember (parallelism in bitplane reads perhaps) they decided to store pixels interleaved in all bitplanes however adding a mechanism so that CPU accesses bitplane 0 at byte 0, plane 1 at byte 1 etc. Almost perfect MCGA emulation if the other EGA/VGA stuff is set up perfectly right but with only a quarter of the normal video memory available*.

Of course if one set up the internals "wrong" in the right way the CPU can see things as in normal bitplane mode with a single plane visible at a time and then the acceleration hardware is also available which meant one CPU read can read 4 "bitplanes" (pixels) into internal latches and one write can also write 4 pixels. Used right this can accelerate sprite rendering and screen fill. It also enables the all video memory to be available for use which indirectly enables higher resolutions and multiple screens to be stored and (via the scrolling mechanism) multi-buffering.

But it isn't a panacea as now many types of rendition have increased overheads with direct rendering being harder if graphics can't be stored in a hidden screen and copied using the acceleration hardware. Any line not strictly vertical is expensive to draw and copying a image from main memory to video memory is hard, actually doing that effectively requires a type of chunky-2-planar routine often using internal CPU caches as a temporary storage. Not fun.

The Amiga have directly accessible video memory, a blitter, a copper, sprites and a lot more. It's superior with the exception of a 256 color chunky mode which as we all know became a huge problem for Wolfenstein 3D and DOOM. But the parallelism in VGA isn't in any way what made the difference and Commodore could likely have added something similar to the Mode-X design by like it bypass the bitplane shifter for a direct color lookup with few extra complications.

(* actually not true for the original IBM VGA as it supported a special 128KiB CPU window mode, sadly most clones didn't)


@bison
Scales as Column_setup * x_resolution + Per_pixel_cost * (x_resolution * y_resolution) with the per column cost higher than the per pixel rendering cost => 320 x 400 is cheaper.

In practical hardware where pixels are normally stored row-wise it isn't as obvious if for instance several columns can be rendered simultaneously with one rendering operation like for instance close walls with a low resolution texture.

Last edited by megol on 05-Apr-2020 at 10:50 PM.

The Amiga blitter also provided some possibilities. Serial bitplane writing in one operation. Limited zooming and scaling. Texture fill. And texture rotation. Perhaps most useful to least useful.

A serial write operation can blit an image with all bitplanes in one go. Interleaved bitmaps provided some optimisation. You could stack all the bitplane lines together so one blit could write to several bitplanes in one go. This was limited by the blit height which was increased to 32768 on ECS. As was the width. This makes it fairly easy to blit an object of any width, height and depth in one go. A 256 line screen expanded to a 2048 line blit for 8 bitplanes.

No much can be done horizontally. But the blitter can easily scale verticaly. It can't exactly do gradients. And scaling up would be harder. But it can easily scale down in exact sizes of half, quarter, eighth, sixteenth, etc. Just tell it to skip lines! This could be broken down into sections for a more gradient scale. But could require lots of little blits. Halving across would be terrible by blitting every second pixel.

The blitter can perform a limited texture fill. Likely limited to cartoon graphics. It works like a mask.

The blitter can rotate textures and write them into the bitmap. Unfortunatey, the textures can be only 16 pixels long, so would need a lot of small writes. But it can take a 16x1 block of pixels, rotate it any direction you like, and write it into a bitplane.

Last edited by Hypex on 12-Apr-2020 at 06:45 PM.

@BSzili

My understanding from reading Fabien Sanglard's book is that graphics data are drawn off-screen and copied. From page 183:

Quote:

To host the framebuffer in the core and not in the video system itself was an audacious trade-off: it was a performance hit since data had to be copied twice before reaching the screen.

I'm not quite following how the data is copied twice, unless he considers the initial draw to be a copy.

_________________
"Unix is supposed to fix that." -- Jay Miner