Allgemeines > Atari - Talk

Rote Heringe - oder: Fehlersuche im STE

(1/4) > >>

czietz:
"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.

Gaga:
Solche Beschreibungen sind goldwert und tatsächlich sehr hilfreich. Statt wild zu probieren gibt dies eine logische Reihenfolge vor.

Danke und bitte mehr davon (soll natürlich nicht heißen, dass ich mir bei Dir defekte Rechner wünsche).

Atariosimus:
Danke auch von meinerseite für die Gedankengänge.

Letztlich stelle ich immer wieder fest, das es oftmals Kontaktfehler sind und weniger
defekte Bauteile. Ich hatte auch schon solche Effekte. Kabel abgezogen wieder angesteckt
erst ging nichts und dann kam doch alles wieder. Oder der Blitter im Sockel hatte Kontaktprobleme.
Dann "nass" eingebaut und alles lief wieder.

Ich glaube wenn man alles verlöten würde was in den Sockeln steckt hätte man vermutlich
kaum noch solche Fehler. Allerdings wer macht das schon.

Das mit dem manuell einhacken um EmuTos zu starten ist natürlich ganz speziell. Da müsste ich schon passen.

Lukas Frank:
Es lohnt ja vielleicht die vergoldeten speziellen Atari PLCC Sockel bei BEST zu bestellen ...

Arthur:
Ja, wirklich interessant Christian, auch wenn ich wünschte das du ein wenig mehr in die Tiefe gehen würdest. Danke



--- Zitat von: Lukas Frank am Sa 31.10.2020, 21:56:41 ---Es lohnt ja vielleicht die vergoldeten speziellen Atari PLCC Sockel bei BEST zu bestellen ...

--- Ende Zitat ---

Klar, für Best lohnt sich das und für das Transportunternehmen auch.

Navigation

[0] Themen-Index

[#] Nächste Seite