Defekter 1040STF

[dbsys]

Ich habe hier einen teildefekten 1040STF, mit dem ich nicht so recht weiterkomme.

Am SM124 erhalte ich keine Bildausgabe.

Ein VGA Monitor mit "Monochrom auf ST" Kabel zeigt mir eine Zeilenfrequenz 15,7 kHz bei 50 Hz an, was der VGA Monitor natürlich nicht verträgt. Jedenfalls erkennt der 1040 STF nicht, daß ein Monokabel  angeschlossen ist, bei dem Pin 4 auf "low" gezogen wird.

Also habe ich per "SCART auf ST" Kabel einen Fernseher angeschlossen und erhalte diese Bildausgabe, siehe unten. Kommt jemandem dieses Farbmuster bekannt vor?

Meine original Atari Testcartridge meldet sich nicht. Auch per Telnet kann ich per RS232 nicht auf den toten Atari zugreifen. Dessen Netzteil ist in perfektem Zustand und liefert die nötigen Spannungen und die sehr genau. Beim Einschalten des Rechners fährt das Floppy Laufwerk an. Die Kontrollleuchte in der Tastatur leuchtet.

[czietz]

Derartige Streifen treten bei (manchen) STs auf, wenn die CPU nicht anläuft bzw. im Boot-Ablauf nicht weit genug kommt, um den Shifter zu initialisieren und das RAM zu nullen. Dazu passt auch, dass Du mit dem Diagnosecartridge keine Ausgabe auf der seriellen Schnittstelle erhältst.

Du kannst prüfen:

- Spannungsversorgung direkt an der CPU,
- 8 MHz Takt an der CPU,
- den Pegel der Leitungen /HALT und /RESET an der CPU,
- Kontaktschwierigkeiten an allen gesockelten Bauteilen (insbes. ROMs),
- Durchgang der Adress- und Datenleitungen von CPU zu GLUE bzw. ROMs,
- ob es nach einem Reset Zugriffe auf die ROMs gibt, d.h. ob an deren Enable-Pins mit dem Scope "Low"-Pulse sichtbar sind und wie viele.

In hartnäckigen Fällen hilft dann leider nur ein Logic-Analyzer, mit dem nachverfolgen kann, wie weit die CPU beim Booten kommt.

[dbsys]

Derartige Streifen treten bei (manchen) STs auf, wenn die CPU nicht anläuft bzw. im Boot-Ablauf nicht weit genug kommt, um den Shifter zu initialisieren und das RAM zu nullen. Dazu passt auch, dass Du mit dem Diagnosecartridge keine Ausgabe auf der seriellen Schnittstelle erhältst.

Du kannst prüfen:

- Spannungsversorgung direkt an der CPU,
- 8 MHz Takt an der CPU,
- den Pegel der Leitungen /HALT und /RESET an der CPU,
- Kontaktschwierigkeiten an allen gesockelten Bauteilen (insbes. ROMs),
- Durchgang der Adress- und Datenleitungen von CPU zu GLUE bzw. ROMs,
- ob es nach einem Reset Zugriffe auf die ROMs gibt, d.h. ob an deren Enable-Pins mit dem Scope "Low"-Pulse sichtbar sind und wie viele.

In hartnäckigen Fällen hilft dann leider nur ein Logic-Analyzer, mit dem nachverfolgen kann, wie weit die CPU beim Booten kommt.

Danke sehr! Ich schaue mir obige Punkte genauer an.

[dbsys]

Hier die ersten Erkenntnisse:

- Spannungsversorgung direkt an der CPU,  Ergebnis: 4,97 Volt

- 8 MHz Takt an der CPU, Ergebnis: ja, 8 MHz Takt ist da

- den Pegel der Leitungen /HALT und /RESET an der CPU, Ergebnis: jeweils etwa 500 mV

- ob es nach einem Reset Zugriffe auf die ROMs gibt, d.h. ob an deren Enable-Pins mit dem Scope "Low"-Pulse sichtbar sind und wie viele. Ergebnis: siehe angehängtes Foto. Da ich aber nicht weiß, wie das Signal normalerweise aussehen sollte, weiß ich nicht, nach welchen Pulsen ich hier Ausschau halten sollte. Das Signal auf dem Foto ist an Pin 22 (Output Enable) gemessen. An Pin 20 (Chip Enable) ist bei einem Reset nichts zu messen.

Vielleicht noch folgende Hinweise:
Es ist ein 1040 STF, Rev. D Board.
Das TOS ist auf 6 ROMs verteilt. ROM Typ: RP23256.

[czietz]

- den Pegel der Leitungen /HALT und /RESET an der CPU, Ergebnis: jeweils etwa 500 mV

Das ist seltsam. Im regulären Betrieb wären sie "high", d.h. ca. 5 V, nicht 0,5 V. Beide Leitungen "low" würde auf ein Problem mit der Reset-Schaltung hindeuten, denn nur die externe Reset-Schaltung kann /HALT und /RESET gleichzeitig auf "low" ziehen. Aber bitte erst Anmerkung unten lesen!

- ob es nach einem Reset Zugriffe auf die ROMs gibt, d.h. ob an deren Enable-Pins mit dem Scope "Low"-Pulse sichtbar sind und wie viele. Ergebnis: siehe angehängtes Foto.

Da sehe ich relativ viele Zugriffe mit plausiblem Timing, d.h. die CPU läuft offensichtlich los, was /RESET und /HALT gleich "low" widerspräche. Jedoch ist auch die die Spannung nur ca. 0,5 V statt 5 V. Das lässt mich vermuten, dass Du Dein Scope u.U. versehentlich auf 1:1-Probes konfiguriert hast aber mit 1:10-Probes misst? Bitte prüfe das, denn von den Spannungspegeln (also ob wirklich 0,5 V oder 5,0 V) hängt das weitere Vorgehen ab.

[dbsys]

- den Pegel der Leitungen /HALT und /RESET an der CPU, Ergebnis: jeweils etwa 500 mV

Das ist seltsam. Im regulären Betrieb wären sie "high", d.h. ca. 5 V, nicht 0,5 V. Beide Leitungen "low" würde auf ein Problem mit der Reset-Schaltung hindeuten, denn nur die externe Reset-Schaltung kann /HALT und /RESET gleichzeitig auf "low" ziehen. Aber bitte erst Anmerkung unten lesen!

- ob es nach einem Reset Zugriffe auf die ROMs gibt, d.h. ob an deren Enable-Pins mit dem Scope "Low"-Pulse sichtbar sind und wie viele. Ergebnis: siehe angehängtes Foto.

Da sehe ich relativ viele Zugriffe mit plausiblem Timing, d.h. die CPU läuft offensichtlich los, was /RESET und /HALT gleich "low" widerspräche. Jedoch ist auch die die Spannung nur ca. 0,5 V statt 5 V. Das lässt mich vermuten, dass Du Dein Scope u.U. versehentlich auf 1:1-Probes konfiguriert hast aber mit 1:10-Probes misst? Bitte prüfe das, denn von den Spannungspegeln (also ob wirklich 0,5 V oder 5,0 V) hängt das weitere Vorgehen ab.

Ja, normalerweise sind meine Probes auf 1:1 gestellt. Ich Dödel habe nicht bemerkt, daß der vorherige Benutzer diese auf 1:10 umgestellt hatte. Also habe ich jeweils 5 Volt gemessen, nicht 500 mV.

[tuxie]

Interessant wäre ob sich etwas an den ROM CS Signalen tut, wenn du ein scope hast kannst du ja dies einmal Testen.

[czietz]

Interessant wäre ob sich etwas an den ROM CS Signalen tut, wenn du ein scope hast kannst du ja dies einmal Testen.

Hat er doch: es tut sich was.

[czietz]

Das ist dann leider der vermutlich schwieriger zu diagnostizierende Fall: Zugriffe auf ROM finden statt, und zwar zahlreich, /RESET und /HALT sind "high", d.h. irgendwas macht die CPU, vielleicht in einer Endlosschleife. Es könnten immer noch z.B. Adress- oder Datenleitungen unterbrochen sein bzw. Kontaktprobleme haben, aber wenn man das geprüft hat, kommt man rasch an den Punkt, an dem man mit dem Logicanalyzer die Buszugriffe belauschen und mit einem funktionierenden ST vergleichen muss, um die Abweichung zu finden.

[dbsys]

Das ist dann leider der vermutlich schwieriger zu diagnostizierende Fall: Zugriffe auf ROM finden statt, und zwar zahlreich, /RESET und /HALT sind "high", d.h. irgendwas macht die CPU, vielleicht in einer Endlosschleife. Es könnten immer noch z.B. Adress- oder Datenleitungen unterbrochen sein bzw. Kontaktprobleme haben, aber wenn man das geprüft hat, kommt man rasch an den Punkt, an dem man mit dem Logicanalyzer die Buszugriffe belauschen und mit einem funktionierenden ST vergleichen muss, um die Abweichung zu finden.

Ja, das muß ich noch machen, die Adress- oder Datenleitungen nachverfolgen. Da man sowas nicht mal eben in ein paar Minuten zwischendurch erledigen kann, warte ich momentan auf eine passende Zeitscheibe. Mehr kann ich dann eh' nicht machen, denn ein Logicanalyzer steht mir nicht zur Verfügung.

[czietz]

Dass mit dem Testcartridge über die serielle Schnittstelle nichts kommt, wie Du oben erwähntest, ist sicher? (Warum ich frage: Ich hatte mal die falschen Einstellungen an der Gegenstelle konfiguriert (korrekt wäre 9600 8N1) und war dadurch in die Irre geleitet worden.)

[dbsys]

Dass mit dem Testcartridge über die serielle Schnittstelle nichts kommt, wie Du oben erwähntest, ist sicher? (Warum ich frage: Ich hatte mal die falschen Einstellungen an der Gegenstelle konfiguriert (korrekt wäre 9600 8N1) und war dadurch in die Irre geleitet worden.)

Ja, der Gedanke schwirrt auch mir noch im Kopf herum. Zur Sicherheit sollte ich es nochmals probieren und dabei sehr genau hinschauen.

Edit: Oder liegt's vielleicht daran, daß mir kein zweiter absolut baugleicher 1040er zur Verfügung steht? Ich habe "nur" einen 1040STE als funktionsfähigen 1040er zur Verfügung. Auf der Atari Testcart steht: 1040/MegaST/1040STE. Vermutlich macht's nichts aus.

[czietz]

Edit: Oder liegt's vielleicht daran, daß mir kein zweiter absolut baugleicher 1040er zur Verfügung steht? Ich habe "nur" einen 1040STE als funktionsfähigen 1040er zur Verfügung. Auf der Atari Testcart steht: 1040/MegaST/1040STE. Vermutlich macht's nichts aus.

Hm? Die Testcartridges sind unterschiedlich für ST (und MegaST) vs. STE. Kann man Deines denn umschalten zwischen ST / STE?

Mir ging es aber um die Gegenstelle, d.h. was auch immer (anderen Atari, PC, ...) Du ans andere Ende des seriellen Kabel hängst. Dort muss das Terminalprogramm natürlich auf die richtigen Settings (9600 bit/s, 8 Datenbits, kein Paritätsbit, 1 Stopbit) gestellt werden.

[Arthur]

Edit: Oder liegt's vielleicht daran, daß mir kein zweiter absolut baugleicher 1040er zur Verfügung steht? Ich habe "nur" einen 1040STE als funktionsfähigen 1040er zur Verfügung. Auf der Atari Testcart steht: 1040/MegaST/1040STE. Vermutlich macht's nichts aus.

Für deinen defekten 1040STF brauchst du eine Cratridge für ST bzw. Mega ST... oder eine Multi-Cartridge die sich auf ST bzw. Mega ST einstellen läßt. Da du erwähntest das du eine original Atari Cartridge benutzt sollte dies also eine entsprechende sein.

Edit: Oder liegt's vielleicht daran, daß mir kein zweiter absolut baugleicher 1040er zur Verfügung steht?

Als Ausgabegerät der Informationen kannst du einen beliebigen zweiten Atari ((M)ST, (M)STE, TT, Falcon) der über ein Nullmodemkabel mit deinem defekten 1040 STF verbunden ist und in dem z.B. Emulator.acc geladen ist benutzen. Die Disketten von http://www.atariworld.org die Emulator.acc enthalten laufen aus dem Stand heraus... die Kommunikationsparameter passen, insofern man sie nicht vorher verstellt und abgespeichert hat. Ein PC/Mac mit einen entsprechenden Programm und Konfiguration tut es aber auch.

[Lynxman]

Könnte auch ein Problem mit dem RAM sein. So in etwa hatte ich das mal bei einem 520er.

Hast Du mal den MMU Sockel und die MMU angeschaut?