Commodore PET 8032 Repair - Screen repeating in blocks

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

Here we have another Commodore 8032 in for repair, this one looks in reasonable condition this time.

Although I was a little worried when I opened the box, bare boards in polystyrene is probably not a good idea for a static point of view. However it did at least provide good mechanical protection during shipping.

This one is slightly unusual in that the regulators and transistors are all bolted down, apparently from the factory. See my previous post about riveting on replacement regulators.

This is the first time I've seen one that appears to have been bolted on from new, including what I'm sure are the original untouched TIP29 datasette power transistors. I see no reason why anyone would drill the rivets out and replace them with bolts if they weren't faulty. Later PET boards (and all the VIC20 and C64 machines) had the regulators 'flapping about in the breeze', presumably to add a little air cooling rather than heating up the PCB.

The rest of the board looks fine. Like the previous post, this one is from Germany, so has an alternate editor ROM and character ROM to support some inflected letters.

The fault report (helpfully taped to the board) on this one is it beeps (a good start, the CPU, address decoding, KERNAL and editor ROMs and at least some of the RAM and IO chips are working), but it is displaying 'some random characters'.

Oh yes, so it is. Time for PET Diagnostics and see what's going on.

The results are interesting, time for some analysis.

So again, many things are working to get this far. When you see a garbled display like that, it's normal the multiplexor chips that have failed. The 74LS157 switch very quickly between the processor address bus and the video address bus (generated by the 6545 CRTC). This is the later 'universal dynamic PET' board, which can be 40 or 80 column by changing that row of jumpers (old blog post on converting an 8032 to a 4032).

What normally happens is they some of the bits get stuck, and you work out which ones by counting the size of the blocks of repetition or blanks. Here you can see we get 16 characters then a repeat, then 16 OK, the repeat etc. That would point to bit 4. being stuck, and I think there is another error higher up. The video RAM is testing OK though (I think I can read that amongst the rest), and there are various RAM faults as well.

I replaced all three mux chips. When one goes, there's a fair chance more will go. They also have a tendency to fail as they work quite hard.

Unfortunately, that didn't fix it. It cleared up part of the problem, but not all of it. I checked over the work, no shorts, everything testing fine, and the chips were new from the tube. I couldn't see anything wrong there, so I looked further up the food chain. The 157s switches the addresses generated by the 6545 CRTC. The 40 pin chips on this board are socketed, so it was a simple matter of replacing the the 6545 to see if it was that.

Well what do you know, faulty 6545, and probably at least one faulty 157. I need to build a proper tester for these. They usually pass on the chip tester built into EPROM programmers as they test at quite low speeds, and these things tend to do OK at low speed, but in their old age can't do things as fast as they used to be able to do (happens to us all).

I don't like running boards too long in this sort of state, if there are faulty chips writing to the databus when they shouldn't, that can burn out other parts on the same bus, the strongest driver transistors win. I noticed the number of RAM faults wasn't constant, but was worse than the previous photo. I did have time to finish probing around the board, and I found the culprit.

This is the 7905 regulator which generates a -5V reference voltage for the 4116 RAM chips. They always seem to be at jaunty angles and are not bolted or riveted down as the tab is connected to the input voltage, rather than to 0V on the 78xx versions. If you do bolt one down and connect the tab to the voltage rail bad things will happen. It looks like the right hand leg has some extra solder on, as if it had been repaired in the past.

The central leg was sort of touching the pad, but wasn't actually connected. When I had first powered on the board, one of the first things I do is check the supply rails, and -5V was present then, but it's not now. Rather than replace this with a similar part, similarly lacking support, it could snap off again, or vibrate around in shipping. I prefer to replace them with an alternative version of the 7905.

This has a plastic cover all around the tab, so it can be mounted flat on the board without shorting out. There is no problem here with heat, as the -5V is only a reference, and it looks like the board has pads for a small TO18 packaged version. I don't think they make those any more.

Everything is now passing. The editor ROM is consistent CRC, but not a version I recognise. The normal DIN versions are 4K ROMs, but this is on a 2716 EPROM, so it's only 2K. It appears to have a different keyboard mapping to the previous German DIN editor ROM. I'll add it to the list of known CRCs.

It took a while to guess which keys to press again, but I got it to load from tape and seemed to be running well. I couldn't get it to load from IEEE-488, but a closer inspection around the IEEE-488 connector explained that.

These were not fitted from the factory on later models, It looks like someone has fitted a connector to the normally empty pads, but has unfortunately damaged some of the through hole plating in the process.

I did what I could to patch up the broken continuity and got the edge connector active again, and looking extra shinny with a touch of contact cleaner and fibreglass pen.

Commodore PET 8032 Repair - ROMs, Regulators and Rivets

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

A Commodore PET 8032 board in for repair today. This is an early 8032, the dedicated 80 column board, not the usual universal 40/80 one. This one looks interesting, my favourite, a board that has previously been worked on. It's always fun having to retest all the previous work.

Firstly, the 6502 is missing, the owner had removed it before shipping (?). Several of the ROM chips have been replaced with EPROMs, including one shrouded in mystery covered in tape, and another that looks to have had some pins broken and soldered into some stand off pins.

Above are two original mask ROM chips, but it looks like they are the wrong way around. The original sequence was three BASIC ROMs, 901465-19, 901465-20 and  901465-21. Then the editor (various versions depending on screen, keyboard and language). Finally, the KERNAL, 901465-22.  A bug was discovered in the 901465-19 ROM, so all but the very earliest 8032s come with that chip replaced with 901465-23. So the correct order of chips should be 901465-23, -20, -21, editor, -22, so those two are the wrong way around.

The other noticeable issue is that the two 7805 (or LM340) 5V regulators have been replaced, and instead of the original round metal TO3 packages, they are rectangular TO220 versions.

I'm not too happy with that aesthetically, but also the 0V lines appear to be connected to the frame ground connection on the IEEE-488 port. That is different from the 0V rail, and the 56R resistor connects the two together and that is the path to ground.

When bolted into the case, that will eventually get back to 0V via the metal case connection back to the centre tap on the transformer, but that's not the best place to reference it. For the moment, I shorted out that resistor to tie the 7805 ground pins to the PETs OV rail. There is also a track, which is the 5V output, that appears to have been cut on the back of the board, but is still making contact.

I powered on and all the voltage rails were present and correct, nothing was particularly hot, so I'll leave those for the moment and get on with the rest of the testing. On power on, the board chirped as normal and the screen was initialised and blanked, but nothing happened. That usually indicates a fault with the BASIC ROMs or a partial RAM failure - enough RAM for the KERNAL to get so far, but not enough for BASIC to print up the READY message.

Time to get out the PET Diagnostics board and fit that in place of the 6502. That should generate a display and test the system ROM and RAM, even when there are ROM and RAM faults. (these are now available on my Tindie store)

That also got a beep and the display fired up and was filled with text, but it was clear there were some video problems. It looks like the main RAM is OK, but there is a video fault, and some ROM issues. To get a clearer result, I switched to the PET LCD board with PET diagnostics plugged into that.

That showed the ROM chip in socket D10 (marked 901465-20) was faulty, giving an unknown CRC. and the chip in D9 (marked 901465-23) was the working, but in the wrong socket (it is the B000-BFFF ROM so should be in D10). I swapped those around and went back to a 6502 to see if it would boot, just in case it was somehow a different variant of the 901465-20 ROM. That got no further, still a blank screen.

The ROM sockets on the PET do not conform to the standard 2732 EPROM pinout, but it can take 2532 EPROMs, and I have a few of those. Most modern programmers don't support the 2532, but I keep my Stag P301 programmer around for things like that (as a follow up to that blog post, the Fujitsu NiMH batteries are still going strong).

I printed a label for the new EPROM, and decided to also label up the other EPROMs, since the editor ROM was uncovered and should have something over it's window to prevent it being erased. The one hidden under the tape was also a TMS2532 replacement. The editor is the German DIN version of the editor ROM.

Checking those with PET Diagnostics, there was now a full set of BASIC 4 ROMs. I wanted to get those fixed, in case that was contributing to the display issue, but that is still present.

The tests show errors in bits 4 and 5 of the even video RAM. Time for a process of elimination. The 80 column PETs have the video RAM split into odd and even bytes, as apparently they were not fast enough to keep up if they were used sequentially. This means the video circuitry is split into odd and even halves. The odd video RAM seems to test OK, and every alternate character does appear correct, so that rules out the common elements such as the character ROM and the output shift register.

It is only affecting bits 4 and 5, so that rules out one of the RAM chips (UC4), and one of the 244 buffers (UB4), as they only connect to bits 0,1,2 and 3. That still leaves the other 244 buffer (UB5) that allows bits 4,5,6 and 7 of the even video RAM to be written (and also read) by the CPU. It also leaves the RAM itself (UC5) and the 373 latch (UB3) that stores the output of the selected byte of RAM to feed the character  ROM address lines. To narrow that down, it's time to get the 'scope out and probe the pins.

Probing the even data lines, bits 0,1,2,3 and 6 and 7 were changing, but bits 4 and 5 were doing nothing. That points at the input buffer, as nothing is getting into the circuit. With a replacement 74LS244 at UB5, time to test the theory.

Success, also note the previous 'inconsistent CRC' messages are now missing and the empty sockets are correctly detected as empty. When testing the CRC, all bits should read high, but when something on the bus is misbehaving and writing to the databus when it shouldn't, some different values are read. In this case it seems the LS244 was causing some output on the databus when it wasn't meant to be. The border around the screen is meant to be a solid line, but the DIN PETs have a different character set, so don't have the line drawing characters.

The only thing left to do now was sort out those regulators and the damaged track. I have some of the right kind, but originally they were riveted to the heatsink. I could bolt them in, but let's do this properly. It's been a while since I riveted anything, but I still have a rivet gun somewhere.

These 7805s were particularly thick, so I had to get some longer rivets, to fit through the PCB, the heatsink and the regulator flange.

Not bad, I think I did OK there, seems to be making good mechanical and electrical contact, don't think they are going anywhere.

That's better, how it was meant to look, the original 7812 and the two new 7805s.

On the back, I scraped away a bit of the solder mask and flowed some solder onto the track where the scratch was. The rivets look nice and clean, I'm quite pleased with the way they turned out.

That's all back together, ready for testing. It chirped, and up came the ready prompt. It was a little tricky running test programs as the DIN keyboard layout is slightly different to the normal UK/US business keyboard, so it was a little trial and error on some of the punctuation symbols.

All looking good, loading programs from tape and IEEE-488 port, and running a BASIC memory test program. A bit more soak testing then it's on it's way back to it's owner.

Atari 5200 not powering on repair and AV mod

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

Here we have an Atari 5200 that has arrived for repair, slightly worse for wear and a little damp due to courier / packaging issues.

This one is reported as 'not powering on', and indeed that is the case. The 5200 has a rather convoluted power system. Power is fed in via the RF cable. I think that says it all really.

Power is injected into the RF cable by the external switchbox above. Inside that, the supplied current is monitored as it passes through a current sense resistor (actually two 0.33R resistors in parallel). This is amplified by the LM393 OP Amp and when it goes above a certain threshold, the relay clicks over and the RF output of the 5200 is connected to the TV in place of the antenna.

Inside the 5200 it continues, power is extracted from the RF, and is switched off via a soft on off switch, i.e. not a nice simple big clunky clicky switch (like the XEGS for example). Was all of this stuff really necessary? I mean, OK, it's a nice idea, and some engineers would have been really pleased with it technically, but how many review meetings did this go through? how many cost reduction exercises did this survive? I think we can safely say this was before the Jack Tramiel days.

Here, a rather unusual and probably expensive SPDT push switch is used to toggle a flip-flop IC which will turn on a series of transistors which will eventually provide power to the 5V regulator (sorry regulators, after all, why have one when you can have two).

And this is where it seems to have failed. The 4013 is a dual flip flop. The first half is used to debounce switch switch and feed a clean pulse to the second half each time the switch is pressed.

The second half then turns the output on or off as appropriate. It is a CMOS chip, so is happy to run off the unregulated 9V DC input. That 9V is getting through fine. Probing around, I can see a pulse out of pin 1 and into pin 11 each time the button is pressed. I can see the /Q output on pins 9 and 12 toggling, but the Q output on pin 13 is doing nothing.

Yes, that would appear to be the issue. The 4013 failed testing in my MiniPro programmer. I didn't have a new one in stock, so I temporarily bypassed it by fitting a wire link from pin 13 to pin 14, effectively making it always on.

That allowed the 5200 to power up and everything else appears to be working fine.

With a new 4013 fitted, the on / off power switch was back in working order. It will soon be losing the external switch box as I have been asked to convert it to 9V DC input, as per my previous post on Atari 5200 AV out / DC in modification, but the soft on / off circuit will still be used.

The last 5200 I converted was mine, so I didn't plan to refit the metalwork shielding cans, but in this case it is a customers, so I will. There is a suitable gap in the metalwork on the inside corner, so I fitted some heatshrink sleeving around the wire bundle for a little extra protection.

I used the same TFW8b composite mod kit. The parts on the 5200 to be removed and the wiring is the same, although I have picked up the ground at a different point to make the cable lie flat.

The rest of the modification is the same as before, with the DC jack in one of the cutouts on the back of the case.

And the AV output board on the other.

That gets covered by the trim that clips over it. That was originally where the RF lead was meant to be wrapped around.

Another bit of trim I didn't mention previously (because it was broken on mine) is the massive storage compartment at the top of the unit. (which reminded me of an old sketch about useless gadgets that came supplied with the plugs already removed, ready to shove in the cupboard under the sink. It was from a TV show I had last seen 30 odd years ago but I managed to find the sketch on youtube).

The 5200 comes with it's own storage compartment, where you can store the original controllers (when they break), although not the power supply or AV switch box.

Thanks to notches at the side, it can also be used to store the AV cable.

With all that reassembled, it is powering on and off and everything appears to be working.