Die Verknüpfung klassischer Videospielwelten mit modernen Programmierkonzepten ermöglicht beeindruckende Einblicke in die Welt der Softwareentwicklung. Ein besonderer Fall ist die Integration eines minimalen Echtzeitbetriebssystems (RTOS) innerhalb des NES-Klassikers Super Mario Bros. Diese innovative Umsetzung nutzt die leistungsfähigen Funktionen von Emulator-Save-States, um Multithreading auf einem System zu simulieren, das eigentlich keinerlei native Unterstützung dafür besitzt. So entsteht eine faszinierende Symbiose aus Retro-Gaming und moderner Computertechnik. Das zentrale Konzept hinter der Umsetzung ist die Kombination aus mehreren Instanzen des Spiels, die als „Threads“ agieren.
Statt ein echtes Multithreading auf Hardware-Ebene, wie in aktuellen Betriebssystemen üblich, werden mittels des Emulators drei parallele Spielzustände gespeichert. Jeder dieser Zustände repräsentiert eine unabhängige Spielsitzung von Super Mario Bros., von der alle im selben Startlevel (World 1-1) beginnen. Ein eigens entwickelter Thread-Scheduler sorgt im Hintergrund dafür, dass in regelmäßigen Intervallen zwischen diesen „Threads“ gewechselt wird. Die technische Grundlage dazu bildet der NES-Emulator FCEUX, der durch eine Lua-Schnittstelle die Möglichkeit bietet, Speicherzustände des Spiels zu erzeugen und zu laden.
Diese sogenannten Save States speichern den kompletten Status des Emulators – inklusive CPU-Register, RAM-Inhalt und Grafikspeicher – und lassen sich beliebig später wiederherstellen. Über diese Methode realisiert das Projekt eine Art „Kontextwechsel“ zwischen den Spiel-Instanzen, ganz ähnlich zur Thread-Verwaltung in einem Betriebssystem. Der Thread-Scheduler wurde so implementiert, dass alle 160 Frames der Emulator von einem Save State zum nächsten wechselt. Zusätzlich wird während des Umschaltens die Farbpalette verändert, um visuell darzustellen, welcher „Thread“ gerade aktiv ist. Den Zuschauern bietet das eine bunte Abfolge, bei der der Spielbildschirm scheinbar wild die Farben wechselt, da unterschiedliche Versionen von Super Mario Bros.
in schneller Abfolge dargestellt werden. Im Gegensatz zu simplen Zeitmultiplexing geht das Projekt jedoch noch einen Schritt weiter und führt klassische Synchronisationsmechanismen ein, die das Verhalten von Multithreaded-Systemen nachahmen. So wurden verschiedene Spielbereiche mit sogenannten Synchronisationsprimitiven verbunden. Diese fungieren ähnlich wie Mutexe (wechselseitiger Ausschluss), Bedingungsvariablen oder Sperrmechanismen, mit denen Threads koordiniert werden. Durch diese interaktiven Bereiche wird das Verhalten der einzelnen Mario-Instanzen gegenseitig beeinflusst und voneinander abhängig gemacht.
Ein Beispiel: Wenn ein Mario die ersten drei Blöcke im Startlevel betritt, werden Interrupts deaktiviert, wodurch der Scheduler nicht wechseln kann. Das simuliert einen Abschnitt des Spiels, in dem der gerade aktive Thread exklusiv die Kontrolle behält. Eine andere Stelle ist ein spezielles Rohr, das einem Mutex entspricht. Nur ein Mario darf sich zu einem Zeitpunkt in diesem Rohr-Sublevel befinden. Taucht ein weiterer Mario dort auf, wird dessen Thread blockiert, bis das Rohr wieder frei wird.
Am Ende des Levels wartet jeder Mario an einer Bedingungsvariablen – dem Flaggenmast. Erst wenn alle Marios diesen berührt haben, können die Threads wieder unblocked und fortgesetzt werden. Darüber hinaus ist das System in der Lage, Schlafzustände für Threads zu simulieren. Nach der Eliminierung eines Gegners schläft der jeweilige Thread für einen definierten Zeitraum, der mittels Frames gemessen wird. Das Schema sorgt dafür, dass sich das Verhalten der Threads lebendig und dynamisch anfühlt, ohne dabei die grundsätzlichen Synchronisationsregeln auszuhebeln.
Das Projekt zeigt eindrucksvoll, wie sich ein eigentlich einfaches Spiel aus den 80er Jahren zu einem lebendigen Experimentierfeld für Softwaremechaniken und theoretische Konzepte umwandeln lässt. Dabei werden ganz praktische Prinzipien eines RTOS sichtbar und greifbar gemacht, die sonst eher abstrakt und unsichtbar im Hintergrund moderner Systeme laufen. Auch aus pädagogischer Sicht bietet die Umsetzung einen enormen Wert: Sie entmystifiziert das Konzept von Threads und Concurrency, indem sie es in einer spielerischen und vertrauten Umgebung präsentiert. Anstatt trockene Theorie zu vermitteln, lässt sich hier mit eigenen Augen nachvollziehen, wie Threads um CPU-Zeit konkurrieren, auf Ressourcen zugreifen und synchronisiert werden. Die Visualisierung mittels Farbwechsel und Spielpositionen macht die unsichtbaren Abläufe von Betriebssystemen für jedermann verständlich und nachvollziehbar.
Entwickelt wurde der Thread-Scheduler vollständig in Lua, einer leichtgewichtigen Skriptsprache, die vom NES-Emulator FCEUX unterstützt wird. Die Codebasis ist dabei überschaubar und auf etwa 300 Zeilen begrenzt. Angesichts der Komplexität der realisierten Funktionen ist dieser Umfang besonders beeindruckend. Er zeigt, wie mit relativ wenigen Zeilen Code ein System entstehen kann, das typische Betriebsystemkonzepte simuliert – und das auf einer Hardware, die eigentlich jedwede Multithreading-Funktionalität kategorisch ausschließt. Das Projekt illustriert außerdem, wie eng verwandt Softwareemulation und Betriebssystemtechnik sind.
Emulatoren bieten einerseits eine exakte Nachbildung alter Hardware, andererseits eröffnen sie die Möglichkeit, Experimente anzustellen, die mit Originalhardware nicht möglich wären. Indem die Technik der Save States adäquat eingesetzt wird, wird eine wörtliche Ebene eingeführt, auf der virtuelle Maschinen multithreaded agieren, ohne dass die zugrundeliegende Hardware dies unterstützt. Diese Arbeit eröffnet spannende Perspektiven für die Zukunft von Gaming und Softwareentwicklung. Einerseits könnten ähnliche Techniken zur Forschung und Lehre eingesetzt werden, um schwierige Konzepte über interaktive und visuell fassbare Methoden zu vermitteln. Andererseits stellt sich die Frage, ob und wie diese Ideen weiterentwickelt werden können, um eventuelle Probleme in klassischen Systemen zu simulieren und zu lösen – wie zum Beispiel Deadlocks, Prioritätsumkehr oder Fairness bei der Ressourcenvergabe.
Die Grenzen des Projekts sind jedoch ebenfalls klar: Es handelt sich nicht um einen voll funktionsfähigen Scheduler wie in einem echten Betriebssystem. Wichtige Features wie dynamisches Thread-Spawning, komplexe Semaphore, Prioritätssteuerung oder ausgefeilte Deadlock-Vermeidungsmechanismen fehlen. Verschiedene Szenarien, insbesondere wenn alle Threads schlafen oder blockiert sind, können zu einem Spielabsturz führen. Trotzdem ist das Experiment ein eindrucksvoller Beweis für die Machbarkeit und bietet einen soliden Grundstein für weitere Arbeiten. Die kreative Kombination aus Retro-Game und moderner Threadtechnik begeistert nicht nur Entwickler, sondern auch Spielbegeisterte und Technikinteressierte gleichermaßen.
Indem Super Mario Bros. als lebendige Plattform genutzt wird, um Softwaretheorie greifbar zu machen, wird das scheinbar Banale zum faszinierenden Werkzeug der Bildung und Forschung. Interessierte können das Projekt nachbauen, indem sie eine legale Kopie des Super Mario Bros. ROMs beziehen, den FCEUX-Emulator herunterladen und das zugrundeliegende Lua-Skript laden. So lässt sich die multithreaded Spielversion live erleben und eigene Experimente durchführen.
Die Open-Source-Community profitiert damit von einem innovativen Beispiel, das zu weiterem Tüfteln und Verstehen anregt. Insgesamt zeigt dieser ungewöhnliche Ansatz, dass technische Grenzen oft nur konzeptionell existieren und mit ein wenig Kreativität elegant überwunden werden können. Von einem einfachen Jump'n'Run zur Plattform für Betriebssystemexperimente ist ein weiter Weg, der zeigt: Softwareentwicklung lebt durch Ideen und deren mutige Umsetzung – auch wenn diese zunächst absurd erscheinen. Super Mario Bros. begegnet so einem faszinierenden Zwischenschritt zur Programmierung von Multithreading, Synchronisation und Scheduling, bereitgestellt in einer Umgebung, die Millionen Spieler rund um den Globus seit Jahrzehnten begeistert.
Die Reise in diese Welt ist ebenso lehrreich wie unterhaltsam und verdeutlicht, dass Verständnis für grundlegende Konzepte zur Verbesserung und Innovation in der Softwareentwicklung unerlässlich bleibt.
![Why Ghostty is written in Zig (not Rust or Go) [video]](/images/30F503DA-81B5-4A5C-8D93-94999333E0B0)
