RAM defekt - Beispielhafte Diagnose und Reparatur

Es gibt 43 Antworten in diesem Thema, welches 13.962 mal aufgerufen wurde. Der letzte Beitrag (3. September 2022 um 19:45) ist von NHeusler.

  • Mein Lieblings C64 zeigt seit einer Woche Symptome eines defekten RAM Bausteins. Die Diagnose und Reparatur ist für mich Routine, aber ich nehme es zum Anlass, einige Beobachtungen dazu niederzuschreiben. Mag für den einen oder anderen von Nutzen sein.

    Erstes Symptom war der Absturz mitten in einem Demo (Oneder), das ich zum Testen der Ladegeschwindigkeit geladen hatte.

    Nach einem Reset war der Einschaltbildschirm mit falschen Zeichen besetzt. Interessanterweise gibt es hier einen Unterschied zwischen Kernals mit einem abgekürzten RAM Test (Speeddos, Dolphindos, Prologic DOS, etc.) und denen mit dem ausführlichen RAM Test (original Kernal, Jiffydos). Auf letzteren kommt gar nicht mehr die Einschaltmeldung, sondern nur noch ein Out of Memory Error. Man hat hier also mit einem Alternativkernal evtl. noch die Möglichkeit, manuelle Tests auszuführen, was beim Original nicht gelingt.

    Bitte melde dich an, um diesen Anhang zu sehen. Bitte melde dich an, um diesen Anhang zu sehen.

    Aus den fehlerhaften Zeichen kann man schon auf den defekten RAM Chip schliessen. Normalerweise wäre hier ein Leerzeichen, Bildschirmcode 32. Stattdessen sehen wir die Klammer auf, Code 40. Die Differenz ist 8, es ist also Bit 3 dauerhaft gesetzt (2^3 = 8 ). Aus dem Schaltplan kann man auf den defekten Baustein schliessen: Auf meiner 250425 Platine ist das U10.

    Man kann auch ein Diagnosemodul verwenden. Diese zeigen direkt den defekten Chip an, wenn sie denn korrekt funktionieren!

    Bitte melde dich an, um diesen Anhang zu sehen. Bitte melde dich an, um diesen Anhang zu sehen. Bitte melde dich an, um diesen Anhang zu sehen.

    Links zu sehen, das Modul aus dem 64'er Magazin. Der defekte Chip wird korrekt identifiziert, und auch die Speicherstelle des gefundenen Defekts gezeigt. $0339 befindet sich im Bildschirmspeicher, ist also korrekt.

    In der Mitte das Modul aus der GO64! Auch hier wird der defekte Chip korrekt angezeigt. Ehrlich gesagt war ich darüber erstaunt, weil ich von diesem Modul bisher nur Fehldiagnosen kenne! Dazu später mehr.

    Rechts das Commodore Modul. Dieses startet gar nicht richtig und bleibt beim angezeigten Bild hängen, dazu werden noch falsche Defekte angezeigt. Offenbar ist es durch die RAM Defekte komplett aus dem Tritt geraten. So ein Modul kann man eigentlich nur für funktionierende Rechner gebrauchen.

    Ohne Bild ist das Commodore 64 Dead Test Cartridge. Dieses zeigt bei schwerwiegenden Defekten den ersten gefundenen defekten RAM Chip durch einen Blinkcode am Bildschirm an. In diesem Fall blinkte es 5 mal. Das ist laut Anleitung der U10. Also korrekt! Warum es 5 mal blinkt und nicht 3 mal ist mir ein Rätsel, es startet wohl beim Bit 8 und geht rückwärts vor.

    Mit der Reparatur gehts weiter im nächsten Teil, weil nur 5 Bilder pro Beitrag erlaubt sind.

    Code: Floppy Fehlerkanal abfragen - Ausserdem kann ich bei "drive not ready" den I: und N: Befehl verwenden und notfalls den Kopf manuell zurückschieben. Und Finger weg vom Stepper!
    10 open1,8,15                   : rem 8 ist die Geräteadresse und das kann man bei Bedarf natürlich anpassen
    20 get#1,a$:?a$;:ifst<>64goto20 : rem Das CLOSE 1 am Ende kann man sich sparen, weil beim RUN automatisch ein CLOSE ALL ausgeführt wird.
    RUN
  • Wie man sieht, sind in diesem C64 die bekannt anfälligen RAMs von Micron Technologies verbaut worden. Als ich den C64 vor einigen Jahren bekam, war er schon defekt, und ich habe ihn durch Austausch eines RAM Chips reparieren können (U21). Diesmal ist also U10 defekt, ich werde diesen also entfernen und durch einen Sockel ersetzen. Dazu kneife ich von oben die einzelnen Pins mit einem Elektronikseitenschneider ab, und kann dann die Pins einzeln auslöten. Das ist sehr schonend für die Platine. Dann werden die Löcher mit einer Entlötpumpe gereinigt und ein Sockel eingelötet. Das ist Routine.

    Bitte melde dich an, um diesen Anhang zu sehen. Bitte melde dich an, um diesen Anhang zu sehen.

    Man sieht hier auch schön, dass es sich um eine Platine handelt, die Zinn unter dem Lötstopplack hat. Bei der Reparatur hat sich der Lack unterhalb des getauschten Chips verzogen, da das Zinn darunter geschmolzen ist. Das ist zwar nicht schön, aber nicht zu ändern, und kein Qualtitätsmangel. Man muss sich freuen, dass das Kupfer eine zusätzliche Schutzschicht aus Zinn hat, und somit weniger anfällig für Korrosion ist. Diese Platinen werden also die billigeren (aber schöneren) ohne die Verzinnung um einige Jahrzehnte überleben :)

    Nach der Reparatur habe ich nochmals die Diagnoseprogramme gestartet. Es wird jeweils kein Fehler mehr gefunden, die Reparatur ist also geglückt!

    Bemerkenswert ist nur das Programm aus der GO64! Bei fast jedem Rechner zeigt es RAM Fehler an. Auch wenn keiner vorhanden ist! Ich weiß nicht warum das so ist, aber man sollte sich davon nicht verwirren lassen. Auf dem reparierten Rechner, und auf einem weiteren, wird jeweils U12 als defekt angezeigt!

    Bitte melde dich an, um diesen Anhang zu sehen. Bitte melde dich an, um diesen Anhang zu sehen. Bitte melde dich an, um diesen Anhang zu sehen.

    Code: Floppy Fehlerkanal abfragen - Ausserdem kann ich bei "drive not ready" den I: und N: Befehl verwenden und notfalls den Kopf manuell zurückschieben. Und Finger weg vom Stepper!
    10 open1,8,15                   : rem 8 ist die Geräteadresse und das kann man bei Bedarf natürlich anpassen
    20 get#1,a$:?a$;:ifst<>64goto20 : rem Das CLOSE 1 am Ende kann man sich sparen, weil beim RUN automatisch ein CLOSE ALL ausgeführt wird.
    RUN
  • Zum Abschluß noch die fehlerhafte Meldung des GO64! Moduls:
    Bitte melde dich an, um diesen Anhang zu sehen.

    Code: Floppy Fehlerkanal abfragen - Ausserdem kann ich bei "drive not ready" den I: und N: Befehl verwenden und notfalls den Kopf manuell zurückschieben. Und Finger weg vom Stepper!
    10 open1,8,15                   : rem 8 ist die Geräteadresse und das kann man bei Bedarf natürlich anpassen
    20 get#1,a$:?a$;:ifst<>64goto20 : rem Das CLOSE 1 am Ende kann man sich sparen, weil beim RUN automatisch ein CLOSE ALL ausgeführt wird.
    RUN
  • Eindeutig als defekt erkannte ICs hole ich auch so von der Platine. Warum umständlich auslöten wenn das Teil am Ende ist? Einzelpins gehen viel leichter raus.

    Bei deinem Rechner könnte man sich jetzt überlegen, ob man nicht gleich alle MT4264 ersetzt wenn jetzt schon der zweite davon defekt ist.

  • Toller Beitrag :thumbsup:

    Eine Frage zu den Modulen, kann man sich so eins in die UII / Chameleon laden und nutzen?

    - WiC64 - The Commodore 64 Wireless Interface -> Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.
    - WiC64 - Radio -> Bitte melde dich an, um diesen Link zu sehen.
    - WiC64 - GameBox -> Bitte melde dich an, um diesen Link zu sehen. :thumbsup:
    - WiC64 - DemoBox -> Bitte melde dich an, um diesen Link zu sehen.

  • Das geht schon (mit kleinen Einschränkungen), aber sowohl das Chameleon als auch die U2 sind mir als Diagnose-Modul einfach zu teuer. Womöglich zieht ein defekter C64 die Module auch mit runter?
    Ein Diagnose-ROM auf dem EF-1 wäre sicher ein gangbarer Weg.

    Gruß Dirk

  • Bei deinem Rechner könnte man sich jetzt überlegen, ob man nicht gleich alle MT4264 ersetzt wenn jetzt schon der zweite davon defekt ist.

    Das hatte ich mir überlegt, aber hatte etwas Angst vor der Reaktion der Gegner von unbegründetem Teilewechsel hier im Forum ;) Mich interessiert aber auch, wann der nächste der kleinen Mistkerle auf sich aufmerksam macht.

    Eine Frage zu den Modulen, kann man sich so eins in die UII / Chameleon laden und nutzen?

    Abgesehen davon dass die Module dafür zu kostspielig sind, ist beim Chameleon je nach Firmwarestand auch nicht klar, inwiefern es das RAM im C64 überhaupt nutzt. Im U2 könnte man sicherlich einen funktionierenden Rechner testen, ob wirklich alles ok ist.

    Ein Diagnose-ROM auf dem EF-1 wäre sicher ein gangbarer Weg.

    So mache ich es mit dem Dead Test. Der ist bei mir aufs EF1 geladen. Die restlichen Module auf einer billigen EPROM Karte von REX, die ich im Ausverkauf bei HCS Lange erstanden habe.

    Code: Floppy Fehlerkanal abfragen - Ausserdem kann ich bei "drive not ready" den I: und N: Befehl verwenden und notfalls den Kopf manuell zurückschieben. Und Finger weg vom Stepper!
    10 open1,8,15                   : rem 8 ist die Geräteadresse und das kann man bei Bedarf natürlich anpassen
    20 get#1,a$:?a$;:ifst<>64goto20 : rem Das CLOSE 1 am Ende kann man sich sparen, weil beim RUN automatisch ein CLOSE ALL ausgeführt wird.
    RUN
  • Zitat

    ist beim Chameleon je nach Firmwarestand auch nicht klar, inwiefern es das RAM im C64 überhaupt nutzt.


    natürlich ist das klar - benutzt wird, völlig unabhängig von der firmware, nur das colorram.

  • Das hatte ich mir überlegt, aber hatte etwas Angst vor der Reaktion der Gegner von unbegründetem Teilewechsel hier im Forum ;) Mich interessiert aber auch, wann der nächste der kleinen Mistkerle auf sich aufmerksam macht.

    Natürlich dann, wenn es am meisten stört... Also auf einem Treffen wo keiner einen Lötkolben, Sockel oder 4164 dabei hat.

    Der Fehler den die MT4264 entwickeln ist ziemlich charakteristisch, die meisten anderen RAMs bei denen ich Ausfälle hatte waren entweder einfach nicht mehr da oder wurden zum Heizkörper. Sieht irgendwie nach einer defekten Zeile aus. Leseverstärker ausgefallen?

  • natürlich ist das klar - benutzt wird, völlig unabhängig von der firmware, nur das colorram.

    Huch, nichtmal für das, was auf dem VIC-II erscheint?

    Natürlich dann, wenn es am meisten stört... Also auf einem Treffen wo keiner einen Lötkolben, Sockel oder 4164 dabei hat.

    Gemäß Murphy's Law wäre das so. Dazu müsste ich aber den 64er auf ein Treffen nehmen. Mach ich ja schon nicht. Und dann selbst kein Ersatzgerät dabei haben. Mache ich auch nicht. Insofern werde ich erleben wann gemäß normaler Alterung der nächste Chip ausfällt :)

    Code: Floppy Fehlerkanal abfragen - Ausserdem kann ich bei "drive not ready" den I: und N: Befehl verwenden und notfalls den Kopf manuell zurückschieben. Und Finger weg vom Stepper!
    10 open1,8,15                   : rem 8 ist die Geräteadresse und das kann man bei Bedarf natürlich anpassen
    20 get#1,a$:?a$;:ifst<>64goto20 : rem Das CLOSE 1 am Ende kann man sich sparen, weil beim RUN automatisch ein CLOSE ALL ausgeführt wird.
    RUN
  • Zitat

    Huch, nichtmal für das, was auf dem VIC-II erscheint?


    ? warum sollte das so sein ? das würde es ja nur viel komplizierter machen :)

  • Dass die MT Rams Mist sind, kann ich btw. nochmal bestätigen. Hatte auch 'mal ein Board (407er Rev.C) bzw. hab' es noch immer, da war ca. -übertrieben gesagt- jeder zweite MT Ram ziemlich hinüber. Es kam aber zum Glück noch die Einschaltmeldung mit "0 Basic Bytes free", daher war sofort klar, was defekt war (u. heiss wurden auch ein paar).
    Dann alle Rams ersetzt (mit diesen grauen/etwas dickeren Japan Rams aus einer frühen 407er Rev.B) und es lief wieder. Das war lange her, quasi meine erste Reparatur, daher häng' ich an der Platine noch immer 'besonders' ;).

  • Hi,

    in diesem Post sind 3 Diagnosemodule zu sehen.

    1. aus der 64'er
    2. aus der GO64!
    3. das Commodore Modul

    In welcher Ausgabe der 64'er hat das 64'er Modul gestanden? Ich suche es und kann es nicht finden.

    Vielen Dank im voraus!

  • Die Beschreibung und auch das Programm findet man in der "Klaut" :
    222 Tips, Tricks & Tools für den C64 von Nikolaus M.Heusler aus dem IPV - Verlag.
    Das Programm Doc64 ist auf der ersten Buchdisk.
    Bei Bedarf kann ich es auch (als PN) als PDF und 2 Diskimages verschicken.

  • Habe den thread ein bisschen verpennt. Ich habe diese Frage an anderer Stelle schon mal gestellt, aber leider keine Antwort erhalten:

    wenn das "Dead Test Cartridge" (oder ein anderes brauchbares Diagnose-Modul) fehlerfrei(!) durchläuft, der C64 aber ohne das Cartridge dunkel bleibt, was kann man dann eigentlich an Defekten ausschließen? Die PLA kann's dann ja nicht sein, sonst läuft ja nichts. Die CPU fällt als Fehlerquelle auch aus, das RAM ebenfalls (wenn das Cartridge korrekt getestet hat). Alles, was mit Spannungen der vorgenannten potentiellen Fehlerstellen zusammenhängt müsste in diesem Fall ja auch OK sein.

    Wie gehen Profis in so einem Fall der Reihe nach vor?

    .....................................................................
    I love the smell of burnt aluminum oxide in the morning

  • Siehe Ray Carlsen: Bitte melde dich an, um diesen Link zu sehen.

    Addendum:
    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.- Bitte melde dich an, um diesen Link zu sehen.- Bitte melde dich an, um diesen Link zu sehen.
    -
    User ignorieren? AdBlock!www.forum64.de##ARTICLE[data-user-id="xxxxx"]

  • Das KERNAL-ROM ist in so einem Falle verdächtig.

    Gerrit:
    Nochmal für Elektronik-Schnulli's: Welche Chips kann man in so einem Fall als Fehlerquelle ausschließen?
    Welche TTL's kann man in diesem Fall auch ausschließen?
    Kommen die CIA's in diesem Fall auch für einen Black Out in Frage?
    Gibt es Spannungsversorgungen, die man trotzdem noch prüfen kann/sollte?

    .....................................................................
    I love the smell of burnt aluminum oxide in the morning

  • Wenn das Teil mit Deadtest läuft und ein Bild bringt sollten die Spannungen alle stimmen. Das heisst auch, daß der Bus OK ist und kein Chip da reinspuckt.

    Die PLA ist weiterhin als Fehler denkbar da mit Cartridge andere Teile benutzt werden als ohne.

    Auf das KERNAL-ROM kam ich weil das beim Deadtest durch das ROM auf der Cartridge ersetzt wird, also nicht angesprochen wird.

  • Hallo,

    Sorry, wenn ich hier noch so reinposaune..

    Ich müsste auf meinem 425er Board ebenfalls die RAMs
    erneuern, welche RAM- Chips nehmt Ihr?

    Sind diese noch zu kaufen?


    MiC