"Red herrings" sind falsche Fährten.
Ich werde öfter gefragt: Wie würdest Du diesen oder jenen Fehler suchen und beheben? Da ich heute ein Problem in meinem 1040STE lösen musste, schreibe ich meine Gedanken und Versuche unten auf. Ich finde, sie sind lehrreich, gerade weil ich diverse Dinge probieren musste, bevor ich die wahre Ursache gefunden habe.
Mein 1040STE wollte heute nicht booten. Nach dem Atari-Logo (er startet unter TOS 2.06) aber noch vor dem Beginn des Speichertests war Schluss, mit einer wechselnden Anzahl an Bomben. Wahrscheinlich RAM, dachte ich zuerst. Die SIMMs in den Rechner haben verzinnte Kontakte, die offensichtlich mit der Zeit korrodieren. Das kenne ich bereits. SIMMs raus und wieder rein oder Kontakte reinigen hilft. Also das Diagnose-Cartridge für den STE genommen, doch der RAM-Test lief ohne Fehler durch. Falsche Fährte Nr. 1.
Dann fiel mir auf, dass der Absturz immer zusammen mit dem ersten Zugriff auf die Floppy auftrat. Aha, das Netzteil gibt langsam den Geist auf, dachte ich. Das Netzteil im 1040STE ist noch original und wenn das Floppylaufwerk anläuft, zieht der Rechner erheblich mehr Strom. Ich habe einen Adapter, um STFs/STEs aus meinem Labornetzteil zu versorgen. Eingebaut, Absturz nicht behoben. Falsche Fährte Nr. 2.
Also zurück zum Diagnose-Cartridge. Tatsächlich, auch dort kam es bei Floppy-Tests zu schweren Fehlern: Bus-Error oder „bad instruction fetch“. Da befürchtete ich, dass etwas Schwerwiegenderes kaputt war, sah mich schon Floppy-Controller oder DMA-IC auslöten. Das sollte falsche Fährte Nr. 3 sein, wie sich später herausstellte.
Gegentest: Floppy-Laufwerk abgeklemmt. Nun kommt der Rechner problemlos über den Speichertest beim Booten. Danach 4 Bomben, aber das ist der bekannte Bug in TOS 2.06, wenn kein Laufwerk angeschlossen ist. Kein Hardwarefehler und auch keine falsche Fährte, denn das wusste ich ja zum Glück.
Bevor ich mich an die Ersatzteilsuche machen wollte, wollte ich aber noch sehen, was EmuTOS zu der Sache zu sagen hat. Mein STE hat ein per Software umschaltbares TOS; was natürlich schwierig ist, wenn er gar nicht so weit bootet, dass ich überhaupt Software starten könnte. Zum Glück kann man mit dem Diagnose-Cartridge (Menüpunkt „Examine Memory“) auch auf beliebige Speicherstellen bzw. Register schreiben und so konnte ich manuell den Befehl einhacken, mit dem mein STE auf EmuTOS umschaltet.
Mit angeschlossenem Floppy-Laufwerk stürzte EmuTOS auch ganz früh ab, noch vor dem Willkommensbildschirm und mit einer unleserlichen Fehlermeldung. Mit abgestecktem Laufwerk kam es bis zum Desktop (hurra!), um dann dort mit einem Bus-Error abzustürzen – dieses Mal aber mit leserlicher Fehlermeldung. Zuerst dachte ich, dass offenbar noch mehr kaputt war. Bei genauer Betrachtung des Fehlers fiel mir jedoch auf, dass EmuTOS hier bei einem Blitter(!)-Zugriff abstürzte.
Da hat es Klick gemacht: Was ist die Gemeinsamkeit zwischen Floppy/DMA und Blitter? Beide können den Bus übernehmen, um ohne CPU Daten zu übertragen. Insbesondere Blitter und CPU machen das komplett untereinander aus, ohne dass andere Chips (z. B. die GSTMCU) beteiligt wären. Was, dachte ich mir also, wenn die Übergabe des Busses nicht richtig funktioniert und DMA bzw. Blitter etwas schreiben, wenn die CPU Code lesen will? Das würde die Abstürze natürlich erklären. Ein weiterer Durchlauf mit dem Diagnose-Cartridge zeigte: Auch dort verursacht die Nutzung des Blitters Fehler, ähnliche Fehler wie der Zugriff auf das Floppy-Laufwerk.
Kontaktproblem an der CPU? Daher die CPU vorsichtig aus dem PLCC-Sockel gezogen, wieder eingebaut: STE läuft wieder! Wie unwahrscheinlich, dass bloß eine der Leitungen, die für den Bus-Zugriff zuständig sind, einen schlechten Kontakt hatte. Wäre es eine Daten- oder Adressleitung gewesen, der STE hätte gar nichts mehr gemacht und mein Verdacht wäre viel früher auf die CPU gefallen.
Ich hoffe, es war halbwegs unterhaltsam, den Fehlersuchprozess mitzuverfolgen. Und es zeigt, wie wertvoll EmuTOS auch bei der Fehlersuche ist.
Thema: Rote Heringe - oder: Fehlersuche im STE (Gelesen 15094 mal)