Sowas sollte doch durch den Tausch der beiden RAM-Bänke leicht gegenzuprüfen sein - Es sei denn, das DRAM ist in beiden Banks 'Grütze', oder der Fehler passiert in der DRAM-Anbidung (Treiber, Muxer).
8032029 Universal Board - Fehlersuche
-
-
eher Letzteres, die DRAMs hab ich neu gemacht.
-
Jetzt kommt die nächste Eskalationsstufe - nachdem ich per Oszi keinen Hardwarefehler finden konnte:
Testclips:
Logic-Analyzer:
Opfer... äh... Patient meinte ich:
Mein Testprogramm läuft einwandfrei und findet sich im Datensalat wieder:
Und jetzt muss ich nur noch die Daten des nicht funktionierenden Programmteils interpretieren...
-
Das Ergebnis:
Code
Alles anzeigenUniversal PET Disassembly ADDR DATA E44C 10 Rest vom vorherigen Befehl E44D F0 BEQ E44E 03 +3 E44F 6C ignored --> E452 6C JMP IND E453 90 0090 E454 00 --> 0090 00 Jumpvektor im RAM 0091 00 0x0000 --> RAM nicht initialisiert! --> 0000 00 BRK --> Falsche Einsprungadresse 0001 00 ignored --> 0103 FF Write Stack SR 0102 00 Write Stack ADR H 0101 02 Write Stack ADR L --> FFFE 42 BRK-Vektor E442 FFFF E4 --> E442 48 PHA (Push Akku auf Stack) E443 8A ignored --> 0100 00 Stack Adresse --> E443 8A TXA E444 48 PHA E445 98 ignored
Eindeutig: das RAM wird nicht richtig initialisiert, ein indirekter Sprungbefehl springt nach 0x0000 und löst dann BRK aus - in einer Endlosschleife.
Aber warum wird das RAM nicht richtig initialisiert?
-
mikemcbike Welchen Logic Analyzer verwendest Du?
-
Fühle mit Dir muss mir jetzt erstmal ein paar Bier aufmachen zur Klarsicht
-
mikemcbike Welchen Logic Analyzer verwendest Du?
China LWLA34. Gibt es leider nicht mehr zu kaufen.
-
Ich habe den Fehler immer noch nicht finden können. Die RAMs verlieren offensichtlich ihre Daten, womöglich stimmt was mit dem Refresh nicht.
Die RAMs funktionieren im 8032 - die ROMs auch.
Der 8032 hat einen durchgängigen Refresh-Zyklus - alle 128 Row-Adressen werden im MHz-Takt angelegt,
Der Universal-PET hat hier eine etwas andere Schaltung: die 128 Adressen werden als Burst alle 1ms geschickt.
Die maximale Refresh-Zeit ist 2ms - sollte hier also problemlos laufen.
RAS/CAS liegt an, der Refresh-Counter läuft einwandfrei.
UE8/9/10 habe ich getauscht - funktionieren einwandfrei. Alle Leitungen zu den RAMs sind in Ordnung. Adressdaten liegen an.
UB9/10 habe ich getauscht - Datentransfer läuft ohne Probleme.
Mit edem Original-ROM habe ich den Ausstieg genau finden können:
Return from Subroutine in E1E0 holt sich die Rücksprungsdresse vom Stack im RAM (1FA und 1FB) - da steht aber Müll drin: der Prozessor springt nach A628... da ist: nix Richtiges... dann geht der Break-Interrupt in Dauerschleife los.
Ich hab langsam keine Ahnung mehr, was ich noch testen kann...
-
Ich frage mich, wieviele Logikbausteine/R‘s und C‘s noch drauf sind, die dafür in Frage kommen könnten?
Unfassbar, welch harte Nuss dieses Board ist?!
-
Das kommt mir irgendwie bekannt vor und hat mich auch schon viele Stunden gekostet...
Steht bei der Rücksprungadresse kompletter Müll drinnen oder ist es nur ein Bit-Kipper?
Ist das auch der erste Rücksprung überhaupt?
Hast Du schon mal die Zero-Page überprüft (per ROM Tester), ob die in Ordnung ist? Deine RAMs an sich scheinen ja zu funktionieren...
-
Hast Du schon mal die Zero-Page überprüft (per ROM Tester), ob die in Ordnung ist?
Ich würde's hier auch mal mit dem Diagnose Clip versuchen. Der sollte zum Beginn Zeropage und Stack prüfen. Vielleicht bringt uns das ein wenig weiter.
Ich würde folgende Fehlerquellen vermuten:
- Der Refresh greift nicht und der Speicherinhalt geht nach einer gewissen Zeit verloren.
- Der Adressen-Multiplexer arbeitet nicht korrekt und es kommt daher zum gegenseitigen Überschreiben von eigentlich durch verschiedene Adressen getrennten Speicher.
- Der Schreib- oder Lese-Pfad verstümmelt die Daten für das RAM. Immerhin werden die Buffer in anderer Richtung genutzt.
Bei den letzten beiden Punkten kann es auch die Steuersignale betreffen, welche evtl. zu wenig oder zu stark verzögert werden. Manchmal muß man da sehr genau hinsehen.
Es wäre interessant, ob die fehlerhaften Daten reproduzierbar sind.
-
Der Refresh Burst (128 RAS Adressen) liegt einwandfrei an und kommt jede Millisekunde.
Die Adress-Multiplexer liefern saubere und nachvollziehbare Signale.
Der Datenbus ist gut.
Die RAMs laufen alle in meinem CBM.
Ich analysiere jetzt mal den Stack-Inhalt beim Rücksprung.
-
Bit 6 auf der Stackpage kippt auf "0" - oder wird hier nicht richtig geschrieben. Komisches Detail: der erste Rücksprung ist korrekt, auch mit Bit 6 gesetzt...
-
Spannend
-
Das ist für mich ein déjà vu. Und irgendwann löst sich der Knoten dann
Das Bild ist nur ein Beispiel.
Auf einer ähnlichen Adresse habe ich auch gesucht, bis mir dann der Gedanke gekommen ist, mich auf die Rücksprungadressen zu konzentrieren, da dies die ersten Stellen sind, wo wieder aus dem RAM gelesen wird und man den definierten Wert weiß. (Vorausgesetzt, das ROM wird richtig durchlaufen)
Den ganzen Leidensweg habe ich in 5 Artikeln beschrieben.
PET 2001-32N, Teil 3Der PET startet nun zwar wieder, aber immer öfter kommt anstatt der Start-Meldung das interne Monitor-Programm, was meist auf einen Fehler im RAM bzw. im Stack…blog.computeum.orgIch bin leider kein Profi wie mikemcbike aber ich habe sehr viel bei dieser Reparatur gelernt.
-
Ich muss das Mistding erst mal weglegen, sonst drehe ich noch durch. Hab jetzt mindestens 10h Arbeitszeit reingesteckt - ohne Erfolg.
Jetzt zeigt die 6502 ein Verhalten, dass ich mir garnicht mehr erklären kann (auch mit anderen CPUs getestet):
An E6BF wird Y decrementiert und so lange zurückgesprungen, bis Null erreicht ist...
Diese Schleife wird nie durchbrochen - das kann doch technisch gar nicht passieren???
Was verstehe ich hier falsch? Der Rechner bleibt jetzt ewig zwischen E6BF und E6C1 hängen...
-
Ich habe mal zwei Tage lang mit dem Logikanalyzer an einer CBM3040 rumrepariert, mir sogar ein Diagnose-ROM gebaut, das nur in einem Sockel läuft.
Am Ende war es dann doch nur ein Kontaktproblem am ROM-Sockel.
-
An E6BF wird Y decrementiert und so lange zurückgesprungen, bis Null erreicht ist...
Diese Schleife wird nie durchbrochen - das kann doch technisch gar nicht passieren???Was verstehe ich hier falsch? Der Rechner bleibt jetzt ewig zwischen E6BF und E6C1 hängen...
Hängt die Kiste im Interrupt? Da habe ich auch mal ewig gesucht, bis ich bemerkt habe, dass permanent die Interrupt-Routine durchgelaufen ist. Sieh Dir mal den IRQ pin der CPU an.
-
Oh je, mein schlechtes Gewissen wird größer…
-
Oh je, mein schlechtes Gewissen wird größer…
Du immer mit deinen Herausforderungen
-
Holla die Waldfee. Ich weiß nicht warum - aber es geht weiter. Die Dauerschleife war eine Falle... die wurde schon regelmäßig verlassen, aber das sieht man in der zeitlichen Auflösung nicht.
Alle 21ms wird der Timer gesetzt. Der ist aber nicht bestückt. Jetzt habe ich den VIA 6522 mal eingesetzt. Und siehe da: der Klingelton kommt, Video-Sync ist da - aber leider kein Bild. Es geht weiter. Warum das RAM Daten verloren hat, weiß ich immer noch nicht...
-
Yeah!
Spannender wie jeder Krimi, werter Bitforensiker… ich ziehe meinen imaginären Hut vor dieser exzellenten Aufarbeitung der Todesursache.
Derrick, der Alte, Matula, der Kommissar, Schimanski- alle wären sie machtlos im Kampf gegen das böse Bit! Du hingegen strotzt den Widrigkeiten, analysierst kühl und nüchtern- mit einem wohltuenden Quentchen Emotion.
Mein erneuter Dank sei dir auf Ewig gewiss. Davon kann man nicht runterbeissen- die Seele jedoch vermag es gar vorzüglich zu erquicken!
Hochachtungsvoll,
der Tatortreiniger
-
Holla die Waldfee. Ich weiß nicht warum - aber es geht weiter. Die Dauerschleife war eine Falle... die wurde schon regelmäßig verlassen, aber das sieht man in der zeitlichen Auflösung nicht.
Alle 21ms wird der Timer gesetzt. Der ist aber nicht bestückt. Jetzt habe ich den VIA 6522 mal eingesetzt. Und siehe da: der Klingelton kommt, Video-Sync ist da - aber leider kein Bild. Es geht weiter. Warum das RAM Daten verloren hat, weiß ich immer noch nicht...
Ich meine deine Haare wären grauer geworden.. Grüße ausm Sauerland ... Du kannst selbst Regenwetter erträglich machen.
-
Bit 6 auf der Stackpage kippt auf "0" - oder wird hier nicht richtig geschrieben.
Ist vielleicht eine Durchkontaktierung im Daten-Pfad für das Bit 6 unzuverlässig und muß nachgelötet werden? Kleiner Haarriss?
Es scheint immer (schreibend und lesend) das Bit 6 des Datenbus vom vorheriegen Zyklus (ROM) erhalten zu bleiben.
-
Ist vielleicht eine Durchkontaktierung im Daten-Pfad für das Bit 6 unzuverlässig und muß nachgelötet werden? Kleiner Haarriss?
Es scheint sich um ein Kontaktproblem im Sockel gehandelt zu haben. Tritt jetzt nicht mehr auf!
-
Ich habe heute das 64k RAM Board begonnen… und was soll ich sagen- von acht ausgelöteten 4116ern waren sage und schreibe fünf defekt!
Wenn das so weitergeht… GUTE NACHT. Ich frage mich immer intensiver, was dem Rechner passiert ist? Blitzschaden? Die Spannungen sind aber alle einwandfrei.
Evtl. war am Userport oder IEEE irgendwas angeschlossen, was einen derben Defekt hatte?
Wir werden sehen, ich löte die Tage mal langsam weiter.
-
Hallo an alle!
Erstmal möchte ich mich bei Wolfgang bedanken, der mir das Board zugesendet hatte (kam heute an)... und was soll ich sagen: ICH WAR HEISS!Also heute Abend direkt mal ausgepackt und reingepfeffert in meinen 8032... aber wie auch bei Wolfgang kein wirkliches Leben. Also testmäßig mal mein UniversalRAMROM Board rein mit einem anderen CPU und siehe da: Er klingelt. Aber es kommt dann auch nach einigen Sekunden ein summen aus dem Röhrenbereich, also direkt wieder abgeschalten... Das ganze habe ich erstmal ein paar mal versucht mit ähnlichen Ergebnissen, auffällig war, dass manchmal auch kein "normales" CBM klingeln kam, sondern ein dunkleres leiseres klingeln... manchmal kurz, manchmal dauerhaft. Also in den Schaltplan rein und siehe da: Die Leitung geht an UD5 (7400, Pin3) der von der PIA und der VIA gesponsort wird. Kurz beide Pins mit dem Oszi angeschaut und den Übeltäter schon gefunden: Der 6520 in UB12 macht zicken... also raus damit und siehe da: Es kommen zumindest wirre Zeichen auf den Bildschirm.
Nochmals RAMROM Board rein und die Diagnose: Es muss wohl an den ROMs (oder zumindest in dem Bereich) liegen.
Also das Board raus und den PETTESTERV04 rein und siehe da: beide ROMs in UD09 und UD10 sind Müll, also direkt 2532er rausgekramt und gebrannt und tadaaaaa: Startbildschirm, aber ohne Cursor...
Also habe ich mir von meinem PET2001 mal kurz einen funktionierenden 6520 ausgeliehen und getestet:
Alles funktioniert wieder!Bilder folgen noch von diesem gebastel, aber das Board kann nun wieder an seinen angestammten Platz zurück, dem 3-Platinen MMF! Da kommt Freude auf!
Ich möchte mich an dieser Stelle noch bei Wolfgang mikemcbike für die tolle Vorarbeit bedanken!
Und jetzt ab in die Falle!