Hallo Besucher, der Thread wurde 3,5k mal aufgerufen und enthält 4 Antworten

letzter Beitrag von drevin am

Semi-faulty C64

  • Hi, (post is in english)


    I have a partially working C64 (works but won't run some programs/games). It has had this problem for years now without any change in symptoms. I've narrowed the problem down to the C64 itself (Disk drive, Power Supply and the files have been tested and found working). I've also tested swapping the socketed chips: CIA1, CIA2, SID, VIC. No change in symptoms.


    The resulting errors depend on the program, usually a frozen garbage screen. The errors are NOT intermittent, meaning if I run a game and it causes a frozen screen, it will produce that exact same frozen screen every time I run it. It's interesting to note that when I use a fastloader called "Star Turbo", it usually makes a loaded program work at least a bit better, sometimes perfectly. The fastloader never seems to make a game work worse (unless the game simply isn't compatible with fastloaders).


    Does anyone know what exactly does a C64 fastloader change in the loading process, how could it make such a big difference. Which chips inside the C64 could be most affected by the fast-loading. I was able to dump the C64 ROMs and they were exact copies of the ROMs bundled with a C64 emulator. Does this mean that the ROMs are OK, or could there still be a problem with them? If they are OK, then I would suspect that the faulty chip is one of the following: PLA, RAM or CPU. The RAM chips I haven't been able to swap, but I've tested them in many different ways:


    -Piggybacking a working RAM chip on top of each chip
    -2 different software diagnostic tests (both passed)
    -Startup screen has never displayed more or less than 38911 bytes free
    -Loaded a "non-working" program to memory, then verified it. Result: Verify OK.


    Because of these tests I'm starting to think the RAM might be OK, although there is still a slight chance that it's not. I don't have diagnostic cartridges so I used disk-based diagnostic tools, which can only test about 80% of the available memory. I've also heard that some people have had problems just like mine and they were caused by faulty RAM.


    If the RAM is ok and it can be assumed that the problem is with one of the bigger chips, then that leaves only the PLA and CPU as possible suspects. I haven't really been able to test these two chips in any way. I've read that PLA failures are very common so a semi-faulty PLA would be my best guess. Could fastloaders have an effect on how these chips work? Both chips run hot, but cooler than the SID and VIC. Are there any more tests that I could do to find out which chip is at fault?


    Thanks in advance.

  • If it's a problem with clock speed, which chip is the one to blame, is it the CPU or something else. Also, I just had to test the CPU and PLA by piggybacking, despite hearing that it's a very unreliable way to test chips. Both piggybacks worked without side effects, but they also didn't change the symptoms. By the way, the machine from where I got the spare chips used to produce a blank screen, does the fact that the piggybacks worked mean its PLA/CPU wasn't causing it.

  • I don't think it's a problem with the clock speed - if it were you'd get a black-and-white picture and probably a rolling picture long before you get data transmission problems with the standard serial protocol.


    Is there a non-working program that is 153 blocks or less? If so, can you try to load it, save it under a different name and compare both files on a different system (e.g. by transferring them to the PC)?


    What is the Assy No of the board in your C64?

  • On the board it says "ASSY NO. 250407 ARTWORK NO. 251137 REV.C".


    I've been able to test the saving method before: saved a loaded non-working program to diskette, then compared it to the original file on my PC, and they were exactly the same. The problematic phase seems to be the part between "RUN" and the program's start screen. I don't know what the machine does at that time, maybe moves the program to different parts in the RAM, decompresses it or something. Usually if a program makes it to the start screen, it works perfectly from then on.


    One thing I've been thinking: Could it be that a small part of the RAM is faulty and it happens to be an area that the OS normally uses (and luckily isn't affected by it). Then the problems would only begin after the program is moved into the OS space of the RAM, which probably only happens after the run command. Also maybe the disk-based RAM diagnostic tools won't test this part of the memory which would explain why they find no errors. I wish I had a RAM diagnostic cartridge, that way I could probably rule out the RAM (unless the cart itself wouldn't work).