Falcon-Diagnostic-Kit

Falcon Repairs and the Diagnostic Testkit. Wie Sie die Fehler Ihres Falcon finden und reparieren können.

Mit ein wenig Bastel-Geschick gehören Sie schon bald zu denjenigen Hardware-Freaks, die ein eigenes Fehler-Diagnose- und Behebungsgerät für den Falcon besitzen. Wir zeigen Ihnen, wie es einzusetzen ist.

Das Testmodul für den Atari Falcon030 ist ein letztes Testkit in einer Serie von Diagnosemodulen für ST, STe und Atari TT Computer. Es entspricht in seinem Aufbau den bisherigen, bereits aus dem Service bekannten Modulen. Diese letzte Release der Testsoftware enthält einige spezielle Routinen, die nur am Falcon F030 Verwendung finden. Die Testkit-Software wurde hergestellt, um die Fehlersuche an defekten Atari-Computern zu erleichtern und schnell defekte Systemkomponenten ausfindig zu machen.

Die Testsoftware befindet sich in zwei ROM-Bausteinen, die auf einer 128-KB-Modulkarte ihren Platz gefunden haben. Beachten Sie bitte, dass Romportmodule nur gesteckt werden, wenn der entsprechende Computer ausgeschaltet ist. Ein 128- KB-Modul/Epromkarte reicht aus, um die gesamte Testsoftware unterzubringen. Das trifft also auch auf ein Service-Testmodul zu.

So unterteilt sich die Modulsoftware in die unteren und die oberen 8 Bit. Also jeweils ein Prom mit den LOW- und eines mit den HIGH-Daten, die zusammen 16 Bit Datenbreite ergeben, die dann auch so am Romport gelesen werden. Entfemen Sie niemals das Modul bei eingeschaltetem Rechner! So vermeiden Sie teure Schäden an Ihrem System. Wie bei allen Atari-Computern liegt auch am Falcon der Systembus ungepuffert am Romport an.

Das Testkit ist menügesteuert. Nach dem Einstecken eines Moduls und dem Einschalten des Computers wird die Testsoftware vom Modul/Cardridge direkt geladen. Der Falcon bootet von diesem Modul. Hierzu genügen bereits 2 KB aktives RAM im Gerät. Eben in diesem Moment werden schon die ersten internen Timing-tests durchgeführt und zeigen dem Benutzer Probleme direkt am Bildschirm an. Ist kein RAM verfügbar, kann das Testkit nicht arbeiten!

Dieses Testkit überprüft den Rechner in verschiedenen Schritten, die auch fast alle ein eigenes Menü haben. Die entsprechenden Diagnoseergebnisse werden auf dem Bildschirm angezeigt oder anhand einer entsprechenden Bildschirmhintergrundfarbe angezeigt.

Unterteilt sind die Tests in automatisch ablaufende und in Tests, die die Aufmerksamkeit des Benutzers erfordern. Automatisch laufende Tests dienen dem Dauertest bestimmter Baugruppen oder auch den sog. Burn in bei Neugeräten, was aber wohl kaum mehr zutreffen dürfte.

Eine der Hauptgruppen ist ein umfassender Speicher-, Takt- und Komponententest. .

Jederzeit wird von diesem Testkit die serielle Schnittstelle benutzt. Das gilt für den Fall, dass am zu testenden Falcon die Tastatur oder/und auch der Bildschirm ausgefallen ist. Sämtliche Bildschirmausgaben werden so an einen weiteren Atari gesendet, der hier dann als Sichtterminal fungieren würde.

Ein releativ komplettes Falcon-Testkit kann bei der Firma Best-Electonics für ca. 80 US-S erworben werden. Die genannten Preise sind ca. einen Monat alt und ohne Porto, Verpackung und Zoll.

Um auch die diversen Schnittstellen des Falcon zu testen, sind noch einige weitere Schnittstellenadapter notwendig:

Falcon diagnostic parts

RS 232 loop back $8.00
MIDI loop back $4.00
Lan loop back $ 15.00
Audio loop back $20.00
DSP loop back $30.00
Expansionport test fixture $ 70.00
Testmodul $ 80.00

Nur mit diesen zusammen kann ein Computer vollständig getestet werden.

Die Bezugsquelle der genannten Teile:

BEST-Electronics:
2021 The Alameda, Suite 290
USA, San Jose, California 95126
Tel./Fax 001-(408) 243-8274

Wenn Sie ein Modul ohne Gehäuse erhalten, stellen Sie sicher, dass Sie die Karte mit den beiden Bausteinen nach immer UNTEN in den Falcon stecken! Module im Plastikgehäuse werden mit dem Fir-menlabel nach oben in den Falcon gesteckt. Wenn Sie einen bestimmten Test machen wollen, schließen Sie auch den entsprechenden Loopback-Kabel an die richtigen Schnittstellen des Falcon an. Selbstredend sollte am Monitorport ein Monitor angesteckt sein. Im günstigsten Fall ist das ein RGB-Farbmonitor!

Nach dem Einschalten des Falcon sollten Sie den Schriftzug

Falcon 030 Diagnostic Cardridge

auf Ihrem Bildschirm lesen können.

Beachten Sie bitte, dass im Moment des Bootens alle gesicherten Parameter im Falcon NVRAM durch die Standardparameter des Testmoduls überschrieben werden. Es wird so sichergestellt, dass nicht eventuell verstellte Parameter im NVRAM den Falcon F030 blockieren. Somit behebt man mit dem einfachen Einstecken und dem Einschalten des Testmoduls zumindest schon einen solchen Fehler.

Wie der Falcon von einem Testmodul bootet:

An erster Stelle im ersten Eprom einer solchen Karte steht die sog. Magicnumber: $ABCDEF42

An dieser Nummer erkennt der Rechner, dass es sich um ein Programmodul handelt. Verschiedene Module tragen hier logischerweise auch jeweils eine andere Magicnumber. Sieht der Falcon hier SFA522255F, wird weder das GEM noch das AES geladen. Auch werden in diesem Fall das GEM sowie das System nicht initialisiert, da eben ein Testmodul im Romport steckt.

Beachten Sie bitte, dass es hier auch keinerlei Bootvorgang von den vorhandenen Datenträgern gibt.

Die eigentliche Reihenfolge der Adressen

Zuerst kommt die magische Nummer gefolgt von $00000000, wenn kein weiteres Programm in diesem Modul enthalten ist.

Die nächste Langwortadresse sollte den Initialisierungscode enthalten, denn das System benötigt Informationen über das Programm. Auch wird hier festgelegt, wann und wo das System in welche Routine springt. Der genaue Zeitpunkt wird durch das hochwertigste Bit bestimmt:

Tabelle
0 Routine wird vor allem anderen gestartet. (Testmodul)
1
3 Bit 3 erzeugt auch einen Start vor dem GEM, allerdings nur bei Computern ohne RomTos. (Gab es nur bei den ersten 260/520ST)
5
6 Es handelt sich um eine .TOS Anwendung
7 Bit 7 legt fest, dass es sich um eine .TTP-Anwendung handelt, welche zum Betrieb noch Parameter benötigt

Headerinformationen / Adressen:

SFAOO18 Der korrekte Programmname.

SFA0008 Das Programminit sowie der Zeiger.

SFAOO 14 Die komplette Programmlänge

SFA0004 Der gesamte Programmkopf sowie dessen Zeiger!

$FAOO 12 Das Erstellungsdatum. $FAOOOO Hier steht das magische Langwort des Moduls.

$FAOO 10 Die Erstellungszeit (Uhrzeit) des Programmoduls.

$FAOOOC Die Anfangsadresse/Programmanfang

An der Adresse des nächsten Langwortes steht dann die Startadresse des eigentlichen Programmcodes. An den beiden danach folgenden Worten (keine Langwörter) können dann auch noch Datum und die Uhrzeit enthalten sein. Das Langwort zum Schluß enthält die gesamte Programmlänge in Bytes. Der nachfolgende String sollte dann noch den kompletten Programmnamen enthalten, den Stringab-schluß veranstaltet dann ein "$00". Das ist alles dringend notwendig, um zu erkennen, um wieviel Programme und um welche Art von Programmen es sich handelt.

Soviel als Nebeninformation zum Romport und Modulsoftware. Speziell geeignete Software wird benötigt, um solche Programmodule zu Hause generieren zu können. Ebenfalls wird ein Eprom-Programmiergerät benötigt, zum Beispiel JuniorPrommer von Maxon.

Ein Testmodul und die ersten Schritte am toten Falcon

Wenn Sie Ihrem Falcon trotz korrektem Anschluss, einer intakten Stromversorgung und einer einwandfreien Peripherie kein Bild entlocken können, beginnen Sie mit den weiteren Schritten.

Führen Sie die folgenden Schritte der Reihe nach aus.

Stellen Sie eine Verbindung zu einem weiteren Atari-Computer her. Starten Sie auf dieser Maschine ein VT52-Terminalprogramm.

Stellen Sie ein serielles Verbindungskabel selbst her.

Das Terminal muss auf die Parameter 9600 Baud, 8N 1 eingestellt werden.

Ein serielles Kabel:

Totes Gerät

Ein weiterer Atari-Computer, 520, MegaST(e), TT

Pin 2...........Pin 3

Pin 3...........Pin 2

Pin 5...........Pin 5 GND (7 an ST, STE)

Setzen Sie das Testmodul korrekt in den toten Falcon ein. Verbinden Sie beide

Atari-Computer mit der oben gezeigten Kabelverbindung. Auf dem intakten Atari starten Sie ein Terminalprogramm mit den Schnittstellenparametern 9600/8/n/l.

!»• Schalten Sie den toten Falcon danach ein.

^ Meldet sich das Diagnosemodul auf dem zweiten Atari, benutzen Sie die dort vorhanden Bildschirmausgabe und die Tastatur für weitere Tests.

fc* Notieren Sie sich die Einzelheiten der dort gemachten Angaben.

^* Sollten Sie nichts sehen, beginnen Sie damit, den toten Falcon zu zerlegen.

Nach dem Öffnen des Falcons benötigen SieTOÄt näher beschriebene Meßgeräte.

l1 Messen Sie den 32 MHz Takt mit einen Oszilloskop nach.

Das Taktsignal sollte eine gleichförmige stabile Wellenform haben.

^- Messen Sie die 32 MHz direkt am Eingang des COMBEL Chips nach!

• Ist der Takt hier nicht vorhanden, verfolgen Sie den Weg zur Takterzeugung und ersetzen Sie ggf. den Oszillator.

l» Danach testen Sie bitte den HALT Pin der 68030 CPU, das ist sehr wichtig.

Wenn Sie hier ein HIGH-Pegel messen, ist das in Ordnung.

Erhalten Sie hier einen dauerhaften LOW-Pegel, sollten Sie bitte die weiteren Punkte beachten.

Testen Sie die Resetschaltung des Falcon, und zwar darauf, ob von hier eventuell ständig ein HALT geliefert wird.

Testen Sie auf einen doppelten Bus-Error. Das bekommt man raus, indem man das BERR-Signal der CPU kontrolliert. Das in ein Input für die CPU! Das Signal sollte immer HIGH sein. Sehen Sie hier auf Ihrem Oszilloskop häufig schnell folgende LOW-Impulse, so werden diese direkt vom COMBO generiert. Das bedeutet, dass das System, der COMBO selber, eine Fehlfunktion festgestellt hat.

p» Verfolgen Sie die Mastertaktleitung rückwärts vom COMBEL bis zum Oszillator. Beachten Sie dabei auch bitte die Taktleitungen nach dem COMBEL! Im COMBEL findet eine Teilung des Taktes statt, so entstehen auch 16 MHz für die CPU/FPU. Auch hier sollten noch Taktsignale zu messen sein!

Stellen Sie hierbei einen Fehler fest, ist die CPU nicht in der Lage, das ROM zu lesen, und sie kann auch die Videoausgabe nicht aktivieren.

Ebenso kann der 68901 nicht initialisiert werden, folglich nutzt Ihnen auch das Testmodul nichts, da die serielle Schnittstelle so nicht funktionieren kann. Im einfachsten Fall ist hier die 68030 CPU defekt.

Stehen die Signale CD und DS an, sind die Leitungen RS1-RS5 sowie DO-D7 aktiv und DTACK rührt sich nicht, dürfen Sie sich langsam mit dem Gedanken anfreunden, den MFP ebenfalls zu wechseln.

Ohne MFP keine Kommunikation

Es gibt leider keinen vernünftigen Weg, eine defekte CPU zu lokalisieren. Einzig der bereits beschriebe Fall und der. dass die CPU so heiß wird, dass man die Chipoberfläche nicht anfassen kann, deutet darauf hin, dass dieser Chip wirklich defekt ist.

Beachten Sie dabei aber bitte, dass man die CPU mit einem einzigen Signal "ruhigstellen" kann. Denken vor dem Löten!

Befindet sich die CPU nicht im HALT-Mode. gibt es keine Bewegungen auf den Datenleitungen, versucht die CPU nicht das ROM oder das Diagnosmodul zu lesen, sollte die CPU gewechselt werden. Sollte die CPU aber das Diagnosemodul lesen, das sieht man an dem Toggeln der Datenleitungen, besteht die Möglichkeit, dass die RS232 und auch das Videosubsystem gleichzeitig beschädigt sind.

Ein sicheres Zeichen für einen defekten COMBEL

Vsync. wird z.B. vom COMBEL an Pin 34 ausgegeben und direkt an Pin 6 des VI-DEL eingespeist. Dazwischen liegt einzig und allein ein 33 Ohm Widerstand, welcher eigentlich auch nur eine Schutzfunktion hat, eine eher unwahrscheinliche Quelle für einen Defekt. Trotzdem nachsehen!

Produziert der VIDEL ein Videosignal, und das Bild ist nicht lesbar oder auch nicht immer vorhanden, kann noch ein Problem mit dem Video-RAM vorliegen. Das Testkit sollte diesen RAM-Fehler leicht aufspüren können. Das Video-RAM ist ein Bereich des normalen ST-RAM, also auf der normalen Atari-Speicherkarte, die eigentlich in jedem Falcon steckt.

Im übrigen bootet die Maschine auch nicht, wenn das RAM defekt oder nicht vorhanden ist, sie kann dann während des Bootens keinen Stack etc. anlegen.

Minimum, bei jedem Atari, müssen 2K RAM arbeiten, um auch überhaupt mit dem Testmodul arbeiten zu können.

Arbeitsspeicher, der einfachste Test: Eine geliehene Karte einstecken. Alles weitere hat in etwa den Umfang des schon vorhandenen Artikels.

Stellenweise lässt sich bei einem defekten COMBEL ein TV-Bild erzeugen, wenn man an Pin 7 das VIDEL mit dem Finger berührt. Aber das ist nur ein spielerischer Test.

PowerUp beim Einschalten

Beim Einschalten mit eingestecktem Testkit werden die untersten 2 KB RAM überprüft. Wird hier ein Fehler entdeckt, erfolgt Meldung an das RS232-Terminal. Fehlt RAM, kann kein Stack und kein Speicher für Systemvariablen angelegt werden. Der Bildschirm bleibt dunkel, und das Testmodul wird die RAM-Fehler an das Terminal senden. Ist das Keyboard beschädigt, wird es deaktiviert, der Benutzter muss das RS232-Terminal benutzen. Alle Tasteneingaben werden über die serielle Schnittstelle zum externen Terminal geleitet.

Power Up Sequence

Das Testkit erlaubt direkte Systemtest nach dem Einschalten. Alle Devices oder Subsyteme werden initialisiert und getestet. Ebenso werden sofort diverse Ti-mingtests gestartet. Sie erhalten direkt danach den Status der einzelnen Subsysteme direkt auf dem Bildschirm. Das NVRAM wird dabei auf von Atari festgelegte De-faultwerte gesetzt. Ihre eigenen Parameter gehen dadurch verloren. Es wird so sichergestellt, dass keine unsinnigen Parameter im NVRAM vorhanden sind. Sie können die alten Parameter jederzeit mit z.B. BOOTKONF.PRG wieder herstellen.

Steigt der Falcon aus, bevor Sie das Menü des Testkits komplett auf dem Bildschirm sehen können, zeigt die letzte Bildschirmaufschrift die Stelle oder Adresse des Subsystems an, bei welchem sich der Absturz ereignet hat. Zumindest klappt das oft. Hier dürfen Sie dann näher in die Hardware einsteigen. Hierzu finden Sie unter gleichnamigem Titel in DOITF030 umfassende Tips und Anleitungen zur gezielten Fehlerbeseitigung am Falcon F030 und dessen Subsysteme. Für einen einzigen Artikel zu umfangreich.

Die niedrigsten 2 KB RAM werden beim PowerUp getestet, stellt das Kit hier einen Fehler fest, wird dieser über die RS232-Schnittstelle gesendet. Es kann dann auch keine Bildschirmausgabe erfolgen. Das Kit wird den RAM-Test fortsetzen und die Meldungen über RS232 ausgeben.

Initialisierung des Systems

Der Speicherbereich für den Bildschirmspeicher wird eingerichtet. Alle Pointer zum Lesen und Schreiben von Daten werden gesetzt. Die so festgelegten Adressen werden an die CPU-Register übergeben. Eventuelle Fehler werden über RS-232 ausgegeben, nachfolgend wird das zur Verfügung stehende RAM getestet. Ist das Einrichten des Bildschirmspeichers fehlerhaft, erfolgt eine Meldung an das von Ihnen angeschlossene Terminal. Der an diesem Falcon angeschlossene Monitor wird dunkel bleiben.

Das Falcon RAM wird vom Testkit auf fünf verschiedene Arten getestet. Hierbei werden alle üblich bekannten Testmuster verwendet. Beachten Sie bitte, dass der Speichertest bei einer 14-MB-Maschine wesentlich länger dauern wird als auf einem 4 MB Falcon!

Wird arbeitendes RAM gefunden, werden die 68030 Exeption Handler geladen und der MFP initialisiert, alle Interrupts eingeschaltet, das Videosubsystem aktiviert und die RS-232 initialisiert. Danach wird der Bildschirmspeicher gelöscht, und die erste Meldung erblickt das Licht der Welt.

Ab diesem Punkt ist das System soweit in Ordnung, dass diverse weitere Tests vorgenommen werden könnten. Ebenso werden ab jetzt Meldungen per RS-232 an einen weiteren Atari, das Terminal, übermittelt. Nach jeder getesteten Funktion werden Sie eine Schlußmeldung oder eine entsprechende Fehlermeldung erhalten.

Ein Bus-Error tritt z.B. beim Versuch auf, das ROM zu beschreiben. Hier sollten Sie direkt einen roten Bildschirmhintergrund erhalten. Einige Busfehler erzeugen nur eine Statusmeldung, das System läuft aber weiter. Haben Sie, warum auch immer, ein gepatchtes TOS in Ihrem Falcon, wird diese kleine Modifikation grundsätzlich immer mit einer fehlerhaften CRC-Checksumme bestraft. Diese Meldung hat keine weiteren Auswirkungen. Dem Testkit ist in diesem Fall einfach nur die aktuelle CRC-Prüfsumme des ROMs nicht bekannt, weitere Fehler werden jedoch auch in diesem Fall korrekt erkannt und führen zu entsprechenden Fehlermeldungen.

Timer Testing - Genlock

Beim Start des sog. Timingtest wird ein eigenes Programmteil aufgerufen. Dieses Programmodul generiert seine eigenen Meldungen.

Es werden alle Timer am MFP getestet und die Ergebnisse an die aufrufende Routine zurückgeliefert. Sobald bei diesen Tests ein einziger winzig kleiner Fehler auftritt, wird die Testroutine abgebrochen und das Ergebnis ausgegeben.

Stellt die Software-Testroutine keinen Fehler in den MFP-Timern fest, werden diese Timer als Referenztimer für weitere Systemtimingtests benutzt. U.a. werden dann auch damit der Takt des Hauptsystems, alle kleineren Taktraten und das Genlock-Interface bzw. der dazu passende Takt, getestet.

Sämtliche Meldungen erscheinen auf dem Bildschirm oder werden auch hier über RS232 ausgegeben, "pass" bedeutet, dass jeweils der entsprechende Test erfolgreich war, also fehlerfrei. Man sieht es auch an der freundlichen Bildschirmfarbe.

Zum allgemeinen Funktionsablauf ist zu sagen, dass bei dieser "Messung" ein MFP-Timer gestartet wird und die CPU damit in eine Instruktionsschleife startet.

Ist die Zeit des MFP-Timers abgelaufen, bevor die CPU diese Schleife abgearbeitet hat, ist die entsprechend getestete Taktrate zu langsam oder das System wird über den Genlock Input mit einer externen Taktrate gefahren. In diesem Fall wird das Testmodul einen Dauerton generieren, die Bildschirmausgabe wird gestoppt, und der Rechner wird einfrieren, einen Reset benötigen.

Erzeugt dieser Test keinen Timeout, erfolgt eine entsprechende positive Meldung, und der Test ist damit positiv beendet.

Als Teil des Genlock-Tests wird das sog. Pixelcontol-Bit im SP-Shiftmode Register gesetzt. Sie als Benutzer können dieses Bit quasi als Oszilloskop nutzen, da, sollten Sie das externe STe-Testboard besitzen, Sie so leicht sehen können, ob der Genlock-Pin auf dem Testboard mit der entsprechenden Pixeltaktrate getoggelt wird. Das funktioniert nicht, wenn ein externer Genlock-Takt anliegt!

Clean Up

Unter diesem Punkt wird das Keyboard neu initialisiert. Die Taktrate wird neu gesetzt und der CPU Cache abgeschaltet. Nach einer Sekunde Pause wird der Bildschirm gelöscht und neu aufgebaut.

Auch ist das für mich ein guter Punkt, um zu betonen, dass dieser Artikel niemals eine komplette Reparaturanleitung sein kann und auch nicht alle Tips und spezifischen Systemmeldungen enthalten kann, die von diesem Testkit geliefert werden. Es würde mit Sicherheit den normalen Umfang der gesamten Heftausgabe sprengen.

Weitere Informationen

Die zu den einzelnen Tests passenden Fehlermeldungen, Tips und näheren Baugruppenbeschreibungen, inklusive der hier notwendigen persönlichen Tips, können Sie aus DOITF030 unter dem gleichnamigen Artikel entnehmen.

DOITF030 ist weiterhin kostenlos und zu beziehen unter:

http://www.rhein-main.de/people/robert/homepage.htm

Selbstredend finden Sie hier sämtliche Informationen durch Grafiken und Flowcharts unterstützt. Dieser Artikel soll nur die Möglichkeiten veranschaulichen, wie man sich mit dem nötigen Know-how versieht, um auch die Reparatur, zumindest aber eine weite Eingrenzung eines Fehlers, auch am eigenen Falcon, zu erreichen.

Unter keinen Umständen kann hier das Handbuch für eben ein Atari-Testkit, im übrigen komplett in englischer Sprache, ersetzt werden. Auch erhebt dieser Artikel und die darin beschriebenen Möglichkeiten keinen Anspruch auf Vollständigkeit, so fehlen hier auch ganz bewußt die Pin-nummern der einzelnen Chips.


Robert Schaffner
Aus: ST-Computer 09 / 1999, Seite 50
Links
Copyright-Bestimmungen: siehe Über diese Seite