The ZX Spectrum Reverse Engineering and Clone Desgin Blog

Harlequin

A site dedicated to the reverse engineering of the ZX Spectrum and related projects.

< 30 of 68 >

Booting the Z80 with ROM

May 22, 2007

Prototyping the CPU/ROM/RAM circuit was a bit of a pain given the number of address and data lines that needed to be routed. I cheated a little by using some lengths of IDE ribbon cable cut into widths of 8 and soldered to 1cm lengths of solid core wire. This gave me some nice bus jumpers which I used for the data bus. The address bus was straightforward, if a little tight, to wire conventionally.

I checked each connection repeatedly with a multimeter as it is quite difficult to spot any wiring mistakes. The whole thing took a good few hours as being neat would pay later if there were any errors or modifications to be made.

I checked all the usual signals with the oscilloscope: the clock, RD and WR lines, MREQ etc. All seemed to be changing state, but were difficult to lock on to as the period between transitions was variable.

Instead I just hooked it up to the TV and turned on.


I didn't get exactly what I wanted. I did get to see the familiar reset screen (black background with thin red lines zipping up the screen and then clearing), but mostly it reset over and over, occasionally displaying a partial screen (as in the photo above).

My immediate suspicion was memory contention due to timing issues. I held VMVen high whilst resetting the CPU. This gave the CPU exclusive access to the lower 16K memory whilst the ROM initialised everything, the screen was really psychedelic! A few seconds later I reconnected VMVen giving joint access again and saw the familiar greeting screen:

I suspect that write access was being interfered with by the video circuit which was preventing the screen from being written to properly, and the system variables set up correctly. This was leading to the repeated resets. Once the screen and memory had been initialised by the ROM, shared access seems to work normally, and this makes me suspect that the RAM switch between video read mode and CPU write mode is the problem. Staying in read mode (after the initialisation phase) as you switch between CPU and video access appears stable.

Tracking this down is likely to be interesting as it's tricky to pin down and latch the oscilloscope onto specific time points.....