Was macht ein 65x02, wenn er "abstürzt"?

N'Abend,

kleine Überlegung beim Brüten über meiner alten Firmware für und dem Zusatzkabelverhau an meinen Taiwan-Clone (GTAC-2), den ich damals als EMUF betrieb, also als universellen 6502-Rechner ohne Apple-ROM-Inhalte. Ich habe diese Fragen in den Apple-Bereich gehängt, auch wenn er in anderen 6502-Welten genausogut aufgehoben wäre.

Kann ein 6502 so hängenbleiben, daß er keine Befehle mehr ausführt? Als Beispiel: der läuft in einen Speicherbereich, der keine gültigen 6502-Opcodes enthält. Die CMOS-Variante hat an den Stellen ohne reguläre Opcodes in der Matrix immer ein NOP, meist mit 2Zyklen, an einigen Stellen mit 3Zyklen, AFAIR. CMOS immer NOP, d.h. der läuft durch diesen Bereich und findet irgendwann wieder einen gültigen Befehl. Auch wenn der 0x00 und somit ein BRK ist. Dann gibt's Ausnahmebehandlung über den Vektor. Wenn er dann in die "Pampa" springt (z.B. wg. falschem Bank-Switching) läuft er immer noch irgendwie weiter. Und wenn er letztendlich nur noch BRKs ausführt ...

Die NMOS-Variante hat je nach Hersteller mehr oder weniger sinnvolle und/oder interessante Befehle. D.h. man weiß nicht, wie ein 6502 (zudem herstellerabhängig) durch einen Bereich der illegal Opcodes kommt. Laut Wiki gibt's darunter einen HALT-Befehl. Der terminiert die Ausführung und kann nur durch Reset beendet werden. Aber alle anderen? Den WAIt-Befehl der späteren 6502-Varianten lasse ich mal weg, denn der ist offiziell und beschrieben, und der ist bei den NMOS- und alten CMOS-Varianten noch nicht existent.

Ich stehe gerade vor der Frage, ob ich meine Lösung aus den 1980ern wieder einbaue, die zwei LEDs leuchten läßt, die an A0 und /A0 hängen. Dort kann ich ablesen, ob die CPU noch Zugriffe veranstaltet, so meine damalige Idee. D.h. beide leuchten: die CPU rennt, auch wenn es eine Endlosschleife ist. Aber ein HALT würde das vermutlich detektieren, indem nur noch eine leuchtet. Oder eben, wenn der 6502 aus irgendwelchen anderen Gründen intern hängenbleibt ...

Das Leuchten bezieht sich natürlich auf die Trägheit des menschlichen Auges, das das Blinken mit 500kHz nicht auflösen kann.

Ich weiß, daß ich stattdessen oder ergänzend eine Watchdog-Schaltung einbauen könnte. Aber das ist ein anderes Thema.

Gruß, Ralf

Zitat von Diddl

Soviel ich weiß läuft die 6502 CPU immer

Genau das ist der Kern meiner Überlegung (und damaligen Annahme, daß dies nicht so sei).

Zitat von Reinhard

Aber das ist doch völlig egal, denn bei einem Bxx * wackelt A0 auch schön weiter...

Endlosschleifen als System-"Absturz" sind eine andere Sache, egal wie elegant man sie bastelt. Da hilft nur ein Watchdog.

Zitat von Reinhard

Was beim 6502 nicht passieren kann, ist dass der Stackpointer durch den gesamten Adressbereich läuft und alles platt macht.

Das passiert doch bei einem Absturz anderer Prozessoren recht häufig.

Wenigstens diesen Vorteil hat die Stack-Konstruktion des 6502.

Zurück zu meiner Ausgangsfrage: ihr seid beide der Meinung, daß ein 6502 immer versucht Befehle zu lesen, sie zu dekodieren und auszuführen egal was kommt. Ausnahme: es gibt einen HALT-Befehl wie bei den jüngeren 65C02 oder ggf. einigen alten NMOS-Designs, aber dort undokumentiert als illegal Opcode.

2:0 Danke. Ich lasse jetzt die alten LEDs weg.

Gruß, Ralf

Zitat von x1541

Wäre tatsächlich mal interessant zu sehen, was die CPU macht wenn sie auf einen KIL/JAM/HLT illegal opcode trifft.

Wer einen Logic Analyzer hat, kann den "mal kurz" anklemmen Ich habe hier nur ein Oszi ohne dem Zusatzwort "Speicher". Da läßt sich diese Aufgabe eher nicht lösen. Außerdem stelle ich gerade fest, daß meine Auswahl an NMOS-Varianten ziemlich überschaubar ist: nur UMC und Rockwell, falls in irgendwelchen Geräte nicht noch andere stecken sollten. Ich hatte bisher "nur" bei den CMOS-Varianten für Auswahl im Lager gesorgt

Zum Hintergrund des Rechners: dieser 6502-EMUF (auf Basis der Apple-II-Clone-Hardware) war seinerzeit mein erster Rechner, den ich als Embedded-/Standalone-/Wie-auch-immer-ohne Tastatur-und-an-die Wand-genagelt-Gerät laufen ließ. Ich kann heute nicht mal mehr genau nachvollziehen, auf welchem Wissensstand ich seinerzeit bzgl. Hard- und Software sowie Betriebssystemen war. Ich lötete so einiges dran und um, z.B. die ROM-Karte des GTAC-2-Boards bekam 8kB SRAM statt dem ROM auf den niederen Adressen sowie ein 8kB-EPROM in dem Sockel, der für 4kB vorgesehen war. Vom Game-Port bastelte ich mir den Softswitch dafür. D.h. ich fand damals eine Software-Lösung fürs Umschalten vom ROM, das die Vektoren enthält. Es war mein erster Versuch ein Minimalbetriebssystem zu schreiben. Auf der anderen Seite hielt ich damals noch nicht viel von Versionsnummern. Aber ich habe in meiner Firmware immerhin eine Datumsangabe hinterlassen.

Also kurz: wilde Zeiten

Nicht zu vergessen wg. den Vektoren: die Apple-II-Hardware belegt den Speicherbereich der Vektoren mehrfach, teils mit dem F8-ROM zum Booten, aber auch mit RAM von der Language Card und diese im Fall z.B. der Saturn-RAM-Disk gleich mehrfach parallel. D.h. man kann sich mit Apple-II-Hardware ziemlich verheddern, wenn man die Vektoren für IRQ, NMI oder BRK braucht.

Gruß, Ralf

Zitat von tofro

Nach allem, was ich mich entsinnen kann, setzt ein 6502 bei JAM/KIL/HLT den Datenbus auf $FF und macht ratzfatz gar nix mehr (auch ein INT oder NMI können ihn nicht wieder wachküssen). Nur ein Reset bringt ihn wieder ans Leben.

Nach dem Überfliegen der Seiten zu den Illegal Opcodes finde ich keine Hinweise, daß sich die 6502-NMOS-Chips verschiedener Hersteller unterschiedlich verhalten. "Damals" wurde das allerdings verbreitet, also damals vor dem Web. Irritierend.

KIL ist verständlich erklärt, IMHO. D.h. diese Befehle sind die einzigen, bei denen die Dekodierung endet. Nicht explizit erwähnt ist das Verhalten des Adreßbusses während dieses Befehls. D.h. meine archaische Methode der Beobachtung von A0 könnte doch den Hinweise liefern, ob der KIL-Befehl die Dekodierung im 6502 beendete.

Aufgabenliste: Also doch einbauen und, wenn die Platine wieder läuft, die KIL-Befehle testen

Gruß, Ralf

Zitat von tofro

Nach der Erklärung finde ich eigentlich keine Hinweise, dass sich die CPUs verschiedener Hersteller unterschiedlich verhalten können.

Eben. Ich bin deswegen etwas verwirrt, weil ich das so in Erinnerung habe, daß "damals" Tabellen kursierten, die einzelne illegal opcodes ausdrücklich einzelnen Herstellern zuschrieben. Ich sage: Erinnerung! Daher habe ich gerade in der Fachzeitschrift für Apple II aus jener Zeit nachgeschaut und finde im Peeker 5/1985 einen Artikel inkl. Disassembler zu genau diesem Thema. Dort ist genausowenig die Rede von herstellerabhängigen Befehlen und eine (auf den ersten Blick) vollständige Tabelle abgedruckt.

Dann ist die Welt der NMOS-6502-doch viel einheitlicher Bis auf den ROR-Befehl, aber das ist eine andere Geschichte.

Zitat von tofro

Das bedeutet, der Zustand deiner beiden LEDs ist auch mehr oder weniger zufällig und höchstens in der Intensität von einem Blinken zu unterscheiden (falls sie grade an sind). Ich befürchte daher, die LEDs sind eh' ziemlich sinnlos. Ob man allerdings den Fall, dass die CPU in diesen Zustand gerät, überhaupt von einem "normalen" Absturz (z.B. einer Endlosschleife Bxx *) unterscheiden können muss, betrachte ich jetzt eher unakademisch: Kaputt is kaputt.

Wenn die Befehlsdekodierung im 6502 aufhört, dann sollten Adreß- und Datenbus den letzten Zustand behalten, also den aus dem letzten Dekodierschritt, der gelaufen ist. So habe ich diese Ablaufsteuerung mit Auswirkungen interpretiert.

Ich habe gestern Abend die LED-Mimik wieder vervollständigt und werde das mit den KIL-Befehlen testen. Das ist jetzt allerdings nur noch von akademischem Interesse. "Damals", als ich diese Idee hatte, hatte ich eine andere Vorstellung von dem, was um die CPU herum abläuft.