Color Computer text display

This all applies to the CoCo 1 and 2 only; the CoCo 3 had much more sophisticated graphics and memory management, which I don't know much about. It was originally written in answer to a question about displaying text with graphics on the same screen.

In "text mode", a chunk of memory is used for the display, one byte per character. But each byte can hold one of 256 possible character codes, and the ASCII code only defines 128 of them, so there are plenty of leftovers. 64 are used for ordinary ASCII characters (the lower-case section is not supported); another 64 duplicates that, but in inverse video; and the remaining 128 are for block graphics.

A block graphic character is subdivided into four smaller subblocks, and all 16 patterns of turning these on and off are allowed. Each block graphic character also has a color, chosen from a set of eight. All the "on" subblocks in a block have that same color, and all the "off" subblocks are black.

In a byte representing a block-graphic character, one bit (the most significant) distinguishes block-graphic characters from text, the next three bits are used to choose the color, and the least-significant four bits are used to turn each of the four subblocks on or off. There is a one-to-one correspondence between those four LS bits and the subblocks, so flipping a single bit will flip one of those subblocks. (One could imagine mapping each of those 16 bit patterns to some block pattern in a different way. Fortunately, Motorola had more sense than that, and did the straightforward thing.)

The following one-liner lets you see all the characters in the character set on the screen all at once:

	FOR I=0 TO 255 : POKE 1024+I,I : NEXT I

Since this covers the top half of the display screen, you should enter the command on the lower half. Otherwise the "OK" prompt will cover up some of the pattern when the command finishes. Also, you don't want to enter it as the last line on the screen, because then you lose the top of the pattern when the screen scrolls to display that next "OK" prompt.

There are several pure graphics modes available, offering various tradeoffs between resolution, the amount of memory used, and number of colors allowed. In none of these graphics modes was text directly supported. You could, of course, draw characters on the screen by flipping the right pixels on and off. But you can always do that with graphics.

Also, odd modes could be had by POKEing the VDG and SAM chips into different modes (they normally cooperate closely to produce a video mode). You can get interesting effects, possibly including some readable text intermixed with some finer-subdivision of block graphics. In short, this worked by telling the VDG to do text while telling the SAM to do graphics. So the SAM wouldn't repeat the same string for enough scan lines to complete a (block) character, and the result was half (quarter, eighth, etc.) of one character and half (...) another. But it would use more memory, be a awkward to use, and I've never seen it actually done on purpose. Back to my top-level CoCo page

17-Mar-96

yakowenk@csx.unxc.edu

(remove all "x"s to get a valid address)