I've been flirting with the idea of the VDU card for a while now. Even though I used to roll my own X11 modelines, the idea of actually putting all these weirdly interrelated counters and comparators together scared me. It's clearly easy to make a CPU out of 74xxx ICs — just look at all those people doing it (myself included). Try researching video cards and you won't be so lucky. Dennis Kuschel's MyCPU ‘VGA’ card is a six-Eurocard monster, bigger than the processor of his homebrew computer. And this guy knows what he's doing. I don't.

I toyed with the idea of using the TMS9918 (used on the TI-99/4x machines, MSX, and pretty much everything else) and the MC6845 (used in the IBM MDA, CGA, the BBC Micro and many others) to keep things simple, but I'm not entirely comfortable with falling back on too many LSI chips. The 6845 isn't easy to find. I have a TMS9918, but I don't want to use that either because it's too limited (no 80-column mode, for instance), and too familiar. I'm not making an 80s home micro.

Pin-compatible FPGA re-implementations on little daughterboards are an option, but then I'd be using FPGAs. And there's one serious drawback to using the 6845: it's designed for 15 kHz monitors which were ubiquitous in the Eighties. They're also incompatible with the VGA's minimum 30 kHZ horizontal rate. This drastically limits the display devices I could connect to the CFT. Granted, I have several monitors in fantastic working condition, but I need the flexibility and I'd rather not destroy an old monitor. Multisync monitors are much more forgiving.

So if I want a VDU card I'll have to bite the bullet. I played with some designs and have so far come up with a single 640x400 resolution (which already pushes the limits of HC technology). I only want text mode, but it's so cheap to get large Flash RAMs that there's no sense limiting myself to just 256 character patterns. And the CFT is 16-bit. I also have a heap of 256 kBit fast SRAMs from old motherboards, so I have plenty of video RAM, enough to double over for up to 65,536 characters.

I may only be doing text mode, but the character cell height is programmable. I went for values of 16, 8, 2 and 1. Bear with me.

640×400 can accommodate an 80×25 mode with nice, readable 8×16 character cells. Add a register bit, a flip-flop and a multiplexer and you have a 40-column mode (320×400). Since there's plenty of character generator memory, I can do block graphics and high-resolution graphics in various styles.

Since the character generator has memory to spare, I can produce block graphic characters in 2×2, 2×4, 4×1 and 8×1 arrangements. Bear with me about the weird ones, things will become apparent.

Video RAM is organised as two planes, each 32 or 64 kW (depending on how many SRAMs I want to wire up). The B (bitmap) plane contains character data. The C (colour) plane contains colour and attribute data. VRAM is accessible through two 4kW (12-bit) windows, crammed in a 4kW (13-bit) CFT memory page. The Video Window Register controls the offset of the windows, both of which move in tandem.

Speaking of colours, and since there's plenty of memory, I went for 64 of them. That's two bits per channel, six bits per colour. The DAC R-2R ladders are easier to do, and there are enough colours to play around. Each character cell position has two colours: foreground and background. There are no colour look-up tables. Keeping it simple. There are two attributes though: inverse and blink. Inverse flips the values of the foreground and background colours. Blink sets the value of the foreground colour to be that of the background colour every so often. This can all be done with a couple of 8-bit buffers and a little look up table made from 74xxx logic.

Now, back to the modes. Take the combinations of 40/80 columns; 16, 4, 2 or 1 rows per character and 2×2, 2×4, 4×1 and 8×1 block graphics (or 8×16/8×8 letter shapes), and you get 48 different modes (even more depending on interpretation), not all of which make sense. You can do text at 40×25, 80×25, 80×50; low resolution block graphics with free colour selection at 40×25, 80×25, 40×50, 80×50, 80×50, 80×100, 80×200, 80×400, 160×50, 160×100, 160×200 and 160×400; medium resolution graphics at 160×100, 160×200, 160×400, 320×100, 160×200, 320×200 (with colour restrictions); and high resolution graphics at 320×200, 320×400, 640×200, 640×400. Even more combinations are possible, and it's incredible how flexible this scheme can be.

Speaking of high resolution graphics, I lied. This is still a text mode with 8×1 cells. This makes it completely useless for text, but perfect for the 256 8×1 block graphics characters. Use those and you get pixel addressable graphics. You can only have one foreground and one background colour per 8×1 block of pixels, but that's pretty standard for this class of VDU driver. Most computers in the Seventies and Eighties would do worse than that.

Having cut my teeth on a non-Extended BASIC TI-99/4A (one accessible mode) and an Oric Atmos (three modes, but very restricted), this got me excited. So I coded a proof of concept in Verilog, and an emulated equivalent in C (for the CFT emulator). Here are the results of the test runs — some have simulated dead/noisy character ROMs or video planes, just to test the feature set.