24.09.2025

{Asteroids im Doppelpack} Asteroids ist ein tolles Arcadespiel! Vektorgrafik, kaum Custom-Chips und sehr übersichtlich aufgebaut. Denkt man. Und wenn man dann zwei Platinen zur Reparatur bekommt, könnte man sich in der trügerischen Sicherheit wähnen, irgendwas zum Vergleichen zu haben. Die Wahrheit ist: ich kenne kaum ein Spiel, was sich so übel reparieren lässt, wie Asteroids. Missile Command vielleicht, oder Centipede. Ich erkenne ein Muster: Atari und alt - eine schlechte Mischung.

Platine 1:

Die RAMs hat schon mal wer getauscht...

Die auch. Dann liegt es vermutlich nicht an den RAMs, wenn hier gar nichts geht.

Platine 2:

Hier gibt es keine Sockel, aber dafür ein Kreuz auf dem RAM.

Die Bustreiber sind neu.

Die hier auch, hat aber wohl nicht geholfen...

Auch hier ist schon einiges gemacht worden - wer weiß, ob es danach besser oder schlechter geworden ist. Manchmal sind auch Reparaturen daran schuld, wenn nichts mehr geht.

Diese CPU taktet immerhin, aber recht eintönig.

Dazwischen legt sie sich mal schlafen, bis der WDT klingelt...

Der 157er war auffällig aber leider nicht die Ursache.

Ich habe endlich meinen Hilfstrafo gefunden. Die 2x18V benötigt man für die Vektorendstufen.

Rustikal aber praktisch!

Wir haben ein Bild - leider ohne sinnvollen Inhalt. Pieptöne gibt es auch nicht, eine Diagnose ist schwer zu geben.

Manchmal ändert sich das Bild auch - ich werde mal alle verbliebenen 2114 tauschen, es scheint, als ob der Programmablauf gestört ist.

Wenn beide Platinen nicht laufen, ist ein Vergleich schwierig. Ich bin gespannt!

28.09.2025

{Und es geht weiter!} Die Asteroids mit Funktion: immerhin funktioniert der NMI. Aber der ist auch Hardware-generiert. Ein geduldiger 4ms-Takt zum Bildaufbau.

Die Asteroids ohne Funktion: Upps. Mein Fehler. Aber mit einem neuen 2114 läuft es genausowenig...

Dafür meldet sich Kandidat 1 akustisch. Nachdem ich das Board mal komplett mit Lautsprecher verkabelt habe (immer eine gute Idee, die Asteroids sind akustisch mitteilungsfreudig, wenn sie mal anlaufen...) bekomme ich im Testmodus 4 höhere und einen tiefen Piepston. Das ist RAM N4. Das war übrigens auch der Baustein mit einem Kreuz drauf...

Das RAM ist schnell getauscht. Die Asteroids sind mit dem richtigen Werkzeug sehr gut auszulöten.

Das Programm startet ohne Fehler-Piep. Die RAMs scheinen in Ordnung zu sein. Wir haben ein statisches stabiles Bild. Im Testmodus kann man das Umlegen der DIP-Schalter jetzt optisch verfolgen.

Außerhalb des Testmodus geht es immer noch nicht gut. Der Watchdog schlägt zu und das ist das Unangenehme bei Asteroids. Jeder Fehler im Vektor-Generator führt zum Programmabbruch und damit zum Watchdog. Gut, dass man den einfach stillegen kann.

Jetzt bleibt erst mal Fehlersuche nach schlechten Pegeln. Nach einer Viertelstunde habe ich etwas gefunden. DVY5 sieht gar nicht gut aus!

Ein 74191 ist mit 10 Ohm eingangsseitig viel zu niederohmig. Viele Kiloohm wären hier zu erwarten gewesen.

Der Baustein ist getauscht, der Widerstand von DVY5 gegen Masse steigt auf 40 Ohm - "Not great, not terrible!". Da ist noch mehr defekt.

An der Leitung hängt einiges drann, ich werde alle Teilnehmer ansehen müssen.

Immerhin haben wir jetzt schon ein Bild, was fast nach Gameplay aussieht!

Der Pegel hat es ja auch schon fast geschafft...

Mich würde mal interessieren, woher dieser Schaden kommt, der diverse IC-Eingänge hat durchlegieren lassen... Kurzschluss? Überspannung? Jetzt muss ich erst mal 7497 bestellen, den habe ich nicht im Lager - braucht man so gut wie nie! Außer bei Asteroids...

08.10.2025

{Und es geht noch weiter!} Die Spezialbauteile sind da!

7497 ersetzt - die Pegel sehen gut aus! Plötzlich sieht auch das Vektorbild interessanter aus, auch wenn noch nichts richtig läuft...

Zumindest wird hier mal was berechnet und dargestellt:

Das Vector-Generator-ROM hat anormale Pegel auf den Datenleitungen.

Da stimmt was nicht:

Ich tausche den alten Bustreiber...

Hier hat man daran gedacht, zwei verschiedene Typen einsetzen zu können.

Ich wähle den modernen 74LS245.

Hat leider nicht geholfen. Das ROM funktioniert. Die 2114 ersetze ich jetzt alle.

Wow! Der Test-Screen läuft plötzlich einwandfrei. Aber hier werden auch keine Anforderungen an den Vector-Generator gestellt...

Präventiv tausche ich (erfolglos) den letzten Uralt-Bustreiber.

Auch gegen einen aktuellen Typen. Hilft nicht.

Aus den 16-Bit Register-RAMs kommt teilweise nichts raus. Ich tausche zwei Bausteine.

Während ich mich noch freue, stirbt einer der Bustreiber... Ich werde noch irre. War ja klar, Signetics SA.

Aber nachdem der auch ersetzt ist, erwartet mich ein überraschendes Vector-Bild.

Leider spinnt immer noch irgendwas im Vector-Generator-Teil - es gibt Artefakte und das Programm stürzt regelmäßig ab. Aber die Programmausführung läuft, der Vector-Generator zeichnet und der Testbildschirm meldet keine Fehler.

Ich bin gespannt, ob ich die Ursache noch finde, bevor wieder irgendein Baustein stirbt...

13.01.2026

{Und ich krieg sie doch!} Warum funktioniert der Vektorgenerator nicht richtig? Stimmt vielleicht doch was mit den Registern nicht? Die ursprünglich verbauten 74LS170 sind Open Collector Typen, daher auch die Pull-Ups. 74LS670 sind 3-State Typen. Ich entferne vorsichtshalber mal die Pull-Ups.

Sieht sauber aus, hat aber nichts genützt.

Vielleicht hat das Vector-ROM einen Schuss? 2716 ist ein 1:1-Ersatz. Keine Änderung im Verhalten.

Es sind keine Bausteine mehr übrig, die ein anormales Verhalten an den Ausgängen zeigen. Multiplexer haben allerdings manchmal die Eigenschaft, funktionsfähige Ausgänge, aber defekte interne Umschalter zu haben. Das sieht man mit dem Oszi nicht. Ein huckepack aufgesteckter Zweitbaustein zeigt dann allerdings Zwischenpegel, wenn die beiden Ausgänge mit widersprüchlichen Pegeln kämpfen. Das hat mich auf einen defekten 74LS157 gebracht.

Hab dich, du Mistkerl!

Platine 1 kann starten.

Jetzt zu Platine 2: die CPU macht ein wenig und verwickelt sich dann in den Watchdog. Alle Messungen weisen darauf hin, dass der Vektorgenerator überhaupt nicht läuft. Die Datenbustreiber sehen nicht gut aus. Ich tausche sie alle.

Meine neue Pace Lötstation macht mir die Arbeit leichter...

Der Tausch war dringend geboten...

Da nehme ich doch gleich die guten 54LS... die mit dem erweiterten Temperaturbereich.

Das Ergebnis ist ernüchternd. Die CPU macht den Selbsttest und springt dann in eine Endlosschleife, weil der Vektorgenerator nicht läuft. Hier hilft mir hoffentlich die genaue Analyse mit dem Logikanalysator.

02.04.2026

{Boot Up im Detail} Die Komplexität der Fehlersuche an Platine #2 hat mittlerweile das Terrain der Vernunft verlassen. Nein, es "lohnt" sich nicht, nein, das kann man nicht bezahlen, ja, ich will es wissen! Und so stelle ich mit dem Oszi fest, dass die komplette Vector State Machine komplett tot ist. Das liegt offensichtlich daran, dass das Signal "DMAGO#" niemals aktiv wird, der Vektorgenerator startet einfach nicht.

Immerhin ist die Dokumentation der Asteroids nahezu lückenlos. DMAGO# wird durch einen Zugriff auf Adresse 0x3000 ausgelöst. Warum das Programm da wohl nicht vorbeikommt, kann mir nur der Logikanalysator zeigen.

Doch zuvor sehen wir uns mal den Source Code der Asteroids genau an: beim Einschalten springt jede 6502 zuerst mal zum Reset-Vektor @0xFFFC - Adressbit 15 ist hier nicht benutzt, also ist 0x7FFC gleichbedeutend.

Der Vektor zeigt auf die Einsprungadresse 0x7CF3. Da geht es dann los mit Stack Pointer setzen, RAM löschen, Selbsttestschalter abfragen und dann in die eigentliche Spielinitialisierung...

"InitGame" @0x6803 fackelt nicht lange und setzt bei 0x6822 DmaGo. Was bei dieser Platine hier nicht passiert. Warum?

Jetzt kommt der Logikanalysator ins Spiel: getriggert auf Reset# kann ich damit den kompletten Aufstart aufnehmen und analysieren. 4250µs nach der Reset-Flanke ist die CPU mit dem Löschen des RAMs fertig (256 x vier Schreibzugriffe, RamClearLoop@0x7CFA) - um dann illegaler Weise in den Selbsttest mit jeweils 8 Schreibzugriffen zu springen...

Im Detail sieht man, dass die 6502 nach dem Löschen ordnungsgemäß den Zustand des Selbsttesteingangs abfragt (0x2007) und dort knallharte 0xFF liest, obwohl der Eingang nicht aktiv ist. Das sollte so nicht sein, die Spielinitialisierung und damit der Start des Vector-Generators wird so nie ausgelöst.

Der Selbsttest liegt an einem Multiplexer 74LS251 an, der je nach Adresse 0...7 die Eingänge auf Datenbit 7 mappt. Das ist pfiffig, weil somit der Zustand dieses Eingangs über ein einfaches BMI (Branch if Minus) abgefragt werden kann.

Wenn man da bei Adresse 7 nur 0xFF liest, ist der Kollege schlicht kaputt... Nebenbei: diese rostanfälligen TI-TTLs verlieren auch öfter mal ihre Beinchen, einfach abkorrodiert!

74LS251 ist einer der wenigen TTLs, die ich nicht auf Lager habe. Die Bestellung ist raus.

15.04.2026

{Die Suche hat sich gelohnt!} Nach nur zwei Wochen Lieferzeit sind endlich die 74LS151 bei mir eingetrudelt. Vermutlich wurden sie von einem berittenen Boten geliefert.

Mittlerweile habe ich echt Routine beim Austausch von TTL-ICs - und mit der richtigen Lötstation macht das sogar Spaß.

Ich lasse die Platine mit Watchdog laufen. Nur so wiederholt sie den Startablauf zyklisch. Wir haben einen DMAGO!

Der Vektorgenerator zuckt so vor sich hin, kommt aber nicht zum STOP - die drei Zähler für den Vektor-Timer liefern widersprüchliche Pegel.

Da sind wohl manche Ausgänge tot...

Das ist die berüchtigte Signetics SA-Pest. Diese Bauteilserie sollte man einfach komplett tauschen.

Von drei Zählern waren drei defekt. Der Vektor-Timer läuft jetzt wieder einen kompletten Start-Stop-Zyklus durch.

Zum ersten Mal seit Ewigkeiten liefert die Platine wieder Analogsignale. Das ist besser, als es auf den ersten Blick aussieht - jetzt kann ich zielgerichtet messen.

Auf der Platine sind noch ganz viele 74LS191 im Vektorgeneratorbereich - davon sind einige deutlich defekt, jetzt gehen mir aber die 74LS191 aus... Nachschub ist schon bestellt. Hoffentlich geht es diesmal etwas schneller! Der Vektorgenerator ist ein technisches Wunderwerk! Er ist eigentlich ein Prozessor für sich selbst. Die vielen Zähler bilden zusammen mit dem Vektor-ROM eine State-Machine, die selbständig die Vektoren auf den Schirm zeichnet. Die CPU schreibt nur die gewünschten Elemente mit Position und Skalierfaktor in das Vektor-RAM und triggert DMAGO. Dann arbeitet die State-Machine alle Zeichenoperationen ab, bis im RAM nichts mehr zu tun ist und meldet Vollzug. Das ist einfach genial. Dumm für den Reparateur: wenn in diesem Konstrukt irgendwo eine Kleinigkeit nicht funktioniert, bricht einfach alles zusammen...