Reparatur C64 Teil 3: 8 neue 4164 RAM-Chips-> 38911 Basic Bytes Free

In meinem Artikel Homecomputer Commodore C64 und VC20 Hauptplatinen nackt getestet hatte ich ja festgestellt, dass der C64 leider defekt ist.

Im ersten Teil dieser Reparatur-Artikelserie stellte ich fest, dass beim Einschalten nur eine "?OUT OF MEMORY ERROR IN 0" Fehlermeldung kam samt ein paar Ausrufezeichen über den Bildschirm verteilt.

Im zweiten Artikel zur C64-RAM-Reparatur tauschte ich die 4 unteren RAM-Chips, zuständig für Datenbits D0 auf U21, D2 auf U22, D4 auf U23 und D6 auf U24 aus.

Damit war zwar der "Out of Memory in 0"-Fehler weg, aber so ganz stimmte das noch nicht:



361 Basic Bytes free. Das konnte nicht hinkommen. Das sollte eigentlich 38911 Basic Bytes free heißen. Irgendwas war da noch faul!

Inzwischen war mein Projekt "VC20/C64-Tastatur-Emulation übers WLAN" abgeschlossen. Damit kann ich jetzt Programme eingeben. Ich habe mir ein kleines Programm geschrieben, um den Speicher zu testen: 10 for i=3350 to 40959 20 poke i,0 : a=peek(i) 30 if a<>0 then ?"fehler in adr.";i;"soll=0, ist=";a 40 poke i,255 : a=peek(i) 50 if a<>255 then ?"fehler in adr.";i;"soll=255, ist=";a 60 next Das Programm schreibt in jede beschreibbare Speicherstelle des C64 mit Poke zuerst eine Null, löscht also alle Bits und liest die Speicherstelle dann mit Peek wieder aus und schaut, ob da auch wieder eine Null herauskommt, oder ein Bit auf High hängt.

Danach werden in die Speicher alle Bits gesetzt, also eine 255 geschrieben. Danach wieder gelesen. Kommt nicht wieder eine 255 heraus, dann hängt eine Speicherstelle auf High.

Falls das gelesene Byte nicht mit dem geschriebenen übereinstimmt, wird es ausgegeben. Ich bekomme folgende Ausgabe:



Das Programm gibt für einige Speicherstelle eine 2 aus. Das heißt, das hier mit Bit 1 (gezählt ab Null von rechts nach links) etwas nicht stimmt. Bit Wertigkeit 0 1 1 2 2 4 3 8 4 16 5 32 6 64 7 128 Außerdem fällt auf, dass die Fehler mit einem Abstand von einem Vielfachen von 512 auftreten.

Die verbauten 8 Stück 4164 DRAM-Chips haben ein 8Kx1 Architektur, das heißt, es gibt 8192 Speicherstellen, wovon jede ein bestimmtes Datenbits repräsentiert. Jeder 4164 ist für ein anderes Datenbit zuständig.

Bei der im Programm ausgegebenen 2 (siehe Wertigkeit in der Tabelle unten) ist dies Datenbit 1. Ein Blick auf den Schaltplan des C64



zeigt uns, dass für Datenbit D1 Der 4164-Chip auf Platinen-Platz U9 zuständig ist und das ist der Platz eines 4164, den wir noch nicht ausgetauscht haben: der erste links in der oberen Reihe.

Mit der folgenden Tabelle lässt sich ablesen, welcher Chip bei welche Programm-Ausgabe defekt ist: Ausgabe Datenbit defekter Chip auf 1 D0 U21 2 D1 U9 4 D2 U22 8 D3 U10 16 D4 U23 32 D5 U11 64 D6 U24 128 D7 U12 Das der Fehler alle 512 auftritt (und manchmal eben auch nicht), kann daran liegen, dass evtl. im Chip irgendwas nicht richtig funktioniert, wenn alle Adressbits gesetzt sind. Eventuell reicht dann der Strom nicht mehr, um das Datenbit sicher zu löschen.

Reparieren kann man den Chip ansich natürlich nicht. Da hilft nur austauschen. Nachdem die untere Reihe DRAMS ja schon gesockelt sind, beschließe ich, dass gleiche auch für die obere Reihe zu tun. Es würde zwar reichen, nur den Chip auf U9 auzutauschen, aber man kommt an die Nachbar-Chips schlechter heran, wenn dort schon ein Sockel ist. Also löte ich alle 4 oberen 4164 aus und ersetze sie durch neue.



Nun bin ich die als unzuverlässig verschrienen Micron-DRAMs los und habe alle RAM-Chips gesockelt. Falls noch einer in Zukunft kaputt gehen sollte, ist die Wartung einfach.

Doch wollen wir ertmal prüfen, ob die Fehlerursache wirklich an dem U9er-Chip lag und das alle neuen (in Fernost bestellten) Chips auch funktionieren. Zwei hätte ich ja noch als eiseren Reserve.

Beim Einschalten lese ich schon einmal erfreuliche 38911 Basic Bytes free, wie das auch sein sollte:



Und auch mein RAM-Test-Programm gibt keine Fehler mehr aus. Wunderbar. Der C64 scheint wieder korrekt zu funktionieren und repariert zu sein.

Ich überprüfe noch einmal, ob die Cartrdige Wizard of War noch alle Sekunde kurz ruckelt. Und nein, tut sie nicht, die Grafikausgabe ist jetzt durchgängig geschneidig, so wie man sich das vorstellt.

Fast erstaunlich, dass das Spiel vorher doch so gut funktionierte, da waren an den durch 512 teilbaren Speicherstelle wohl keine Daten geschrieben, bei denen das Datenbit 1 super wichtig war.

Video

Zu dem Ganzen habe ich natürlich auch wieder ein Video gemacht, dass meinen Reparaturversuch und dessen Ergebnis dokumentiert: