Repair
I'd like to mention at the outset that this repair might not have been impossible without help from the forum of the Verein zum Erhalt klassischer Computer (Association for the Preservation of Classic Computers), but it would certainly have been significantly more difficult and time-consuming!
Snow Removal
Unfortunately, an initial attempt to put the device into operation only delivered snow on the connected TV - neither the channel scan nor manually selecting channel 36, which the Spectrum normally uses, produced a picture. However, a look at a few bus lines of the running computer with the help of an oscilloscope showed that there was still life in the system.
Following a recommendation from the forum, I bypassed the RF modulator using the so-called composite hack to obtain a pure composite video signal – in case the TV's receiver had a problem with the computer's antenna signal. And voilà! – now a picture actually appeared! Although not a pretty one...
Wild guesswork
It's great when a) ICs are socketed and b) a replacement is available! That was at least the case with my Speccy's CPU; I was able to replace it with the Z80s from my CPC464 and the Sharp MZ80-A. At least the former continued to work perfectly with the Spectrum's CPU (I didn't want to try that with the Sharp's because of the exposed CRT electronics, as I didn't know how long I would have had to wait until life-threatening voltages were dissipated before swapping the CPUs back). On the other hand, even transpalting a CPU known to work didn't revive the Sinclair.
As is generally known, old dysfunctional electrolytic capacitors often cause problems in older hardware. Following a tip from the forum, I came across a repair report on a Spanish Speccy fan site that described screen patterns similar to the ones I observedw as a symptom, and in which replacing an electrolytic capacitor (C44; involved in generating the 12V voltage for the DRAM chips of the lower RAM) led to recovery. I replaced both C44 and the neighboring C45 - unfortunately, without success.
Addressing Issues
So, on to further detailed investigations! A careful examination of the address signals on the lower RAM showed that address line A1 (blue in the figure) was always low, while the other address lines were bustling. Here, we're talking about the address lines used directly by the ULA, while the CPU uses them only indirectly, to perform row and column addressing in the 4116 RAM ICs -- not the address bus, which is directly connected to the CPU (green). These lines are separated from the CPU by several 74157 multiplexers, and I was able to demonstrate that there was a steady flow of HIGH and LOW changes on the two CPU address lines, which are multiplexed to the RAM-side A1 line, as well as on the multiplexer output. The line only went dead beyond the isolation resistor R17 (red). My first suspicion was that a defect in the ULA was permanently pulling the A1 line down to ground, but perhaps a defective 4116 could also have this effect?
Now it was time to pursue two different approaches and further investigate the two suspects (ULA and Lower RAM).
ULA
The ULA is an uncommitted logic array, a chip with a large number of logic gates that are only connected during production (but then they're no longer "uncommitted", are they?). In the case of the ZX Spectrum, it acts as a "jack of all trades" (roughly comparable to the PLA chip in the Commodore 64 or the gate array in the Schneider CPC464) and handles, among other things, video signal generation, speaker control, and interaction with the cassette connector.
As a custom chip, the Spectrum ULA is of course no longer available as a spare part -- or at most, used at exorbitant prices at online auctions. Fortunately, someone in the forum offered to loan me a NebULA board -- a modern, FPGA-based replacement for the original ULA IC. After receiving and installing it, I did indeed see different colorful patterns on the screen than before -- although I still didn't get the Sinclair Research startup message I was hoping for.
But at least there was activity on the A1 address line again! Time to move on to the next suspect...
RAM
A method for identifying defective RAM chips, which isn't 100% reliable but sometimes works, is to piggyback a known-good IC onto the ICs under test, so that they can potentially take over their function. I was able to track down a (presumably) good 4116, but the piggybacking method didn't lead to any noticeable improvement on any of the eight lower RAM ICs.
A post in the forum drew my attention to a supplier of modern RAM modules, which could replace the entire RAM bank in one fell swoop with a board containing modern, static RAM. Thanks to the very reasonable price, I didn't hesitate and ordered one. Until delivery, I passed the time by desoldering the 4116s and soldering in the corresponding sockets—a task I was somewhat apprehensive about due to my unpleasant experience attempting to repair a TI-99/4A, but I managed to complete it somewhat successfully (I only damaged a single soldering pad).
Now, as endless discussions on the web show, opinions can differ greatly regarding the use of precision sockets. It may be debatable whether they're actually more durable and more contact-friendly than conventional sockets -- my idea that I'd done my board some good by using such sockets was proven wrong, though, as the RAM module came with pins that had a square cross-section instead of a circular one, and they simply wouldn't fit into the round holes of the precision sockets. But here, too, the forum was incredibly helpful. I got the tip to desolder the pins from the module and replace them with short sections of, for example, resistor connection wires. Since the solder joints were located on the top of the module, the entire operation could be performed quite conveniently in place:
The RAM swap didn't produce the desired end result, but at least it produced some new, colorful patterns -- which made it seem as if the cooperation between the ULA and the RAM was now working. However, the initialization routine, in which The CPU replaces the random RAM contents with defined values after startup, seemed not to be executed. There were 8x8 pixel arrays with random patterns in two colors each, and some of the arrays are periodically inverted – all of this can be explained by random bit patterns in both the RAM area containing the bitmap data and the attribute RAM, which defines the colors and blinking behavior of the 8x8 cells.
By the way, depending on whether I used the NebULA board or the old ULA, I saw random patterns with slightly different geometries. This is consistent with the observation that on the old ULA, the A1 address line, which is used for both column and row addressing of the RAM chips, is always low. While I haven't looked in detail at how exactly the ULA addresses the RAM to read pixel and attribute data, if an address line always transmits 0 instead of alternating 0 and 1, that should explain why on the old ULA, both pixel and attribute values are repeated once in both the X and Y directions -- because this means some data is read twice and others aren't read at all.
Intermezzo Transistore
Because troubleshooting apparently wasn't complicated enough yet, fate had decided to suddenly cause a transistor (TR4) to glow and smoke – possibly due to a short circuit caused by bits of leftover solder carelessly left on the table, ahem... The original ZTX650 type was, of course, no longer available for purchase, but the ZTX651, recommended as a possible replacement, could still be found online. Since TR4 – like the replaced capacitors – is involved in the +12 V generation, but this voltage is no longer needed with the new RAM board, the replacement had no further consequences, as expected. But the replacement certainly didn't do any harm either – especially since real DRAMs were to be used temporarily later on.
ROM
The (presumably) failed initialization of the video RAM made me suspect that the ROM might no longer be working properly. Another forum member kindly offered to burn a 32 kB EPROM (a 27256) with the 16 kB original Spectrum code and a diagnostic ROM from Retroleum. I could then switch between them according to the instructions, allowing me to run various system tests when turning on the device if necessary.
Now I had time to kill again until the EPROM arrived. I took the opportunity to remove the old ROM and solder in a suitable socket. I also randomly read some of the address contents of the original ROM "by hand," using the method I had already used when repairing the CBM 3032 -- with the result that I always received the correct values at all selected addresses. So the ROM might not have been broken at all -- and might have even survived desoldering!
Short Circuit
While I continued to wait for the EPROM to arrive (shipping by snail mail took over a week!), I removed all the socketed ICs from the board and examined the bus lines a bit more with an oscilloscope and continuity tester. I noticed that address lines 5, 6, and 11, as well as 9 and 12, were electrically connected. Not a good sign. A close inspection of the board with my trusty watchmaker's loupe revealed that when I removed the CPU, I had apparently not only scratched the underlying circuit traces, but had also pried out metal filaments that had crossed and connected neighboring traces.
After eliminating the short circuits, I was actually able to briefly see the startup message when powering on -- woohoo! However, the socket in which the NeBULA board sat had become so worn out by its thick, solid pins that you practically only had to look at the board before the image on the monitor started twitching wildly. I then got a suitable precision socket, hoping that the round NebULA pins would fit well in it. And they did! So I soldered in the socket, inserted the NebULA, turned the Speccy on, and what can I say: "(C) 1982 Sinclair Research Ltd"!
I also tried inserting the old ULA again – as expected, without success.
So I put the NebULA back in, connected the keyboard, screwed the case shut, turned it on – black screen with a white border. What the... it worked just a moment ago?!
EPROM
Since the old ROM still seemed to work, at least in principle, I thought I might be able to avoid the EPROM hack. But now I wanted to try the Retroleum diagnostic ROM, hoping it might offer some helpful hints. So, according to the instructions, I soldered in two diodes and a resistor, and did some more tinkering to be able to switch between the original and diagnostic ROM: I attached a cable (blue) with a small plug to the soldering point for pin 27 of the ROM socket. This cable can be connected either to a ground cable (black) or to a corresponding +5V cable (red; both with a matching socket). Pin 27 of the EPROM corresponds to address bit 14, and depending on whether it is a 0 or a 1, the lower 16 kB of the EPROM (= original ROM) or the upper 16 kB (= diagnostic ROM) are activated.
And indeed: The computer booted into diagnostic mode, and the lower RAM test, which was automatically performed right at the beginning, immediately reported IC 13 as defective. This is the 4116, where bit 7 of all lower RAM addresses is stored—which also explains the display errors in the screen output.
Now it seemed unlikely to me that the still relatively new RAM module could have spontaneously developed a defect. Since I found a few more (probably) mint 4116s while cleaning up, I tried using them instead of the board -- same result.
So another session with the oscilloscope and continuity tester was called for. The former confirmed that the data pin of IC13 (D7) was dead, and the latter showed that the connection between pin 31 of the ULA and the data pin of the 4116 was broken. And indeed -- apparently, during my last ULA change, I had once again scratched around heavily on the board and cleanly cut the trace leading from pin 31 under the ULA IC. (I still need to work on my IC removal technique...) Fortunately, I was able to identify two suitable solder points that I could use to bridge the break – which means I now have three "bypasses" on the underside of the board.
Mission Accomplished!
With the trace break repaired, the RAM test then ran successfully, and with the original ROM, the computer then booted successfully to the startup screen. And also after reinserting the replacement RAM board and reconnecting the keyboard, the Speccy finally behaved like new again. Phew!
