Semi-graphics-6 display mode

There is a semi-graphics mode that allows mixed text and graphics with six subblocks per block-character, instead of the four subblocks that you get automatically in the CoCo's text mode. It is called Semi-graphics-6. But you can't get it through Color Basic's PMODE, and it isn't quite as colorful as the Tech Manual (or 6847 data sheets) would have you believe.

The way the CoCo is wired, semi-g-6 is a bit limited. The 6847 VDG and 6883 SAM can both be configured for it, but in the CoCo the most significant VDG data bit is hardwired to the VDG's '*alpha/semi_g' inputs. This allows it to automatically switch between alphanumeric mode and semi-graphics mode based on the MS data bit, which allows mixed text and block-graphics on the same screen. But in semi-g-6, the two MS bits are also used by the VDG to determine the color of the 'on' subblocks. So while you can tell the VDG to do semi-g-6 rather than semi-g-4, you still need to turn on the MS bit of each data byte to turn on semi-g rather than alphanumeric mode, and that partially selects the color to be displayed; half of the four colors are unavailable because of that. Well, maybe that's not so bad.

The other semi-graphics modes were awkward for two reasons: they used more memory; and to get a single whole letter, you'd have to store the exact same character code in several places. For instance, in semi-g-12, each character block was divided into twelve subblocks, two horizontal by six vertical. Each horizontal pair of subblocks came from a single byte of memory. So you could get the top 1/6th of a letter "A", and the second 1/6th of a letter "Q" just below that, and then 1/6th of a letter "M", etc, by storing an "A" in one place, a "Q" in another, an "M" somewhere else, and so on. If you wanted the whole letter "A", like in a readable message of ordinary text, you'd have to store the character code for that "A" in all six of those places - you get the top 1/6th of the first, the second 1/6th of the second, etc. Writing a message on the screen would be a bit of a pain. Of course, nifty symbols could be made from fractions of letters this way, too.

The other semi-graphic modes don't have the same color-set problem as semi-g-6, because they don't use the MS bit of the data byte; they use essentially the same coding as for semi-g-4 (I think the VDG is actually programmed to think it is doing semi-g-4, and it is just the SAM slipping it data from different locations than it expected). But those other modes pay for their colors by using more memory. Semi-g-4 and -6 use only 512 bytes for the display, like an ordinary text display, one byte per block.

I suspect the tech manual is wrong about the color sets that "should be" available for semi-g-6 - why would they have two different ways to encode buff/green? It seems they should have just taken the CSS bit and used it like the C2 bit in semi-g-4, so the colors should be: To test this out, you'd need a non-CoCo setup, or have to cut the trace that connects DD7 and *A/S on the VDG. (Maybe a switch there could let the thing act normally until you get the screen set up, and then you could flip the switch to see the hiding colors). Back to my top-level CoCo page

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