Mike McBike @ Home / Arcade Reps Teil 5 / Sidam Invasion |
|
{Sidam Invasion} Ein Space Invaders Bootleg-Nachbau von Sidam. Gibt es auch als "Space Attack" von Lich. Allen gemeinsam: drei Logikversorgungsspannungen (+5V/-5V/+12V), 2708 EPROMs, 8080 CPU und anfällige TMS4060 RAMs... In diesem Fall ist die PCB tot. Takt geht, aber die CPU ist an Daten- und Adressbus hochohmig. Reset ist aus, andere Signale muss ich testen, vielleicht stimmt was mit dem HALT-Signal nicht. Ach ja, der WDT macht alle 4s einen braven RESET, dann zucken mal kurz die Adressleitungen... Diese hier sieht aus, wie frisch aus dem Laden. So ein Anblick ist selten. Selbst der Audio-AMP ist teuer verkühlkörpert! Der klassische Sidam-Kühlkörper für die vier Linearregler (2x7805, 7905 und 7812) - danach gut kopiert von Proel... Technik, die begeistert: 8080 und 2708... nicht gerade einfach zu ersetzen. Ich messe mich an der Sidam noch zu Tode... Vielleicht kann mir mal jemand 8080 erklären, diese Prozessorgeneration scheint nicht ganz trivial zu sein. Nach dem Start der PCB steht das Ready-Signal des Prozessors stabil auf High. Das sollte so nicht sein. Leider entspricht der Aufbau der Sidam PCB in keinster Weise weder dem Original (Taito), noch der Kopie (Lich). Also darf ich mir einen Wolf(gang) suchen... Die Russen sind da - hat schon Meister Eckart gestammelt... Auch bei mir sind sie eingezogen, in Form von billigen 8080 CPU-Clones: KP580BM80A oder auf Lateinisch KR580VM80A. Die auf dem Seziertisch liegende Invasion macht mich irre und ich will testen, ob es am Prozessor liegt... 8080 sind jetzt nicht so häufig, daher hatte ich mir mal die Russen kommen lassen. Hier mal im Vergleich: Moment... da stimmt doch was nicht - das Teil geht nicht richtig in den Sockel... Argh... die Russen haben wohl noch nie was von Zoll gehört, oder? Der Pinabstand ist hier nicht 2,54mm, sondern glatte 2,50mm. Mit etwas Vorsicht geht ein 40poliges IC gerade so rein, aber kontaktsicher geht anders. An der CPU liegt's übrigens nicht, die Symptome der Invasion ändern sich nicht... Wenn man ganz viel Glück hat, dann tut das System nach einer der vielen Watchdog-Resets sogar kurz was: Phänomenal: wenn ich alle EPROMs ausstecke, dann läuft zwar kein Programm ab, aber der Prozessor rödelt brav vor sich hin. Wenn ich alle EPROMs außer #0 stecken lasse, dann ebenso. {Weiter geht's} Das probehalber neu gebrannte ROM0 (2716 adaptiert auf 2708) hat leider nichts gebracht. Das Verhalten ändert sich nicht. Jetzt muss ich in's Detail gehen... Daten und Adressbusse durchklingeln. Der Prozessor macht nach einem RESET genau neun Zugriffe auf Speicherstellen. Getriggert auf den Pin DBIN kann man das gut erkennen. Hier der Adressbus (ein Bit): Hier der Datenbus: Nun ist Fleißarbeit angesagt: 8 Datenbuspins und 16 Adressbuspins aufnehmen und dann händisch in Hex umwandeln: Ja, ich hätte auch den Logikanalysator nehmen können, aber das waren einfach zu wenige Bits... Das Ergebnis korrespondiert (nach Korrektur des Fehlers in Byte 0 FB-->DB)mit dem Hexdump vom MAME-ROM. Ein Blick in das 8080 Datenbuch ermöglicht ein Disassemblieren: {Noch weiter geht's:} Was für ein Drecksteil... ;-) Als Erstes habe ich mal die Bitmaske auf "immer richtig" geändert. X and 0 ist immer Null. Dann endlich mal einen sauberen 2708-zu-2716-Adapter gebastelt: In Betrieb genommen: Wow - Huston, wir haben ein Bild! Danach allerdings wieder Stille im Digitalwalde... das gleichmäßige Muster am Adressbuss lässt eine Endlosschleife vermuten: Wieder mit der Hand am Arm Daten- und Adressbus durchgeklingelt und disassembliert: WTF! Jetzt fragt er auf Adresse 0x03 das dritte Bit ab... Ich muss unbedingt rausfinden, wo auf dieser blöden Platine I/O-Adresse 3 ist... 8080 ist nicht trivial, I/O-Zugriffe haben keinen eigenen Pin, der das anzeigen würde. Die in den Büchern beschriebenen IN- und OUT-Signale werden erst mühsam generiert, weil der Prozessor während der ersten OP-Code-Microzyklen ein Statuswort auf den Datenbus legt, welches man mit dem SYNC-Pin latchen kann. Daraus kann man dann entnehmen, ob ein I/O Zugriff stattfindet. Die Logik dafür muss ich jetzt auf der Platine suchen, für die ja bekanntlich kein Schaltplan existiert... {Endspurt:} Es ist nicht einfach... der Space Invaders Plan ist ganz anders aufgebaut, der Plan von Lich ist unvollständig... Das hier ist quasi ganz neu. Deswegen ist die Suche auch so schwer - selbst die trickreiche Bitshifter-Aktion hat andere TTLs als im Original. Nur 8080 und die TMS4060 RAMs und die EPROMs sind gleich. Mir bleibt erstmal nur die Möglichkeit, im Assemblercode zu pfuschen: wenn man jetzt aus dem RET NZ ein simples RET macht, dann wird auch wieder der nächste I/O Zugriff ignoriert... Ist es nicht putzig, wie der Kleine den Buchstaben klaut... genau so, wie Sidam das Spiel geklaut hat. Leider springt das Spiel aus dem Attract Modus ganz schnell wieder raus und hängt sich auf... Grafik geht also, nur warum gehen die I/O-Zugriffe nicht? Viel gelernt, das Rumpfuschen im Code macht richtig Spaß - langsam verstehe ich die Leute, die so Sachen wie Highscore Saver machen - aber bei der Reparatur hat mir das bisher leider noch nicht geholfen... Next Step: wenn die Hardware nicht macht, was die Hardware soll, dann muss man eben ein eigenes Diagnoseprogramm schreiben. 8080 hatte ich noch nie, aber der ist fast wie Z80, nur schlechter. Irgendwas geht beim Zugriff auf I/O $03 schief, also möchte ich das permanent gelesene Byte gerne mal auf dem Bildschirm visualisieren, den Watchdog regelmäßig löschen und vorher den Bildschirm reinigen... Dazu ein kurzes Programm, welches als HEX-File in EPROM#0 gebrannt wird: Tatsächlich erscheint nach dem Anschalten nach einem Clear Screen folgendes statisches Bild: Wenn man genau hinsieht, kann man das zurückgelesene I/O-Byte #3, danach 0xAA (10101010) und 0x55 (01010101) erkennen (Bitreihenfolge ist vertauscht!). Jetzt geh ich auf's Ganze: Reverse Engineering des Schaltplanes (das Teil scheint übrigens keinen HW-Barrel-Shifter zu besitzen) und 8080 Assembler-Programmierung. Ich mach die Sau fertig. Diese Platine wird nach meiner Pfeife tanzen! ;-) Die beiden rot markierten Eingänge führen zu den beiden Bits, derentwegen das Programm immer stehen bleibt. Die Sidam Invasion Doku schweigt sich über die Funktion dieser Pins aus. Ich manipuliere händisch, erst mal Edge Connector B12: Dann eine Transistormimik auf der Platine, deren Sinn ich noch nicht begriffen habe: hier erwartet das Programm +5V statt 0... Voila! Das Programm startet, geht in den Attract Screen und stürzt dann beim Aufbau der Invader-Schar ab - das mag aber an defekten RAMs oder schlechten ROMs liegen. Ich wusste doch, dass die TTLs keine Fehlfunktion haben... Nebenbei hab ich übrigens noch Zeichensätze entworfen, 8080 Printchar und Printstring geschrieben, alles von Null an und ausschließlich in Assembler. Und ohne aus dem Netz zu kopieren. ;-) Nachdem stundenlanges Messen, der Entwurf eigener Test-Assemblerprogramme und Sonstiges mir allerlei Interessantes über diese Platine verraten hat - in erster Linie, was alles NICHT defekt ist - habe ich den nächsten logischen Schritt gewagt. EPROMs neu brennen: Dank der Drahtbrücken im Eingangskreis startet alles wie gehabt... ...um dann im Attrakt Screen einfach zu FUNKTIONIEREN! Das ist das Gefühl, welches ich so liebe. ;) {Nachspurt:} Die Sidam-Geschichte war noch nicht ganz fertig... Daher hab ich mal einen hübschen Spezialadapter gebaut, der die richtigen Signale auf das Board gibt, damit das Spiel startet: Mit dem Testrom im Steckplatz 0... ...ergibt sich folgendes Bild: So soll es sein. Die PCB läuft mit dem Adapter problemlos an. Zum Ende der Reparatur habe ich wieder den originalen 8080 eingesteckt: Nee, oder? Der Kollege ist hin - läuft auch mit dem Test-ROM nicht! {Space Invaders Test ROM} Dieses ROM startet ab Adresse 0x0000 und kann als 2708 (oder '16 oder '32, je nach PCB in Steckplatz 0 gesteckt werden. Es löscht den Bildschirm und visualisiert den Zustand der Input-Daten 0, 1, 2 und 3. Je nach Modell finden sich darin die Controls, DIP-Schalter und (wenn vorhanden) Schieberegister. Außerdem wird zyklisch der Watchdog zurückgesetzt. Wenn das Spiel mit diesem ROM funktioniert (die übrigen ROMs können stecken bleiben), dann funktionieren zumindest CPU, Video-Generierung und der Video-Bereich der RAMs - das ist schon mal eine ganze Menge. Wenn das ROM nicht funktioniert, dann kann man damit zumindest schon mal sinnvoll auf Fehlersuche gehen, weil immer nur zyklisch die Displayschleife durchfahren wird.
|
© 2013 - 2023 · W. Robel | e-Mail senden |