A few weeks ago I finished the Harlequin Dynamic Memory interface. This was required to test the dynamic ram timing reverse-engineered from the ULA. Since then I have been designing a complete Xilinx CPLD implementation.
This CPLD work has progressed steadily, and I have so far implemented everything except tape and keyboard IO. There have been a few issues such as glitch and timing problems due to some aspects of the design taking on an asynchronous nature. The Xilinx ISE development tool and compiler really tries to look at everything from a synchronous point of view - and quite right too, as CPLDs are inherently synchronous devices.
So far I have a XC95144XL Xilinx CPLD hooked up to an issue 4A ZX Spectrum in place of the ULA. As the CPLD contains no analogue components such as transistors, resistors etc, so a breadboard provides a simple transistor oscillator driven from the Spectrum 14MHz crystal (which is proving to be particularly unstable, so a dedicated 14MHz clock is also there for comparison), and two output drivers for composite sync and green of the RGB signal.
The first test has been to generate a stable television frame to prove that the CPLD is clocking correctly. This worked as expected and so the CPLD was hooked into the Spectrum, as shown above. Here the CPLD is driving the Z80, updating the television picture and controlling access to the ROM and RAM. However, there is certainly something wrong with Z80 access to the lower 16K RAM or ROM as the video memory has not been written to with the usual ©1982 Sinclair Research Ltd message.
Something else that could be incorrect is the phase of the 3.5MHz clock. If this is wrong, then the clock will be held low during ULA video memory access instead of high. The CPLD implementation inverts its 3.5MHz CPU clock output, as the ZX Spectrum will invert it back to its proper phase with a transistor driver before passing it to the Z80. This phase will have to be checked.
The advantage of designing with discrete logic, is that you can get to every logic signal to test it during debugging. When designing with programmable logic, you usually have to revert to the simulator. So to find this problem I will have to either
- be lucky enough to spot something with the scope
- write a VHDL simulation of the CPU memory access, and run it in the Xilinx ISE
Tracking this problem will be the very next task, but it is encouraging that that the display is consistent as it means that the video access to the RAM is stable.