This is an old post, preserved for reference.
The products and services mentioned within are no longer available.
Here is a slightly unusual ZX Spectrum +2 128K, the grey model. It appears to be running, but there is noise on the screen when it is working.
The noise doesn't appear to be analogue in origin, it is very clear regularly repeating patterns, and they stop when you hold down reset. Quite strange.
Normally when you see screen corruption like that on a Spectrum it is a RAM fault, it is in the shared memory bank that provides both the screen RAM and the lower 16K. That means the Spectrum doesn't usually work.
This one is a little twitchy, some things aren't running, but running the same thing from a ROM appears to work better.
And indeed this memory tests pass.
As does the other one.
So, I was less inclined to think this is a memory problem. (I was wrong, but please don't judge me). The 128K has a lot more going on inside that the original 48K machine, but still has a lot in common.
I had seen something similar on a 48K Spectrum, there it was a problem with the multiplexor chips which switch the RAM address lines between the Z80 and the ULA (which generates the screen display).
On later Spectrums, and the Grey 128K, the multiplexor chips are combined into a single 40 pin package, here marked PCF1306P. I desoldered and socketed that, and tried a known working MUX chip (a later Amstrad 40058 version), but that didn't make any difference.
I also looked at a few other chips involved in the multiplexing circuitry, before accepting that it probably wasn't there.
Maybe it was the RAM then? Even though it was passing RAM tests? I decided to get a second opinion before starting on the RAM.
Brendan Alford (the author of the
ZX Diag software I had been using for testing) confirmed the RAM hypothesis (and referenced an article he had written about
ZX Spectrum RAM faults). He even pinpointed the problem chip for me.
IC26 is bit 6 of the lower bank of memory (which is shared between the CPU and the display). You can see for looking closer that all the lines are on the second pixel along on each character. The rest of the characters are fine, although the background brightness changes (which is also controlled by bit 6).
I removed IC26 and replaced it with a known working chip. I didn't have the same speed (150nS) to hand, so I used a faster 120nS chip.
Success. The corruption has gone, so it seems the RAM was woking fast enough when the CPU accessed it, but not quite fast enough for the video RAM. Most of the Grey 128K machines I have seen had 120nS RAM, so maybe they changed to that later on.
This one now has the single 120nS chip, and the rest still seems to be coping fine after a soak test. I wouldn't normally mix speeds, but you can get away with it as long as your replacements are not slower than the originals.
That seems to have fixed it. Can't say I've come across a RAM chips which was right on the edge of failing, but still just about running OK at slower speeds.
Time for some more testing with the built in tape drive, and a divMMC future.
