Video Display Cloning

Timing

To duplicate the displays of old micros, you need to know the signal timings.

Horizontal Timing

NTSC and PAL have very similar timings to display horizontal lines.

For simplicity, this discussion will assume 64 µs per line.
This is split into the following regions:

I started by looking at the timings of the 6847 chip, used in relatively simple micros (the Acorn Atom and the Tandy Color Computer). For economy it uses a single crystal (3.579545MHz) to drive the colour signal, the dot clock, and the entire timing chain for memory accesses. It clocks out pixels at both clock edges (so a 50% duty cycle is required), i.,e. at twice the crystal frequency. There are 8 pixels per character cell width, so characters are accessed at a quarter of the crystal rate - i.e. 0.8948863 MHz.

Interleaving

It is possible to interleave CPU/VDG memory accesses so each has alternate access without interfering with each other. This is just what the Tandy CoCo does. The Acorn Atom however does not, which allows it to run at its own maximum speed - 1MHz . The Atom avoids disrupting video by restricting access to the non-display periods.

I wanted to produce a 6847-like system that would suit both micros. I have a PAL-standard TV, and wish to drive it via the RGB inputs of its SCART socket, so the NTSC colour crystal frequency is not required. I am free to use other crystal frequencies for the timing.

A later Acorn machine - the BBC micro - used a 6845 video sequencer chip, and interleaved access at 1 (or 2) MHz in 40 (or 80) characters per line modes.

At 8-pixels per character width, and 40 characters per line, the BBC micro produces 320 pixels in a 40 µs time period. The 6847 in contrast uses 32 chars = 256 pixels in 35.76 µs. About 80% shorter time and narrower display.

Square pixels

At this point it is worth pointing out the desirability of square pixels - i.e. when you draw 100 x 100 pixels on a screen it appears square. This simplifies display geometry. Pixel height is of course fixed by the TV standard, but the pixel width depends on the pixel clock.

Clearly the BBC micro's 6845 and the 6847 cannot have the same pixel aspect ratio, so I measured their displays on my TV to find out the ideal pixel clock for square pixels. I found the BBC micro in 320x240 pixel mode (8 MHz pixel rate) gave almost square pixels. The few percent error I can attribute to the TV's own width-adjustment settings being slightly off.

So it seems the nominal horizontal display time is 40 us. This is smaller than the 52 µs TV picture display time because a TV picture normally goes from edge to edge, while a computer image must not lose anything at the edges hence a 6 us margin left and right.

A 40-char display shows 320 pixels in the 40 us. For 32-character displays to clock out 256 pixels in the same time, the character rate is reduced from 1 MHz to 0.8 MHz. The dot clock drops from 8 MHz to 6.4 MHz.

Suddenly, a few facts clicked into place. The ZX81 (designed for the UK and PAL) has a 256x192 pixel display, and a 6.5MHz dot clock which is near enough the ideal 6.4 MHz.

I reckon that 40 us is the ideal time, and 6.4 MHz is the ideal for 256 pixels in that time.
8 MHz is the ideal for 320 pixels in that time.

Pragmatic decisions

Ditching the NTSC colour crystal based timing allows both the 6502 and the 6809 to run at their standard maximum ratings of 1 MHz and have square pixels. As an added bonus, it makes higher-resolution displays (40 chars / 320 pixels wide) possible.

Video RAM decisions

The original CoCo teamed the 6847 with the 6883 - a chip that multiplexed addresses and generated control signals for dynamic RAM. Close inspection of the timings for typical 150 ns rated DRAMs show they are safely met by the 6883 with an NTSC colour crystal, but there is not much room for 'overclocking'. Running the CPU at 1MHz shortens the access time required. The 6502A of the BBC micro can run at 2 MHz, shortening access time even further and hence the BBC micro used 100ns rated DRAM chips.

Static RAM chips have simpler timing diagrams. These have more address lines to drive but this seems a fair trade in return for simpler interfacing. I'd prefer to get a simpler design running first then improve it later, than to spend longer getting a more complex design running.

Usually, static CMOS RAM chips are designed to run at a balanced speed (70ns to 150ns) and power. However, the PC industry created a demand for cache RAM that was faster that the main DRAM, and static RAM chips were produced optimised for this task. As a result, you can get very fast static RAM (15 to 20 ns) pretty easily. I picked up an old 486 motherboard with nine UM61256 SRAM chips (32K x 8 bit, 15ns). I thought they would be expensive (because of the speed) but they are only £2 ($3) from Maplin (the UK equivalent of Tandy).

Fast SRAM also opens the door to some serious overclocking: 15ns = 1/66 MHz! The 6502 is available up to 4 MHz tops, but if I stick a VHDL 6502 into my Xilinx X2C200, I could be running it around 40MHz! I'll need to the EPROM copy itself into the RAM first (I don't know of any ROM that fast and cheap), then switch the clock to higher speed. It would be amusing to see an old micro with a 'turbo' button, running many times faster than normal. It might blow away all those software emulators running on Pentiums!

This recent look at RAMs made me realise how slow these things are compared with the CPU.
My PC's CPU is running at nearly 1 GHz, main DRAM modules run about a tenth of that, and only then through clever access modes.

Proposed New '6847' Display Horizontal Timing

The 6845 bases timings from the top left corner of the active display area, and the diagram below follows suit.

Of the 52 µs active picture region, the margins are defined to centre a 40 µs (320 pixel) window. It would also be possible to make the timing centre a 256-pixel window by changing the margins to be 8 µs each, but for now I would like to keep things simple by using this one timing which will suit both sizes.

The front porch and sync pulses have been rounded up to the nearest couple of microseconds.

Proposed New '6847' Display Vertical Timing

The 6847 had a significant nuisance in the UK - it ran at 60 Hz field rate (NTSC standard) while the UK expected 50 Hz (PAL). Most cheap TVs managed to cope with this but some did not. Imaging coils are designed to run at their resonant frequency. Anything else is less efficient and generates more heat. A good TV would be quite right to refuse a non-standard signal. Designing with programmable logic allows this problem to be fixed.

The Atom sensed the frame sync pulse to sense when it was safe to write to the screen without causing snow. With an interleaved memory system, any write is 'snow-free', so the CPU can omit 'anti-snow' procedures to have full-time access to the screen. This accelerates video-intensive operations.

The Atom also sensed the frame sync pulse to provide timing information. Some software might rely on this to regulate the speed of events - e.g. the ticking of a real-time clock. For this reason it might be worth generating a 'fake' 60Hz signal that is nothing to do with the real frame rate but exists solely for the benefit of such programs.

The BBC micro's default 6845 register values

Values cross-checked with BBC documentation.

PAL requires 625 lines = 312 lines in even field, 313 in odd field.
Registers 4 and 5: (38+1)x8+0 = 312, (30+1)x10+2 = 312.

6845 register settings to emulate the 6847

Cursor registers are not relevant to 6847 emulation because the 6847 has no hardware cursor control.

Ideally the memory would be scanned as rows of characters with either 1,2,3,4,6, or 12 scan lines per characters, but register 4 can only go up to 128 character rows so it is not possible to choose 312 character rows which are one scan line high. The best it could do is 312/3 = 104. Instead, the 6845 is set for 39 rows of 8 lines per character row. This requires the character row outputs from the 6845 to drive address lines of the display instead of the font-generator ROM.

Of course the 6845 model could be extended to count beyond the 128-character-row limit, but for now it would be simplest to see if the 6845 can work with the fewest modifications.