Hardware diagnostics interface (Pico based)

[dfzx]

Whenever someone pops up asking for help with a broken Spectrum, the initial investigation asked of them is always the same: measure the voltages, tell us what test equipment you have, then do some initial signal checks based on what they can do with the equipment they have to hand.

Would it not be useful, I considered to myself, if there was a device which you could plug into the back of a Spectrum which would take a few of these measurements for you, and perhaps run a handful of tests which might give some useful clues as to the health of the machine?

Yes, I thought, such a thing might be useful, so I made one.

The interface consists of two Raspberry Pi Picos with their RP2040 microcontrollers programmed to run various tests which sample the voltages and monitor the signals on the rear edge connector. There's a small OLED screen on the front to display the readings and results.



I wrote it up here. Here's a short video introducing it:



The current implementation measures the +5V, +12V and -5V voltages, checks the ULA generated clocks, checks several Z80 signals, checks the data and address buses are at least sane, and ensures the Z80 is running at least the start of the Spectrum's ROM program. It could do a lot more, I think, so if anyone's go any bright ideas for further useful tests I'd like to hear them.

Clearly there are limitations to the approach, given it can only sample what levels are on the edge connector, as opposed to what might be going on actually inside the machine. But it does provide useful information.

As with all my projects it's open source and free software. The Github repository is here.

[1024MAK]

Nice

The next step would be an instruction trace, Often knowing at what point the Z80 is no longer executing the expected sequence can help identify the problem, or at least narrow it down. If there is no input from the user, the machine should make it to the "copyright" screen with the only variable being how much RAM the ROM code finds (16K or 48K or if there is a RAM fault, some other random value) (not including other faults).

If the Pico can output the instruction trace to a file or to a USB/serial port, then the instruction trace can be studded on a PC.

Mark

[1024MAK]

Oh, and during the RAM check that the ROM does, it may be possible to check for some RAM faults that the ROM code does not test for. It's not possible to pick up all RAM faults, because the intention of the ROM routine is to simply work out how much RAM is fitted, NOT if it works correctly. Hence the range of values written to the RAM during this test is rather limited.

Mark

[dfzx]

The next step would be an instruction trace, Often knowing at what point the Z80 is no longer executing the expected sequence can help identify the problem, or at least narrow it down. If there is no input from the user, the machine should make it to the "copyright" screen with the only variable being how much RAM the ROM code finds (16K or 48K or if there is a RAM fault, some other random value) (not including other faults).

That's a very good idea. The issue is the number of instructions the Z80 would fetch and execute in order to get to the (C) message. The Pico only has 264K of RAM so the Z80's address data would likely need offloading on the fly. It could be done, though, somehow.

[dfzx]

Oh, and during the RAM check that the ROM does, it may be possible to check for some RAM faults that the ROM code does not test for. It's not possible to pick up all RAM faults, because the intention of the ROM routine is to simply work out how much RAM is fitted, NOT if it works correctly. Hence the range of values written to the RAM during this test is rather limited.

I already have my Pico based ROM emulation interface, and I did think it would be nice to merge the devices and have the Z80 running a ROM image containing custom tests, the results of which could be examined in the hardware. Bit of a step up in the challenge, though.