Contact us
Leave a message

Bitte benutzen:

Mein öffentlicher Kryptographie-Schlüssel


Mitglied bei

Ein krankes Haustier...

Eines Tages war das Furchtbare geschehen: Beim Einschalten sah mein PET gar nicht gut aus und erwachte mit dem gefürchteten "Garbled Screen"-Syndrom ("GSS")... Allerdings nur direkt nach dem Einschalten -- kurzes Aus- und wieder Anknipsen führte zu einem blanken Bildschirm. In diesem Falle wurde offenbar eine Routine zum Bildschirmlöschen ausgeführt, die auch Teil der normalen Boot-Sequenz ist (nennen wir's "Blank Screen"-Syndrom oder "BSS").

Um die Innereien des Geräts durch das häufige Ein- und Ausschalten während der Untersuchung nicht zu sehr zu belasten, hatte ich übrigens bald einen Reset-Knopf eingebaut, der bei Betätigung meist ebenfalls ein BSS zur Folge hatte.

Hirnscan

Als unschätzbares Hilfsmittel bei der Reparatur erwies sich der VICE-Emulator, der auch die PETs der 3000er-Serie emulieren kann und zu diesem Behufe auch Kernal-Images bereitstellt, die mittels des eingebauten Monitorprogramms untersucht werden können.

Um den Bildschirm zu löschen, muss das Video-RAM ($8000 - $83E7) mit dem Bildschirmcode für das Leerzeichen (32 = $20) gefüllt werden. In der Annahme, dass dies mittels einer Indexregisterschleife aus dem Akkumulator heraus geschieht, habe ich mal den ROM-Bereich von $C000 bis $FFFF nach der Bytefolge A9 20 durchsucht, was dem Opcode von LDA #$20 entspricht. Und eine der Fundstellen sah tatsächlich verdächtig nach Bildschirmlöschung aus:

e246   A9 20      LDA #$20
e248   9D 00 80   STA $8000,X
e24b   9D 00 81   STA $8100,X
e24e   9D 00 82   STA $8200,X
e251   9D 00 83   STA $8300,X
e254   CA         DEX
e255   D0 F1      BNE $E248

Dies habe ich mal als Hinweis genommen, dass das $E000-ROM prinzipiell OK ist. Auch das $F000-ROM schien soweit in Ordnung zu sein, wurde doch der RESET-Vektor, der auf die Boot-Routine verweist, aus $FFFC/$FFFD ausgelesen. Es sei verraten, dass sich letzteres als ein etwas voreiliger Schluss erweisen sollte...

Physiotherapie

Als eine der ersten Maßnahmen bei Auftreten des GSS empfiehlt die Allwissende Müllhalde das Herausnehmen und Wiedereinsetzen aller gesockelten Chps. In meinem Falle waren das die CPU, die beiden PIAs, die VIA und die vier ROMs bei $C000, $D000, $E000 und $F000. Aber leider war damit keine Besserung zu erzielen.

Taktvolle Untersuchung

Als nächstes wurde der 6502-Prozessor Pin für Pin mit einem eigens angeschafften Logik-Tester, der nicht nur L- und H-Pegel, sondern auch Pegelwechsel detektieren konnte, untersucht. Dabei wurden folgende Beobachtungen gemacht:

  • Beim Einschalten -- egal ob erstmalig oder nach kurzem Ausschalten -- ging die RESET-Leitung brav kurz auf L, um nach ein, zwei Sekunden wieder auf H zu gehen.
  • Ein- und ausgehende Taktleitungen (Phi0, Phi1, Phi2) waren in jedem Fall gepulst -- Herzschlag war also vorhanden.
  • Bei Auftreten des GSS verharrten alle Address- und Datenleitungen sowie R/W nach kurzer Pulsphase auf einem konstanten Wert (alle auf H bis auf D0, D3 und D4); beim BSS blieben alle Leitungen pegelaktiv. (Die GSS-Werte entsprechen übrigens exakt einer Leseoperation aus $FFFF!)
  • Die IRQ-Leitung blieb konstant auf einem Pegel stehen -- statt, wie erwartet, 60 Mal pro Sekunde kurz auf L zu gehen.

Konsultation von Kollegen

Bei meiner Web-Recherche zur weiteren Vorgehensweis stieß ich auf dasVintage Computer Forum, in dem offenbar sehr kompetent diskutiert, diagnostiziert und therapiert wurde. Der Thread "PET got seriously ill..." dokumentiert die konstruktive, hilfsbereite Stimmung in diesem Kleinod der Laberlisten im unendlichen Netz.

Spannende Sache

So wurde mir also geraten, mal die Stromversorgung zu überprüfen. Mit Hlfe der Schaltpläne (und lieben Hinweisen aus dem Forum) waren die Testpunkte 5, 6 und 10 schnell auf dem Board gefunden und vermessen -- direkt nach dem Einschalten entsprachen die Spannungen recht gut den Sollwerten (5, 12 und -5 V), doch nach einiger Zeit stiegen die Absolutbeträge deutlich an (ca. 9, 20 und -9 V nach 2 Stunden). Was zunächst wie ein Problem mit der Stromversorgung aussah, enpuppte sich auch tatsächlich als solches -- jedoch nicht des PETs, sondern des Multimeters, das ich verwendet hatte. Als ich -- auf Vorschlag eines Forenmitglieds -- mal die Batterien austauschte, blieben die Werte auch nach längerem Betrieb so, wie sie sein sollten. Da muss man erstmal drauf kommen...!

Später erwies sich übrigens auch der Spannungsregler VR3, den durchzumessen mir empfohlen wurde, mit seinen 5 V ebenfalls als in Ordnung.

Transplantationsversuche

Als nächstes wollte ich mir nochmal die Ein-/Ausgabebausteine näher ansehen -- unter anderem, um dem fehlenden IRQ auf die Spur zu kommen. Dieses wird im PET zwar eigentlich primär von den Videoschaltkreisen erzeugt, in der PIA1 aber in ein ordentliches Digitalsignal umgewandelt. Laut Logiktester tat sich auch tatsächlich was auf der "VIDEO ON"-Leitung, aber Fehlanzeige bei den IRQ-Ausgängen der PIA. Überhaupt schienen an den PIA1-Pins eher seltsame Pegel anzuliegen, die mir nicht recht zu ihren Funktionen (u. a. Tastaturabfrage) zu passen schienen. (Details sind im Forenthread nachzulesen.) Offenbar wurde die PIA nicht ordentlich initialisiert -- was weiter zur Hypothese eines unvollständigen Bootvorgangs passen würde.

Um Probleme mit defekten Chips zu minimieren, habe ich noch die VIA- und 6502-ICs gegen die entsprechenden (und glücklicherweise: gesockelten) Teile eines funktionstüchtigen 1541-Diskettenlaufwerks ausgetauscht. Beide Geräte liefen nach dem Austausch wie zuvor (oder, im Falle des PET, eben nicht), so dass das Problem offenbar nicht bei diesen beiden Chips lag. (Hut ab vor der Robustheit der MOS-Chips -- die 6502 hat mir nicht mal übel genommen, dass ich sie einmal versehentlich verkehrt herum in die Floppy eingebaut habe...)

Diagnosevorsprung durch Technik

Da die vorhandenen Apparate offenbar nicht ausreichten, um eine detailierte Diagnose zu stellen, wurde über ein bekanntes Internet-Auktionshaus eigens ein (gebrauchtes) Oszilloskop angeschafft. Als erstes erfolgte eine Vermessung der verschiedenen Taktsignale am Prozessor, die dann auch recht merkwürdige Oszillogramme lieferten. Zum Beispiel habe ich mir den Eingangstakt (Phi0, links) eigentlich immer als Rechtecksignal vorgestellt -- nicht als etwas, das gerne auch mal die definierten TTL-Pegelbereiche (rechts) verlässt...

Auch die beiden vom Prozessor erzeugten Halbtakte Phi1 und Phi2 (rechts einer der beiden -- ich weiß nicht mehr welcher, aber sie sahen sowieso praktisch identisch aus) wiesen -- zumindest für meine Begriffe -- recht merkwürdige, küchenmesserschneidenartige Wellenformen auf. Andere Haustierbesitzer aus dem Forum haben mir jedoch bestätigt, dass all diese Signale bei ihren gesunden Oldtimern genau so aussahen wie bei meinem kranken PET.

Interessant waren auch die Oszillogramme der Daten- und Adressleitungen sowie das R/W-Signal, das rechts dargestellt ist. Wenn der PET im BSS landete, schienen all diese Leitungen ebenfalls ein periodisches Signal anliegen zu haben -- und zwar mit einer ziemlich kurzer Periodenlänge von etwa 70 Mikrosekunden. Es sei verraten, dass dieses Phänomen später eine plausible Erklärung bekommen sollte.

Künstliches Koma

Nun hat die 6502-CPU einen sehr nützlichen Eingang namens READY, der, wenn auf L heruntergezogen, den Prozessor anhält. Dies machte ich mir (unter Zuhilfenahme des L-Pegels vom GND des internen Cassettenports) zunutze, um mittels des Logik-Testers einfach mal Leitung für Leitung auszulesen, was den so am Adressbus passiert, wenn der Rechner im BSS verharrt. Ich las vor allem Adressen wie $E61E, $E620, $E621 und $E624 -- die alle im IRQ-Handler (ab $E61B) liegen, der wie folgt aussieht:

e61b   48         PHA         ; save A, X and Y on stack
e61c   8A         TXA
e61d   48         PHA
e61e   98         TYA
e61f   48         PHA
e620   BA         TSX         ; get stack pointer
e621   BD 04 01   LDA $0104,X ; get status register from stack
e624   29 10      AND #$10    ; check for break flag
e626   F0 03      BEQ $E62B   ; no break: skip next instruction
e628   6C 92 00   JMP ($0092) ;   handle BRK
e62b   6C 90 00   JMP ($0090) ; handle hardware interrupt

Die in den indirekt adressierten JMP-Befehlen verwendeten Zeropage-Adressen $0090 und $0092 stellen die Sprungvektoren zum Hardware-IRQ- bzw. BRK-Handler dar und zeigen üblicherweise auf $E62E bzw. $FD17.

In-vitro-Experimente

Da ich mir bisher noch keinen Reim auf die beobachteten Symptome machen konnte, beschloss ich, mir die ROMs mal genauer anzusehen. Mangels eines Lesegerätes wich ich dabei auf eine manuelle Lösung unter Verwendung eines Steckbretts aus: Einzelne Adressen wurden durch Anlegen entsprechender Pegel an die Adresspins des ROM-ICs ausgewählt und der Inhalt der jeweiligen Speicherzelle per Logik-Tester ausgelesen. Da ich keine Lust hatte, über zehntausend Adressen durch händisches Umstecken von Kabelbrücken auszuwählen, habe ich mich zunächst bei jedem ROM auf die (relativen) Adressen $000, $001, $002, $004, $008, $010, $020, $040, $080, $100, $200, $400 und $0800 beschränkt, so dass wenigstens jede Adressleitung einmal auf H war. (Anmerkung: Das $E000- oder Editor-ROM ist mit 2 kB nur halb so groß wie die anderen ROMs, so dass hier nur bis $0400 getestet werden musste. In die andere Hälfte der $E000-Seite wird beim PET der I/O-Bereich eingeblendet.)

Unten bin ich gerade beim Auslesen von Bit 5 (links) und Bit 6 (rechts) aus der ersten ($000) Zelle des $C000-ROMS zu sehen -- es wird sehr schön deutlich, dass hier (erwartungsgemäß, laut VICE-Kernal-Image) die Werte 0 (L) bzw. 1 (H) drinstehen:

Es war schon eine Erleichterung zu sehen, dass das $C000-, $D000- und $E000-ROM in den ausgewählten Beispieladressen offenbar die korrekten Daten enthielten. Spannend wurde es bem $F000-ROM -- hier zeigte sich gleich bei der ersten Adresse, dass hier nicht mehr das drin war, was drin zu sein hatte: ich las eine 0 statt der erwarteten $54. Tatsächlich waren die ersten 8 Zellen ($000 - $007) "genullt", danach schien für weitere 8 Zellen ($008 - $00F) wieder alles in Ordnung. Weitere Stichproben ließen vermuten, dass sich dieses Muster (8 Nullen, 8 Treffer) im Großen und Ganzen über den gesamten Adressbereich des Bausteins wiederholte -- mit einigen zusätzlichen Fehlstellen.

Elektroätiologie

Nun versuchte ich zu rekonstruieren, was genau beim Booten des PETs schief lief, so dass es zum GSS bzw. BSS kam. Zu diesem Zweck richtete ich mein Augenmerk zunächst auf die letzten Speicherzellen des Adressraums (und damit auf die letzten Zellen des defekten $F000-ROMs), die beim 6502 immer den RESET- ($FFFC/$FFFD) und den IRQ-Vektor ($FFFE/$FFFF) enthalten. Ersterer sollte auf $FCD1 zeigen und letzterer auf $E61B -- was auch in meinem defekten ROM noch der Falll war.

Auslesen der ersten paar Bytes der RESET-Routine lieferten nun noch eine Überraschung: Nicht nur, dass dort falsche Werte gespeichert waren -- nein, mehrfaches Auslesen der selben Adresse ergab z. T. sogar veränderliche Werte. Zumindest ca. 30 Sekunden lang nach Einschalten der Stromversorgung des Chips -- wobei tendenziell anfangs eher Werte mit vielen, später Werte mit wenigen gesetzten Bits gefunden wurden.

Und damit ergab sich folgende Erklärung für das Entstehen des GSS bzw. BSS:

  • Es erscheint plausibel, dass die CPU beim Arbarbeiten des fehlerbehafteten RESET-Codes früher oder später auf eine ungültige Instruktion trifft -- ein Klemmen der CPU (oder wie sonst sollte man CPU-Jam übersetzen?) wäre die Folge, was in Einkläng stünde mit der oben beschriebenen Beobachtung, dass beim GSS jegliche Busaktivität zum erliegen kommt.
  • Wird einige Zeit nach dem Einschalten ein Reset durchgeführt, könnten einige der Zellen in der RESET-Routine einen Nullwert erreicht haben, also BRK-Anweisungen darstellen, was zum Ansprung der IRQ-Routine führen würde. Diese befindet sich, wie oben erwähnt, an der Adresse $E61B, also in einem intakten ROM-Baustein. In der Routine wird der BRK als Auslöser des Interrupt-Requests identifiziert werden, was in $E628 zu einer Verzweigung nach $FD17 (dem Inhalt von $0092) führt. Und hier kommt der Clou:

Manuelles Auslesen von $FD17 brachte eine neue 0 zutage -- also eine BRK-Instruktion, die zu einem erneuten Interrupt-Request führt, der über den BRK-Vektor zu $FD17 überleitet, wo eine 0 steht -- also eine BRK-Instruktion, die zu einem erneuten Interrupt-Request führt, der über den BRK-Vektor zu $FD17 überleitet, wo eine 0 steht -- also eine BRK-Instruktion, die zu einem erneuten Interrupt-Request führt, der über den BRK-Vektor zu $FD17 überleitet, wo eine 0 steht -- also eine BRK-Instruktion, die zu einem erneuten Interrupt-Request führt, der über den BRK-Vektor zu $FD17 überleitet, wo eine 0 steht...

...und dieser Teufelskreis passt ganz wunderbar zum beobachteten repetitiven Muster auf der R/W-Leitung: Bei einem BRK werden zunächst die beiden Bytes des Programmzählers, dann das Prozessorstatusregister auf den Stack geschreiben (erste, längere L-Phase). Sodann werden im Interrupt-Handler über drei PHA-Befehle noch der Akkumulator sowie die beiden Indexregister auf den Stack geschoben (die drei kürzeren L-Impulse). Dann erfolgt zunächst keine weitere Schreiboperation, bis (fälschlicherweise) der nächste BRK ausgelöst wird.

Eine Prothese muss her

Nachdem nun der Übeltäter identifiziert war, musste irgendwie Ersatz her. Glücklicherweise konnte mir Christian mit einem EPROM-Brenner und -Löscher sowie einer Hand voll gebrauchter EPROMs aushelfen. Da sich darunter jedoch leider weder ein 2532 noch ein 2732 fand, griff ich auf ein 8 kB großes 27C64 zurück, das mit einem Quick-and-dirty-Adapter zur Pinkompatibilität gezwungen wurde.

Und damit war mein PET wieder fast der Alte! :-)

Es bleibt fast keine Narbe zurück

Der krönende Abschluss der Therapie war jedoch das freundliche Angebot von Dave M. aus dem Forum, mir ein 2532er-EPROM zu brennen und aus dem sonnigen Kaliforniern zuzuschicken -- was er auch prompt getan hat. Und damit will ich's gut sein lassen -- es sei denn, jemand möchte mir noch ein Original-ROM schenken... ;-)