gameboy-sharp
Ein Game-Boy-Emulator (DMG) in C#. Ein frontend-unabhängiger Kern, sodass die gesamte Maschine läuft und headless gegen Standard-Test-ROMs verifiziert wird.
Ein Game-Boy-Emulator (Modell DMG), geschrieben in C#. Der Kern ist vom Frontend getrennt und wird headless gegen Standard-Test-ROMs geprüft, damit fremde Spiele Bit für Bit laufen.
Überblick
gameboy-sharp ist ein Emulator des originalen Game Boy, des Modells DMG, geschrieben in C#. Die Aufgabe klingt einfach: Spiele, die vor dreißig Jahren erschienen sind, ohne die Änderung eines einzigen Bytes laufen lassen. Die Schwierigkeit steckt im Wort "originalgetreu" - der Emulator muss die Hardware so genau nachahmen, dass der Originalcode nichts bemerkt.
Wir haben den Kern so gebaut, dass er nichts von einem Fenster oder vom Ton weiß. Die ganze Maschine ist eine reine Bibliothek, die einen Bildpuffer und Audio-Samples zurückgibt, und erst das Frontend verwandelt sie in das, was Sie sehen und hören. Genau das erlaubt es, die ganze Konsole ohne Bildschirm laufen zu lassen und ihr Ergebnis mit dem zu vergleichen, was herauskommen sollte.
Fehler in einem Emulator stürzen fast nie mit Getöse ab. Das Spiel startet, das Spiel läuft - nur der Ton ist eine Spur zu hoch, oder die Figur bewegt sich einen Pixel zu weit. Es gibt keine Ausnahme, keinen Absturz, nur ein subtil falsches Verhalten, das Sie "mit bloßem Auge" nicht vom richtigen unterscheiden können.
Das ändert die ganze Arbeitsweise. Sie können dem Eindruck, es "sieht gut aus", nicht trauen, denn genau dieser Eindruck lügt am häufigsten. Das Einzige, dem man trauen kann, ist der Vergleich des Maschinenzustands mit einem Wert, den Sie im Voraus kennen - und genau darum ist das ganze Projekt herum gebaut.
Das Herz der Maschine: die CPU
Das Herz der Konsole ist die CPU des Game Boy, eine Z80-Variante. Jede Instruktion ist das Lesen eines Opcode-Bytes und das Ausführen genau dessen, was das Original tun würde, samt der Anzahl der Zyklen, die diese Instruktion kostet. Timing ist kein Detail - es entscheidet, ob Ton und Bild so synchronisiert sind wie auf echter Hardware.
Eine Instruktion und ihre Kosten in Zyklen
| Opcode | Instruktion | Zyklen |
|---|---|---|
| 0x00 | NOP | 4 |
| 0x3E | LD A, d8 | 8 |
| 0xC3 | JP a16 | 16 |
Der Kern weiß nichts von einem Fenster oder vom Ton - er ist eine reine Maschine. Das Frontend bekommt nur einen Bildpuffer und Audio-Samples. Genau das erlaubt es, die ganze Konsole ohne Bildschirm laufen zu lassen und das Ergebnis mit dem Erwarteten zu vergleichen, Zyklus für Zyklus.
Tests bis auf den Zyklus genau
Die Emulations-Community pflegt Sätze von Test-ROMs, die einzelne Register, Flags und das Timing bis auf den Zyklus prüfen. Wir führen sie headless aus und vergleichen den Maschinenzustand mit dem, was herauskommen sollte. Das ist der einzige ehrliche Weg, um zu sagen, dass ein Emulator korrekt ist, und nicht nur "läuft bei mir".
Genau deshalb wurde der Kern vom Frontend abgetrennt. Bräuchte die Maschine ein Fenster, müsste jeder Test von Hand durchgeklickt werden. Da sie eine reine Bibliothek ist, laufen die Test-ROMs automatisch durch, und das Urteil ist binär: es stimmt oder nicht.
Das Ergebnis: fremde Spiele Bit für Bit
Heraus kommt ein Emulator, der fremde Spiele startet und die standardmäßigen Test-ROMs besteht, und nicht nur einer, der das Nintendo-Logo zeigt und stehen bleibt. Der Ton ist dort, wo er sein soll, die Figur bewegt sich um so viele Pixel, wie sie soll, und die Korrektheit ist durch Tests bewiesen, nicht durch einen Eindruck. Es ist ein Projekt aus Liebe zur alten Hardware, gebracht in einen Zustand, in dem man das sieht.
Weitere Projekte
Weitere Projekte aus derselben Kategorie - sehen Sie, wie wir ähnliche Herausforderungen angehen.
Haben Sie ein ähnliches Projekt?
Melden Sie sich - ein Angebot ist kostenlos und kommt innerhalb einer Stunde.



