8032029 Universal Board - Fehlersuche

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).

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:

Universal 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

Zitat von jobi23

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...

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...

Zitat von jobi23

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 3

Der 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.org

Ich 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.

Zitat von mikemcbike

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.

Zitat von CBM_Ba

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...

Zitat von mikemcbike

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.

Zitat von mikemcbike

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.

Zitat von HofMar

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!

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!