#pragma once

class ThomasHilbert
{
    struct Person
    {
        Motivation;
        Games;
        Kontakt;
    };

    struct Projekte
    {
        Pläne;

        CCM;
        NESulator;
        Abutroid;
        UOSharp;
    };
    
    Downloads;
    Links;

} GameProgrammer;

NESulator

Projektdetails
NES Emulator screen1
Abschluss:2010
Umfang:Vertical Slice
Entwickler:Thomas Hilbert
Rahmen:Hobbyprojekt
Dauer:1 Monat
Plattform:Win32
API:DirectX 9.0c

Dieser Emulator bildet die Hardware des "Nintendo Entertainment System" nach. Das bedeutet, er ist in der Lage, NES-kompatible Software auf dem PC auszuführen.

Technik

Um NES-Software zu emulieren muss der Emulator natürlich alle Komponenten der NES-Hardware in Software abbilden. Dazu gehören unter anderem die CPU, die Grafikhardware, Soundhardware, RAMs, System-Bus und natürlich die Joypads.

Grafik

Mangels programmierbarer Shader-Einheiten rendert die NES-interne PPU (Pixel Processing Unit) alle Pixel allein aufgrund in Hardware verbauter Mechanismen wie Shift-Registern, Latches und Countern. Alle Funktionen der PPU, wie z.B. Scrolling, pixelbasierte Kollisionserkennung, V-Sync und die Darstellung von Sprites basieren auf diesen Hardware-Mechanismen.

Die Software hat diverse Möglichkeiten, in den Render-Prozess einzugreifen. So ist es zum Beispiel möglich, nach dem Rendern einer bestimmten Bildschirmzeile (Scanline) das von der PPU zu verwendende Tileset oder den aktuellen horizontalen Scroll-Offset umzuschalten. So erreichen viele Spiele einen Split-Screen-Effekt. Um diese Möglichkeit auch im Emulator sauber anbieten zu können, muss das Verhalten der PPU im Emulator so detailgetreu wie möglich nachgebildet werden.

Die Steuerung der PPU und Abfrage ihres Status geschieht über Register, welche in den Addressbereich der CPU geschaltet werden (siehe System).

All diese Aspekte machten das Verstehen und Umsetzen dieser Mechanismen zu einem der interessantesten Tasks des Projekts.
Wer sich ein Bild davon machen möchte (lol), dem empfehle ich folgende, nahezu vollständige Dokumentation der PPU.

Sound

Genau wie die PPU ist auch der Soundgenerator des NES ein rein auf Countern und Latches aufgebautes Hardware-Monster, allerdings lange nicht so komplex wie die PPU.

Cartridges

Als Spiele noch auf Steckmodulen verkauft wurden, war es üblich, die Module mit Zusatzhardware zu erweitern. Dies ermöglichte Spiele-Entwicklern beispielsweise, neben dem NES-internen RAM/VRAM zusätzlichen Speicher auf dem Modul unterzubringen. Auch zusätzliche Soundkanäle, DMA-Geräte und batteriegestützer Speicher waren durchaus üblich.

NESulator unterstützt die gängigsten Hardwareerweiterungen, so dass die wichtigsten NES-Spiele ausgeführt werden können. Weitere Hardware-Erweiterungen zu supporten ist lediglich eine Frage der verfügbaren Zeit, und davon hab ich aktuell leider nicht allzu viel.

CPU

Im NES wurde die damals sehr populäre 6502 verbaut, allerdings mit einigen kleinen Modifikationen.
Der Nachbau einer CPU in Software ist eine äußerst zeit- und test-intensive Angelegenheit, weshalb ich diese Komponente (als einzige) bereits als fertiges Modul aus dem Netz besorgt habe. Lediglich die NES-spezifischen Anpassungen hab ich selbst vorgenommen. Ist trotzdem sehr interessant, sowas mal gesehn zu haben.

System

Alle oben genannten Komponenten sind für sich allein natürlich machtlos. Erst ihre Anbindung an den Systembus und das Interrupt-System machen aus den Komponenten ein funktionsfähiges NES.

Wie bereits unter Cartridges erwähnt, kann das NES um zusätzliche Hardware erweitert werden. Die Emulation der NES-Hardware muss diesen Umstand durch eine flexible Software-Architektur nachbilden, welche das dynamische Verschalten und Hinzufügen von Hardware an den Systembus erlaubt. Viele Geräte wie z.B. ROM-Chips ändern ihre Adresse am System- oder Grafikbus regelmäßig, oft sogar mehrmals pro Frame. Andere Geräte hängen sowohl am Grafik- als auch am Systembus. Manche Mapper zählen rising edges an der Addressleitung A12 des Grafikbus, um nach einer bestimmten Zahl gerenderter Scanlines einen IRQ auszulösen.

Somit gilt auch hier: je näher die Emulation das tatsächliche Verhalten der Hardware nachbildet, desto überschaubarer wird der Code und desto besser werden die Ergebnisse der Emulation.

Motivation

NESulator ist eigentlich mein zweiter NES-Emulator. Bereits 2003 hab ich mich an einem solchen Emulator versucht. Einfache Spiele, die ohne Hardwareerweiterungen auskommen, konnte dieser bereits sauber ausführen. Der Support für komplexere Spiele gestaltete sich aufgrund der darauf nicht vorbereiteten Programmstruktur des komplett in C programmierten Emulators allerdings sehr schwer und wurde letztlich nie umgesetzt. Außerdem unterstützte dieser Emulator keinen Sound, weil mir damals schlicht die Kenntnisse dazu fehlten.

Während der letzten Jahre allerdings schwirrte mir dieser Emulator immer wieder im Kopf herum und ich war mir sicher, dass der nächste Versuch gelingen würde. Nach dem Abschluss von CCM war dann endlich Zeit. Also nichts wie ran, und 4 Wochen später war NESulator in voller Pracht vollendet (hust). Naja, es gibt da noch ein paar Bugs. Der Sound knackt und läuft nach einigen Minuten Spielzeit nicht mehr synchron. In Super Mario Bros. 3 gibt es ein Problem mit den Sprite-Prioritäten und in Zelda 2 sind die Sprites sogar noch schlimmer. Trotzdem: die Mission ist erfüllt. NESulator ist bereit, jegliche Form von NES-Programm zu supporten, und mit ein paar wenigen Bugfixes sollte er dem wahren NES in nichts nachstehn.



NESulator steht im Downloadbereich zur Verfügung.