Commodore 64 (ASSY 250425) Board Repairs

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 set of C64 boards I worked on, specifically a large number of ASSY 250425 boards – an intermediate revision longboard which followed the ASSY 250407.

Commodore 64 250425 Board #1

The first board would output video but would not boot up correctly, displaying only a blank black screen with no border or text.

Example of a Commodore 64 black screen fault.

Instead of repairing this board myself, I decided to donate it to renowned Youtuber Jan Beta for use in one of his retro computer repair videos – he manages to repair it here.

Commodore 64 250425 Board #2

The second board needed a lot of work before it could even be powered on: it was missing all its RAM ICs (U9-U12 and U21-U24) and both multiplexer ICs (U13 and U25), which had been socketed by a previous owner, and it was completely missing its 556 timer IC (U8). All of the major ICs were socketed, including both CIAs (U1 and U2), all ROMs (U3-U5), the CPU (U7), SID (U18), PLA (U17), VIC-II (U19), and MOS 8701 clock generator IC (U31).

I fitted eight new-old-stock 4164 DRAM ICs, and two new-old-stock 74LS257 ICs (both available to buy from Retroleum); I also installed a socket on U8, and fitted a new-old-stock 556 timer IC (available to buy from Retroleum).

I always use high-quality double-sided sockets, which are more reliable than cheap single-sided sockets as they contact the IC legs on both sides – a lot of people push the use of turned-pin sockets, but I don’t like using them as they make swapping ICs difficult, they are difficult to desolder, and they are visibly obviously non-standard.

I then tested the board with a set of test chips installed, and it would output video but would not boot up correctly, displaying only a blank black screen with no border or text.

Board #2 initial testing.

In the C64, a black screen fault is a common failure mode which can indicate all kinds of problems: typically, a missing or improper signal, a data or address bus conflict, an addressing problem, or a stack page fault, all of which can be caused by a power issue or a failed IC. Most of the ICs on the board are connected to the data or address bus, so there are a large number of potential problems that need to be worked through.

The first thing to check with any repair is that power is being correctly received on the board, which may indicate a problem with the power socket, power switch, or fuse – I checked for 9Vac and 5Vdc at the user port, and both were OK; I also checked the 5Vdc and 12Vdc supply to the VIC-II, and both were OK.

A constant reset can also cause a black screen – I checked the reset signal at the user port and it worked as expected, staying low (around 0Vdc) for about a second at power on, then going high (around 5Vdc).

Commodore 64 user port pin diagram (image credit: MyOldComputer).

I checked for physical damage on the board which could be causing connection problems, including scratches or cold solder joints, but everything seemed OK.

I checked for signs of previous rework which could indicate a potential problem (flux residue, non-factory sockets, etc) – the board had obviously seen a lot of rework in the past for whatever reason, given that all 4164 RAM ICs (U9-U12 and U21-U24) and two logic ICs (U13 and U25) were socketed and wouldn’t have been from the factory. I checked over the installation of all the non-standard sockets (checking continuity on all connections against the schematic, using my multimeter), and everything was OK. I even replaced the sockets on the RAM multiplexers (U13 and U25) as they were a bit loose, but no change.

I reseated all of the socketed ICs and cleaned all sockets, ports, and switches with contact cleaner, however there was still no change in symptoms.

I tried the machine using a dead-test cartridge, which can indicate potential hardware issues (i.e. bad ROM, bad RAM) – however, there was no change in symptoms. I tried the same with a diagnostic cartridge, with the same result.

At this point I decided to aim my investigation at the soldered ICs themselves. Because there weren’t many left in place, I decided to take a brute-force approach: I removed them one by one using my desoldering station (a Duratool D00672), installed a socket, then tested them where possible using my MiniPro TL866II, refitting the original IC if it was OK.

I did this for: U8 (7406), which buffers several control lines, which was OK; U15 (74LS193), a video counter, which was OK; U27 (74LS08, in this case a MOS 8712 equivalent), used in video addressing, which was OK; U14 (74LS258), used in video addressing, which was OK; U26 (74LS373), used in video addressing, which was OK; U6 (2114), the colour RAM, which was OK; U16 (4066), used in colour generation, which was OK; U28 (4066), used for analogue inputs, which was OK.

At this point there were no ICs left to test – I double-checked that my tests chips were OK, and it turned out that my PLAnkton CPLD-based PLA replacement (available to buy from Retroleum) had failed. With a known-good replacement fitted, the board now started up to a blue border screen.

Board #2 border screen fault.

This highlights the importance of having known-good test equipment, and having the means to proactively verify it (i.e. through a known-good test board) – by removing as many unknown variables as possible, you significantly reduce the number of potential failure points, making diagnosis far easier. In this case, it took me longer than I’d have liked to think of testing the PLAnkton – with it being a modern part, I ignored the possibility of its failure, however it was probably damaged at some point by a loose socket (CPLDs are sensitive to I/O signals if not powered correctly).

With a dead-test cartridge installed, all tests passed, so this was a probable ROM fault.

Board #2 dead-test cartridge screen.

The character ROM socket (U5) looked worn and a little corroded, so I removed it and installed a replacement. After this, the board now seemed to boot correctly for the first time (with flashing cursor and correct amount of RAM showing).

Board #2 boots correctly for the first time.

It also passed all tests with a diagnostic cartridge and loopback harness installed.

Fully tested with diagnostic harness; composite video output OK; luma/chroma video output OK; audio output OK; cleaned ports, power switch, and edge connectors.

Commodore 64 250425 Board #3

The third board needed a bit of work before it could even be powered on: it was missing its fuse, and it was completely missing U14 (74LS258). All of the major ICs were socketed, including both CIAs (U1 and U2), all ROMs (U3-U5), the CPU (U7), SID (U18), PLA (U17), VIC-II (U19), and MOS 8701 clock generator IC (U31).

I fitted a fuse of the correct type; I also installed a socket on U14, and fitted a new-old-stock 74LS258 IC (available to buy from Retroleum).

I always use high-quality double-sided sockets, which are more reliable than cheap single-sided sockets as they contact the IC legs on both sides – a lot of people push the use of turned-pin sockets, but I don’t like using them as they make swapping ICs difficult, they are difficult to desolder, and they are visibly obviously non-standard.

I then tested the board with a set of test chips installed, and it would output video but would not boot up correctly, instead displaying a screen with seemingly random garbage.

In the C64, a garbage screen fault is a relatively common failure mode which can indicate all kinds of problems: typically, an issue with either the video generation circuitry, the video addressing circuitry, the system RAM, or the system addressing circuitry. Most of the ICs on the board are connected to the data or address bus, so there are a large number of potential problems that need to be worked through.

The first thing to check with any repair is that power is being correctly received on the board, which may indicate a problem with the power socket, power switch, or fuse – I checked for 9Vac and 5Vdc at the user port, and both were OK; I also checked the 5Vdc and 12Vdc supply to the VIC-II, and both were OK.

I checked for physical damage on the board which could be causing connection problems, including scratches or cold solder joints, but everything seemed OK.

I checked for signs of previous rework which could indicate a potential problem (flux residue, non-factory sockets, etc), but there was none.

I reseated all of the socketed ICs and cleaned all sockets, ports, and switches with contact cleaner, however there was still no change in symptoms.

I tried the machine using a dead-test cartridge, which can indicate potential hardware issues (i.e. bad ROM, bad RAM) – it seemed to boot up and the tests seemed to run in the background, but the screen had the same scrambled look to it.

At this point I decided to aim my investigation at the soldered ICs themselves. Because there weren’t many that could theoretically cause these kind of problems, I decided to take a brute-force approach: I removed them one by one using my desoldering station (a Duratool D00672), installed a socket, then tested them where possible using my MiniPro TL866II, refitting the original IC if it was OK.

Many of these were MOS-brand equivalents of 74-series ICs, which make them especially suspect as these are particularly unreliable due to their manufacturing process.

I did this for: U14 (74LS258), used in video addressing, which was OK; U27 (74LS08, in this case a MOS 7712), used in video addressing, which was OK; U26 (74LS373), used in video addressing, which was OK; U15 (74LS139, in this case a MOS 7711), used in video addressing, which was OK; both RAM multiplexer ICs, U13 and U25 (74LS257s, in this case MOS 7708s), used in system RAM addressing, both of which had failed.

I fitted two new-old-stock 74LS257 ICs (available to buy from Retroleum) and re-tested the board, and it now seemed to boot correctly for the first time (with flashing cursor and correct amount of RAM showing).

Board #3 boots correctly for the first time.

It also passed all tests with a diagnostic cartridge and loopback harness installed.

Fully tested with diagnostic harness; composite video output OK; luma/chroma video output OK; audio output OK; cleaned ports, power switch, and edge connectors.

Commodore 64 250425 Board #4

The fourth board needed a bit of work before it could even be powered on: it was missing its fuse, and it was completely missing U17 (PLA). The only socketed ICs were the SID (U18), VIC-II (U19), and MOS 8701 clock generator IC (U31).

A short note on this board, before we start: the underside of the PCB looks “crinkled” – this is not a problem, it is just a result of the wave-soldering process used during manufacturing. By adding extra solder to the traces, you reduce their resistance (and therefore thermal loss and voltage drop), so can get away without making them wider.

I fitted a fuse of the correct type, and installed a socket on U17 (which allow the quick removal of ICs without the need for rework) .

I always use high-quality double-sided sockets, which are more reliable than cheap single-sided sockets as they contact the IC legs on both sides – a lot of people push the use of turned-pin sockets, but I don’t like using them as they make swapping ICs difficult, they are difficult to desolder, and they are visibly obviously non-standard.

I then tested the board with a set of test chips installed, but it wouldn’t output any video – there was no signal on the monitor, on either the composite video output or the luma/chroma video output.

Example of a Commodore 64 no video fault.

In the C64, a no video fault is an uncommon failure mode which typically indicates one of two potential causes: either video is not being generated by the video circuit correctly (due to a bad VIC-II chip, power problems with the VIC-II chip, or lack of a clock signal to the VIC-II chip), or the video signal is not reaching the display (bad trace or video connector).

The first thing to check with any repair is that power is being correctly received on the board, which may indicate a problem with the power socket, power switch, or fuse – I checked for 9Vac and 5Vdc at the user port, and the 9Vac input was not present. I traced it forward from the power connector, but it was not getting through the power switch.

The VIC-II also has its own “clean” 5Vdc and 12Vdc supply rails, which are derived from the 9Vac input via a bridge rectifier and two voltage regulators, a 7805 and a 7812 – therefore, it makes sense that the lack of 9Vac would lead to a no video fault.

I removed the power switch using my desoldering station (a Duratool D00672) and replaced it with a known-good spare (also available to buy from Retroleum), then re-tested the board – it would now output video but still would not boot up correctly, displaying only a blank black screen with no border or text.

Example of a Commodore 64 black screen fault.

In the C64, a black screen fault is a common failure mode which can indicate all kinds of problems: typically, a missing or improper signal, a data or address bus conflict, an addressing problem, or a stack page fault, all of which can be caused by a power issue or a failed IC. Most of the ICs on the board are connected to the data or address bus, so there are a large number of potential problems that need to be worked through.

The first thing to check with any repair is that power is being correctly received on the board, which may indicate a problem with the power socket, power switch, or fuse – I re-checked the 9Vac and 5Vdc supplies at the user port, and both were OK; I also checked the 5Vdc and 12Vdc supply to the VIC-II, and both were OK.

I checked for physical damage on the board which could be causing connection problems, including scratches or cold solder joints, but everything seemed OK.

I checked for signs of previous rework which could indicate a potential problem (flux residue, non-factory sockets, etc), but there was none.

I reseated all of the socketed ICs and cleaned all sockets, ports, and switches with contact cleaner, however there was still no change in symptoms.

A constant reset can also cause a black screen – the reset signal at the user port should stay low (around 0Vdc) for about half a second at power on, then go high (around 5Vdc) and stay high, however it was staying constantly low. The reset signal is active-low, so the system was indeed being held under reset, indicating a problem with the reset circuit.

Commodore 64 reset circuit schematic (image credit: C64 service manual).

The reset circuit uses a 556 timer IC (U20) to generate an active-high pulse (whose width is determined by the size of R34 and C24), which is then buffered and inverted by a 7406 IC (U8). This pulse initialises the CPU, loading the program counter register with the address of the first instruction of the operating system (Kernal) from addresses $FFFC and $FFFD – this instruction is then decoded and executed, giving the Kernal control of the computer.

I checked the passive components which could be causing problems, including C24, C39, and R34, but there were no immediate problems – this meant that the issue was probably being caused by the 556 timer IC (U20) or the 7406 buffer IC (U8).

I checked the output pulse of the 556 timer IC (U20) on startup using my logic probe, and it was not present, so I removed, socketed, and replaced it using a new-old-stock 556 timer IC (available to buy from Retroleum) – I tested the board again but there was no change in symptoms, however the output of the timer IC was now present, but the output of the 7406 buffer IC (U8) was still static. I removed, socketed, and replaced it using a new-old-stock 7406 IC (available to buy from Retroleum) – the board now seemed to boot correctly for the first time (with flashing cursor and correct amount of RAM showing).

Board #4 boots correctly for the first time.

However, with a diagnostic cartridge and loopback harness installed the board failed keyboard tests, indicating the 6526 CIA at U1 as the problem.

Board #4 fails the keyboard diagnostic test.

I removed the U1 CIA and tested it in my C64 test board, and it had indeed failed – I installed a socket and fitted a known-good test IC and the board now passed all tests.

Fully tested with diagnostic harness; composite video output OK; luma/chroma video output OK; audio output OK; cleaned ports, power switch, and edge connectors.

Commodore 64 250425 Board #5

The fifth board would output video but would not boot up correctly, displaying only a blank black screen with no border or text.

Board #5 initial testing.

In the C64, a black screen fault is a common failure mode which can indicate all kinds of problems: typically, a missing or improper signal, a data or address bus conflict, an addressing problem, or a stack page fault, all of which can be caused by a power issue or a failed IC. Most of the ICs on the board are connected to the data or address bus, so there are a large number of potential problems that need to be worked through.

The first thing to check with any repair is that power is being correctly received on the board, which may indicate a problem with the power socket, power switch, or fuse – I checked for 9Vac and 5Vdc at the user port, and both were OK; I also checked the 5Vdc and 12Vdc supply to the VIC-II, and both were OK.

A constant reset can also cause a black screen – I checked the reset signal at the user port and it worked as expected, staying low (around 0Vdc) for about half a second at power on, then going high (around 5Vdc).

I checked for physical damage on the board which could be causing connection problems, including scratches or cold solder joints, but everything seemed OK.

I checked for signs of previous rework which could indicate a potential problem (flux residue, non-factory sockets, etc), but there was none.

I reseated all of the socketed ICs and cleaned all sockets, ports, and switches with contact cleaner, however there was still no change in symptoms.

I tried the machine using a dead-test cartridge, which can indicate potential hardware issues (i.e. bad ROM, bad RAM) – however, there was no change in symptoms. I tried the same with a diagnostic cartridge, with the same result.

I noticed that the Kernal ROM (U4) socket was in quite poor condition, so I removed it using my desoldering station (a Duratool D00672) and installed a new socket – I did the same for the SID socket at the same time, as this also looked rather loose and corroded. Unfortunately, there was no change in symptoms.

I always use high-quality double-sided sockets, which are more reliable than cheap single-sided sockets as they contact the IC legs on both sides – a lot of people push the use of turned-pin sockets, but I don’t like using them as they make swapping ICs difficult, they are difficult to desolder, and they are visibly obviously non-standard.

At this point I decided to aim my investigation at the soldered ICs themselves. Because there weren’t many that could theoretically cause these kind of problems, I decided to take a brute-force approach: I removed them one by one using my desoldering station (a Duratool D00672), installed a socket, then tested them where possible using my MiniPro TL866II, refitting the original IC if it was OK.

Many of these were MOS-brand equivalents of 74-series ICs, which make them especially suspect as these are particularly unreliable due to their manufacturing process.

I did this for: U14 (74LS258, in this case a MOS 7709), used in video addressing, which was OK; U15 (74LS139, in this case a MOS 7711), used in video addressing, which was OK; both RAM multiplexer ICs, U13 and U25 (74LS257s, in this case MOS 7708s), used in system RAM addressing, both of which were OK; U8 (7406), used as a signal buffer, which was OK.

I did the same for all eight 4164 DRAM ICs (U9-U12 and U21-U24) in case any were pulling on any data lines, testing them using my RAM tester. However, all eight were OK.

Board #5 with all eight RAM ICs carefully removed for testing.

I noticed that the CPU socket was also quite loose on several pins, and that the Vcc supply voltage on the CPU itself was sitting around 1.7Vdc instead of the expected 5Vdc. I removed and replaced the socket, and the dead-test cartridge now booted up OK.

Board #5 boots with dead-test cartridge installed.

The basic suite of diagnostics tests performed by the dead-test cartridge passed OK.

However, when trying to start up with a full set of known-good chips, the board seems to boot to a normal startup screen, but with weird graphical corruption.

Board #5 graphical corruption on startup.

With a diagnostic cartridge installed, the corruption persisted – the cartridge also indicated the PLA (U17) and CIA timers as being faulty (the other tests require the loopback harness).

Board #5 graphical corruption with diagnostic cartridge.

As the PLA test was an obvious failure, I decided to remove and replace the PLA (U17) socket, which was worn and corroded – unfortunately, there was no change in symptoms.

Again I looked at the soldered ICs, this time ones used in video display: I removed them one by one using my desoldering station (a Duratool D00672), installed a socket, then tested them where possible using my MiniPro TL866II, refitting the original IC if it was OK.

I did this for: U27 (74LS08), used in video addressing, which was OK; U26 (74LS373), used in video addressing, which was OK; U6 (2114 SRAM), the colour RAM IC, which was OK.

The character ROM (U5) – a common cause of character display issues – and BASIC ROM (U3) sockets also looked a bit worn and corroded, so I decided to remove and replace these too – after this, the board now seemed to boot correctly for the first time (with flashing cursor and correct amount of RAM showing).

Board #5 boots correctly for the first time.

However, with a diagnostic cartridge and loopback harness installed the board failed the user port tests, indicating the 6526 CIA at U2 as the problem.

Board #5 fails diagnostic tests.

I removed and replaced both CIA sockets as both were worn and slightly corroded, and the board now passed all diagnostic tests.

Upon reflection, I wish I’d just replaced all of the sockets on the major ICs in the first place, as this would have saved a lot of time – these kind of factory sockets are of a very poor quality, the board seemed to have had a lot of use as they were all worn, and the board seemed to have been stored improperly as they were all tarnished or corroded. However, at least the additional socketed ICs will give the new owner peace of mind.

Fully tested with diagnostic harness; composite video output OK; luma/chroma video output OK; audio output OK; cleaned ports, power switch, and edge connectors.

Commodore 64 250425 Board #6

The sixth board was missing its fuse and was completely missing its CPU (U7) and PLA (U17) – I installed a fuse of the correct type and installed sockets on the missing parts (which allow the quick removal of ICs without the need for rework), and cleaned the power switch with contact cleaner as it was quite stiff.

I always use high-quality double-sided sockets, which are more reliable than cheap single-sided sockets as they contact the IC legs on both sides – a lot of people push the use of turned-pin sockets, but I don’t like using them as they make swapping ICs difficult, they are difficult to desolder, and they are visibly obviously non-standard.

After testing, the board seemed to boot correctly for the first time (with flashing cursor and correct amount of RAM showing).

Board #6 boots correctly for the first time.

It also passed all tests with a diagnostic cartridge and loopback harness installed.

Fully tested with diagnostic harness; composite video output OK; luma/chroma video output OK; audio output OK; cleaned ports, power switch, and edge connectors.

Commodore 64 250425 Board #7

The seventh board would output video but would not boot up correctly, displaying the normal start-up screen but with scrambled text.

Board #7 scrambled video fault.

Instead of repairing this board myself, I decided to donate it to renowned Youtuber Jan Beta for use in one of his retro computer repair videos – he manages to repair it here.

Commodore 64 250425 Board #8

The eighth board wouldn’t output any video – there was no signal on the monitor, on either the composite video output or the luma/chroma video output.

Example of a Commodore 64 no video fault.

In the C64, a no video fault is an uncommon failure mode which typically indicates one of two potential causes: either video is not being generated by the video circuit correctly (due to a bad VIC-II chip, power problems with the VIC-II chip, or lack of a clock signal to the VIC-II chip), or the video signal is not reaching the display (bad trace or video connector).

The first thing to check with any repair is that power is being correctly received on the board, which may indicate a problem with the power socket, power switch, or fuse – I checked for 9Vac and 5Vdc at the user port, and both were OK.

The VIC-II also has its own “clean” 5Vdc and 12Vdc supplies which are derived from the 9Vac input via a bridge rectifier and two regulators, a 7805 and a 7812 – these were also OK.

I checked for physical damage on the board which could be causing connection problems, including scratches or cold solder joints, but everything seemed OK.

I checked for signs of previous rework which could indicate a potential problem (flux residue, non-factory sockets, etc) – I noticed that the signal connections to the RF modulator had been desoldered, which would definitely cause a lack of video, so someone had obviously been trying to investigate this problem previously. However, with the connections soldered correctly, there was no change in symptoms.

I reseated all of the socketed ICs and cleaned all sockets, ports, and switches with contact cleaner, however there was still no change in symptoms.

I replaced the VIC-II socket (which had minor corrosion) and checked all of the traces underneath in case there was a contact problem, however there was no change in symptoms; I replaced the video socket in case it had internal contact problems, however there was no change in symptoms; I even replaced the RF modulator with a suitable equivalent from one of my spares boards (which is no mean feat, trust me), as this could cause a lack of video output, however there was still no change in symptoms.

I checked the supply voltages to the VIC-II and RF modulator, and all were OK; I checked the clock tuning capacitor, and it seemed OK; I also checked the output of the crystal oscillator using my logic probe, however it was completely static. I replaced the crystal with one from a spares board, and the board now seemed to boot correctly (with flashing cursor and correct amount of RAM showing).

Board #8 boots correctly for the first time.

It also passed all tests with a diagnostic cartridge and loopback harness installed.

Fully tested with diagnostic harness; composite video output OK; luma/chroma video output OK; audio output OK; cleaned ports, power switch, and edge connectors.

Commodore 64 250425 Board #9

The ninth board would output video but would not boot up correctly, displaying only a blank black screen with no border or text.

Example of a Commodore 64 black screen fault.

In the C64, a black screen fault is a common failure mode which can indicate all kinds of problems: typically, a missing or improper signal, a data or address bus conflict, an addressing problem, or a stack page fault, all of which can be caused by a power issue or a failed IC. Most of the ICs on the board are connected to the data or address bus, so there are a large number of potential problems that need to be worked through.

The first thing to check with any repair is that power is being correctly received on the board, which may indicate a problem with the power socket, power switch, or fuse – I checked for 9Vac and 5Vdc at the user port, and both were OK; I also checked the 5Vdc and 12Vdc supply to the VIC-II, and both were OK.

A constant reset can also cause a black screen – I checked the reset signal at the user port and it worked as expected, staying low (around 0Vdc) for about a second at power on, then going high (around 5Vdc).

I checked for physical damage on the board which could be causing connection problems, including scratches or cold solder joints, but everything seemed OK.

I checked for signs of previous rework which could indicate a potential problem (flux residue, non-factory sockets, etc), but there was none.

I reseated all of the socketed ICs and cleaned all sockets, ports, and switches with contact cleaner, however there was still no change in symptoms.

I tried the machine using a dead-test cartridge, which can indicate potential hardware issues (i.e. bad ROM, bad RAM) – however, there was no change in symptoms. I tried the same with a diagnostic cartridge, with the same result.

I noticed that the VIC-II (U19) and 8701 (U31) sockets were corroded, which could cause contact problems and therefore a black screen, so I removed them using my desoldering station (a Duratool D00672) and installed replacements – however, there was no change in symptoms.

I always use high-quality double-sided sockets, which are more reliable than cheap single-sided sockets as they contact the IC legs on both sides – a lot of people push the use of turned-pin sockets, but I don’t like using them as they make swapping ICs difficult, they are difficult to desolder, and they are visibly obviously non-standard.

At this point I decided to aim my investigation at the soldered ICs themselves. Because there were a few that were most likely to cause these kind of problems, I decided to take a brute-force approach: I removed them one by one using my desoldering station (a Duratool D00672), installed a socket, then tested them where possible using my MiniPro TL866II, refitting the original IC if it was OK.

Some of these were MOS-brand equivalents of 74-series ICs, which make them especially suspect as these are particularly unreliable due to their manufacturing process.

I did this for: U8 (7406), a signal buffer which also generates the reset and RAM control signals, which was OK; U14 (74LS258, in this case a MOS 7709), used in video addressing, of which several gates had failed.

With a new-old-stock 74LS258 IC fitted (available to buy from Retroleum) and the dead-test cartridge installed, along with the minimal number of major test ICs required for boot (VIC-II, 8701, CPU, PLA), the cartridge would boot up correctly.

The basic suite of diagnostics tests performed by the dead-test cartridge passed OK.

However, when trying to start up with a full set of known-good chips, the dead-test cartridge would give a flash code (indicating a fault with data bit 3) – without the cartridge installed, the board would revert to the black screen fault. I managed to narrow the problematic ICs down to the three ROMs.

The ROM ICs that I was testing with were all known-good parts, so these were not at fault; given that the dead-test cartridge only indicated a data line problem whilst the ROMs were fitted, it was unlikely that there was a problem with any other ICs on the board.

This all lead me to believe that it was a probable contact issue, so I replaced all three ROM sockets, all of which had noticeable corrosion. Unfortunately, this corrosion had also damaged two of the via eyelets on the top side of the board, so I had to install two small jumper cables using wrapping wire on the underside of the PCB.

I then tested again with a full set of test ICs, and the board now seemed to boot correctly (with flashing cursor and correct amount of RAM showing).

Board #9 boots correctly for the first time.

The board also passed all tests with the diagnostic cartridge and loopback harness.

Fully tested with diagnostic harness; composite video output OK; luma/chroma video output OK; audio output OK; cleaned ports, power switch, and edge connectors.

Commodore 64 250425 Board #10

The tenth board would output video but would not boot up correctly, displaying only a blank black screen with no border or text.

Example of a Commodore 64 black screen fault.

In the C64, a black screen fault is a common failure mode which can indicate all kinds of problems: typically, a missing or improper signal, a data or address bus conflict, an addressing problem, or a stack page fault, all of which can be caused by a power issue or a failed IC. Most of the ICs on the board are connected to the data or address bus, so there are a large number of potential problems that need to be worked through.

The first thing to check with any repair is that power is being correctly received on the board, which may indicate a problem with the power socket, power switch, or fuse – I checked for 9Vac and 5Vdc at the user port, and both were OK; I also checked the 5Vdc and 12Vdc supply to the VIC-II, and both were OK.

A constant reset can also cause a black screen – I checked the reset signal at the user port and it worked as expected, staying low (around 0Vdc) for about a second at power on, then going high (around 5Vdc).

I checked for physical damage on the board which could be causing connection problems, including scratches or cold solder joints, but everything seemed OK.

I checked for signs of previous rework which could indicate a potential problem (flux residue, non-factory sockets, etc) – two of the 4164 DRAM ICs had been socketed and seemingly replaced by a previous owner for whatever reason, so I checked over their work, and everything seemed OK.

I reseated all of the socketed ICs and cleaned all sockets, ports, and switches with contact cleaner, however there was still no change in symptoms.

I tried the machine using a dead-test cartridge, which can indicate potential hardware issues (i.e. bad ROM, bad RAM) – this consistently gave a seven-flash fault code, indicating a problem with data bit 1.

The dead-test cartridge manual says to suspect the 4164 DRAM IC at U9 on this board revision, which would explain why the previous owner had started pulling RAM ICs. However there are lots of potential causes of a stuck data bit, as I know from experience – addressing problems due to bad ICs (such as the RAM multiplexers and PLA) can cause this, as can stuck output drivers on ICs (in particular, the ROMs). Therefore, I wasn’t going to start pulling RAM ICs until I’d investigated a little further.

I noticed that the two RAM multiplexers (U13 and U25) were MOS-brand equivalents of 74-series ICs (in this case, MOS 7708s instead of 74LS257s), which are particularly unreliable due to their manufacturing process, so should be suspect.

I removed both ICs (U13 and U25) using my desoldering station (a Duratool D00672) and tested them using my MiniPro TL866II – one had indeed failed. I installed sockets (allowing the quick removal of ICs without the need for rework), and fitted two new-old-stock 74LS257 ICs (available to buy from Retroleum).

I always use high-quality double-sided sockets, which are more reliable than cheap single-sided sockets as they contact the IC legs on both sides – a lot of people push the use of turned-pin sockets, but I don’t like using them as they make swapping ICs difficult, they are difficult to desolder, and they are visibly obviously non-standard.

After this, the board now started up to a garbage screen with random flashing elements.

Board #10 garbage screen.

The board still gave a garbled image even with the dead-test cartridge installed.

At this point I decided to aim my investigation at some of the glue logic ICs associated with video addressing, which could cause these kind of problems. I decided to take a brute-force approach: I removed them one by one using my desoldering station (a Duratool D00672), installed a socket, then tested them where possible using my MiniPro TL866II, refitting the original IC if it was OK.

I did this for: U27 (74LS08, in this case a MOS 7712), used in video addressing, which was OK; U8 (7406), used to buffer the RAM (including video RAM) control signals, which was OK; U14 (74LS258, in this case a MOS 7709), used in video addressing, which had failed.

I fitted a new-old-stock 7406 IC (available to buy from Retroleum), then tested again – the board now booted correctly (with flashing cursor and correct amount of RAM showing).

Board #10 boots correctly for the first time.

The board also passed all tests with the diagnostic cartridge and loopback harness.

Fully tested with diagnostic harness; composite video output OK; luma/chroma video output OK; audio output OK; cleaned ports, power switch, and edge connectors.

Published by themightymadman

A conscientious, intelligent and committed graduate engineer, with excellent interpersonal skills, an eye for detail and a keen interest in hardware design, mathematics, and software development.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: