Alongside purchasing complete systems, over the past few years I’ve also accumulated a large quantity of incomplete circuit boards for “spares and repairs”, primarily from Commodore computers (VIC-20, VIC-20CR, C64, C64C, C16, Plus/4, C128, etc).
I got these for cheap in various job lots, with the intention of fixing up as many as possible and selling the working ones on for those who needed a fully-tested board (for swapping into a system, for use as a test board, etc). This meant I could focus on my favourite part of my work – the electronics restoration – without having to worry about case and keyboard cleaning, which is fun but can get quite tedious; also, a reliable supply of original spare parts from irreparable boards.
I recently finished my restoration of the salvageable boards, which has taken a VERY long time (bit by bit for the past year or so) because of both the quantity of the boards and the amount of work involved in testing, repairing, and cleaning each one.
This article focuses on a handful of C128 boards I worked on.
Commodore C128 Board #1
The first board appeared to boot OK in C128 mode, but only when the reset button is pressed on startup – the power-on reset pulse was not present, and an attached disk drive does not reset either.
To make matters worse, booting in C64 mode shows an incorrect reading on available RAM – testing further with the diagnostic cartridge and harness installed, all system RAM tests fail, along with the serial port.
A lot of evidence of rework on the common causes of the reset fault was present (i.e. the reset switch had been removed and reinstalled, flux residue under suspect components, wire links and damaged vias), indicating that someone had been attempting to diagnose this issue in the past.
I checked all the passives in the reset circuit, which seemed OK; I replaced C91 (1uF 16V) and C92 (10uF 16V) which trigger the reset pulse, to no effect; I repaired damage under the reset switch and C107, to no effect; I socketed and tested both CPUs, but both tested OK; I replaced the low-quality socket on the MMU to no effect.
I then socketed and tested a variety of small glue-logic ICs in an attempt to track down both problems, starting with those most likely to be causing the reset or RAM problems, including: U27 (556 timer), U27 (7406), U29 (7406), U30 (7406), U16 (74LS14), U57 (74LS17), U68 (74LS17). However, all of these ICs tested OK using my MiniPro TL866II.
I decided to sell the board on as-is, as I was getting quite frustrated at this point. Hopefully the new owner will have more luck with it than I did!
Commodore C128 Board #2
The second C128 board worked perfectly first time. Boooo!
Commodore C128 Board #3
The third board appeared to boot OK in C128 mode, however upon testing with a diagnostic cartridge and harness, all the system RAM tests and the serial port test fail.
All the socketed ICs (every major IC except for the PLA and CPUs) are my known-good test ICs, and all seem to be making proper contact in the sockets. Given that all the RAM ICs are identified as bad, I expected an addressing issue as opposed to the RAM ICs themselves, so I decided to socket and test the PLA, which was OK; I then socketed and tested the 8502 CPU, which was indeed bad.
With a known-good CPU, all the diagnostic tests now passed – however, I noticed that when the board warmed up for a few minutes, all the characters on-screen would gradually start to flicker and turn to garbage.
At first, I suspected a failed video chip, however both of my test chips are new-old-stock and worked fine in the other boards; I then suspected a potential power issue, however both video chips in the C128 are powered from 5Vdc (unlike the VIC-II in the long-board C64, which also requires 12Vdc), and the 5V supply was fine.
It appeared that each of the characters was being shifted, but by comparing the PETSCII codes between the displayed characters and the expected characters (i.e. space and “*”), it seemed that bits 1 and 3 were stuck high – this explains why some characters (such as “O” and “K”) were unaffected.
Suspect ICs included U17 (74LS373), U26 (74LS257), and U55 (74LS245), all of which interface with the video subsystem. I removed U17 and tested it using my MiniPro TL866II, and it failed intermittently – I installed a socket and fitted a new part, and the problem was resolved.
Commodore C128 Board #4
The fourth board was missing its power socket – the fact that someone had started breaking the board for parts was indicative of further problems.
Sure enough, after sourcing and installing a power socket and fitting my known-good test ICs, the board would output video but would only display a black screen – there was no change in symptoms with either a diagnostic cartridge or a dead-test cartridge.
This board was fitted with very poor-quality sockets at the factory – to make matters worse, the board seemed to have been stored in adverse conditions, and had noticeable corrosion to most of the sockets. I therefore decided to replace as many as possible, to ensure that the socketed ICs were making proper contact with the board.
The sockets I replaced were as follows: U4 (CIA), U32/U33/U34 (ROMs), U25 (ROM), U36 (ROM), U18 (ROM), U7 (MMU), and U5 (SID).
With the new sockets installed, the board would still only output a black screen – however, the dead-test cartridge now worked, giving a flash code 8 and indicating a stuck data bit 0, which in the C128 is usually associated with a faulty RAM IC at U38 or U46.
I socketed and removed U38 and U46 for testing, and one had failed – after replacing this with a new-old-stock 4164 DRAM IC, the board now booted normally in C128 mode.
On further testing using a diagnostic cartridge, the high RAM bank 1 test still failed, indicating U50 as faulty. After socketing and replacing this 4164 DRAM IC, all the RAM tests passed OK.
I then moved onto testing the board further with a diagnostic loopback harness installed – all tests passed except for the control port test, indicating the SID as faulty, and the sound test was all messed up.
Initially, I thought that my test SID might have failed, as the 6581 is hardly known for its reliability. However, the same symptoms were exhibited even with another known-good SID, so the problem is with the board.
First, I tested the 5Vdc and 12Vdc supplies to the SID, which were both OK; I also double-checked that the new socket was installed correctly, which it was. I then used a logic probe to check all the signals on the SID whilst the diagnostic tests were running – all signals were present except for A0 (pin 9), which appeared to be floating. Sure enough, when I checked A0 continuity between the SID and MMU it was open-circuit.
I removed the SID and MMU sockets to check for corrosion on the board – I found a small patch of dark trace below RP10, which I removed for better access. I then stripped and tinned the trace, and installed a small wire jumper over a small break in the copper, and reinstalled the sockets for testing. After this work, everything worked OK.
I have a C128 where data bus bit 0 (D0) is stuck (low resistance to ground). D5 was also stuck but interestingly, that was caused by the BASIC high ROM – removing it proved that. I still need to find the D0 ‘short’ (actually 442 ohm resistance to ground).
All the RAM has been replaced, which is when problems seemed to start (black screen/garbled screen/random sound), and I replaced the PLA thinking that was likely faulty, as it was running very hot. Anyway, the data bus doesn’t pass through the PLA, so it is something else.
I’ve removed all socketed chips, so I know it isn’t the MMU, VIC, VDC, other ROMs… which leaves me with the 8502 and a few other small chips like the LS373 connected to the data bus. Also the LS244.
Have you seen a fault in the LS373 or LS244 create a 442-ohm connection between D0 and ground – I wonder if that’s possible?
Removing the 8502 is a last resort, I’ll get to that after trying to replace these 74LS chips. Unless you’ve seen the 8502 do this?
Cheers for any leads
-Alex
Very nice reports, by the way. I especially liked the corroded address trace repair at the SID chip!
The C128 I’m working on had a bizarre fault that was caused by the bit-0 RAM chip (just like you replaced). Instead of a black screen, I was getting incorrect characters displayed by a PRINT or a LOAD (the latter attempting to load a wrong-named file). The character codes were ‘shifted’ by 1 but only for codes having a 1, ie. odd codes.
I found it interesting that the machine still started up and functioned with a faulty RAM bit 0; obviously the C128 doesn’t test its RAM on startup (a fact I later learned elsewhere).
Replacing the bit-0 chip got everything working correctly. I then decided to replace the other RAM to match – big mistake. The machine has never worked again, because of D0 and D5 being stuck as described in my other comment. I tested the replacement RAM using an Arduino – all good – and I removed the sockets I’d fitted to test the board thoroughly in the RAM area – no faults found there. The cause of D5 being stuck turns out to be the BASIC ROM; a coincidence, and I expect there is another coincidence somewhere else that’s causing D0 to be stuck – except, this latter fault might have been what damaged the RAM in the first place 🙂