Diagnosing a C64 (memory related problem)


  • drevin
  • 5316 Views 3 replies

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • Diagnosing a C64 (memory related problem)

    Hi,

    I have an old partially working C64 that I'd like to diagnose and possibly fix. The machine is a 1983 brown breadbox C64 with "Assy no.250407 Artwork no.251137 rev.c". The only symptom is some programs do not work correctly, mostly longer ones. The problem is NOT with the files; they work perfectly with VICE.

    I've already spent a lot of time investigating the cause, and have found out the following:

    1) Something causes data to not get written in RAM properly

    2) Because some of the required data is missing, the program crashes

    So while the problems ARE related to corrupted data in the RAM, the RAM itself is almost certainly not faulty (been tested very thoroughly). Instead, something causes data to not get written or to get written incorrectly. I tracked down that when a program loads, it stops writing data to RAM when it goes over 38911 bytes. This does not happen with VICE, with the exact same loading procedure. With help from another forum, I found out that this happens because after that point, the loading process starts to write to the RAM "through the ROM". This is what the faulty C64 does not handle correctly. They even made a memory test that tests writing data through the ROM, and it detected an error, unlike all ordinary RAM tests.

    So it seems the machine only has problems writing data when it goes through the ROM. This results in some programs working while others don't. I feel I'm getting closer and closer to the solution. Now all I'd need to find out is, which part inside the C64 could cause this behaviour? Perhaps someone has in-depth knowledge of the C64 and can pinpoint the culprit with the information given above?

    I've been able to rule out the following parts:

    -Disk Drive (tested with substitute)

    -Power Supply (tested with substitute)

    -CIAs (tested with substitutes)

    -SID (tested with substitute)

    -VIC (tested with substitute)

    -RAM (tested from $0002 to $FFFF)

    -ROMs (dumps were 100% correct)

    That pretty much leaves only CPU, PLA and the smaller logic chips (which are all soldered). I've attached the code for the memory tester (it should always print 0, on the faulty C64 it prints 7).

    Source Code

    1. 1 data169,0,133,2,169,85,32,16,192,169
    2. 2 data170,32,16,192,169,255,162,0
    3. 3 data157,0,160,232,208,250,120,160,54
    4. 4 data132,1,221,0,160,208,5,232,208
    5. 5 data248,24,36,56,38,2,200,132,1,88,96
    6. 6 fori=0to46:reada:poke49152+i,a:z=z+a:next
    7. 7 ifz<>5392thenprint"data error":end
    8. 8 sys49152:printpeek(2)
  • Thanks for the suggestion. The PLA chip isn't socketed though, and I don't have much soldering experience. So if possible, I want to be sure it is actually faulty before starting any desoldering.

    I have spare PLA from another C64 which produced a blank screen. To see if it makes any difference in symptoms, I piggybacked it on top of the other PLA. It didn't change anything, but I noticed that the bottom PLA became warmer than the piggybacked one, leading me to believe that the machine didn't even use the piggybacked chip.

    If a piggybacked chip is faulty, can it lead to the system using the bottom one instead? Maybe the spare PLA caused the blank screen on the other C64. With CPU piggyback, the top chip did become warm but no difference in symptoms. Is there any way to test the PLA via software?
  • drevin wrote:

    Thanks for the suggestion. The PLA chip isn't socketed though, and I don't have much soldering experience. So if possible, I want to be sure it is actually faulty before starting any desoldering.

    In that case just hook it up to a logic analyzer, capture its behaviour and compare what you see with the expected behaviour of a working PLA (the equations are available on the net).

    If a piggybacked chip is faulty, can it lead to the system using the bottom one instead? Maybe the spare PLA caused the blank screen on the other C64. With CPU piggyback, the top chip did become warm but no difference in symptoms. Is there any way to test the PLA via software?

    Piggybacking chips to diagnose problems only works in very specific cases, trying it with a known-bad chip with an unknown failure mode produces completely unusable results.

    Source Code

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage