Skip to content

The Adventure of the Spectrum +2 and the Faulty but Working Data Bus Part 2 – or “Why A != B”

Well, you learn something new every day.

For one thing I’d always assumed that on a 128K Spectrum, memory banks 0, 2 and 5 were in the 64K bank closest to the ULA – after all, the ULA has to access them for the screen. However, when I took out IC 24, I noticed that it destroyed valid data in banks 0, 2, 4 and 6. That leaves banks 1, 3, 5 and 7 as being ICs 25-32 (i.e. the RAM chips at the bottom of the board)

That’s not all I learned though….

I noticed that the memory in banks 1,3,5 and 7 was disintegrating over time. It’d be fine for a while then deteriorate beyond all recognition. This immediately made me think of a refresh problem. But all the chips were known good. And the connections were good. And the signals all looked identical to a working +2.

So what could be wrong?

The more I looked at the Multiface window, I could see it deteriorating into $BF. Not $FF, but $BF. But now I knew that bank 1 which I was looking at wasn’t ICs 17-24 which I had previously thought, but was ICs 25-32.   Now $BF in binary is %11011111 and looking at the RAM chips ICs 17-24, I could see that the third one along (the zero, which is correct) was a different type. I’d replaced all the RAM chips with known good ones to be safe….

.. but this one RAM chip was different.

KM4164B it said.

All the rest said KM4164A.

It seems that a KM4164A needs a more frequent refresh than a KM4164B.

DRAM chips constantly need to be reminded of what they’re holding, otherwise they forget. The KM4164B has a very slightly longer memory tham the KM4164A, so the ‘A’ chip was gradually forgetting what it had been told!

As soon as I put back in the original RAM all was well!

Now it really is fixed! Hurrah!

(I hope!)


The Adventure of the Spectrum +2 and the Faulty but Working Data Bus

Sometimes, you get a Spectrum in that’s a nice easy fix, and nothing all to worry about. The process goes like this:

1) Find Spectrum

2) Examine screen

3) Diagnose fault

4) Locate probable culprit

5) Swap out culprit with known good replacement

6) Check screen

7) Feel smug

8) Go off for a (potentially metaphorical) pint, and blog about how great you are.

Occasionally, however, a machine can be a little less co-operative. It goes something like this:

1) Find Spectrum

2) Examine screen

3) Diagnose fault

4) Locate probable culprit

5) Swap out culprit with known good replacement

6) Check screen

7) Feel smug

8) Notice that games don’t work, even though they load fine.

9) Swear/Curse/Blaspheme* (*delete as appropriate).

10) FOR F = 1 TO 1000

11) Attempt to diagnose fault.

12) Switch out potential culprit

13) IF (F AND 1) THEN Pull out hair ELSE Scream

14) NEXT F

15) Shout “Hallelujah”

Here’s a little piccy of the motherboard. It looks so innocent, doesn’t it? Except there’s something wrong with it. And it’s very well hidden.

Can you see what’s wrong with it?

No, nor could I. Not surprising as I don’t have an X-Ray microscope filter on my eyeball.

So, first up is the symptom:

Don’t worry about the black and white-ness of it all, that’s just because of the usual Spectrum 128+2 Amstrad fail (they put all the 2N3904 transistors on the wrong way round on the board, which includes the one for the amplification of the video signal. Oops). The problem is the pixels (quite obviously) and the pale shadowing to the right of the menu (less obviously).

The eagle-eyed among you will notice that the pixel that’s bad is the second from the left in each character square, i.e. bit 6 (there are 8 bits per byte, from D0-D7 – this is D6 as D0 is the least significant bit, which is on the right of the square, if you see what I mean).

Also, the pale shadowing is because the “bright” attribute is set on the square. Guess which bit of the colour attribute byte governs the “bright” attribute? It’s somewhere between bit 5 and bit 7 (exclusive). Yes, it’s bit 6.

So, out comes the IC responsible for bit 6 of the main bank of RAM, which has the video. Fire her back up again, and hurrah! It looks right! Yay!

Now let’s load up a game. How about Knight Tyme 128? That’ll test the 128K RAM as well.

Here we go… now, I think I need the camera first… ah, there’s Klink. Let’s examine him… all good, now let’s go and….

.. what? No I didn’t! I didn’t press any BREAK key at all!  Grr… let’s try again, I’ll just press a key and…

… it reset.

Oh dear.

That’s probably not meant to happen.

OK, sounds like some bad RAM in the upper 128K. Let’s plug in the test ROM…

… nothing. Strange. OK, let’s whip out the CPU – it’s the Zilog type that the Multiface One doesn’t like at the best of times. Put in a new CPU and…

… all RAM checks out. Which is what I expected, as the machine initialises ok.

So let’s write a little RAM checker in BASIC…. All is good.

Well there must be a problem…. so what is it?

Let’s change all the electrolytic capacitors. That’s always a good place to start on these awkward problems.

Still bad. Let’s load up Hungry Horace. That’s a 16K program, so it’ll help to diagnose where the RAM problem is.

Well, that looks just fine.

Except for the HUGE BLACK LINES on the border!

Now because this is a photo and not a video, you may not realise that at this point it’s making a lot of bloop-bloop noises.

In fact it turned out that every time the game made a bleep noise, the border would change colour. Sometimes black, sometimes yellow, and occasionally green would get a cameo appearance. This leads to the deep philosophical question:

What the heck?

Now naturally, every man in the world (and his dog) would think: “Aha! The border colour is on the same bit as the beeper bit. This means there’s a short somewhere!”

But of course, it could never be that simple, oh no. See, the border colour is held in the lower 3 bits (D0-D2) of the output port $7FFE. If this was a short, then the colour would be yellow all the time – it wouldn’t vary.

Yet clearly the data isn’t getting to the ULA correctly. So something’s squiffy on the data bus.

Not only does the border change, though, but occasionally Horace changes direction. Definitely something weird on the data bus when it’s an I/O (Input/Output) request.

There are two sorts of memory access that the CPU can make:

One is a memory access. The CPU tells its chips what bit of memory it needs, and the memory decoder chip tells the memory chip which row and which column the data bit is that it wants. So in other words, the CPU says “I want the bit at location 10000”, and the memory decoder chip, says to the memory chip “Right you. Go and select row 12. Great, now you’ve got that, you need to look in column 23. Got that? Brilliant, now what’s there? Feed me data!”. Obviously this takes a bit of time (called “latency”). The number at the end of a RAM chip describes the latency, so a 4164-15 means it has 150ns latency. That’s 150 nanoseconds, which is pretty small (but waaaay longer than a modern chip, of course).

The other is an I/O access. The CPU sticks an address on the address bus which the ULA (the bit that makes a Spectrum a Spectrum and not a ZX81 or whatever) can read, and says “Oi! You! Forget the RAM, just tell me what’s on your input port at this location! Now!”  These input/output requests are used for all sorts of things, such as, ohhh I don’t know… border colour, beeper, keyboard presses, that sort of thing. Sound familiar?

So it seems that RAM accesses are working fine, but I/O accesses are not, but it’s not a short circuit.

I say again: What the heck?

Let’s try Jet Pac, I have that on Interface 2 ROM – so I don’t need to wait for it to load.

Plug it in, press a key… now what do I press, let’s …

… hey, the game started automatically! That ain’t right.

OK, at least it’s worki…

Oh, that’s just not funny.

Now, the weird thing about Jetpac is that it does an output to output port $1FFE.  Now the Spectrum is lazy – it doesn’t bother to check that you’re looking at port $7FFE to respond to it – it actually just checks the highest bit and the lowest bit. So $1FFE will actually send data to $7FFE as well. On the 16/48K Spectrum this doesn’t matter – it’s harmless. But on a 128K Spectrum (this is a +2, remember), it activates the shadow screen. So you can hear it playing in the background, but you can’t see anything.  The really weird thing though is that this is a known incompatibility, and it only happens if you select keyboard mode. In joystick mode it works fine.

So when it started automatically, it’s in keyboard mode. Fair enough.

Start again and quickly start the game in joystick mode. Great, here I go… flying, blasting, picking up radioactive bits…  it’s all good! And then….

NOooooo!!! That’s not right. That means – again – that the data bus is wrong, i.e. the output byte it’s sending to $1FFE (and therefore $7FFE) is wrong, because it should be ok in joystick mode.

At least we can replicate it quickly now.

Now, I suffer a bit from PLA-phobia. A Programmable Logic Array (PLA) is a custom chip that’s programmed to behave like another chip. Because they’re custom chips, they’re nigh-on impossible to get replacements for. However, you can program blank ones… if you happen to own a very expensive (usually) programmer. This particular PLA does thinks like artbitrating between different chips, so it might be sending the data to the wrong place. Let’s whip it out…

… Aha! It’s working!

Oh no it’s not.


Let’s change IC10 – that’s another custom chip that governs the address bus between the CPU and ULA. That must be it! Swap it out…


OK, if it’s not that, let’s check the CPU and ULA sockets. Maybe they’re a bit loose and floating. Out they come…. did that make a difference?


OK, maybe it’s noise on the lines? Let’s try a different regulator and coil?


Right, this is getting me down now and my hair is getting thinner all the time. Time to take out all the main bank of memory chips. Maybe one is borderline misbehaving…

Any change?



Well, it could be the upper bank. Change all 8 of those chips too…



Could it be the AY sound chip affecting the data bus? Switch it out…


OK, maybe the 74LS174 next to it? Out it goes….



Right, that’s pretty much every semiconductor around the CPU and ULA now. And they’re all good. As are the transistors.

So… the data bus is good, because the machine runs. The connections are all good. The resistors between the CPU and ULA are all good. The memory decoders are good. Everything’s good.

Let’s take another look at the schematic….

It’s something to do with the ULA or CPU, so let’s look at the ULA first. No, everthing there is tested. Let’s look at the CPU…

That’s odd.

The schematic is missing a chunk. The scan I have is split over two pages, but it looks like the middle  bit – where the CPU is – is missing. This is what you get when you put the two together:

Now look at the top bit. According to the schematic, the clock signal goes from the ULA to a gate, and a pull-up resistor. A pull-up resistor isn’t a kind of nappy, it’s a resistor that means that when the pin is floating (i.e. is neither logically high or low – 1 or 0), it becomes high. A pull-down resistor does the opposite and make the pin 0V. The output of that gate then just goes off to the expansion port, pin 8A.

But that can’t be right. And sure enough, a quick check on the multimeter shows that the pin doesn’t only come out of the gate and into another gate (in the same chip). No, it actually goes off to the CPU.

A brief explanation is perhaps necessary here.

In a normal system, the CPU is attached to a clock crystal, which sends a pulse whenever the CPU is to do anything. So, in a 3.5MHz system like the Spectrum, it would get 3,500,000 “ticks” per second.

A Spectrum is cleverer than this though. A Spectrum sends the clock crystal output to the ULA. The ULA – as it’s the display chip – sometimes needs to be sure it can get at its data, as the display is more important than the CPU (this ain’t no ZX81, you see). So the ULA takes in the clock input, and then sends the clock pulse off to the CPU but only when the ULA isn’t accessing the data bus. When the ULA is reading memory, or doing an input/output to port $7FFE, the ULA stops the clock. The CPU doesn’t get its clock cycle so of course it stops doing anything. As soon as the ULA has finished doing its thang with the bus, it sends clock pulses off again and the CPU gets its turn.

But what if there was a problem with this mechanism?

What if the CPU was doing stuff when it shouldn’t? We already know the CPU is good… but what if it was getting a bad clock?

We know the ULA is good too.

But there’s this little logic chip which acts as a buffer. It’s a 75HCU04

Most logic chips are 74LSxx, for instance 74LS04.. but this one is a 74HCU04 because it’s a high-speed one meant for clock pulses and the like. So what if it’s failed? Could it be echoing clock pulses or something?

Out it comes….

It works! Horace is back to normal! Jetpac works! Hurrah!

Edit: But 128K games still don’t work! There’s a problem with the upper memory as well. The memory is desteriorating, so it’s probably just a dodgy refresh line somewhere. Out come the upper 8 chips again… *sigh*.

Watch this space!

The Amiga 600 and the Unusual Suspects

Here’s a departure from the norm. A “modern” computer. Well, actually, it’s earlier than some of the Spectrum +2A’s and +3’s I do, but technologically it’s a lot more advanced.

When somebody listed a dead Amiga 600 motherboard for £3.99 it was impossible to resist. If nothing else, it’d be good practice on the capacitors!

Amiga 600’s and later all have a problem – Commodore in their “infinite” wisdom used cheap capacitors… the kind that leak and go all gooey all over your lovely motherboard, that kind. Hence here’s the first picture of the victim – er, “patient”.

…. and this is what it does.

Yes, the TV is on. It just does nothing except display a friendly black screen.

Bizarrely, that’s a good thing. A computer that doesn’t start is usually much easier to fix than one that just does something odd if it’s been on for 5 hours exactly, you’ve just got a fresh cup of coffee and there’s an ‘R’ in the month. Not that I’ve ever had a machine with that exact problem, but it’s felt like it sometimes, as they’re bad news, trust me.

The first thing I did was to replace the electrolytic capacitors. As I said, CBM used the cheapest they could find, so when you have an A600 that doesn’t boot, the first thing to do is to recap it. Unfortunately my SMT caps aren’t all quite the right physical size, so I had to squeeze in an occasional radial capacitor instead. The really eagle-eyed reader will notice a whopping great white wire going half way across the board. This is because two of the capacitors are caught between the audio sockets and the keyboard socket, making them practically impossible to get to without removing connectors. I didn’t fancy attacking the connectors, so I took them off the hard way (with a soldering iron) as I couldn’t use my trusty Aoyue SMT reworker as it would turn the keyboard connector into a stodgy mess, which doesn’t help when you want to play a text adventure. One of the caps promptly removed the track off the motherboard for good measure, leaving me nowhere to attach the cap… hence the long wire going off to where the track normally goes. This happened at the top left where the primary power supply caps are too, so there’s a few imaginitively positioned radials up there too.

Hey, don’t look at me like that – I told you I bought this board to practice on!  Those pads are awful as they just fall off so easily.

Luckily, that’s all that went wrong, so once I’d recapped it, I turned it on again and….

… well, see the previous picture.



The Amiga has lots of custom chips that do all sorts of funky things, and of course the main one is the CPU. Let’s check the lines….  nothing. Absolutely nothing. Very odd. Oh hang on…

The /HLT line is low. As is the /RST line. That means the pins on the CPU for /HLT (which means “HALT when logical low 0.0V) and /RST (which means “RESET when logical low”) are both active – the CPU is doing nothing because something somewhere is telling it to do nothing.

A quick check of the schematic shows that the /RST line goes all over the place because it resets everything, not just the CPU. But, the /HLT line, on the other hand, is governed by the chip which is responsible for resets…. Gayle.

So, Gayle, are you defective…?

Out come the Aoyue 8208 (which is awesome), and off comes Gayle. Enter our donor machine, a spare A600 motherboard which I bought ages ago when my A600’s board died (it was just the capacitors, though, so both ended up working). Off comes the known good Gayle, on goes the dodgy Gayle to the working board… and….

…. it works! Hurrah! Gayle is working. That means I have a chance.

Stick the known good Gayle onto the dead motherboard and….

… still dead. Just as expected.

OK, that’s fine. That means that Gayle is receiving a signal to reset.

There’s two reasons for Gayle to reset the board – one is the Vcc (+5V) voltage being under about 4.7V, and the other is the keyboard reset.

Now the voltage being under 4.7V is the usual culprit when A600’s don’t start – that’s what happens when certain important electrolytic capacitors fail.

But the voltage is 5.04V. That’s just peachy.

So what about the keyboard reset? If Gayle thinks that the keyboard is constantly sending a reset signal, that’d cause the motherboard to stay reset and never do anything.

Let’s have a look….

Meet Gayle.

I’ve helpfully labeled pin 63. It’s the keyboard reset line, and like the /RST and /HLT lines, it’s actually /KB_RESET – i.e. it’s active low. So let’s look and see what the value is… *drum roll please*

0.0V (more or less).


The keyboard reset line is being held low! That means poor Gayle is sitting around waiting for the keyboard to say it’s ready. We have a potential culprit.

Let’s take a look at the circuit, boys and girls….

Here’s the part of the circuit board….

… and here’s the schematic for that part of the board….

The white wire on the chip is for that nasty capacitor, remember? It’s not important, but it’s not normally there so just imagine it’s not there or something.

So what we have is a keyboard connector, which is wired up to an AND gate, presumably so that when Ctrl, Left Amiga and Right Amiga are pressed together, it triggers (for people who don’t own an Amiga, that’s the soft-reset key combination). That then goes through a 555 timer/flip-flop, and gets sent to Gayle. The 555 is the little 8-pin chip.

So… which is wrong, the 555? Or the input to the 555? Let’s take a look at some pins.

The output pin on the suspect one is 3.7V. That means it’s logic high, for a 555. The good one is 0.0V. That’s good. It’s consistent with what I expected.

And the input pin is on the good 2.2V (i.e. active) and on the bad 1.1V (i.e. inactive).

Ladies and Gentlemen, we have a winner. The input to the 555 is bad!

Let’s check the input voltage to the transistor Q622, which governs the input. That should be low (inactive) on both… and it is.

Right, so the transistor is bad, or the capacitor or resistor in parallel to the connection to the 555 are bad. Ignore R624 on the schematic, by the way, it’s not really there.

Quick check of the resistor… should be 10K… measures… 10K.

So, either the 555 is bad (unlikely as it’s behaving correctly), or else we now have a prime suspect: C611.

Now ceramic capacitors like this very rarely go wrong. They’re not like electrolytic ones, they’re pretty study. And there’s a lot of them, so it’s not really practical to change them all.

However, we can change this one.

There he is. Time for the donor board to give “blood” once more….

… fire up the machine and….


Well, in that case maybe…

… oh, the screen just went grey.

Hurrah! Success!

“No disk present”? Thou liest, foul 3″ disk drive of Darkness!

Obviously interesting repairs are like number 9 buses – they always come several at a time when you’ve had none for ages.

This particular “gem” comes – as always – courtesy of eBay. The seller had pointed out, to be fair, that the disk drive wasn’t working. Now me being a sucker for this sort of thing (the words “not working” are synonymous with “a challenge”), and me realising that 90% of the time this is just a disintegrated drive belt, bought it. It’s in good nick, actually, a bit of wire rash but nothing too bad.

Anyway, back to the patient. When the 6128 arrived, first thing to do, is fire her up and….

… it’s exactly as it was sold. Let’s just check the reality:

Either I’m seeing things, or else my Amstrad is lying to me. That’s good. I hate when I get ripped off and buy something that’s supposed to be broken and it works perfectly.

So out comes the disk drive, and out comes a new drive belt ready for it.

That’s odd. The belt is still there. See those black marks on the spindle? That I believe is where the previous belt munged itself all over the inside of the drive. When these belts get old, they turn into a sort of mush. I once made a little ball out of a mushy drive belt, just by rolling it together – it wasn’t just a ball of belt, note, it was actually a solid ball of rubber. That’s how disintegraty they get. So – the belt has gone all kersplatto all over the drive, so why is there still a belt there? It must be a different one. Would have been nice if the seller had mentioned that he’d already tried to fix it and found it wasn’t the normal belt error, but that’s probably a bit much to ask for.

So if it’s not the belt, then what is wrong with the little fella? Let’s have a close look… hmmm… everything seems ok.

Now, the main reason for an Amstrad failing to see a disk is the index hole. If the CPC doesn’t receive an index pulse then it thinks there’s nothing inserted. The index hole is on the disk – if you look at a disc you’ll see a little hole towards the centre. The drive shines a red L.E.D. through this part of the disk – when the light hits a receiver on the other side of the disk, it knows the hole is there, and it knows where to start reading. No pulse = no disk.

So – this index hole – is it working…..? Out comes the oscilloscope. Right, motor not running. Check voltage… voltage is there, light is shining. Check voltage on receptor – yes, that looks correct.

Now… fire up the disk.

Aha! Pulses on the light receptor. That’s good, it means it’s getting an index hole ok.

So what could be wrong…? All looks good.

Now, let’s check the resistors as they’re easy to check. Let’s start here with this… er…

What is R19? Out comes the multimeter… OK, it measure 66.6 KOhms. 66600 Ohms in other words. That’s possible. Although all the other resistors around it are rather lower.

Now as luck would have it, I use a 3″ drive with my Catweasel. I maintain the Catweasel drivers for AmigaOS 4, which means I have the necessary hardware and software for playing with disks. And Oh Look! my 3″ drive on the Catweasel is exactly the same type of drive as the misbehaving one.

Let’s take a look.

Now that’s interesting.

That says “301” which means 30 with one “zero” after it. I.e. 300 Ohms. Now a resistor in a circuit will usually have a different resistance to when it’s on its own, because other parts of the circuit will affect it. However, the resistance will never go up, only down. So… I’m guessing that 66600 Ohms instead of 300 Ohms may be a little wrong. Now what does this resistor do…? Interesting. It’s the resistor for the index hole LED. Very interesting.

One quick switch later, and my patient has a 300 Ohm resistor for R19 instead of a 66600 Ohm one. And look! the LED is rather brighter now! Hurrah! It must be that the LED was too dim to trigger the transistor on the other side of the index hole.

Let’s fire her up again….

Yes! It sees the disk! No! It’s got read errors.

It was to be expected, I guess. Probably just needs realigning. Realign the drive… same error. Odd.

Keep realigning it… still exactly the same error. Very odd.

So something else is wrong as well? Typical. Change the belt (again)… same problem. Another quick look over the PCB and I see… nothing odd. Everything looks good.

Remember I mentioned about the Catweasel, and how I maintain the software? The great thing about that is that I have complete control over the disk interface.

First thing – try and dump the disk…. errors. Nothing reads. OK, that’s good, it means that the drive is behaving the same on the Catweasel as it does on the CPC.

So I modify the code so that it dumps out the pulse widths instead of actually reading the data.

Data on an MFM disk like this is stored as a sequence of pulses, of certain lengths. Zero is one length, One is another (longer), Two is longer still. That’s not the actual data, but it’s represented using those three lengths.

So what’s on the disk, is it reading anything?

Hello… it’s reading data! So why it is not working! I can even see the sync pulse which says the beginning of the track, helpfully and skilfully highlighted in red by The Gimp (no, not that sort of gimp – I mean the software package).

The sync pulse is a 0,1,0,1,2 sequence. I.e. short, medium, short, medium, long. So it is reading data.

Let’s plug in another working drive.

Once again we see the same. Lots of zero pulses, followed by the sync pulse.

But they’re different lengths!

The bad drive is reading $15 for the 0 pulse, but the good drive is reading $1A. No wonder it’s not working! The data is correct, but the pulses are the wrong length, so therefore the motor is turning the disk at the wrong speed!

Usually, if the speed is wrong, it’s because the belt is slipping. But this would make it too slow not too fast.

“Hmm…”, thinks I, “… I wonder what would happen if….”

so off I go back to the code, ready to change the thresholds to see if I can read data.

Well, well.

Those timings look familiar.

Just to explain: 5.25″ disk drives rotate at different speeds depending on whether they’re Double Density (very early PC – 360K 40 track) or High Density (286/386 era PC – 1.2MB 80 track). The earlier drives rotate at 300 rpm like every other drive, the later ones at 360 rpm. This means that data read on a 360 rpm will be different timings if it’s been written on a 300 rpm – i.e. you write a disk on a 360K disk, then the 1.2MB drive will read back with shorter timings. This is why my code can handle both timings depending on what kind of drive is attached to the Catweasel.

So … let’s set the normal timings to be the same as the 300rpm-read-in-a-360rpm-drive timings.

Hey presto! The disk dumps correctly!

Er… that doesn’t make sense. That means the drive is running at 360rpm. No 3″ drive does this that I know of.

Let’s measure the voltage… 12.1V. Check against the working similar drive – 12.1V. That’s ok then. It’s a D.C. motor, so it should be spinning at the same rate.

But it’s not.

Both motors have the same part number.

But they’re getting the same voltage and spinning at different speeds.

Let’s try swapping the motors… it’s easier than faffing around with chips and stuff.

Set the timings back to correct timings….

… and the disk dumps perfectly.


Stick it all back together… put it in the CPC….

It works! Another CPC lives to fight another day!

The only thing I can think of is that the previous owner, upon realising that changing the belt did nothing (and not noticing the 66.6KOhm resistor) even changed the motor for some reason, and put in a motor from a 1.2MB PC drive. And then it still didn’t work, so he flogged it to some poor unsuspecting fool (read: me).

Now… does anybody have a spare 300 rpm 12V DC motor….?

Crikey! An update! RAM looks good, so why doesn’t it boot ….

Yes, after a few aeons of non-interesting repairs, I have finally been given a moderately non-standard one. The patient: a perfectly normal Spectrum 48K. Perfectly normal, that is, if it weren’t for the fact that it doesn’t start up (although some might say that is perfectly normal for a Spectrum). The symptom: a black screen. Or sometimes a white screen. And occasionally one odd block on the screen. First thing to check is to attach the memory test Multiface 1. Boot up the Spectrum, press the magic button and… .. nothing. Oh great, it’s one of those faulty Z80s that doesn’t have a working M1 or NMI line and so the Multiface doesn’t work, which means no memory test. So first thing to do is to whip out the Z80, and stick in a nice new Zilog  Z080004PSC Z80A CPU. That’ll do it. Press the magic red button and… still nothing. Huh? Let’s try the new CPU in a known good motherboard…. press the button and… nothing. OK, maybe it’s a faulty chip (it looks new so should be ok). Try another, as I have three from the same place.  Same thing. Faulty CPUs? Maybe. So in goes a known good CPU, press the magic button and lo and behold the Memory Tester appears!

Excellent – there’s just one problem – it all looks good. But it’s still not working. Does this mean the ROM is bad? Let’s try something….

JetPac exists on ROM cartridge. This is useful. Not just because you can get a fix of blasty-shippy-goodness at a moment’s notice, but also because it lets you see if the RAM is really good or not. As you can see by the picture, it works. Of course, I had to check this for a few levels, and after realising how rusty I was at it, decided that yes, the game works. Which means the RAM is good. OK, so RAM is good. CPU is good. ULA is good (tested that first ‘cos it’s easy – they’re always socketed). ROM is dubious, then. Suddenly, a thought appears in my brain (cue Light Bulb and “Aha!” noise). My memory test shows the RAM, is good, and we know the RAM is good, so let’s see what happens when I attach a perfectly normal Multiface 128…

Bingo! Multiface works. That’s odd, that implies the ROM is good too.  Let’s have a look…. Yup. The ROM looks ok. While I’m here, I can check the upper RAM. If the upper RAM is bad, the Spectrum will boot into 16K mode… To test the RAM, the Spectrum writes $02 in all RAM locations down to the bottom of RAM. That’s why you get the red lines on the black background – the colour red is $02, and the line is actually one bit being set in the display (bit 1, naturally, as bit 1 would be $01, and bit 3 would be $04). The Spectrum then checks that it can read back $02, and then does the same back up the ram using $00 instead. When it finds a bad location, that’s when it knows the end of the RAM is here. Occasionally, though, RAM chips can get triggered when they shouldn’t.

Now that’s very interesting. I just wrote $FF into location $8000, and what’s the $04 in the line below doing? Write $FF into $8010 and ping! $04 appears in $8018. We’ve got crossed address lines! Out comes the old, in with the new…. well, usually, anyway. For some reason I felt like keeping it original, so I grabbed a genuine  TMS 4532-NL4 from a spare Spectrum (rather than a 4164 I’d usually use – 4532s became obsolete in the mid 80s as they’re actually faulty 4164s, and it was cheaper to just use 4164s then as manufacturing processes improved).

There we are, just like new.

Interesting fact: Multiface 1’s don’t work with Zilog Z080004PSC Z80A CPUs – Multiface 128’s do. Need to find out why now!

Help! I’ve forgotten how to boot!

I couldn’t resist this when it came up:

It’s a VIC-20 that appeared on eBay for £10 + £10 postage, in nice nick. “Too much!”, I hear you cry – but this one was boxed too. OK, the box is a bit ragged round the edges, but it’s acceptable. And the machine is nice. Now, obviously, it doesn’t work. Turn it on and the screen is black. That can be any number of things. So, let’s take a look inside, shall we, children?

Joy! A lot of the chips are socketed!

A quick check of the oscilloscope shows not a lot of activity, so the first thing to test is the CPU. Stick a new 6502 in that I have lying around, but no change. Put this one’s 6502 into a working VIC-20, and it works fine. OK, it’s not the CPU.

Next most obvious thing is the VIC chip – these things die fairly often. A quick switcheroo with the working machine, and it’s still working (the working one, that is, not the patient!). OK, it’s not that either.

In order of likelihood of morbidity of computer components, the order goes like this: RAM, custom chips, CPU, Gate Arrays, ROM. The CPU is good, we know that. The custom VIC chip is good… so what about RAM – the usual culprit?

Now from what I recall, the VIC-20 does a memory test when it boots up… so let’s have a look at the RAM. Ah heck, these guys aren’t soldered.

This is a later model VIC-20. It has the C64-style power supply, rather than the earlier two-prong PSU. Also, therefore, it has only 5 RAM chips – the older model has 11.

Now, anyone with a modicum of technical knowledge is probably now thinking I made a mistake in that sentence. Yes, I said 5. FIVE. That’s not exactly a nice round number in computer terms. Nor is eleven, incidentally. Far from it, in fact.

The VIC-20 is a curious beast. It has 5KB of main RAM, and an extra chunk of 4-bit RAM for the colour map for the screen. Hence there being an odd number of chips: the larger two on the left are 6116s, which are 2KBx8 (i.e. 2048 locations with 8 data bits), the smaller ones are 2114s, which are 1KBx4. That means 2 lots of 2KBx8 (= 4KBx8) and one pair of 1KBx4 (thus giving the equivalent of 1KBx8). 4+1=5 (usually) so we get 5KB RAM. Then you stick on the colour map chip (on the far right, I believe) and you get 5KB of RAM and 1KB of 4-bit RAM for the colour. Phew.

Still reading? Good.

Now, me having seen the oscilloscope readings, noticed that the CPU was starting up, executing for a bit, then freezing solid.

“Aha!”, think I in a fit of optimism, “This sounds like a memory error in the system memory!”.

So, I decide to switch out the main 4KB of RAM.

Now, it’s a little known fact that some PCBs are suicidal. If you so much as look at them with a soldering iron, a track will break. So, despite a lot of very careful soldering, one track lifted with the IC. D’oh! Annoyed now.

This is what the back now looks like:

It could be worse, but it’s still annoying.

Put in a new IC to see what happens… I don’t have a  socketed 6116 anywhere to test in, and I didn’t want to desolder my working VIC-20’s RAM. No change.

Out comes the other bit of RAM…. this one is fine, though, it pops out nicely.

In goes a new RAM chip, and ….

… no change whatsoever.

Hmm. So the RAM was good after all. I could change the other RAM chips, but they’re mostly for display – the machine would probably come up even if they were dead, it’d just look wrong.

Let’s take another look. The 6522 VIA chips? Let’s remove them and try… no, still nothing.

I guess it could be a ROM, let’s trying switching it with a working ROM, may as well…

Ping! Up comes a working VIC-20!


Which just leaves me annoyed because I damaged a track for nothing. D’oh!

Let’s have a look at the culprit:

That’s him there. Socketed all along. Should have checked him first. Thicky Ian Thicky.

The great thing about ROMs, is that you can replace them as long as you have a dump of their contents (which is easy to get). The really bad thing, is that the 2364 ROM chip is a 24-pin IC. Fine, except the 2764 EPROM chip is a 28-pin. So we need to be imaginitive.

So, grab the ROM from the CBM FTP site – there we go. Fire up the Pegasos II machine which has a Catweasel in it, and put the ROM file onto an Amiga floppy. Boot up the A500 with the EPROM burner, and burn a nice new VIC-20 ROM. A new ROM is born!

But of course it needs to be operated on now. As it stands it has too many pins, some of which are in the wrong places.

Here’s a useful site:

To copy his info:

2364 Pinout:

8K * 8 NMOS ROM, 24 Pin DIP (various manufacturers).
A7 | 1 24| Vcc
A6 | 2 23| A8
A5 | 3 22| A9
A4 | 4 21| A12
A3 | 5 20| /CS
A2 | 6 19| A10
A1 | 7 18| A11
A0 | 8 17| D7
D0 | 9 16| D6
D1 |10 15| D5
D2 |11 14| D4
Vss |12 13| D3

A0-A12 Address Lines. 2^13 = 8192 (8KB).
D0-D7 Data Lines.
Vcc = +5V.
/CS = Chip Select (Active Low).

1 -|Vpp Vcc|- 28
2 -|A12 /pgm|- 27
3 -|A7 nc|- 26
4 -|A6 A8|- 25
5 -|A5 A9|- 24
6 -|A4 A11|- 23
7 -|A3 /OE|- 22
8 -|A2 A10|- 21
9 -|A1 /CE|- 20
10 -|A0 D7|- 19
11 -|D0 D6|- 18
12 -|D1 D5|- 17
13 -|D2 D4|- 16
14 -|gnd D3|- 15

That probably looks better in a monospaced font. Oh well, you get the idea.

From that info, we can wire up the 2764 to pretend to be a 2364.

And here it is! My new baby:

Lovely eh? Just looks like it’s starring in The Silence of the Lambs or something. But it works. For reference, here’s the back….

Stick it in and see what happens:

It still works! A little bit of insulating tape….

and it’s safe to use!

I know, I know, I could have just used wires. But I’m actually using the cut-off parts of capacitors for this, so I’m recycling. Plus I’m going for the whole tortured-ROM effect, and it looks cool.

Stick it all back together and….

Ladies and Gentlemen, we have a winner. And very smart it is too.

Now, here’s a picture of a lizard.

He was sitting outside the office and I nearly trod on him. Failing to find Mr. Attenborough anywhere around, I took a few photos (looking a complete idiot in the process), and put him safely on the grass.

Now I’ve just received a mountain of parcels from Nice Mr. Postie. Hurrah again!

The Mystery of the Troubled +2

A new patient arrived today! First one for a while, indeed the first of this month, it seems.

This particular Spectrum +2 is doing nothing. That is, you plug it in and nothing happens at all. Here it is:

The eagle-eyed among you will notice that it’s not plugged in. Trust me, if it were, it would look exactly the same.

Now Spectrums that do nothing are actually fairly easy to diagnose. A quick check of the multimeter and sure enough, the +5V line is… +0V. Nothing (give or take a bit). Certainly not enough to power the power LED let alone the rest of the system. So, here’s the obvious culprit:

It’s the regulator. I buy them en masse as they get old and kick out a load of interference (especially on issue 2 16K/48K machines).

This one, however, has gone to meet its maker. It has joined the choir invisible. If it weren’t for it being screwed to the heatsink, it’d be pushing up the daisies. This is an  ex regulator.

So, out with the old, in with the new:

Much better. The white stuff is just thermal paste, to make sure a good thermal connection is made between the regulator and the heatsink.

Time to power it up and test it! Here’s hoping…

Hurrah! Let there be light! And it was good.

Well, kinda. The light was good.

Nooo! Not the old “No Signal” screen. Obviously not quite as easy as I hoped!

While I’m at it, I may as well fix up the transistor in this machine. It’s a well-known(ish) fact that all the 2N3904 transistors on the Spectrum +2 are the wrong way round. This doesn’t exactly help them work well. So this:

becomes this:

Try again… Still nothing.

But wait a minute, I’ve seen this before. In a previous blog posting I droned on about a toastrack not seeing a display. So a quick check on the TEA2000 chip (pin 11, the +12V supply) showed that it most definitely wasn’t +12V. Aha! Now, if I remember correctly….

It’s a ZTX650! My old friend! Which means here….

is its partner in crime! The ZTX213!

OK, out they come, in go a brand new ZTX653 and BC213. Turn it on and:

Hurrah! It lives!

Now, I noticed that the tape’s drive belt was very loose. That’s not good – it should be taut. So, here’s a new one:

One of Dataserve Retro’s most excellent drive belts. And no, the fellow who runs that company is no relation.

A quick change…. press play and… it’s very loud! Very squeaky! Not good. What’s causing that noise….?

THIS is causing that noise. You see that white block in the middle? It’s not supposed to touch the metal wheel. For some reason it just lightly clips into place, and there’s a spring on it, so it can unclip itself and hit the wheel. It’s actually the pause button mechanism.

So now:

That’s better! See there’s a 1mm gap now!

Fire her up again…..

start up the loader.. press “play” and….

Nothing. Zip. Nada. Rien. Oh joy.

Obviously, just like everyone else in the world, I have a spare Spectrum +2. So I try the tape deck…. and it loads just fine. Hmm…..

Here’s the tape deck’s PCB:

Now by this time I’ve already recapped the Spectrum, but wait! There’s more! No, not a free pen with every enquiry, but more capacitors!

A quick change of them and…

It works!

Another Spectrum +2 lives to play Jet Pac another day!