Commodore 64 / 1541 Repair Info

Recently I've had to diagnose and repair various hardware problems with my Commodore setup. There's already a lot of useful information on the Internet, although this didn't quite cover the problems I was seeing. The Commodore 64 PLA seems to get blamed for nearly every 'blank screen' problem (quite rightly - as it's the most common part to fail), but this is not always the case. It's always worth checking to be sure.

I'll give any dead boards a good home.

Commodore 64:

Symptom: Black Screen (of death)

This was a breadbin style 64 that I picked up from a radio rally with a load of games. It was really the included Simon's Basic cartridge I wanted, the 64 was just an added bonus. Sadly, the 64 just presented a blank screen on power up, i.e. a tunable picture is produced, but it's just all black (no border).

Inserting a cartridge into the cartridge slot (I used Music Composer) produced a correct colour border but a screen full of garbage characters. After a couple of minutes the characters seemed to fade out.

Cause:

RAM fault.

Solution:

Power up the 64 and leave running for a couple of minutes. Feel each 8K RAM chip for heat. Usually labelled 4164 or similar at the bottom left of the PCB. If any of them are noticeably hotter than the others, it's duff.

In my case, one of the RAM chips was much hotter. When replaced the 64 powered up normally.

Conclusions:

If I was to repair another 64, I'd recommend the following steps before assuming (prematurely) it's a PLA failure:

• Check PSU and internal voltage rails. As a minimum check for a red power LED and that the C2N cassette motor runs to prove the correct voltage rails are present. Use a known working 64 PSU when diagnosing problems.
• Insert cartrige and power up. Cartridge will work even without the 3 ROMs being present. As above, you may get some output even if a RAM page has failed (Music Composer was a good example).
• Pull non-essential chips, like SID (which normally runs hot).
• Check RAM. Chips that feel warm/hot after a few minutes, especially when hotter than the other RAM chips, are faulty and must be replaced.

The older 2364 ROMs can be quite quirky and appear dead/unconnected in an EPROM programmer, especially expensive high-end programmers. Often these ROMs are actually OK. In my experience some ROMs, although working in the host system, will sometimes pull an unexpected large amount of current, appear unconnected in a programmer and sometimes stay in permanent hi-Z when read (read 0x00 or 0xFF throughout). See page on 2364 ROMs for more information.

Based on the above steps and known chip vs failure conditions (see Ray Carlsen's site), diagnose likely fault.

A true PLA failure seems to result in a black screen and the cartridge is also ignored.

By far the easiest way to diagnose faults is with a second, known working 64. It seems a lottery whether some or all of the main chips are socketed, but I've found it relatively easy to de-solder chips and and fit DIL sockets retrospectively - this may be tricky without experience and a decent soldering iron and de-solder tool. Swap over suspect chips one by one and check whether the control (known working) 64 stops working and whether the faulty 64 starts working - if there's more than one fault, it pays to check both ways. Try eliminating the PLA and RAM first.

C=64 PCB, 3 ROM chips shown top centre.	C=64 PCB, RAM chips at the bottom (1 replaced).	This one has previously been repaired. Recognise this company?

Commodore 1541 Single Floppy:

Symptom: Red LED Flashes Twice (Motor Runs Continuously)

The 1541 was working fine when stored away about 15 years ago. However, now on power-up the spindle motor runs continuously, the green LED (power) is illuminated and the red LED (drive status) indicates a self-test 'flash code'.

1541 LED Flash Codes

The following information is taken from the 1541 service manual (available from funet).
Warning! This may be incorrect, also read following sections.

The 1541, upon power-up, goes through its own internal diagnostic. If an electronic problem is detected, it's indicated by flash code. The led's will blink a number of times, pause, and then flash again until the problem is corrected. Number of flashes

Number of Flashes:	Service Manual Symptom:
2	Zero Page
3,4	DOS ROMs
5,6,7,8	RAM

From actually pulling out chips and disassembling the DOS ROMs, I disagree with the above service manual defined flash codes. Perhaps this changed in later drives or DOS versions (I'm running 901229-05). From the ROM disassembly, the flash codes for the above DOS version are:

Number of Flashes:	Disassembled Symptom:
1	Zero Page fail (RAM $00-$FF)
2	$E000-$FFFF DOS ROM (UB4) Checksum Fail ($E0)
3	$C000-$DFFF DOS ROM (UB3) Checksum Fail ($C0)
4	RAM fail (remaining 7 pages)

I'm interested to know whether anyone else disagrees with the LED flash codes printed in the user manual?

As stated in the service manual, circuitry associated with these components can also cause the failure code. Therefore, it should be suspected as the next possible defect, although this is mainly (pretty robust) TTL logic.

Solution:

1. Removed UB4 (901229-05) and UB3 (325302-01) DOS ROMs. On an EPROM programmer UB4 read back correctly, UB3 would not read at all! Made an EPROM adapter (2364 to 76C256) and programmed modern 256kB EPROM with original 64Kb in each of the 4 new banks. Could bank switch later with JiffyDOS, etc. Ensure new ROMs inserted into adapter read back as a 2364 PROM (compatible with Motorola 68764 if your programmer recognises it). Compare data/checksums, etc. (901229-05 = 0x000F0CC5, 325302-01 = 0x000F575A).

2. With new ROMs, drive still does the double flash LED error code on startup. The problem persisted even after replacing most of the address decoding logic for the ROMs, RAM and 6522's.

Problem was caused by partially failed 6502 processor. Odd, because the CPU was obviously functioning partially OK in order to read the boot vectors, initialization code and LED flash code from ROM. In fact the Zero Page RAM test had completed, only the UB4 ROM check reported a checksum fail - which was known to be bogus because the ROM was read out and checked against the known binary image on funet. I suspect one of the address lines was duff internally to the chip when addressing the lower E000-EA00 range.

I've ended up replacing most of the address decoding logic and replaced both bridge rectifiers because one of the diodes had partially broken down. So nearly all the chips are socketed and replaced, it's got beefed up 6A bridge rectifiers, modern 76C256 banked ROMs, etc. Any offers?

For future reference, the 1541 ROM checksums should read back as follows:

Use the checksum.pl Perl script to generate checksums compatible with EPROM programmer.

Before...	and after repair.

Repair Links:

• C=64 and 1541 (plus loads others) on funet
• Ray Carlsen's site (see chip vs symptoms pages)
• comp.sys.cbm