ZX Spectrums – Part 4

This is a continuation of fault finding and (hopefully) fixing my ZX Spectrums. Since working through the pre-power up checks in ZX Spectrums – Part 2 I’ve acquired another rubber key – an Issue 3B, so I’ve added the pre-power up checks of that to my table too. This post looks a bit more at the new acquisition and also getting the other Issue 3 up and running.

• Part 1 – Introduction to fixing ZX Spectrums and general visual inspection and stock take of my collection.
• Part 2 – Pre-power up checks and running diagnostics on my Issue 2s.
• Part 3 – Repairing (and modding) the two Issue 2s.
• Part 4 – Looking at the Issue 3s and interesting peripherals.

Issue 3B Initial Checks

This is another rubber-key 48K, but it has a really interesting modification done to it as shown below.

This appears to be a DC-DC mod which brings the power circuit up to the status of the improved circuit used on an Issue 4. But weirdly, that mod usually just involves replacing a few components and adding some extra links (I’ve seen this referred to as the “flux capacitor” mod in chat, but not found a reference to that online so far).

But this version has cut the track beneath TR4 and re-routed one of the legs of TR4. I’ve only found one other reference to this mod being done this way and that is here: https://sharedmemorydump.net/fixing-zx-spectrum-48k-with-video-issues-part-1. But it doesn’t really go on to explain it.

The mod itself is explained in a number of places online, and kits (and instructions) are available from many of the usual retro supplies. Most point back to these instructions: https://www.markmorton.co.uk/docs/DCDC_Mod.pdf.

The theory itself is discussed in detail here: https://www.derekfountain.org/zx_dc_dc.php and it was often done as a service mod (ref). In fact it appears in the Service Manual although the online version has a note that the details are wrong and left in for “the spirit of being faithful to the original service manual”.

Other points to note from the pre-power on checks:

• It looks like there might be an issue with the power regulator.
• TR4 and TR5 readings are a bit high, but possibly still in spec.

I had a quick go at powering it up (using my current limiting supply) with the diag card and there was no 12V indicated, so this definitely needs some work. The regulator is the first thing to check and then maybe see how TR4 and TR5 look. But if I need to get TR4 off the board, that might be a bit tricky with that mod in place.

I went ahead and replaced the regulator but I get the same problem – no 12V, so now it is looking like I will have to do something with TR4 and TR5 and hope it hasn’t taken some of the RAM with it too.

But that is something for another day.

Other Issue 3 Updates

Given that the only item that I wasn’t sure about on the other Issue 3 was one of the capacitors, I thought I’d give that a go with the diagnostics card too. It seems to boot fine which is encouraging and all power rails are present.

The main fault with this (or so I thought) is the keyboard membrane. As can be seen below, one part of the connector has a fold and subsequently a break in it.

I bought a couple of original and Plus keyboard membranes a while back (originals ~£10 each, Plus ~£20 each), so set about replacing this one.

The main thing here is to be careful and very gently get the metal fascia off without damaging or otherwise warping the metal, whilst also keeping the four metal tags that attach it to the case intact.

I’ve seen many keyboards that don’t seem to have these tags, so I was particularly careful with them. I also took the opportunity to clean up the rubber keys too and carefully pushed out a couple of small dents in the metal that I noticed once everything was apart (although I’m pretty sure that wasn’t me – looks like something managed to bash a couple of the keys at some point).

Whilst I was fiddling around I also performed a capacitor composite mod (as described in ZX Spectrums – Part 3).

Once everything was back together I booted the diagnostics again and all seems fine. Unfortunately when I then rebooted without the diagnostics, everything is no longer fine… I’m getting a pile of random stuff on the screen.

Booting into the diagnostics, everything checks out – CPU, ULA, RAM, keyboard, display, speaker, etc. But without it – garbage.

At this point I’m wondering if there is an issue with the original ROM. I did note that the CPU and ROM look like they might have been resoldered at some point. There are also two RAM chips that have been replaced. See if you can spot what I mean in the photo below.

So I need to take a more detailed look at what is going on here, but the keyboard, video and booting from an external ROM are all working fine.

Interesting Peripherals, The Interface 1 and /M1

In parallel to repairing Spectrums, I’m also trying out some of the hardware I’ve retained and acquired over the years.

In particular, I am very happy to have a range of music related hardware which I’m keen to try out once more:

From top left to right: 128K MIDI cable; RAM Music Machine; Specdrum. Then the software: The Music Box, RAM Music Machine, Specdrum, finally three additional Specdrum kits.

I also have an Interface 1 and Microdrive, and recently picked up an Interface 2, so I’m keen to try these too. But the Interface 1 was not recognised at all by either of my working Issue 2 boards.

It turns out that the Interface 1 requires a fully working /M1 line from the Z80. As most of the Spectrum doesn’t care about M1, many Z80s may have failed or failing signals and we won’t even know. There is a good discussion of the issue here: http://blog.tynemouthsoftware.co.uk/2017/07/z80-m1-signals.html

Sure enough, for both my Issue 2 boards, /M1 is floating about all over the place – there is evidence of it being driven but it is never pulled fully LOW and so presumably is never recognised.

One reason for pressing on with the Issue 3 boards was to try to find a board with a working /M1 – and when booting from diagnostics, I can see that the Issue 3 board does indeed have a very clean /M1 signal.

But the Interface 1 still doesn’t boot. Even with a ROM fault, as the Interface 1 has its own shadow ROM, I’d hoped this might boot instead, but that also gives me weird display patterns, albeit of a different type. The IF1 boots with large black and white vertical bars. The internal ROM seems to give me a pretty random display.

I’ve not found a detailed description yet, but from asking around and reading what I have found it seems that the Interface 1 is running with dynamic ROM switching so needs both a working ROM and /M1 to allow it to extend the existing ROM and not completely replace it. The diagnostic card is a static “all or nothing” ROM switch. When inserted, the /ROMCS signal is active and the internal ROM completely ignored.

As I test more boards, I’ll also start looking at /M1 now too.

Whilst the Interface 1 is still undecided (and I don’t have any ROMs to try with the Interface 2 yet), another recent acquisition was more fruitful. I managed to get a Cheetah Sweet Talker which uses the SP0256A-AL2 that I’ve messed about with myself. Here are some photos of the device:

Mine even came with the instructions, although unfortunately not the iconic box. But following the BASIC program provided in the instructions, I was very pleased to find that it all works.

Debugging a Faulty ROM

So back to that Issue 3 and the Interface 1. At this point I know the following:

• The Issue 3 does not boot from the internal ROM.
• The Issue 3 does not boot from an Interface 1 ROM.
• The Issue 3 will boot and run a diagnostic ROM and pass all diagnostic tests.
• My Issue 2s boot but do not recognise the Interface 1 ROM due to a faulty /M1 signal.

My starting point in diagnosing the ROM on the Issue 3 is to reflow all the solder joints for the ROM, especially as it looks like this might have been done before or maybe the ROM was replaced along with the CPU (if they were then they were replaced with “period correct” type parts – they look like originals to me). This did not solve the issue.

Just to satisfy myself that the Spectrum will function, I burned the original 48K ROM (all ROMs are available here) to a Winbond W27C512 and plugged it into a DIY ROM card. This booted up into the familiar (c) 1982 prompt fine, so it is definitely something about the internal ROM.

Whilst inspecting the ROM prior to reflowing, I did notice there was a patch where it looks like a trace had pulled away. But I checked it for continuity and all seemed fine.

So next, armed with the schematic and layout for an Issue 3 board from here I went on and checked continuity between all of the ROM pins and various other points on the board. IC3 and IC4 were good candidates for some, the edge connector for others, and for pins 20 and 27, there are some ROM type select jumpers that allow the choice between Hitachi and NEC ROMs which apparently have CS and CE the opposite way round.

There is actually a mistake on this schematic. A12 is on pin 2 not pin 27. This schematic has two pin 27s labelled. My jumpers are set in the “H” position, so presumably I have a Hitachi 16K ROM. Pin 1 for a Hitachi is not connected, hence it also not appearing on the schematic. Continuity was good for all pins.

At this point I broke out an oscilloscope and probed the signals to see what they looked like when it was displaying garbage on the screen. All signals are fine apart from pin 20 which was showing a very fuzzy-looking, probably floating, result. This is /CS2 which is apparently connected to the /ROMCS signal on the edge connector and then, via R33, to pin 34 of the ULA.

This would explain the symptoms. With no external ROM, /ROMCS and thus /CS2 is floating and the ROM isn’t switched in, meaning there is nothing providing data on boot. With an external ROM /ROMCS is driven HIGH and thus /CS2 is also HIGH so the ROM is officially switched out, but now there is an external ROM to provided data to allow the system to boot.

Probing for continuity I found there is a break somewhere between R33 and the ULA, but tracing it through wasn’t easy. One tool that made everything an awful lot easier was the interactive PCB and BOM here: https://retrobox.it/files/pcb/ZX_Spectrum_Issue_4.html. In particular the ability to select a point or trace and have the whole path indicated was really, really useful.

This is for an Issue 4 board, but it is similar enough to an Issue 3 that I could follow most of the traces virtually without losing them under components or going cross-eyed trying to follow them on the board. Eventually I broke out a microscope to follow a particularly long trace and found the problem. There is a break in one of the traces between the ULA on its way to R33 right near to the end of the CPU.

If I had to guess, I’d say this might have happened when the Z80 (right) was reflowed or replaced. It looks like something has scrapped across some of the tracks here. The other track that looks like it might be affected too, is part of the link between the ULA and the “V” signal on the edge connector. That one seems to still be connected.

To check this really is the issue I added a wire link between the ULA pin 34 and the wire links – and it booted! With hindsight, whilst writing this, I just realised I’ve bypassed R33, but anyway, the principle is sound. It works.

In fact, with the patch the right side of R33 I can even plug in the Interface 1 and it all boots successfully. How can you tell? Well just typing “RUN” will do it.

For the normal 48K ROM typing RUN will give “0 OK, 0:1”.

With the Interface 1 booted, typing RUN will give either “Microdrive not present, 0:1” or “Program finished, 0:1”. Which it now does.

I’ve added a small patch wire on the underside of the board from ULA pin 34 to the far side of R33. I did wonder about soldering into the vias on either side of the broken link, but figured it was less risk to solder to existing solder points. It makes for a longer wire it seems to me a lot less intrusive.

Conclusion

I’ll leave this here for now. There is the occasional bit of jitter on the video, so there might still be a bit of tweaking to do somewhere. And as is apparent, I still have some work to do on the Issue 3B board but that will require a bit more in depth investigation. If it turns out to just be the transistors then I’ll come back and update this post.

Getting the Interface 1 running was a bonus though. I did try it with an actual Microdrive too, and it was recognised for a bit, did some whirring, but I couldn’t get CAT to work, and eventually it stopped having a power light on at all, so I think the drive I have needs a bit of care an attention.

I am also getting a lot closer to being able to get some of those other peripherals up and running though which is great news.

As an aside, I’ve also picked up a ZX81 and Amstrad CPC 464 so want to take a proper look at those at some point too.

Kevin