Saturday, 15 August 2026

Pixel Addressable Colour on Freebee

The Microbee Premium had enough Programmable Character RAM to assign a unique PCG character to every spot on the screen, so you could display a picture that filled a 512 x 256 screen. It also had colour, but alas the colour was organised by character, not pixel. So a character had a foreground colour (1 of 16) and a background colour (also 1 of 16). So if you wanted to draw something that had more than 2 coulours in the same 8x16 character cell, you were out of luck.

Other computers of the time had pixel addressable colour, where an individual pixel could be any one of 16 colours. This makes for much more expressive games etc. There was usually a compromise though - full colour displays were usually only 320 x 240 (40 column), while monochrome displays did higher pixel densities.

On Freebee, only four of the attribute bits actually do anything. The other four are available for our use. Let's use attribute bit 7 to determine if a character cell is normal Microbee character colour or pixel colour. So if this bit is set, for that character rather than doing a screen addressed fetch for colour, then a character addressed fetch for character data, let's instead do a pair of character addressed fetches, yeilding 16 bits of data. Now if we make a character four pixels wide, we have enough data to describe a unique 4 bit colour to each of our four pixels. We are now able to display a glorious 320 x 264 full colour picture. Of course we need more memory for colour (say 32K rather than 2K, but this is easy. Just increase the video RAM size to 128K (a single 628128).

It's not at all Microbee compatible, and we don't care. Keep attribute bit 7 reset and it'll work like a normal Microbee. Indeed as the determinant for pixel colour is stored in the attribute RAM, we can freely mix pixel addressable colour on the same screen as character addressable colour, plus we get all the sorta-kinda advantages of PCG characters, where we can move character sized blocks around with just a couple of writes, rather than having to laboriously write every pixel.

So here are the schematics. Note this is pre layout, so the designators will change quite a lot. Essentially there is a bigger RAM for video - a 628128 128k x 8 SRAM. This has enough space to store screen, attribute, colour, 2 x character sets, 16 banks of PCG, plus another 32 banks of "pixel colour" PCG.

IC44 latches one byte of pixel colour PCG, and IC40 (shared with colour) latches the other one. When we want to output a pixel colour block, the 16 bits are spread across the outputs of IC42 and 44. Again, IC42 is shared with colour. IC46 and 47 do a simple 4 of 16 select to push out each pixel at the 1/2 dotclock rate. Note I use the tristate ability of the muxes to allow the selection of either normal character based colour or pixel colour.

Now there's no way I'm going to fit this much extra stuff on the board, so I caved and put the address decode in PALs. I chose PAL16P8 chips, which werer available in 1986, so aren't cheating. Actually I'll use ATF16V8 GALs, as these are readily availabvle in 2026 and emulate a 16P8 quite nicely. Two PALs (IC 49 and IC53, do the address decoding for the video RAM - one for CPU access and the other for CRTC access. A third (IC50) eats up a lot of the random logic used for enabling the various latches and buffers in the video circuitry.

The result is 54 chips, compared to 60 of the normal FreeBee Fremium. Perhaps I could sneak a RTC on the board as well...