Sunday, 8 October 2017

Commodore PET 3016 repair

A slightly different repair today. This is a Commodore PET 3016 board, the same board as used in the 2001N and 30xx and 40xx series (but not the 12" monitor 40xx series). It's not working, but it looks like it has had a lot of work done to it already. I normally try to avoid working on boards like this.
All the ROMs have been socketed, the original white single wipe contact sockets tend to be a bit rubbish, so they have been replaced with good quality turned pin sockets, I approve.
The capacitors have also been replaced. I'm never sure of the point of this, all of the caps I have removed from PET boards to check have tested fine, often still showing higher than the rated values of capacitance, and acceptable levels of internal resistance, so I don't really see the need to change them.
Looking around the board, it is clear that quite a lot of chips have already been replaced. No clear pattern, some with 80s date codes, some modern looking TI chips (which annoyingly don't have a date code). The latest actual date code was 1999 on one of the 74LS244 RAM data buffers.
Plugging in the PET diagnostics, a couple of problems show up, firstly there were some intermittent video RAM faults (only a couple showing up on this picture, as it is difficult to read otherwise).
The RAM appears to have passed (the last four blocks are the second bank of 16K which is not fitted in the 3016). Two of the ROM chips are OK, two faulty.
Looking at the video RAM, it appears the two chips have been replaced. One is at a definite angle, it appears to be making connection, but is certainly not straight. I socketed these to retest the chips to make sure it wasn't just an intermittent connection.
The problems persisted, but were also present with known working 2114 chips. So since the video RAM tests were failing, and always bits 0-3 only, and the display was corrupted, the problem must be the buffer feeding the video RAM (if the tests passed but the screen was still corrupted, I would be looking at the latch on the video output side instead). Swapping out that 74LS244 (UE8) and the problem was fixed.
I tested the two faulty ROMs in a programmer and one didn't respond and the other had corrupted data. Replacing those with EPROMs in adapters, all the tests passed. I had now set the diagnostics to 16K RAM test mode.
Swapping back to the original CPU, I still got a black screen. I tried a known working one, and got the same. Switching back to the diagnostics, all passed. Hmm, something odd is going on here.
I installed a ROM/RAM board, with the original 6502 CPU*, and got a READY prompt no problem. Switching off the ROM, and rebooting also brought up the READY prompt, so the ROM was working. Switching off the RAM and I got a black screen. (* actually just looking at the photos, it's not the original CPU or 6522, both have been replaced at some point, as has the RS branded 7425 below, I'll add those to the list)
Switching the ROM/RAM board to the PET Tester ROM, rather than the screen full of 'G' (for Good), it was more than half full of 'B' (for Bad). Going back and repeating the testing with the diagnostics board seems to indicate there was a timing difference between when the 6502 itself was accessing the RAM, and when the diagnostics board was.
I started looking through what could be causing that, starting with the data buffers, or maybe the address select logic, or the multiplexing. Maybe an issue with the R/W line. Following those up on the board, I found all the chips I was checking had already been replaced, the 74LS04 by the CPU, the 7417 by the IEEE-488 port, the 74LS10 in the middle of the board, the 74154, one of the RAM data buffers, one of the RAM multiplexors. Oh, and all 8 RAM chips.
This was ringing alarm bells. Someone has already spent a lot of time looking at this fault, and has replaced a lot of chips. What I don't know is whether they fixed the problem, or if they gave up. Also, crucially, I don't know if they damaged any tracks or through hole plating whilst replacing all these chips, potentially introducing the fault whilst repairing another. Or if any of the chips used were out of spec, or already faulty. This is why I don't like working on boards which have already had work done on them.
I went back to the ROM/RAM board and gave the rest of the board a thorough test. It was all running fine, the board bypassing the RAM fault. I looked further into the problem and replaced a few more chips, the 244 buffers and the 153 multiplexors without any improvement. The next step would have been to socket and replace the RAM chips, which probably wouldn't have helped, or go back and remove more of the previously replaced chips, test those and also check the state of the board underneath for faults. Which would make this a much longer and more expensive repair. At this point, I was aware the owner had said they didn't want to spend too much if it wasn't repairable and decided to give up on tracing that RAM fault.
I suggested the owner use the ROM/RAM board, which also gave them the option of upgrading to the full 32K from the original 16K and selecting the original BASIC 2 or upgrading to BASIC 4. Not ideal, I would have like to have repaired the board fully, but when there are that many unknowns, it would have meant a lot more work, and potentially a full set of RAM chips, which along with the two EPROM adapters would have worked out several times more expensive than going for the ROM/RAM board.
With the ROM/RAM board in place, that is all working nicely, I also fitted a user port piezo buzzer, which gives sound to games which support it such as Space Invaders and things like Down from Revival Studios.

If you want to support this blog, you can donate via Patreon or Paypal, or buy something from my store.