Thread by @TubeTimeUS

i've been digging into Tandy graphics modes to understand how they change and improve CGA. the implementation may not be as hard as i thought. 🧵

(screenshot from oldskool.org/shrines/pcjr_t…)

the most obvious difference is that Tandy modes support a 320x200 mode with 16 colors instead of just 4. but how do they do it?

to understand, first we need to compare the text modes. CGA has two: 80 column and 40 column. these are the timings that get programmed into the CRT controller chip.

you can see here that each mode has the number of character columns programmed into register 1. interestingly enough, regardless of the mode, a single horizontal line takes 64 microseconds to display.

40 column mode has fewer pixels, so the clock feeding the CRT controller must be running at half the speed.

the CGA has a bit in the mode control register that switches the CRT controller between a fast clock and a slow clock. the clocks are called HCLK and LCLOCK (high and low clock speeds).

(i meant to say LCLK instead of LCLOCK.)

with the CRT controller in 40 column mode and LCLK selected, you get 320 horizontal pixels per line. this setup *just so happens* to be used for the 320x200 graphics mode as well.

OK so what about the 640x200 graphics mode? you might think it uses 80 column mode, but it doesn't!

it's a trick: 640x200 graphics mode is actually 320x200 but they clock out two pixels per "pixel" by splitting the 2 bits per pixel (320x200) into 1 bit per pixel using a mux and a flip flop.

so graphics modes in CGA always use LCLK, and only 80 column text uses HCLK. but what if you try to set up a graphics mode using HCLK instead?

well, you can get a 4 color 640-pixel wide graphics mode. unfortunately it has a nasty achilles heel: the CGA card doesn't have enough video memory to fill the full 200 lines.

see, the CGA card cheats again and uses a nasty hack to generate the timings. the CRT controller doesn't know about graphics: all it knows is that it is configured to produce a text mode of 100 lines, and each character cell is 2 rows tall!

in fact, in graphics mode, some logic gates reroute the "row address 0" line from the CRT controller and it becomes the most significant address line for video RAM! this is why CGA has the weird interlaced memory map.

let's say we double the video RAM to get 32K. that should be enough for 640x200 at 4 colors (2 bits per pixel).

how do we address all that RAM? we have one extra address bit. what we can do is tie it to "row address 1" from the CRT controller, and change the size of the "character cell" from 2 lines to 4 lines.

this is essentially what the Tandy graphics modes do. we get 4 scan lines per row and 50 "character cells" per screen instead of 100.

but wait! you say. that gives us 640x200 at 4 colors, but what about 320x200 at 16 colors?

well, i'm glad you asked.

it's another dirty hack! 320x200 at 16 colors is actually 640x200 but with a *demux* that takes two adjacent pixels and combines them into one. 2 bits per pixel, 2 high res pixels gives you one low res pixel with 4 bits per pixel ➡️16 colors!

of course Tandy also adds some other features, like a 160x100 16-color mode, multiple pages of video RAM, and a palette register file.