TOS 1.4 MFP init Endlosschleife

[hausdorff]

Hallo zusammen,

ich hoffe, daß ich mit meiner Noob-Frage im richtigen Subforum gelandet bin.
Ich bin gerade dabei, meinen eigenen sehr bescheidenen Emulator zu schreiben. Auf dem aktuellen Stand sind sämtliche CPU-Instruktionen implementiert, und ich versuche nun, ein TOS-Image zum Laufen zu bekommen, indem ich nach und nach alle benötigten Devices (alles noch sehr rudimentär) implementiere.

Momentan hänge ich aber an folgendem Problem: In der Subroutine fc34fc ("MFP init") gerät der Code in eine Endlosschleife, und ich sehe beim besten Willen nicht, wie man da herauskommt (Interrupts sind zu diesem Zeitpunkt noch abgeschaltet, und aus dem Code ist schwer ersichtlich, was eigentlich von der realen Hardware an dieser Stelle erwartet wird).

Weiß vielleicht jemand, was in dieser Routine genau passieren soll, oder gibt es irgendwo ein Dokument, in dem das genauer beschrieben ist?

Viele Grüße
Christian

[czietz]

Hilfreich wäre, wenn Du beschreibst, wo genau (in welchen Instruktionen) Dein Emulator in eine Endlosschleife gerät. Dann kann ich Dir sicherlich erklären, was an genau dieser Stelle passiert.

EDIT: Auf den ersten Blick (mit Ghidra) sehe ich in der genannten Routine bei 0xfc34fc in TOS 1.04 keine Endlosschleife. Umso wichtiger, dass Du obige Frage nach der genauen Stelle beantwortest.

Sehr viele Leute finden übrigens EmuTOS super hilfreich, um neue Hardware (oder in Deinem Fall: neue emulierte "Hardware") zum Laufen zu bringen. Es liegt im Quelltext vor, weitgehend in C und somit verständlich und man kann entweder per Compile-Option oder notfalls durch Auskommentieren Dinge herauswerfen, die man (noch) nicht unterstützt.

[hausdorff]

Vielen Dank für die schnelle Antwort und den Hinweis auf EmuTOS, das werde ich auf jeden Fall mal austesten. Ich weiß, daß meine Frage leider hinreichend unspezifisch ist, aber es ist nicht so, als ob der Emulator irgendwo in einen hard loop von einer Handvoll Instruktionen geriete. Vielmehr ist das hier der "call graph":

$00fc0034
    [...]
    bsr $00fc34fc
        bsr $00fc36ac
            bsr $00fc371e
                bsr $00fc3726
            [...]
        bsr $00fc36ac
            bsr $00fc371e
                bsr $00fc3726
            [...]
        bsr $00fc3656
        bsr $00fc4232
        bsr $00fc3762 (*), aufgerufen von $00fc3634
            bsr $00fc3788
                bsr $00fc37e2 [4x]
            bsr $00fc37c2
                bsr $00fc37e2 [2x]

Ab (*) wird der call graph periodisch: Ab dem zweiten Call nach fc3762 kommt man nach einigen Zyklen wieder an dieselbe Ursprungsadresse mit identischem Registerinhalt:

╔══════════════════════════════════╦═══════════════════════════════════════════════════════╗
║ CPU state                        ║ Next instruction: bsr $00fc3762                       ║
╟─────┬───────────┬────┬───────────╫──────────┬──────────────────┬─────────────────────────╢
║ A0  │  00000000 │ D0 │  00fc3640 ║ 00fc3626 │ 2401             │ move.l d1,d2            ║
║ A1  │  00000000 │ D1 │  00fc3637 ║ 00fc3628 │ 2001             │ move.l d1,d0            ║
║ A2  │  00040000 │ D2 │  03f0d8dc ║ 00fc362a │ 0600 0009        │ addi.b #$09,d0          ║
║ A3  │  00fc369c │ D3 │  00000000 ║ 00fc362e │ e582             │ asl.l 2,d2              ║
║ A4  │  00fc0652 │ D4 │  00000000 ║ 00fc3630 │ 2473 2000        │ movea.l (a3,d2.w),a2    ║
║ A5  │  00000000 │ D5 │  00400000 ║>00fc3634 │ 6100 012c        │ bsr $00fc3762           ║
║ A6  │  00fc00dc │ D6 │  00000000 ║ 00fc3638 │ 51c9 ffec        │ dbf d1,$00fc3626        ║
║ A7  │  00003786 │ D7 │  00000000 ║ 00fc363c │ 45f9 00fc 3aec   │ lea (00fc3aec).l,a2     ║
╟─────┼─┬─┬─┬─┬─┬─┼────┼───────────╢ 00fc3642 │ 7006             │ moveq #$06,d0           ║
║ IRQ │S│X│N│Z│V│C│    │           ║ 00fc3644 │ 6100 011c        │ bsr $00fc3762           ║
╟─────┼─┼─┼─┼─┼─┼─┼────┼───────────╢ 00fc3648 │ 45f9 00fc 38aa   │ lea (00fc38aa).l,a2     ║
║ 111 │1│0│0│0│0│0│ PC │  00fc3638 ║ 00fc364e │ 7002             │ moveq #$02,d0           ║
╚═════╧═╧═╧═╧═╧═╧═╧════╧═══════════╩══════════╧══════════════════╧═════════════════════════╝

Das ist am Ende auch der Grund für meine recht unspezifische Fragestellung. Ich kann den Inhalt einzelner Instruktionen einigermaßen interpretieren, für oben genanntes Problem fehlt mir allerdings das "big picture", daher die Frage nach Literatur, die mir eventuell entgangen ist.

Viele Grüße
Christian

PS.: Den source code zum Möchtegern-Emulator gibt's hier, falls jemand daran interessiert ist: https://github.com/christiankuhl/em68k

[czietz]

Die gezeigte Stelle rund um 0x00fc3634 ist die Initialisierung mehrerer Interrupt-Vektoren für MFP-Interrupts.

Aber was mir auf Anhieb auffällt: D1 ist kaputt! D1 ist hier ja der Schleifenzähler und es wird in 0x00FC3624 mit "3" initialisiert und zählt dann runter: 2, 1, 0, -1. Bei Dir aber steht 0x00fc3637 drin. Ich kann leider erst heute Abend selbst probieren, doch ich habe einen Vorschlag: Schau Dir die Stelle im Hatari-Debugger an und vergleiche. Dann solltest Du sehen, wo D1 bei Dir mit einem falschen Wert überschrieben wird.

[czietz]

PS: Die aufgerufenen Unterfunktionen sichern und laden D1 auf/von dem Stack mit MOVEM.L ...,-(SP) bzw. MOVEM.L (SP)+,... Insofern wäre ein Fehler in der Emulation dieser Instruktion ein heißer Kandidat -- meiner Meinung nach. Mangels Rust-Kenntnissen (oder auch nur der Fähigkeit, sowas zu compilieren) kann ich zu Deinem Emulator-Code in dieser Hinsicht leider nicht viel sagen.

[hausdorff]

PS: Die aufgerufenen Unterfunktionen sichern und laden D1 auf/von dem Stack mit MOVEM.L ...,-(SP) bzw. MOVEM.L (SP)+,... Insofern wäre ein Fehler in der Emulation dieser Instruktion ein heißer Kandidat -- meiner Meinung nach. Mangels Rust-Kenntnissen (oder auch nur der Fähigkeit, sowas zu compilieren) kann ich zu Deinem Emulator-Code in dieser Hinsicht leider nicht viel sagen.

Vielen Dank! Das Problem war in der Tat die Implementierung von movem... Habe in der Motorola Spezifikation folgenden Satz überlesen: "When the instruction has completed, the decremented address register contains the address of the last operand stored". Dummerweise waren meine Tests diesbezüglich blind, deshalb ist mir das durchgegangen.

Nach dem Fix habe ich jetzt eine noch viel größere Endlosschleife, aber ein Problem nach dem anderen 

Viele Grüße
Christian

[czietz]

Nach dem Fix habe ich jetzt eine noch viel größere Endlosschleife, aber ein Problem nach dem anderen 

Hatari, den schon in meinem vorigen Post erwähnten Emulator, kennst Du sicherlich? Er hat auch einen relativ mächtigen (wenngleich nicht selbsterklärenden Debugger): https://hatari.tuxfamily.org/doc/debugger.html. Mit dessen Hilfe solltest Du vergleichen können, was bei Dir anders läuft.

[hausdorff]

Nach dem Fix habe ich jetzt eine noch viel größere Endlosschleife, aber ein Problem nach dem anderen 

Hatari, den schon in meinem vorigen Post erwähnten Emulator, kennst Du sicherlich? Er hat auch einen relativ mächtigen (wenngleich nicht selbsterklärenden Debugger): https://hatari.tuxfamily.org/doc/debugger.html. Mit dessen Hilfe solltest Du vergleichen können, was bei Dir anders läuft.

Ja, Hatari habe ich mal kurz angetestet. In den Debugger werde ich mich morgen mal versuchen reinzufuchsen.
Zum aktuellen Stand: Irgendwo überballert mir irgendeine Instruktion den Stack, und ein RTS zuviel schickt mich dann ans Ende des Video RAM, wo die CPU dann Zeit mit Nichtstun verbringt, bis der program counter überläuft und das Spiel von neuem beginnt
Gilt nur, den Übeltäter zu finden, das kann ich aber mit meinem Hirn heute Abend vergessen

Vielen Dank allen für die tatkräftige Hilfe!

[yalsi]

Die 8-Bit Postings sind jetzt hier: https://forum.atari-home.de/index.php/topic,16502.0.html

[Arthur]

Vielen Dank allen für die tatkräftige Hilfe!

Wen meinst du?