On the verge of finishing my greatest ever 4K video art, I've begun to explore the other end of the video world — the Apple II's NTSC artefact colours.
First up, the 6-colour mode that debuted (with a tweak) in the 1977 Apple II (original model) — it can actually do ten colours:
 |
| … depending how you feel about dithering lines that aren't interlaced to begin with? (credit: Beagle Brothers) |
Remember this is on a 192-line frame contained on a 240p display fed to a 480i TV. But it does make the moon in Choplifter™ go from stripey-colours to grey. It's the moon so it must be true.
Next question: What do you call those colours? Not-quite-yellow, not-even-cyan, crazy-violet and are-you-even-blue?
Well, if you've been paying attention, you might recognise these as your weird friends in those other colours who didn't fit in the normal colour bars, from the test pattern as seen in Europe and Australia:
 |
| "PM5544", so much better than those SMPTE bars. Yes, this is one of the NTSC versions. (credit: William Brown) |
And what do those sections of the almighty test pattern denote?
1 + 5 = chroma 180º which is 75% yellow, 25% green
1 + 6 = chroma 270º which is 75% cyan, 25% green
2 + 5 = chroma 90º which is 75% red, 25% magenta
2 + 6 = chroma 0º which is 75% blue, 25% magenta
 |
| If only the many t-shirts that ripped off PM5544 had checked with this first. No, not NTSC: horizontal acuity is too high. |
In fact it's worth pointing out here what the HGR colours really are:
1 = chroma 225º green
2 = chroma 45º magenta ("Violet")
5 = chroma 135º which is 50% red, 50% yellow ("Orange")
6 = chroma 315º which is 50% blue, 50% cyan ("Blue")
 |
| credit: gvworks.blogspot.com |
In the revision A motherboard of June 1977, the Apple II only showed green and magenta (plus black and white), with two bits per (colour) pixel in high-res graphics (colour mode). A third invisible bit per (colour) pixel was soon added that shifted the colour phase 90º — this then formed the basis of the colour graphics for the largest collection of games and software until MS-DOS. That's why the two "new" colours don't have a proper name but you can see why they make logical sense if you want a balance; you can create any other hue via dithering, and Apple II graphics don't show a tint bias.
Second up — the more complex, far less supported 16-colour mode introduced in 1983: still the same number of (colour) pixels, but now with 4 sub-pixels instead of 2, thanks to the 80-column mode doubling the resolution. That's a proper 4 bits per pixel, rendered straight onto the NTSC signal like CGA composite*, no phase bits. If you subtract black, white and the two new greys, that's 12 colours, or 8 new colours.
 |
| That's probably just a complete coincidence … right? |
As you can see, text on colour backgrounds is a challenge.
Coloured text on coloured backgrounds even more so. The situation on Apple II is generally:
- Normal high-res (HGR) gets you 40 columns of black & white text
- Double high-res (DHGR) gets you 80 columns of black & white text
So perhaps double high-res could accommodate colour text in just 40 columns? The Beagle Brothers toolkit only supported that in 20 columns though, because the (colour) pixels are still as wide, there are still 144 total per line. Nevertheless 🤔 there are now 4 sub-pixels to play with … ?
The text generally used on Apple II is only 1-pixel thick. If you lay 40 columns onto the DHGR mode, they're now 2 pixels thick. But you need 4, most of the time …
Interestingly, the Apple IIgs had already faced this problem in its Shaston system font. Back in 1987 they had to make a system font that was generally 2 pixels thick — and this is in 640 mode (the equivalent of 80-column mode, but in an entirely new graphics system). They had to make it 2 pixels thick because the only way to create the colour grey was black-white dithering (like a B&W Macintosh), and they needed grey for the menus (like a Macintosh):
 |
| credit: http://www.whatisthe2gs.apple2.org.za/ |
But that's not all that makes Shaston interesting:
- It still had to be legible when the dithering was active — each dot in the ellipsis "…" is visible
- It still had to look good in 320 mode, at double the width
- It still had to be small enough to work on half-SDTV 240p video
- Unlike the rest of computing in the mid-'80s, this font didn't suck
So we have a font that will guarantee 2 pixels width everywhere on 40-column DHGR, but try its very best to give 4 pixels at all the important times — albeit a bit offset, so the colour starts in the middle of its "colour pixel" but continues into the next.
I threw a bunch of pixels at the next-best thing to a real NTSC monitor and this is what I got:
Surprisingly, far more legible than expected. On the left half, a lot of the "Shaston pixels" line up exactly with the DHGR colour pixels, so you get a bunch of blocking. The two sets of "ABC012" are aligned differently because each letter is 14 pixels, and doesn't fit neatly in a 4-pixel cell, so repeating the same string on an odd or even character will create a different result. This is necessary if you're going to fit 40 characters into 144 colour pixels, though.
On the right, I pushed everything to the right by a pixel. In theory, this should always be worse, because you won't have a single colour occupying each "colour pixel" block very often. (In reality, there is always a single colour occupying it … but it will be neither the foreground or background colour you chose). In practice though, it looks far more promising.
The bottom half was an experiment in adding an extra 1-pixel edge to any rounding on the shapes, e.g. the top of the "A" is round. To the real Shaston font, this is only a half pixel in its universe. I gave up on this as it seemed okay in lesser emulators but didn't produce superior results here.
After trying a few more colour combinations, what's more interesting now is that the non-offset versions sometimes win. It looks blurrier but always preferable, very much like any other antialiasing on graphics systems 20 years hence.
One goal isn't to generate every single colour combination, but only the RGB+CMY+B&W combinations found in teletext and videotex. This was a 40x24 (actually 39x23) system that was used in European televisions and dial-up terminals in the 1980s to create a kind of socialist-paradise internet prototype. A very colourful one at that, so naturally it has a cult following, and an app for Apple TV 4 to let you see what is broadcast by most of the TV stations in Europe that still use it.
DHGR's "pink" on "dark blue" is far more legible than the colour generally called "red" (I suspect it is 90º chroma). DHGR's "dark blue" seems a lot closer to the pure "B" in RGB's colour bars anyway, and it certainly works better on a yellow background for legibility. There are three greens and three blues to work with, so I will experiment to see if a substitution table can make all RGB+CMY+B&W combinations legible, without making it too obvious that they are changing.
There might even be a mathematical model to derive instead of a look-up table. I'm certainly hoping so when it comes to the selection of offset = 0 or 1 for any given foreground and background.
* for some really good reading on CGA composite tricks — and a lot more NTSC theory — go see the amazing 8088mph blog: http://8088mph.blogspot.com.au/2015/04/cga-in-1024-colors-new-mode-illustrated.html
