{Universal PET Motherboard} Mich erreichte eine Reparaturanfrage aus dem Altcomputerforum: ein Universal-PET-Motherboard. Die Diagnose des Besitzers wies auf sterbende 4116 hin, es ging immer weniger, am Ende ging garnichts mehr. Allerdings hatte das Teil auch bereits ersetzte defekte ROMs und einen defekten CRTC zu verzeichnen. Seltsam...

Mein 8096 zeigte sich sofort bereit, als Netzteilverleiher zu fungieren. Die Diagnose wurde bestätigt. Es geht fast nix mehr auf diesem Board. Reset geht nach 1s brav auf High. Der IRQ von den Schnittstellenbausteinen ist dauernd low - nicht gut, aber den Programmablauf sollte das nicht blockieren. Trotzdem startet die CPU nur sporadisch.

Der Datenbus ist nicht wirklich gut - ich teste die Datenausgänge der dynamischen RAMs...

Zwei der bereits getauschten RAMs sind defekt - schlechte Idee, die defekten Teile wieder in den Sockel zu stecken. Mit "neuen" RAMs sehen die Datenpegel wieder gut aus.

Bit 0 und 1 sind auch platt - ich tausche gleich beide Bänke, man kann die ja eingelötet schlecht auseinanderhalten, die Datenleitungen liegen parallel.

Die Leiterplatte ist von sehr guter Qualität, Auslöten mit Entlötpistole und moderater Heißluftfönunterstützung geht prima!

Neue RAMs beruhigen den Datenbus - das Programm läuft trotzdem nicht richtig an.

Nur als Beispiel: so muss das IRQ#-Signal an der CPU aussehen, wenn alles gut läuft.

Bei der Fehlersuche fällt mir auf, dass die ROMs nicht wirklich angesprochen werden. Es kommt kein Chip Select. Der Decoderbaustein 74154 ist völlig tot. Nach Austausch kommt endlich ein sauberes Chip Select - die CPU versucht von ROM 0xFxxx zu starten - hier liegen die Sprungvektoren für Reset , Break und Interrupt. Trotzdem: kein zuverlässiger Programmstart, keine Initialisierung.

Immerhin läuft schon mal irgendwas zyklisch. Manchmal bricht es nach wenigen ms ab - manchmal bleibt das Programm in einem stabilen Zustand...

Ich tausche konsequent alle RAMs in Bank 0.

Das hilft auch nicht, aber mir fällt auf, dass es auf dem Datenbus nicht mit rechten Dingen zugeht!

Deutlich zu sehen beim Zugriff auf ROM 0xFxxx: der Datenbus ist nicht das gesamte CS# (oberes Signal) stabil! In den letzten 500ns zwingt offensichtlich ein weiterer Busteilnehmer den Datenbus auf einen Zwischenpegel. AM ROM ligen in diesem Zeitbereich keine Pegelwechsel an. Dieser 500ns-Zeitslot wird nur vom DRAM genutzt - aber auch nicht, wenn CS# aktiv ist...

Die Schnittstellenbausteine bekommen derzeit eh keine CS# Signale und müssten stillgelegt sein. Ansonsten liegen am ungebufferten Datenbus nur die ROMs, die DRAMs und zwei Bustreiber. Der Tausch eines der Bustreiber bringt keinerlei Änderung.

Die DRAMs können auch nicht der Verursacher sein - wenn ich das Pärchen auf Bit 0 entferne, ändert sich nichts am Verhalten. Als letzte Möglichkeit entferne ich alle Schnittstellenbausteine.

Das war sehr aufwändig - aber leider erfolglos. Der Fehler ist immer noch da. Ich fange langsam an, an meinen Fähigkeiten zu zweifeln...

{Fortsetzung:} Weiter im Text: ein komplettes Abkoppeln des buffered databus hat nichts gebracht. Der Datenbus wird weiter zeitweilig doppelt verwendet. Also kann es nur was mit der CPU und dem ROM zu tun haben. Die CPU versucht auf das ROM zu schreiben.

Also Fehler im Programmablauf - vermutlich schreibt die CPU Sprungadressen in das RAM und springt dann in die Prärie... Ich entferne alles Unnötige:

...und schreibe ein aufwändiges Testprogramm direkt am Hex-Editor.

Die Sprungvektoren darf man natürlich auch nicht vergessen:

Das Ganze in ein TMS2532 gebrannt:

Und schon kann man in aller Ruhe das Verhalten der Schaltung bewundern:

In diesem Fall ist Gelb das Chip select von ROM Fxxx und Lila ein Chip Select von ROM Bxxx (der vierte LDA Befehl) Die 10µS Pause oben sind der Rücksprung auf Adresse F000. Das Programm wird erweitert: Zugriffe auf die komplette I/O, den Video-RAM (hätte ich schreiben und nicht lesen sollen - so hat's keinen Effekt...) und wichtig einmal Schreiben und Lesen im DRAM.

Die Chip Selects am CRTC 0xE880:

Und am DRAM: Schreiben und Lesen einer logischen "1" auf Adresse 0x0000.

Schreiben und Lesen einer logischen "0" auf Adresse 0x0000:

Schreiben und Lesen einer logischen "0" auf Adresse 0x0000 ohne weitere Datenbusaktivität zu diesem Zeitpunkt:

Jetzt kommt die nächste Eskalationsstufe - nachdem ich per Oszi keinen Hardwarefehler finden konnte: Testclips.

34-Bit Logikanalysator.

Und die dazu gehörige Analysesoftware. Zuerst mein Testprogramm: alle Aktionen finden sich im Datensalat wieder.

Ebenso die DRAM Schreib- und Lesezugriffe und der Rücksprung in der Programmschleife. CPU, Daten- und Adressbus und die ROMs arbeiten einwandfrei.

Jetzt prüfe ich das Verhalten mit den Original-ROMs.

Mein Verdacht bestätigt sich: die CPU versucht auf 0xE452 einen indirekt adressierten Sprung. Der Vektor steht im DRAM auf den Adressen 0x0090 und 0x0091. Dort stehen aber nur Nullen drin. Somit springt die CPU auf Adresse 0x0000 und findet dort den Befehl 0x00 - also BRK.

Offensichtlich hat die Initialisierung der Sprungvektoren im RAM nicht geklappt - entweder sind die RAMs defekt (unwahrscheinlich, weil neu), das Schreiben in dem Adressbereich klappt nicht (Adressbus-Buffer defekt) oder die RAMs vergessen Daten (Refresh-Logik defekt).

Weitere Erkenntnisse werde ich nur mit einem verbesserten Testprogramm erhalten!