Repairing a faulty 48K issue 2.
I am investigating one of a pair of non-working issue 2 48K Spectrums that
have been sitting in a cupboard untouched for quite a few years.
I haven't got it working yet and am wondering whether any of you have any
useful suggestions from experience, though I fear you won't narrow down
the problem much further than I already have.
I found its voltage regulator not to be working so I removed that and
before replacing it made a few measurements to make sure there wasn't an
obvious complete short circuit anywhere in the various power supply
circuits on the board.
With a new regulator I can now measure +5V at all the RAM chips and -4.7V
(exactly the same as I measure for -5V on a working model) and +12V at the
right places on all the 4116 RAMs.
The Spectrum draws 630mA @ 9V from its DC input.
The lower RAM chips are marked ITT 4116-2N, apart from one which is an STC
4116-2N. It is clear from the rear of the board that this last one is a
replacement (not by me and it appears to have been soldered in
neatly).
It produces a display more-or-less exactly like the one in the top picture
in the following thread
http://www.worldofspectrum.org/forums/showthread.php?t=30802
(Thick black and white vertical bars, but almost always with a purple
border.)
I have verified the ULA (5C112E-3) works by testing it in another
Spectrum and a working ULA from another Spectrum produces the same result
when installed in this non-working one (and thankfully works again when
put back!) It does seem the ULA becomes slightly hotter than usual in the
broken Spectrum.
So far I haven't fully tested the CPU nor the ROM because I don't want
to unsolder the former unless I have to and while the ROM is socketed, I
haven't got another Spectrum where the same is true.
I have verified connectivity of the data bus lines between the CPU and ROM
and ULA, with the expected 470ohms resistance in them between the CPU and
ULA. They also all measure ~5.5Kohms to the +5V rail.
Measurements with an oscilloscope show the following:
- ~3.5MHz 0-5V clock at pin 6 of the CPU.
- Hopeful looking RAS signals at all RAM chips (upper and lower).
- Hopeful looking CAS signals at all 4116 chips. CAS is at ~5V at all
the upper RAM chips, which I imagine is correct for a Spectrum at switch
on.
- 0-4V square waves at the output and input pins of all RAM chips
(upper and lower), though some of the rise times look a bit long.
- WE is ~5V at all RAM chips (upper and lower).
- 0-4V square waves on all data bus lines at the CPU.
- 0-4V square waves on A0-A7 at the CPU.
- A8-A14 at the CPU mostly sit at just under 4V.
- A15 is at 0V. I'd have thought this is correct for a Spectrum at
start-up.
- RD (pin 21) at the CPU has a clean 0-3.7V square wave of ~875KHz.
- WR (pin 22) at the CPU sits at ~3.4V. It looks similar to above on a
working Spectrum I have compared it with. This seems a bit low to me if
it's meant to be a logic high.
I think my prime suspects are now the lower RAM chips or perhaps a
partially faulty CPU.
Any ideas?
P.S. I've left the inverting bar off the signal names above where it
applies, but I'm sure you know what they mean.
have been sitting in a cupboard untouched for quite a few years.
I haven't got it working yet and am wondering whether any of you have any
useful suggestions from experience, though I fear you won't narrow down
the problem much further than I already have.
I found its voltage regulator not to be working so I removed that and
before replacing it made a few measurements to make sure there wasn't an
obvious complete short circuit anywhere in the various power supply
circuits on the board.
With a new regulator I can now measure +5V at all the RAM chips and -4.7V
(exactly the same as I measure for -5V on a working model) and +12V at the
right places on all the 4116 RAMs.
The Spectrum draws 630mA @ 9V from its DC input.
The lower RAM chips are marked ITT 4116-2N, apart from one which is an STC
4116-2N. It is clear from the rear of the board that this last one is a
replacement (not by me and it appears to have been soldered in
neatly).
It produces a display more-or-less exactly like the one in the top picture
in the following thread
http://www.worldofspectrum.org/forums/showthread.php?t=30802
(Thick black and white vertical bars, but almost always with a purple
border.)
I have verified the ULA (5C112E-3) works by testing it in another
Spectrum and a working ULA from another Spectrum produces the same result
when installed in this non-working one (and thankfully works again when
put back!) It does seem the ULA becomes slightly hotter than usual in the
broken Spectrum.
So far I haven't fully tested the CPU nor the ROM because I don't want
to unsolder the former unless I have to and while the ROM is socketed, I
haven't got another Spectrum where the same is true.
I have verified connectivity of the data bus lines between the CPU and ROM
and ULA, with the expected 470ohms resistance in them between the CPU and
ULA. They also all measure ~5.5Kohms to the +5V rail.
Measurements with an oscilloscope show the following:
- ~3.5MHz 0-5V clock at pin 6 of the CPU.
- Hopeful looking RAS signals at all RAM chips (upper and lower).
- Hopeful looking CAS signals at all 4116 chips. CAS is at ~5V at all
the upper RAM chips, which I imagine is correct for a Spectrum at switch
on.
- 0-4V square waves at the output and input pins of all RAM chips
(upper and lower), though some of the rise times look a bit long.
- WE is ~5V at all RAM chips (upper and lower).
- 0-4V square waves on all data bus lines at the CPU.
- 0-4V square waves on A0-A7 at the CPU.
- A8-A14 at the CPU mostly sit at just under 4V.
- A15 is at 0V. I'd have thought this is correct for a Spectrum at
start-up.
- RD (pin 21) at the CPU has a clean 0-3.7V square wave of ~875KHz.
- WR (pin 22) at the CPU sits at ~3.4V. It looks similar to above on a
working Spectrum I have compared it with. This seems a bit low to me if
it's meant to be a logic high.
I think my prime suspects are now the lower RAM chips or perhaps a
partially faulty CPU.
Any ideas?
P.S. I've left the inverting bar off the signal names above where it
applies, but I'm sure you know what they mean.
Post edited by Zorn on
Comments
I am sorry to say but I do suspect that if its not the RAM, then its most likely the ROM.
The display is exactly the same with the ROM removed. I have also been able to try the ROM in a different Spectrum and it seems to be fine.
The upper RAM (like the lower) is soldered in, so I don't want to remove that unless I have to.
I've also noticed that unlike before, A0 at the CPU sits just under 4V(with quite a lot of noise) so it looks as if the CPU is not trying to step through memory, or something is interfering with that address line. This pin shows a nice 0-5V square wave on a working Spectrum.
There is a square wave on MREQ, though it is only 0-3.3V; it goes up to almost 5V on the working one I've looked at. I assume that means the CPU is at least not completely dead.
I will continue investigating...
I think I will next remove the lower RAM and fit sockets. I would think at least some of it is faulty, especially given that the first fault I found was a dead voltage regulator.
On the other hand: having lower RAM on sockets surely is a good thing even when the problem was not there.
It could be the ROM but... are you sure that the CPU is being properly resetted? With the computer on, and showing a border colour different than white, try shorting C27 for a moment, and see if the border colour changes to white. if it is so, then the ROM is probably good (so it's the CPU) and then you can focus on finding out which memory from the contended bank is damaged (and replacing C27, by the way). Measure voltage at the positive side of C27 and see if it is near 5V. If it is lower than, say, 2V, change C27.
If after forcing a reset/changing C27 the border doesn't change on power up, it could be the ROM, the CPU, or the non contended RAM, as these devices share the same address and data buses. The later because a damaged RAM could force a data pin low all at all times, even when the device is not being accessed. A forced value means that the bus contents are corrumpted and hence, the CPU cannot read any valid instruction from the ROM.
So another test is to measure (with the computer switched off, of course) resistance between each data bit at the processor side and ground. If there is a data bit whose resistance is significatively different from the others, suspect that there's probably a damaged device that is altering that bit... most probably a chip in non contended RAM.
Do the same with the address lines. This time, a significatively drop in resistance can be due to a faulty CPU, faulty ROM (most probably), or faulty multiplexers. Non contended RAM is not directly connected to the address bus.
If I start the Spectrum with the lower RAM all removed, then the display has a yellow border (but always purple if turned off and on again with less than ~5mins in between) and usually an all white central area, but sometimes narrow (character width) yellow/white vertical columns.
Briefly shorting C27 to reset the CPU (still with the lower RAM removed) doesn't have any effect on the border, though it does sometimes change the main display area between the two types described above.
I haven't got any spare 4116 DRAMs to hand, so I can't try putting in different ones yet. I have got some 32Kx8 SRAM ICs and am wondering whether I could make up a little board with one of those on that plugs into the newly installed sockets.
With all the lower RAM missing, a "working" Spectrum shows a screen with a very fast moving pattern in it, as the ULA, in absence of lower memory, "reads" the CPU bus searching for data. If you hold the CPU in a reset condition, the data bus freezes and the pattern vanishes (paper bright white, as the ULA reads always $FF). Besides, the later is valid if the CPU and/or the ROM is dead.
So, in absence of lower RAM, shorting C27 and leaving it shorted should give you a bright white paper, and a border of some random (but steady) colour. Is it so? If not, can you show us a picture (or a video) of what you see?
You would need a 7-bit latch too to demultiplex the address bus. The latch outputs would be connected to A0-A6 at your SRAM. The latch inputs would be connected both to VRAM_A0-VRAM_A6 from the ULA, and A7-A13 at your SRAM. SRAM A14 would be connected to GND. CAS from ULA to SRAM CS. WE from ULA to SRAM WE. SRAM OE would be connected to a circuit that goes low when CAS=0 and WE=1, but I think it will work if you join CS and OE together at the SRAM.
Well... sort of. I cannot assure that this description is accurate enough (or valid). I believe I've seen some schematics about replacinig lower DRAM with SRAM at the speccy.org forum some years ago...
So if you already soldered in sockets, it might be easiest to find some replacement 4116's now (sorry to say, but you should have thought about what to use as replacement before soldering in sockets :cry: ). Another option would be to use 64Kx1 DRAMs (my page has a link), which are easier to find and only use 5V supply. Or try 64Kx4 or 256Kx4 DRAMs, but I couldn't tell you if/how that would work (read: not recommended for repairing a machine with unknown fault).
a) CPU (most likely)
b) ROM (quite likely)
c) TR3 (ZTX313 - also quite likely).
If you get that pattern it almost always means the CPU isn't doing anything which is because either the CPU is dead or it's not getting a clock signal (which comes from the ULA - which we know works - via TR3). If the ROM is dead the CPU will just get confused and HALT probably.
Don't go desoldering the RAM chips unless you're confident - some of these boards destroy themselves as soon as look at a soldering iron, and with that many pins the chances of tracks lifting on one of those boards is VERY high.
What's the value of pin 6 on the CPU compared to your working Spectrum?
Removing the lower RAM was time consuming and fiddly, but I don't seem to have damaged any tracks and all my tests suggest that the socket pins connect to the right places.
I've got another 48K with an unknown fault (I haven't investigated it much, but it seems that there is at least a complete short circuit on its power input) and a 48K+ that recently developed a fault that I'm almost certain is a lower RAM failure (it only sometimes fully initialises and when it does there is a low level of seemingly random display corruption and it soon crashes). Between these I hope I can find a working set of 4116 ICs for the one I'm working on now. I'll have a go at an SRAM replacement on one of the others.
I've also been having some frustration with circuit diagrams. I've been mostly referring to what claims to be the Issue 2 diagram available from from WoS. I noticed that the address line connections from the lower RAM to the ULA are wired as shown in the Issue 3 diagram instead (the board I've got says Issue Two on it). One of the 'mandatory modifications' shown on the diagram is to change R60 to 270 ohms. The service manual only says to do that for an Issue One Spectrum (though R60 is 100 ohms on my board). I then started looking at /RAS an /CAS for the upper RAM. Both the Issue Two and Issue Three diagrams show that CAS here is just a buffered copy of /MREQ. This doesn't make sense (it'd probably result in the upper RAM putting stuff on the data bus when it shouldn't) and continuity tests on my board suggest the diagram at the very least has /RAS and /CAS swapped. I'm slightly confused about the RAS/CAS circuitry for the upper RAM. I suppose I should draw up a truth table for it and try to understand what it does, but now I don't even feel very confident the diagram is correct. I'd have thought it ought to involve /RFSH and I can't work out whether there is a mechanism for refreshing the upper RAM while the ULA has stopped the CPU (perhaps it is never stopped for long enough to need it). So, does anyone on this forum know of the existence of any more accurate Spectrum circuit diagrams?
Back to my diagnosis... While the main display area usually shows plain white when I turn on the Spectrum with the lower RAM removed, it does sometimes show apparently random patterns and effects. After turning it on and off many times it seems that the display not being plain white coincides with there being signals on the data bus. Normally at these times /CAS on the upper RAM remains high and so I think these signals are probably due to the CPU accessing ROM (I've never seen /IOREQ low and so I don't think they can be from the ULA). Then I removed the ROM and found the central display area is almost always white, but now and then patterns flicker across it and these coincide with data on the data bus lines and low going pulses on the upper RAM /CAS (quite why these happen, I'm not sure). All this makes me think the CPU is probably working, but I haven't been able to find any pulses on its /M1 pin and sometimes there are odd signals on the data bus lines (square waves going between about 3V and 4V). Looking at the ROM disassembly (and as someone else has pointed out in this thread) also says that if the CPU is able to start executing the ROM then almost the first thing it does is to tell the ULA to turn the border white and I have never seen a white border from this Spectrum.
I think I will next remove the lower RAM from my other dead 48K and see whether I can find a working set and also be prepared to change the CPU (I need to get a 40 way socket).
If you remove the ROM, and if there's not anything in the databus that supplies a value, the CPU reads $FF when it's fetching instructions. $FF is the opcode for RST $38, which pushes the current PC to the stack and then jumps to $0038.
A Z80 cold start (see http://www.worldofspectrum.org/forums/showthread.php?t=34574&highlight=USR+46578&page=3) sets SP=$FFFF, so PC is written to the top of upper memory, downwards. This is why you observe CAS pulses on upper memory.
ftp://ftp.worldofspectrum.org/pub/sinclair/technical-docs/ZXSpectrum48K_Diagram.gif might give you a clue. (It surely gave me :-) )
Just a more or less plain white screen when lower RAM removed? Don't know for issue2 (old ULA) but IIRC 16 or 32 vertical bars are visible then, built from faint (greyish) hor. stripes. At least on iss6. iirc. In steps of 1/8 screen getting more 'solid' each time an 4116 is added. BTW modification for using the more common 6164 is relatively simple as shown on this forum lately.
Might be time to move suspicion towards Z80. Guarantee for 99% alive is not enough...
And specific block patterns are passing the screen at regular intervals of some .5 second. At address $38 another &FF will be read instead of a RET, resulting in a continuous growing (downwards) of the stack with identical values. IMHO.
It works!
This is the Spectrum+ that had faulty lower RAM rather than the one I started off trying to repair in this thread.
Now I just need to make a neater and more permanent version. I also don't want to have to have a whole great big IC just to invert one signal. So far my very brief experiments with a simple single transistor inverter haven't worked well because the transistor won't turn off fast enough for the frequencies involved, but I've still got some ideas and will keep experimenting.
On the breadboard are (left to right) a TTL inverter IC, a TTL 8 way latch and a 32Kx8 SRAM IC (it had a previous life as cache in a 486 PC).
P.S. I also changed all the electrolytic capacitors on this board because it had a very noisy display (which is quite a bit better now), but while I was at it I accidentally damaged the tiny track that connects the ROM's /CS line. It took me quite a long time to find this problem. So, take care if you're doing anything similar.
It's now working - somewhat. Not too surprisingly it needed a new Z80 and I identified a couple of 4116 ICs that were clearly dead. Between the remaining ones and some from the Spectrum+ that recently developed a problem, I've put in a set that I think are good.
However, spurious pixels and sometimes attribute squares appear now and then, almost always down the left hand side of the display and software sometimes behaves oddly. I've found loading Chaos is a good test as the display corruption always shows up during loading and once the game starts it gets stuck in a loop endlessly asking for wizards' names. So, I suspect at least a few bits in lower RAM are being unreliable.
Strangely though, if I move all 8 4116 ICs to my Spectrum+ (even keeping them in the same positions just in case a faulty bit in a particular location triggers the problem) everything works perfectly. So, either timings/voltages in the Spectrum+ just happen to be a bit different and not trigger the problem or there is something else wrong in the Issue 2.
Is anyone here aware of any RAM test software for the Spectrum? It might help narrow down the location of the problem. I have seen that someone has a ROM based test, but that isn't too convenient for me for now. I can probably put something together myself fairly easily, but I thought I'd ask first...
Just in case it applies to this Spectrum, I quote from my webpage: "On issue 2 and issue 3A/B boards, several gates of IC24 (74LS00, sometimes 74HCT00) are not used. Connect one of these unused inputs to +5V, and the other input (+corresponding output) works as inverter, so that you don't have to add one."
Anyway congrats for locating the problem!
I wouldn't have thought the more rapid transitions should cause the Spectrum a timing problem. It probably could make unwanted crosstalk and nasty transients on various lines more likely.
I was a bit surprised it worked through that tangle of wires out to the breadboard. I didn't test it too extensively, but it did load and run Chaos without any signs of problems. I put a 22uF Capacitor across the power lines on the breadboard and a 100nF one for each IC. It worked without them, but there was a slight increase in general noise on the display.
I would like to have a plug in board with SRAM on, even if just for when testing Spectrums, so when I get time I'll continue experimenting with a transistor inverter so I can avoid any flying leads. I'm considering making up a board that has the option to plug in a single 4116 and use it for one bit of each byte to make it easier to test 4116 ICs individually.
Me too :smile: it's a bit of a cost / market / numbers problem, the parts hardly cost anything but having circuit boards made ain't simple or cheap...
I've written a very simple BASIC program that writes a chosen value to every byte in a specified range, then repeatedly reads each byte in that range and stops and reports if it finds something has changed. I've been running this over the display area of RAM and lowering the RAMTOP and running it over the top half of the lower 16K of RAM.
It quickly identified another 4116 chip that clearly has something badly wrong with it. I then ran it again and again and each time it reported a problem, I worked out which bit had changed (it was always one bit) in the first wrong value it reported and changed the 4116 that's responsible for that bit. I've been doing this for most of the day and have gone through all the spare 4116s I've got and it still reports problems. It's not unusual for bits of the BASIC program to become corrupted too. I think all the problems I noticed corresponded to a bit becoming reset when it shouldn't and never the other way around.
I ran the program over an area of the upper 32K of RAM for a while too and it didn't find any problems, though I didn't leave it going for long enough to be absolutely sure.
I moved all 8 4116 chips that were the last lot I had in the Issue 2 Spectrum with the problem over to a Spectrum+ and so far have been unable to get one error report out of it. This makes me think something other than the DRAM chips is to blame.
When the memory corruption occurs within the display it is always in the left most column of character or attribute bytes. I've also noticed that when something is updating the display (and not usually otherwise) there is very frequently a single row of flickering (to white - it only shows up when the surrounding area is not white) pixels in the left most column somewhere around the very top of the lower 3rd of the display area.
I've tried changing the ULA and that makes no difference, so I don't think it's that, unless the two I've got have exactly the same fault.
This is very annoying! I can only imagine that something is intermittently disrupting a bus/control signal for the lower RAM.
Are any of the timings of a brand new Z80C (that's what's in there now) different in a way that is likely to cause a problem? I haven't checked the data book, but I'd rather assumed it should be an acceptable replacement.
A plug in board for speccies with socketed lower ram would almost certainly work out cheaper than a set of 8 replacement 4116s if you had them made in sensible quantities.
The stripboard monstrosity below is plugged into sockets in a Spectrum+ in place of the 4116 DRAM ICs.
(Sorry for the blurry photo).
It seems to work perfectly. The display is quite a lot cleaner too, probably because the Spectrum now draws only 400mA from its power input. I've had it running for about a day and it has loaded and run my BASIC memory test program (for several hours), Through the Trapdoor and Kikstart II with no signs of problems.
It fits in reasonably firmly, but if I were to use it as a permanent fixture I'd want to find a way to hold it in place more securely or perhaps remove the sockets and solder it onto the Spectrum's board. It is possible to put the lid on the Spectrum+ with it fitted as it is, but only just; I had to re-install the transistor (used to invert /RAS) lying on its back to make it fit.
I can post the layout and circuit diagrams I used should any of you want to have a go at making one. Perhaps you can come up with a neater layout too, though I thought it was going to be impossible on stripboard when I first started trying to design it.
I tried the SRAM board in it and it didn't work well at all. The display was full of flickering lines. This Spectrum mostly works with 4116 RAM installed, but suffers from corruption of data in this RAM (as described earlier).
I examined some of the signals on the board and noticed that /RAS looked a bit odd. I returned what I believe to be a working set of 4116 ICs to it and found that the display looked correct, but /RAS still seemed wrong.
This is what I saw:
(/RAS is in yellow and /CAS in blue in the second two.)
I can't remember /RAS looking like that before, so perhaps something else has gone wrong/been damaged during my repair efforts. By the way, the /RAS signal looks about the same with no lower RAM installed.
I put the same 4116 ICs into the Spectrum+ (the one I have been testing the SRAM in) and it seemed to work normally and the /RAS signal looked normal:
I also examined /RAS (and /CAS) as applied to the lower RAM on a problem free Issue 2 that has NEC 4116s installed:
I didn't find even a single oddly shaped or 'half way' pulse on /RAS on the Spectrum+ nor the good Issue 2.
I note that the good Issue 2 has had the resistor value change and additional capacitor installed in the power supply circuit, but the bad one has not. The good one lacks C54 from /RFSH to 0V, but the bad one has it.
I've tried the ULA from the good Issue 2 in the bad one (they are of exactly the same type) and the same problem remained.
I think some unwanted crosstalk or failed decoupling may be at work. Has anyone here seen a problem like this before?
[EDIT] I've also just noticed that the good Issue 2 lacks R57, but the bad one has it. This couples the CPU's /RFSH to /RAS. It also appears to be absent on all later versions of the Spectrum. I think I'll see what happens if I remove it.
[EDIT2] With R57 banished, /RAS look far more sensible. Now let's see whether it works properly...
I have removed it from the one I'm working on and made the recommended changes to the power supply circuit and so far it seems to have been working perfectly since then.
The display is still badly corrupted if I use my SRAM board though. I wonder why it works perfectly in an Issue 4, but not this Issue 2...
Having worked on a ZX81 ULA clone lately, I have a pretty good understanding of /MREQ, /RD, /WR, /RFSH etc timing at this particular point in time. ;) Looking at this /RFSH-C54-R57-/RAS add-on, I think I know what's going on:
Each memory read or write is followed by a refresh cycle, and /RFSH stays active (low) until very short before start of a next read/write cycle. C54 delays that, probably moving rising edge of /RFSH somewhere into the next cycle.
Now when the ULA makes /RAS low, there's 2 signals pulling it down so it drops quickly at first. But then the delayed /RFSH goes high, and pulls /RAS back up again (the 'downward thumb' on your 1st scope picture). A little later the drive strength of ULA's output gets the upper hand again, and pulls /RAS down as it should have done earlier. A similar story for the rising edge where you see /RAS hesitate halfway.
So I suspect you'll see improvement when you take out R57 (unsolder one side for a quick test). And if so: no reason to keep C54 around either. I read you just took out R57 - results? :???: Btw nice you have a scope and willing to get to the bottom of it...
From what I read in earlier posts, it looks like you may have an iss2/iss3 Frankenstein on your hands... :D Of particular interest here: you might want to double-check where the LS157's select signal comes from! (resistor or gate)
Btw you mention a Z80C (Z84C00xx I assume) put into it, is that this machine & if so, what speed grade? In my experience 8 or 10 MHz is usually fine, but 20 MHz version might not be a good match for a machine like the Spectrum.