That page is a little bit confusing, yes. It's mixing up the concept of the frame buffer and the palette without explaining how they are distinct. Without trying to confuse the issue by talking about DACs and how the monitor works, it might be easier to just talk about how what they are and how you use them.
A frame buffer, as they describe, is just a block of memory that represents the screen. There are a number of ways to represent the screen, but in this case (and for all practical purposes most cases relating to the Jaguar), it means that the memory represents a 2D array of pixels.
Now the page talks about bitplanes - and that is a valid way of storing more color depth information, the Amiga and the Atari ST worked this way. But the Jaguar doesn't use bitplanes in its hardware, instead it uses what's often called a 'chunky' mode, where all the bits run together. Let me explain in more detail.
Imagine a system where you have 4 possible colors -- each pixel thus needs 2 bits to describe it. (Don't worry at this time what the colors are - that will come later. Just that there are 4). For sake of example, let's say your screen is 320x200 pixels.
In a planar system, you would have two arrays of memory, each 320x200x1 bit in depth, so, basically, 320x200x(1/8) (because there are 8 bits in a byte) = (320*200)/8 = 64000/8 = 8000 bytes. So you would have two 8000 byte buffers, each representing 1 bit of every pixel.
In a chunky system, you just run the bits together. So you would have a single array of memory which is 320x200x2 bits, or 320x200x(2/8)=320x200x(1/4)=64000/4=16000. Note that it takes the same amount of memory, it's just arranged differently
A chunky system is a lot easier to work with -- you only have to look at one spot in memory to get the color of a pixel. In a planar system, you have to get one bit out of each plane, and put all those bits together, to know what color it is. So why use a planar system at all?
It's actually more efficient when you deal with sizes that don't work nicely into a byte. For instance, the Amiga has a mode that is 5 bit planes deep (for 32 colors). Making this work in a chunky mode would get very complicated, because you would have one pixel overlapping two bytes if you just streamed the bits together. Alternately, you could waste a lot of memory, by storing one 5-bit pixel in a byte, and throwing away the other three. This is easy to deal with in hardware but wasteful. A planar mode, however, just creates 5 bitplanes and doesn't waste a thing, and it's easy for the hardware to work with. But since it's not easy for the programmer, they fell out of fashion as soon as graphics became powerful enough to be worth it (such as 256-color modes).
All right, so the second program that graphics hardware had to overcome was how to get colors on the screen. Most early systems had only from 2-4 bits available for color, so that's 4 to 16 possibilities. It's pretty hard to map these bits directly to the Red/Green/Blue values that a display uses to make a picture -- in the 2-bit case you can't even do 1 bit per gun! So instead, the concept of a "palette" was created. Much like an artist's palette, this is a set of pre-defined colors, and they are simply numbered. So when the graphics system see "3" as a pixel number, for instance, it goes to the palette, and extracts the /actual/ color information for Palette Color #3. In older systems, these colors were hard-wired, but in later systems, including the Jaguar, you the programmer can define this color table and so you can make color 3 anything that the hardware supports.
The Jaguar supports mixing of 16 bit graphics, 8 bit graphics, 4 bit graphics, 2 and I think 1 bit graphics, and the Object Processor can automatically handle the lookups into the color table. (The caveat being that the Jaguar only supports one 256-color (8-bit) table, that all the various bitdepths share). 16 bit graphics are "high color" and instead of going through a color palette, they are directly decoded by the hardware. (16-bit RGB maps bits directly to the red/green/blue values, and 16-bit CRY actually uses a different hard-wired color selection system to provide 65536 colors).
The concept of a line buffer is almost unique to Atari platforms. Most systems define enough video accessible memory to provide a full frame buffer, and the CPU draws into the frame buffer, while the video hardware pulls from it. But the Jaguar (and the 2600 and I don't know about the 5200 or 7800) only provide a line buffer. The object processor normally fills the line buffer for you, and as a programmer you usually don't care about it, except that you have to provide the data that will ultimately go there. Basically, the video hardware only has enough memory to buffer a single line of video at a time (it's actually 2, but you can't do anything about the second one so no point worrying about it). The system has to erase and fill that line buffer in time to provide the data to the television set in real time - the TV will /not/ wait. If the line buffer isn't updated, whatever was in it was just be displayed again on the next line.
What this means to the Jaguar is you can actually run a game without a frame buffer at all -- the idea probably being that you save memory for your own purposes. The Object processor (and the blitter) can write into the line buffer fast enough to generate a scanline in real time, meaning as long as you can /calculate/ the line, you can display it without needing a big reserved block of data. In practice, though, most games use at least a little memory for building the display. For instance, the Jaguar hardware can not rotate a 2D sprite, so it has to be drawn rotated into a temporary buffer by the programmer (with the blitter) then copied out line by line (by the object processor). The hardware also usually renders polygons to a traditional frame buffer, because this is much easier (you don't have to keep up with the TV). In /theory/ it's possible to render polygons on the Jaguar without a frame buffer, but your code needs to be very fast and very smart, to draw the correct line segments and keep up with the TV.
Hope that helps.
Originally Posted by brewbuck
