Getting Freebee Premium to run at 13.5 MHz

Late model Microbees generally run at a 3.375 MHz CPU clock. The Peter Broughton 512K OS included a scheme for doubling that to 6.75 MHz, which was generally problematic. I really want Freebee to run at either 3.375 or 13.5 MHz - ie a full four times the original speed - selectable by software. On the prototype I was cowardly and included a jumper so that the fast speed could be jumpered to either 6.75 or 13.5 MHz.

Turns out the jumper was a good idea, as I simply can't get video CPU read and writes to work reliably at 13.5 MHz. Everything else works a treat (for example talking to the CRTC and the PIO, plus normal memory reads and writes). Additionally my video arbitration logic stops CPU access until the retrace period, so often there are whopping great 60usec long access times.

I've been working on a scheme for more rapidly swapping from CRTC access to CPU access for the video RAM. It involves doubling the RAM access speed (again!), and inserting a CPU access in between each video access, so screen, cpu, attribute, cpu, colour, cpu, character, cpu etc.

Life is complicated with the Z80 because unlike a 6800 it does accesses across multiple clock cycles. Morover, the accesses are wildly different for opcode fetch and other reads, incuding a requirement that the data is valid on the rising edge of the CPU clock for opcode fetch and falling edge of the clock for data fetch. Go figure.

So here's the scheme I'll be prototyping to make that work. It involves separating reads and writes out. Writes are just done via a straightforward buffer to isolate the CPU data bus and the video RAM data bus, but for reads, we use a register to hold the data from the memory, clocked at the end of the (short) access cycle, and present that data to the CPU data bus for as long as it needs it.

The flip-flops that hold the CPU in wait until the retrace period are gone, and replaced with a straightforward 1 clock wait state generator. This is needed to make the CPU wait long enough for data at 13.5 MHz.

Now to design this into a new PCB. I've ditched a component in the old wait state generator, but added one in the data bus flip-flop, so it should be even in terms of component count.