Commodore PET 3032 Repairs - Intermittent Problems

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

Today we have a couple of Commodore 3032 (2001N-32) board repairs, with some unusual problems. The first has a couple of intermittent issues. Firstly, the display occasionally drops down to half width, with the ready prompt appearing in the middle of the screen. It also has a tendency to lock up, sometimes after a few minutes, sometimes it will last an hour, and occasionally drops to lower case before doing so.

When powered on, all looked well, all the ROMs and RAM appeared to be working. I ran this for a while and eventually saw both problems. As ever when looking at a new board, my eye was drawn to some previous repair work. The 74LS08 at UH10 had been socketed and replaced. This is part of the frame counter / sync generation circuitry, so could well be the cause of the intermittent display fault.

Although it looked a similar vintage to the rest of the board, I don't think it was as original as the other 74LS08 chips on the board are marked F (Fairchild?) not Texas Instruments, and there was flux residue on the back of the board.

The pins on the chip were tarnished, so I sanded them to get a better contact and replaced the chip. It ran for quite a while, but the half screen problem did come back (between a few lockups). Ah the fun of testing intermittent faults.The chip had tested OK, but I tried a replacement anyway, and again it ran for a while and eventually showed the problem again.

I suspected it might be a bad contact on the socket, so I removed the socket and soldered the chip directly the board, and that sorted it. The board has run for probably a couple of days since then and that half screen display problem has not showed up again. It did keep locking up through.

Testing with PET diagnostics, it ran flawlessly all day. So there were no issues with the ROM chips or the RAM, they were all working fine, and kept passing all the tests, but as soon as I went back to a 6502, the lockups returned.

I tried various 6502 chips, also removing or replacing the 6520s and 6522. Taking those four chips and running them in another 3032 board, they also ran all day without a problem, so it wasn't the chips, it was something on the board. Nothing was running hot (at least nothing that wouldn't normally run hot).

I turned again to the sockets. The white single white IC sockets are generally a bit rubbish, and I have had problems in the past, usually with intermittent contacts on the ROM chip sockets, but these had continued to pass the tests. A trick I have used in the past is to push a turned pin IC socket into the white socket, and put the chip into that. The pins on the turned pin socket are a lot thicker than a normal IC, so it's not recommended, as it bends the contacts away. In doing that though, it does usually make a good contact with them. I tried installing an extra socket for the 6502, and in ran for a good few hours, but finally locked up again. Power cycling at this point brought up the monitor program, often a sign that the 6522 is faulty, so I double socketed that as well, and this time it ran for 6 hours without a problem.

side note: the missing chip is the 6520 which is used for the IEEE-488 port, you can run the PET fine without that, you are just limited to loading from tape, so I removed it to simplify things. And yes, I put big labels on my test chips to make it easy to identify them. Have you got a problem with that?
Excellent, I think the issue has been located. It's probably not the best idea to leave the double sockets in place, so I removed all four 40 pin sockets (since two had problems, I wouldn't trust the other two).
I have found in the past these can be tricky to desolder as they tend to hold into the tracks on the top of the board and can lift tracks or pads if you're not careful.

I have found the safest way to remove them is the carefully lift off the plastic cover and desolder the pins one by one. You can see how the sockets 'work' quite clearly here. The pin is a bent bit of metal with a bit of a spring to it, and the pin sits between the plastic body and the bent bit of the pin.

Here you can see the arrangement with the cover removed. It doesn't take much to imagine one of those pins might not be pushing enough, or thermal expansion might move things just enough to break the contact.

One of the pins from a white socket from that PET board is on the left. I referred to these as 'single wipe', so a single contact point with the chip leg. On the right is a modern 'double wipe' contact, where the pin also includes a side section and the chip left is held between the two points of contact, which is usually more reliable.

I prefer to use turned pin sockets, which have three or four points of contact and seem far more reliable. With those four sockets replaced, and the original chips installed, the board ran for most of a day with no problems, and again for several hours the next day after a cold start.

You can never say conclusively an intermittent fault has been fixed, but this board seems solid now, and I am happy to send it back. Unusually, with all its original chips intact and working.

Time for a bit of a break before we move onto the next board. You can drink your weak lemon drink.....now.

Board #2

The second board was showing a garbage screen, the usual symptom if the PET hasn't 'booted up', if the CPU has not been able to run the instructions in ROM, which very early on clear the screen. Instead, the screen shows the contents of the video RAM, which is just the random state of uninitialised static RAM.

It looked like it was going to be easy, as soon as I opened the box, I could see the ROM chips were in the wrong order.

Or rather, there was an EPROM (of the wrong size) in UD9, and that chip was in socket UD5. Nice and easy, swap those around, quick test and I can finish early today. Well, no, that was never going to happen, was it. Better run the diagnostics first, just to check they are alright.

Oh, that's not good. You can see the EPROM is empty (confirmed in EPROM programmer), and the F000 ROM chip is on the wrong place (in D5). It also shows the ROM in socket D4 is faulty.

I initially read that number as 901474-04, which is the editor ROM chip from a PET 8032. But no, it's actually 901472-04. This is a ROM chip from a Commodore printer.

It may seem odd to have a printer ROM chip in there, but those chips were occasionally to be found inside PETs, normally with black paint on them to hide the number, as shown on the top chip in that photo. They were presumably bought cheap from Commodore, and were sold as security keys with the Visicalc software. It would check certain bytes in that ROM chip to see if the user had bought a licensed version of the product. This one doesn't look like it's been painted, so may have been someone cheating the system.

Same markings on the rear, but unfortunately it is not working, returning intermittent results and running a bit warm, so has been removed. With that removed, the results were the same. The display was messed up a bit, usually indication a video RAM fault, and indeed, it was showing an issue with bit 6 of the video RAM, and bit 7 of the lower bank of main RAM. That would explain why it wasn't booting.

I fitted a video RAM replacement board, which uses a modern RAM chip instead of 2114 chips, which are more difficult to get hold of. That last lot I bought about 75% were faulty.

Seeing ebay listings like this with chips on nice staticy carpet may go someway to explaining it, as would the cling film they will probably arrive wrapped in.

With the video RAM replaced, the screen was clear, and I noticed another issue it had detected, reset line stuck high. I'll sort that later. At the moment, the main issue is bit 7 of the main RAM is still faulty.

Looking at the RAM, one of the chips is socketed. Can you guess which one? I swapped in a known working 4116 chip, but it was still failing. Checking continuity, three or four of the address lines were not making contact on the chip. Another bad socket? Well, I though that, then I looked under the board. I was obviously so horrified, I neglected to take a proper photo of that. Several of the pins had blobs of solder on them, but were not actually making contact with anything, the pads having fallen off. I removed that and cleaned up that board, and also removed the chip next to it (properly, without doing the sort of damage as the last person who had worked on this board).

With the board cleaned, I could see one track had been lifted and two pads damaged on the top, and on the bottom, half of the pads had falled off, clearly the through hole plating had come off when the original chip had been removed (apparently using a claw hammer or similar implement).

As most of the tracks are on the top side of the board, I decided to solder the chip back in, so I can make sure each pin was soldered to its track. I used a small wire to replace the missing track. The RAM chip beside it and the 74S04 were removed to give easier access to solder the chip in from the top of the board (there was nothing to solder to below).

You can see there are now 8 pads are missing, a extra few were loose and not connected to anything, so they were removed. You can see the scorching to the board where the previous repairer had used too high a heat.

I actually put the chip which was originally bit 6 in the spot where the damage had been done, as that was a matching chip to the rest of the set. I didn't have an identical one, so I fitted one with similar specs where the bit 6 chip had been (in case it had to be changed later, as that would be a lot easier to remove).With those replaced, running the diagnostics again, all was well, and the PET was booting.

I ran that for a while, and a few power cycles later I noticed the keyboard wasn't working. Ah yes, the reset line was stuck high.

I confirmed this on the scope, the reset line was going high at the same time as the 5V line, so there was no low pulse which should be there to correctly initialise the chips. The reset circuit is a fairly reliable one, a 555 timer which generates a one second pulse which is then inverted and buffered. I used this same circuit on my CPU, Clock and Reset board for the RC2014.

On the PET, the 555 wasn't firing, and checking the two RC circuits, it seems the 1uF capacitor was open circuit. Ah, tantalum bead capacitors, my second least favourite capacitor (behind the RIFA brand mains filter capacitors). These have a tendency to fail, sometimes you're lucky like this one, and they fail open circuit, it is like they are not there. Other times, they fail short and go bang eventually if across a power rail. Nasty, evil blobby things, they should be banned.

Luckily, the Commodore engineers provided pads for two types of capacitors, the other being an axial ceramic capacitor (like I use on the RC2014 board), so I fitted one of those instead, and the reset pulse was present once more.

When testing these boards, I often use a BASIC memory test program. I've updated this several times, so it now tests quite a lot of things, so is quite slow, but that's often quite handy as it takes about an hour to run, so is a bit of a stability test as well.

More soak testing and several power cycles, and there is another 3032 board back up and running.

Designing the divMMC Future

This is the story of the divMMC Future, a version of the divMMC SD card disk drive solution for the ZX Spectrum, produced by The Future Was 8 bit.

From the start, this had to be the best divMMC you could buy, had to be small and neat and work on as many Spectrums in the range as it could, ideally all of them. It had to be as good as the SD2IEC Commodore disk drive. This was quite a tall order, I don't think any of us realised what we had taken on.

My first involvement with divIDE and divMMC boards came when one supplied with a ZX Spectrum that came in for repair many years ago. The Spectrum had been working, but it didn't recognise the divIDE (can't remember what type it was), then the Spectrum failed (flashing coloured squares), so I was asked to fix it, and test it with the divIDE. The repair of the Spectrum was straightforward (dodgy RAM and TR4, one of which most likely caused the other). When it was working again, it still didn't see the divIDE. I tested that with another Spectrum board and it turned out it did work. Google at the time came back with result basically along the lines of 'yes, they don't work with some Spectrums'. I now know why, but at the time, wasn't able to provide a solution. I had similar results when I borrowed a divMMC (another type, sorry, can't remember what that was either), the owner of which said it was 'intermittent', and he was right.

divMMC Future V1.0 

Move forward to August 2016, and TFW8b had just started to produce my VIC20 Penultimate Cartridge. They had built some prototypes of a new divMMC board, and asked me to do some testing. They had done an excellent job squeezing the circuit into the form factor that had been chosen.

The board I received had already gone through a few changes, but would go through quite a few more as time went by. The issue at the time, and the one that persisted through many versions was that of compatibility across the range of Spectrum computers, and of stability. The rule in place from the start was the TFW8b would not be selling this unless it worked across the range and was stable on all of them. We had several other divMMC units to compare against, and an increasing range of Spectrums to test with, and a big spreadsheet of 'which divMMC boards worked on which machines', and later we added, 'with which games' and 'with which SD cards'.

The other boards we were comparing against, let's call them a big black board and a blue board, both worked on many machines, but both had issues with various models. So the aim was to get the divMMC Future to work on more models, ideally on all of them. The only one we ruled out at the time was the Spanish Spectrum 128K Toastrack, as that doesn't have a clock signal on the edge connector..... (see later).

One thing that might surprise you on the back of the divMMC future v1.0 board is a set of DIP switches. At the time, two were fitted, one to enable programming, and one to select the right model of Spectrum to get around changes to the ZX Spectrum edge connector in later machines.

ROM enable lines

The Spectrum up to and including the Grey +2 128K had a single ROM chip, and a single enable line on the edge connector. This was setup so the ROM enable line from the ULA went via a resistor, so an external device could pull that line high to stop the ROM being enabled, and replace some or all of it. This was used by ROM cartridges and by things like the Interface 1 ROM extensions.

The Black +2 and +3 had two ROM chips, controlled by two separate lines from the ULA. Amstrad decided to make these signals available on the edge connector (in place of two different signals from the Sinclair versions), and then to ignore the original enable line, thus stopping a number of devices from working.

To make it worse, one of the lines they replaced has a video signal on the original Spectrums, so it would cause interference if this line was controlled all the time. A DIP switch on most divMMC devices is used to select the single or dual ROM lines so that the Spectrums ROM (or ROMs) can be disabled.

Clock Signal

The main issue we found was due to the clock signal on the edge connector. This varies widely from completely absent, through various degrees of being very poor, through to actually quite good in the later models. The circuit used on the V1.0 divMMC Future was similar to that used on other boards, and used a 74LVC1G14 single gate Schmitt trigger inverter to drive the clock. The circuit as built had VCC connected to 3.3V. The input signal from the Spectrum is (theoretically) a 5V TTL signal, but the LVC gate input is 5V tolerant. The input of the CPLD used on the divMMC is 3.3V. That should be fine then.

But it wasn't. Researching had brought up advice for one of the other boards for a modification to improve performance on some Spectrums. I had to check this several times, and even tracked it through on a board which included this change to make sure the schematic was correct. It just looked wrong to me. The modification appeared to address this by connecting via resistors to both the 3.3V and 5V rails in what appears to be a potential divider, to give a supply rail somewhere around 4.2V, depending on load. It did actually work better, but I wasn't happy with it.

The other change here is a 4K7 resistor which can be switched in to add an additional pullup to the clock line. This was the 'Toastrack' switch, and helped the particularly weak signal on the UK Spectrum 128K model to come into range. This had to be switchable, as it added too much load on some Spectrums and stopped the clock signal getting to the Z80.

Clock Signal Traces

Depending on the model of Spectrum the clock signal varied significantly, so it required quite a lot of work to be able to get a decent clock out of the full range of machines.

Spanish 128K

Let's start with this one. It doesn't have a clock. They forgot to connect the pin. Or maybe decided the signal was so poor, there was no point in connecting it.

Issues 1 and Early Issue 2 Spectrums

Here the clock signal is taken directly from the ULA output. The same signal is fed to the Z80. The original issue 2 Spectrum had a transistor driving the Z80 clock, fed by a 3K3 base resistor bypassed by a diode. A 'Mandatory Modification' to later issue 2 Spectrums changed the transistor input to have a 100pF capacitor bypassing a 1K base resistor, and added a 1K pullup resistor on the output of the ULA.

This improved the signal a bit, but was still a bit low (about 2.8V peak) and not very square. Read more in a blog post from January 2017 on testing the divMMC Future with early Issue 2 Spectrums.

Most 48K Spectrums (Issue 3-6)

Later Spectrums followed the modifications to the issue 2 boards, with an additional bypass capacitor, and the later ULAs produce a stronger signal, so the clock output is better than before, about 3.2V peak, but still a bit rounded with a very long rise time.

Spectrum 128K (Toastrack)

This is one of the worst signals, really low, about 1.5V peak. This needed an external pullup to get anything usable out of it, but did have a bit faster rise to 1V at least.

Spectrum +2 (Grey and Black)

Both versions of the +2 have a buffer amplifier feeding the clock signal to the edge connector which gives a good solid 5V peak square wave on the output (note the scale is double that of the previous images). This is what all the others should look like but don't.

Solution #1 - Simple transistor buffer

My first approach to this was to replace the inverter with a similar circuit to the later 48K Spectrums, a simple transistor inverter. The initial testing was done with some standard through hole parts. Which look surprisingly large and out of place on this board.

A later version of the same thing with surface mount parts was a little more suited to the size of the board.

This worked rather well. The pullup was to 3.3V, as required by the CPLD, so the output was a nice clean 3.3V peak square wave with no ringing or overshoot. A little rounded, but that should do nicely. Job done. Time to go home.

Well, no. I used the word 'should'. Every sentence we spoke on the long phone calls into the early hours working on this stuff seemed to include the word 'should'. It should work, and like that it was working on quite a lot of systems. We built a few of these, the 'divMMC Pleasure' as it was then, and sent them out to our early testers and assembled the results.

Solutions #2 onwards

Thank you to @sanxion and @ChinnyVision and our other early testers. The results were good, but not perfect. I will spare you the details of the weeks if not months of work we put in trying to modify that waveform to get it just right. We found that the timing and relationship to the input waveform appeared to be critical, as was the risetime and even the pulse length.

We had tested the construction skills of Rod Hull at TFW8b time and time again building slightly different versions. We had transistor buffers driving inverters, driving monostable timers and all sorts, trying to get that waveform just right.  Seriously, some of this stuff was just mad. This one was a bit of a masterpiece; it had both the simple transistor buffer, which worked best on the toastrack, and also the version based on two monostables, which suited most of the other models. It detected when there were valid pulses coming out of the monstable circuit, and switched to the transistor version if there were none.

It seems that every change we made altered the range of machines it worked on. Sometimes extending the range, sometimes reducing it. Sometimes not working at all. These were all valid square waves, and so should have worked. At this stage, we had to test each of these versions on a set of machines that most versions worked with (an issue 3B, and a grey +2), and some edge case boards (an issue 4B that was very picky, and a toastrack board of course with it's awful clock). And also, we had found some variance in SD cards, so had to test with a couple of those. Sometimes it wouldn't boot, sometimes you would get the (C) screen without the firmware loading. Sometimes it would appear to boot then crash on the menu. Other times it would load small games, but fail with large ones.

Here we were comparing traces from other divMMC boards and various ones we built, superimposing the waveforms to try to see where we were going wrong. The yellow is the input clock, the others the clock fed to the CPLD. There are dozens and dozens of these screenshots with various different options, each of which should have worked, but didn't quite. I'm doing a disservice to the amount of time and money we spent doing this, but it had to be right, and we both wanted to get an answer to the problem. It did get close to getting binned several times.

The Breakthrough

One late night phone call, bonfire night 2016, not out enjoying fireworks, but at home trying to work this stuff out, I asked an important question. This clock signal, is it only used to generate the clock for the SPI bus on the SD card? Does it really need to be synchronous to the Spectrum clock? Could you just feed any 3.5MHz clock in there? It was one of those, we should give it a go, it might work.

And you know what, it did. Or rather, it had a good go. Initially we had used a signal generator and tried to adjust the mark space to match the signals we had seen from the other boards. (but remember, they didn't work on all Spectrums either). A lot of testing with various settings on the signal generator, and we found that the mark space now didn't appear to make a difference, and it worked best between 3.9MHz and 4.2MHz. We settled on 4MHz 50% duty cycle as a nice stable option.

That worked well and because we were now ignoring the clock, it worked across all models. It also meant it could be quite easily implemented with a 4 MHz crystal oscillator module. The board is looking a lot less cluttered now.

It's scary typing this now, because at the time this was top-secret classification, after all this effort, the divMMC Future had to be the first to market with a 4MHz crystal oscillator. (we noticed others have since followed suit with a 4MHz oscillator appearing on at least one other model)

Spectrum Detector

Whilst the clock issues were being resolved, we also made progress on some of the other issues. As part of the 'detect if the clock is working', I had build several 'Spectrum Detectors'. These were circuits which could detect which model of Spectrum the board was plugged into, and set the DIP switches auto-magically. That one was based on the voltage level of the clock, if less than 2V, it is a toastrack, under 4V, a 48K, and over 4V was a +2. The actual levels needed a bit more fine tuning to get the switch between 48K and +2 Spectrums just right.

That worked, but I then came up with a simpler option, since the toastrack switch was no longer necessary, using the separate crystal (shh, don't tell anyone). Now it only needed to detect if it needed 1 ROM control line (48K Spectrum, Toast Rack or +2 grey - remember way back near the top of this post?), or 2 ROM control lines (the black +2/+3). That turned out to be a lot easier than expected. The black +2/+3 do not have 9V DC on the edge connector, but it is there on all other models, so all we need to do it check for the presence of that. This was done with a simple potential divider, and a bit of logic to control the switching.

That has taken care of all but one DIP switch. The one which sets the divMMC into firmware programming mode. TFW8b suggested using the card detect switch on the SD socket. When the SD card is present, the device works normally. When the SD card is removed, it can have it's firmware updated using the loader program (loaded from cassette). That meant the divMMC Future could now be jumperless. Nothing to configure, just plug and go. (we note the jumperless idea has also been adopted by another divMMC, happy to have helped)

Testing

This version again went out to testers in late November 2016, and we all went through as many machines as we could lay our hands on, testing these to make sure they were as good as they could possibly be. Yes, that's an issue 1 Spectrum, yes, that's a divMMC Future prototype, yes, it's working.

We had a query about early issue 2 board without the diode/resistor mod, and yes, it works on those as well, the issue actually coming down to the earlier boards (that didn't work with other divMMC boards) not having the 'Mandatory' clock modifications.

Does it work with the Harlequin Spectrum clone? It should, but I didn't know, so I built a Harlequin, and yes, it did work with with divMMC Future.

Also, since we no longer needed a clock signal, the Spanish 128K works fine with the divMMC Future. I have used it to test my repaired Spanish toastrack, but wanted to be sure a stock machine would also work.

Thanks for Will Woodvine for the loan of a nice Spanish toastrack to prove this with.

By this point, all was looking good. We had a few machines that didn't work with any divMMC boards, even the divMMC Future. We couldn't have that. Further investigation revealed these machines had Z80 chips with missing M1 signals, a new Z80 later and all was well.

I also wanted to give this a wide ranging test, so bought a selection of 'untested', 'working when put away' etc. loft find ZX Spectrums from ebay. In the main, these worked straight out of the black binliners they arrived wrapped in (many would say they should have remained in them). The few that didn't work straight away had grubby edge connectors, since these had been exposed to the elements for 35 years. After a clean, these also worked well, so was born the divMMC Future edge connector repair tool. (yes, it's a rubber, but it works quite well).

Continuing to go through as many machines as we could to prove this thing, I started resurrecting some scrap boards, including a pretty ropey issue 2 Spectrum, and a pile of grey Spectrum +2 boards, and anything that got as far as actually working, worked with the divMMC Future.

Quite late in the day, we also had a couple of machines which had issues that seemed to be down to NEC ROM chips. One turned out to have the wrong jumper settings (H=Hitachi, N=NEC, they have swapped OE and CS pins). The problematic ones did seem to have quite a large input current on the CS pin, which was stopping the ROM being disabled.

This could be proven by swapping the ROM for any other ROM chip, including later or earlier NEC ROM chips (I think the 1983 dated ones were the worst). A resolution for this was adding an extra transistor to the circuit to boost the pullup capability on the CS line, and that fixed that problem. This was the final change and the divMMC Future was ready for production.

Production

Throughout testing, we had some nice 3D printed cases (thank you Simpson Industries), which were great for protecting the boards during development and testing, but I don't think they could keep up with demand for production.

By this point, the injection moulds had been created, and the final cases had arrived. And don't they look smart.

In order to speed up production, I had built a four gang programmer. This used four revived basket case +2 grey boards and allowed four devices to be programmed and tested in parallel.

Later a joystick tester module was added to automatically test all the inputs using a tester program loaded from the SD card.

With that, TFW8b went into production, and is still turning these out by the boxload.

To date, around a thousand units have been sold, and we have only heard of a couple of problems, and one of those was a +3 power supply failing (which also took out the Spectrum). So I think we did a good job. I think this is the best divMMC we could make. I hope you like them.

The divMMC Future is available from The Future Was 8bit.

*Other divMMCs are available, but I wouldn't recommend them.