C64 mit vermutlich defektem RAM - Reparaturvorschläge ?

Overdoc · 12. März 2018

Hallo an alle Hardware Gurus,

Jetzt muss ich auch mal hier im Forum um Hilfe bei einer Reparatur fragen.
Hab hier einen Brotkasten (ASSY 250407), welcher vermutlich ein RAM-Problem hat:

- Startbildschirm ist zu 99% normal (38911 Bytes free, nur ein einziges mal startete er mit nur 254 Bytes free)
- längere Programme stürzen meist ab (schon beim de-crunchen), kürzere laufen meist.
- Cartridges funktionieren ebenfalls meist. (brauchen ja auch nicht viel RAM) Manchmal fehlt aber der Sound, (z.b. bei Kickman), oder es sind Grafikfehler zu sehen (z.b. beim Soulless Intro)
- RAMs huckepack aufklippen bringt keine Änderung
- ebenso keine Verschlechterung oder Verbesserung (schön wärs ) nach längerer Laufzeit mit Wärmeentwicklung
- Dead Test Cartridge meldet keine Fehler (RAM wird auch nach 1h Laufzeit und zig Durchläufen als OK erkannt)
- Den Speicher abwechselnd mit '$00 und '$FF füllen und wieder auslesen klappt immer (mit einem kleinen Basic Programm). Auch ein anderes RAM-Test Tool zeigt an daß alles OK wäre.

Bin leider noch nicht dazugekommen mein Check-64 zusammenzubasteln, denn da wäre ja auch ein etwas intensiverer RAM-Test dabei, als es z.b. das Dead-Test Cartridge macht.
Werd mir aber ein Ultimax-Cartridge herrichten und das Test-Cartridge darauf mal laufen lassen.

Interessant wäre auch ab wo der Start-Up RAM-Test zu zählen beginnt? Wenn 254 Bytes free gemeldet wird, heißt das dann daß der Fehler auf Adresse $08FE bzw. 2302 (2048 + 254) aufgetreten ist?
Und kann man sich von irgendwo noch den Wert auslesen, welcher falsch gelesen wurde, sodass ich einen Hinweis bekomme welches Bit auf dieser Adresse umgefallen ist?

Falls noch jemand Ideen hat wie ich am besten feststellen könnte welcher RAM (oder sonst was?!) defekt ist, bin ich für jeden Vorschlag dankbar
Möchte es mir wenn möglich ersparen auf gut Glück 8 RAMs und evtl. noch die 2 Multiplexer auszulöten....

Günni74 · 12. März 2018

Ich hatte vor ca. zwei Jahren auch ein ASSY-250407-Board mit ähnlichen Symptomen.
Soweit ich mich erinnern kann, war die PLA defekt. Nur kleinere Dateien funktionierten meistens problemlos, größere haben sich aufgehängt, bzw. Grafik mit Fehlern.

kinzi · 12. März 2018

Zitat von Overdoc

Dead Test Cartridge meldet keine Fehler (RAM wird auch nach 1h Laufzeit und zig Durchläufen als OK erkannt)

Vorsicht: "Dead Test" testet nur die ersten 4 K RAM des C64! (Systembedingt, im Ultimax-Mode sind nicht mehr verfügbar). Die Aussage von Dead Test ist für dich also eher wertlos.

Beim Check64 wäre der "Ultimax RAM Tester" von GIJoe dabei, der lässt sich umschalten nach dem initialen Test und testet das ganze RAM. Ansonsten hat Mac Bacon einen kleinen RAM-Test hier irgendwo mal veröffentlicht, der im Screen-RAM läuft. Der ist so klein, den könntest du sogar abtippen.

[EDIT]

C64-ULTIMAX-RAM-TESTER im Selbstbau - kleine Bauanleitung für ein Wochenendprojekt

Minimales Speichertestprogramm

[/EDIT]

Mac Bacon · 12. März 2018

Zitat von Overdoc

Interessant wäre auch ab wo der Start-Up RAM-Test zu zählen beginnt? Wenn 254 Bytes free gemeldet wird, heißt das dann daß der Fehler auf Adresse $08FE bzw. 2302 (2048 + 254) aufgetreten ist?
Und kann man sich von irgendwo noch den Wert auslesen, welcher falsch gelesen wurde, sodass ich einen Hinweis bekomme welches Bit auf dieser Adresse umgefallen ist?

$0801 plus die "BASIC BYTES FREE"-Anzeige ergibt die Speicherstelle, bei der der Test fehlschlug. Im Normalfall eben 2049 + 38911 = 40960, eben das erste Byte des Basic-ROMs. Wenn bei Dir 254 Bytes free angezeigt werden, wäre also $801 + $fe = $8ff = 2303 karpott.
Welche Bits darin umgekippt sind, kann man dann per POKE+PEEK testen (einmal mit Null und einmal mit 255) - natürlich nur unter der Voraussetzung, dass die vom Basic benutzten Teile der Zeropage und des Systembereichs ok sind.

Overdoc · 12. März 2018

Danke mal soweit an euch alle!

Daß das Dead Test Cartridge nicht vollständig prüft hab ich schon gewußt, aber danke für die Erklärung mit dem Ultimax Mode - jetzt macht es auch Sinn warum nicht mehr als 4K getestet werden

Werde mal MacBacon's Proggy laufen lassen, und wenn das nichts bringt dann evtl. GIJoe's Ramtester auf ein Eprom in einem Ultimax Mode Cartridge brennen.
Besser wärs aber wenn ich endlich mal mein Check 64 zusammenbaue....da hätte ich ja dann neben dem Dead Test Cartridge auch den GIJoe RAM-Test, und auch noch das Diagnose Modul dazu....
Ansonsten hätt ich noch ein RAM-Test Kernal-Eprom, allerdings ist bei der defekten Kiste das Kernal eingelötet, und bin zu faul es extra dafür auszulöten

Achja, PLA kann ich ausschließen, die ist gesockelt und hab ich schon in anderen Rechnern getestet, bzw. auch andere PLAs in der kaputten Kiste - macht keinen Unterschied.

Danke auch für den Hinweis mit $0801, wusste nicht ob von $0800 oder $0801 an gezählt wird.

Melde mich morgen wieder falls sich neue Erkenntnisse ergeben haben

kinzi · 12. März 2018

Du musst ja das Check64 gar nicht komplett zusammenbauen. Der Ultimax RAM Checker benötigt nur das EPROM und das Mäuseklavier, wenn ich das richtig im Kopf habe. Es muss ja nur das EPROM ansprechbar sein und mit dem Mäuseklavier stellst du die Konfig ein.

Das ganze andere Gedöns kannst du ja nachträglich bestücken.

So als Tipp von faulem Hund zu faulem Hund.

Overdoc · 12. März 2018

So, kurzer Ergebnisbericht:

MacBacon's RAM-Test läuft kurz an, man sieht daß sich die Speicherstellen 1025, 1060 und 1077 für ca. eine Sekunde ändern, hinter dem Proggy füllt sich der Bildschrim mit '@'
Anschließend füllt sich Speicherzelle 1026 bis 1056 mit '@', und das Proggy stürzt ab.
1024 zeigt dann ein '@', 1025 ein 'v', 1060 ein 'D', und 1077 ein 'D'.

KBR's RAM-Test läuft durch und liefert die Werte: 55, AA, FF, 00.
Das selbe kommt allerdings auch auf meinem funktionierenden 64er raus - scheint den Fehler also nicht zu erkennen?!

Mac Bacon · 13. März 2018

Zitat von Overdoc

MacBacon's RAM-Test läuft kurz an, man sieht daß sich die Speicherstellen 1025, 1060 und 1077 für ca. eine Sekunde ändern, hinter dem Proggy füllt sich der Bildschrim mit '@'
Anschließend füllt sich Speicherzelle 1026 bis 1056 mit '@', und das Proggy stürzt ab.
1024 zeigt dann ein '@', 1025 ein 'v', 1060 ein 'D', und 1077 ein 'D'.

Das heißt, dass das Programm sich selbst überschrieben hat. Mögliche Gründe:
1. etwas stimmt nicht mit der Adressierung
2. es liegt ein Speicherfehler in den ersten beiden Bildschirmzeilen vor (der den Programmcode verändert)
3. die CPU ist defekt

Möglichkeit 3 ließe sich durch Test der CPU in einem anderen Rechner testen, ist aber eher unwahrscheinlich. Möglichkeit 2 kannst Du testen, indem Du das Programm ab $500, $600 oder $700 laufen lässt (siehe Post #64 in dem Thread für die Binaries).
Ich tippe aber auf Möglichkeit 1: Waren die beiden "D" wirklich Großbuchstaben? Und der Screen immer noch im Groß/Kleinbuchstabenmodus? Dann hätte das Programm nämlich sich selbst ab $0400 überschrieben, obwohl die Befehle auf $4400 zugreifen wollten -> damit wäre dann Adressleitung A14 verdächtig.
Gib mal im Direktmodus POKE17408,IRGENDWAS ein - wenn sich daraufhin an der HOME-Position etwas tut, wäre das eine Bestätigung. Allerdings scheint mir der Fehler sporadischer Natur zu sein, auch wegen der oben erwähnten "254 Bytes free".

Parser · 13. März 2018

Zitat von Mac Bacon

1. etwas stimmt nicht mit der Adressierung

... ggf. Multiplexer?

... hier gibt es noch eine .d64 (RAMTEST):

ART - DAS Speichertestprogramm für den C64

Overdoc · 13. März 2018

Hab die Kiste gestern spät abends dann mal eine Weile laufen lassen, und die RAM-Tests wiederholt, worauf sich folgendes getan hat:

- nach dem Start vereinzelt '1' und '@' am Bildschirm zu sehen
- KBR RAM-Test zeigt mehrere Fehler an, teilweise wird beim 'ERROR AT....' ein 'Q' statt einem 'A' und ein 'D' statt einem 'T' angezeigt.
Scheint also nach längerem Laufen schlimmmer zu werden.

Fazit:
@ statt Space: Bit 5
1 statt Space: Bit 0 und 4
Q statt A: Bit 4
D statt T: Bit 4

Glaube aber nicht daß jetzt gleich 3 RAMs defekt sind?! Obwohl es natürlich möglich wäre....?

Nachdem ich aber ähnliche dubiose RAM-Fehler auch schon mal wegen eines schlecht eingelöteten PLA Sockels hatte (PLA selbst ist ok, die hab ich geprüft), werd ich mir mal den Sockel der PLA anschaun, messen, und nachlöten. Die war bei diesem 64er schon von jemandem gesockelt wie ich ihn bekommen hab.

Wenn bei der PLA alles ok ist, dann werd ich die Multiplexer mal tauschen, bevor ich mich an die RAMs mache. (werde dann auch noch vorher nach längerer Laufzeit den von MacBacon vorgeschlagenen Adressierungs-Check via POKE machen )
Muss morgen mal schaun, evtl. sind es ja die berüchtigten MOS 7708 Multiplexer Varianten?!

Gerrit · 13. März 2018

Zitat von Overdoc

Glaube aber nicht daß jetzt gleich 3 RAMs defekt sind?! Obwohl es natürlich möglich wäre....?

Wenn die verbauten RAMs zufällig vom Typ MT4264-20 sind, dann ist das sehr wohl möglich. Die MT4264-15 sind weniger anfällig, aber trotzdem problematisch. Micron hatte damals keine glückliche Hand bei RAMs.

Overdoc · 14. März 2018

Hab gestern noch kurz nachgeschaut:
RAMs sind vom Typ TMS 4164, also kein MT Multiplexer sind 74LS257, keine MOS 7708

Komm leider erst am WE wieder dazu an der Kiste weiterzuwerken, und werd mir dann als erstes mal den PLA Sockel vornehmen.
Anschließend wäre mein Plan mal einen der evtl. defekten RAMs auszutauschen. Wenn dann immer noch die selben Bitfehler auftreten, dann wird es vermutlich nicht an den RAMs, sondern an einem der Multiplexer liegen?

Gerrit · 14. März 2018

Zitat von Overdoc

TMS 4164

Von denen hatte ich auch schon defekte, aber längst nicht soviele wie von den MTs.

Zitat von Overdoc

Wenn dann immer noch die selben Bitfehler auftreten, dann wird es vermutlich nicht an den RAMs, sondern an einem der Multiplexer liegen?

Nein, denn im Bezug auf die Multiplexer sind alle RAMs parallel geschaltet, da müsstest du mit allen Probleme gemeldet bekommen. Wechsel erst die jetzt verdächtigen RAMs und dann teste nochmal. Ich würde mit Bit4 anfangen, das ist U23, dann noch einmal testen. Bit 5 ist U11 und Bit 0 ist U21.

Parser · 14. März 2018

Zitat von Overdoc

Anschließend wäre mein Plan mal einen der evtl. defekten RAMs auszutauschen. Wenn dann immer noch die selben Bitfehler auftreten, dann wird es vermutlich nicht an den RAMs, sondern an einem der Multiplexer liegen?

... frage mal @Goethe ... das Thema haben wir auch schon durch ... im Ergebnis 8 gesockelte RAMs ... am Ende war es der Multiplexer ... das DEAD TEST Cartridge hat uns da schön im Stich gelassen ... da hilft nur messen ... nicht wahr @axorp?

Also ... nicht unbedacht einfach Draufloslöten ... tut dem Board nicht gut.

CommieSurfer · 14. März 2018

Das riecht für mich auch nach einem anderen Fehler, dieses variable darin, als dass es ein oder mehrere Rams seien. Nur so wenn ich 'mal wieder mein Gefühl spielen lasse (ok, etwas gepaart mit deinen Einschätzungen).
Ich hatte sowas ähnliches mit hängen bleibenden Chars u. noch gröbere Fehler+Abstürze bei größeren Dateisachen auch schonmal bei einem zu leistungsschwach gewordenen Netzteil (auch auf nicht nur einem Board.., jedoch bei einem davon nur bei zwei Demos). Nach dem Tausch war's wie weggeblasen. Elkos (im Cevi, bei z.B. Amiga NTs sowieso) tauschen schadet in diesem Zusammenhang btw. auch nicht, haha .

Defekte Ram ICs werden auch gerne 'mal warm (wärmer als die funzenden) bis heiß*, war bei mir bisher immer so. Das also auch 'mal prüfen.
*Vor allem die Ram Typen ab der 466er, 469er Platine (mit den nur noch zwei Ram ICs).

Gerrit · 14. März 2018

Zitat von CommieSurfer

Defekte Ram ICs werden auch gerne 'mal warm (wärmer als die funzenden) bis heiß*, war bei mir bisher immer so. Das also auch 'mal prüfen.

Ein RAM mit diesem Fehler hat eine Kernschmelze und funktioniert gar nicht mehr. Da bleibt der Monitor beim Einschalten schwarz.

CommieSurfer · 14. März 2018

Bei einem heißen Ram vlt., ja (so wie hier bei ein paar defekt erstandenen 466er Platinen das der Fall war). Ein defektes (in einem 8 Ram Board) kann aber sicher auch schonmal ungewöhnlich wärmer als normal werden, bei dennoch startendem Rechner. Muss natürlich nicht.

axorp · 14. März 2018

Zitat von Parser

... frage mal @Goethe ... das Thema haben wir auch schon durch ... im Ergebnis 8 gesockelte RAMs ... am Ende war es der Multiplexer ... das DEAD TEST Cartridge hat uns da schön im Stich gelassen ... da hilft nur messen ... nicht wahr axorp?

ja

Zitat von Parser

Also ... nicht unbedacht einfach Draufloslöten ... tut dem Board nicht gut.

ja

Overdoc · 15. März 2018

@'Gerrit:
Korrekt, ein Defekt im Mulitplexer müsste sich auf alle auswirken.

CommieSurfer:
Habe die Kiste an einem umgebauten C128 Netzteil laufen, welches mit anderen C64 keinerlei Probleme macht. Die 5V scheinen auch stabil zu sein, aber um sicher zu gehen dass der Spannungsregler und Elkos im C64 auch ok sind, müsste ich eine Langzeit-Aufzeichnung mit einem Speicheroszi machen (welches ich ned hab )

@Parser:
Löten ist prinzipiell kein Problem, hab hunderte 64er, 1541, VC20 usw. wieder zum Leben erweckt.
Möchte nur den Aufwand so klein wie möglich halten....

Irgendwie hab ich leider auch das Gefühl daß es nicht 3 RAMs auf einmal erwischt haben wird. Außerdem sieht man in solchen Fällen meist via Huckepack draufstecken irgendeine Veränderung, welche hier aber nicht stattfindet.
Wie gesagt, mein Hauptverdächtiger ist der PLA Sockel, weil ich schon einmal exakt so einen Fall hatte (RAM Fehler nach Erwärmung, mehrere Bits betroffen, immer unterschiedliche), wo es daran lag.

Werde am WE berichten....

kinzi · 15. März 2018

Zitat von Overdoc

Wie gesagt, mein Hauptverdächtiger ist der PLA Sockel,

Dass die PLA Auswirkungen auf einzelne Bits im RAM haben soll (und alles andere - Ultimax-Mode, usw. - aber trotzdem einwandfrei funktioniert) halte ich für äußerst unwahrscheinlich. Wenn defekte Bits auftreten, würde ich zuerst bei den RAMs suchen. Frei nach dem Motto: "Wenn du Hufgetrappel hörst, denk an Pferde, nicht Zebras."

Wenn du dir nicht zu viel Arbeit antun willst, löte halt nur ein RAM aus, sockle es, tausche es testweise und mach den Test nochmals. Dann müsste ja ein kaputtes Bit weniger vorhanden sein.

[EDIT]

An der PLA liegen die Datenbusleitungen übrigens überhaupt nicht an. Ich kann mir im Moment nicht vorstellen, wie der PLA-Sockel hier was beeinflussen soll. Wenn er RAS, CAS oder eine andere Steuerleitung beeinflussen würde, wäre der Effekt meiner Meinung nach viel häufiger zu spüren, als durch ein paar defekte Bits.

[/EDIT]

Tags