Hardware > Emulatoren

TOS 1.4 MFP init Endlosschleife

(1/2) > >>

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.

Navigation

[0] Themen-Index

[#] Nächste Seite