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.
