Wie funktionieren Emulatoren für PlayStation, Xbox, Windows...?

Was ist ein Emulator? Ein Programm, das ein Gerät auf ein anderes „übersetzt“, ähnlich wie man eine Datei von .docx in .pdf konvertiert? Wäre es so einfach, gäbe es für jede Konsole, die erscheint, auch einen Emulator. Doch dem ist nicht so. Wir warten jahrelang darauf oder bekommen ihn nie. Es ist eine der größten Herausforderungen der Programmierung überhaupt.

Ein Emulator ist kein einfacher Konverter, sondern eine Softwareversion des gesamten Geräts. Prozessor, Grafikkarte, Arbeitsspeicher, Soundchip und Betriebssystem müssen perfekt, in Echtzeit und so präzise zusammenarbeiten, dass das Spiel oder Programm den Unterschied gar nicht bemerkt.

Wo beginnt die Entwicklung? Woher nehmen Entwickler die Ideen für ihre Entwicklungen?

Emulator-Entwickler haben fast nie Zugriff auf die offizielle technische Dokumentation der Konsolenhersteller. Sony, Microsoft oder Nintendo geben ihre internen Spezifikationen nicht preis. Im Gegenteil, sie schützen diese Informationen als Geschäftsgeheimnis. Deshalb beginnt jedes Projekt mit dem sogenannten „Reverse Engineering“. Das bedeutet, dass die Entwickler die Originalhardware zerlegen, die elektronischen Schaltkreise analysieren, Signale zwischen den Chips abfangen und so nach und nach rekonstruieren, was der Prozessor mit jedem Befehl aus dem Hardware-Code der Firmware (also der direkt im Gerät integrierten Software) tatsächlich macht.

Dies erfordert häufig ein „Clean-Room“-Verfahren. Eine Gruppe analysiert und dokumentiert die Funktionsweise des Geräts, während eine andere Gruppe diese Dokumentation nutzt, ohne jemals den Originalcode des Herstellers einzusehen, um ein neues Programm zu entwickeln, das dasselbe Verhalten nachbildet. Diese Trennung ist nicht nur eine technische Formalität, sondern auch eine rechtliche Absicherung, da die Emulation selbst nicht illegal ist, das Kopieren herstellereigenen Codes hingegen schon. Darüber hinaus benötigen Entwickler das originale BIOS oder die Firmware der Konsole, das grundlegende Bootprogramm, das die Hardware steuert. Benutzer müssen dieses in der Regel selbst beschaffen, oft direkt von ihrer eigenen Konsole, da die gemeinsame Verbreitung mit dem Emulator nicht zulässig ist.

Was ein Entwickler wissen muss?

Wer schon einmal die Entwicklertagebücher von Emulatoren wie RPCS3 für PlayStation 3 oder Eden für Nintendo Switch gelesen hat oder lesen wird, dem wird schnell klar, dass solche Entwicklungen ein größeres Team erfordern, nicht nur eine Einzelperson. Man muss ein breites Spektrum an Fähigkeiten beherrschen.

Es erfordert ein umfassendes Verständnis der Prozessorarchitektur, sei es PowerPC (wie im Xbox 360-Prozessor), ARM, MIPS oder x86, einschließlich aller Befehle, Register und Timing-Besonderheiten. Ebenso wichtig ist die Beherrschung der GPU-Funktionsweise und die Übersetzung ihrer Befehle in moderne Grafikschnittstellen wie Vulkan oder DirectX. Dies beinhaltet die Emulation des Soundchips, der Controller, der Speicherhierarchie und des Betriebssystems der Konsole, das Dateien, Threads und Zugriffsrechte verwaltet.

Die größte technische Herausforderung ist oft die dynamische Rekompilierung, auch bekannt als Just-in-Time-Kompilierung (JIT). Anstatt jeden Befehl der Originalkonsole einzeln zu interpretieren, was zu langsam wäre, übersetzt der Emulator die Befehle in Echtzeit in den Maschinencode des Host-Prozessors und führt sie nahezu in nativer Geschwindigkeit aus. Dies erfordert extrem präzise Kenntnisse beider Architekturen gleichzeitig, und das Ergebnis muss bitgenau mit dem Original übereinstimmen, da das Spiel sonst einfriert, abstürzt oder fehlerhafte Grafiken anzeigt.

Warum dauert die Entwicklung Jahre, manchmal Jahrzehnte?

Die Antwort liegt größtenteils in einem einzigen Beispiel – der PlayStation 3. Ihr Cell-Prozessor, der von Sony, Toshiba und IBM gemeinsam entwickelt wurde, war kein herkömmlicher Mehrkernprozessor, sondern eine einzige Hauptverarbeitungseinheit (PPU) in Kombination mit acht speziellen Hilfsverarbeitungseinheiten (SPUs). Jede dieser Einheiten verfügte über einen eigenen kleinen lokalen Speicher und keinen direkten Zugriff auf den Hauptspeicher. Spieleprogrammierer mussten die Arbeit manuell auf diese Einheiten verteilen, da kein Compiler dies automatisch erledigte. Das bedeutete, dass ein Emulator den Code nicht einfach kompilieren konnte, wie es bei einem herkömmlichen Prozessor der Fall gewesen wäre.

Es muss den eigentlichen Zweck des extrem spezifischen, handoptimierten Codes verstehen. Die Entwickler von RPCS3 mussten einen Prozessor entwickeln, der fast alle Annahmen der x86-Architektur bezüglich Speicher, Datenkohärenz und Threads brach, um ihre Programme auf Hardware auszuführen, die nur wenige Gemeinsamkeiten mit Cell aufweist. Der erste öffentlich verfügbare Prototyp des Emulators erschien 2011, und selbst heute, mehr als ein Jahrzehnt später, verkündet das Team gelegentlich Optimierungsdurchbrüche, die erst jetzt Teile von Spielen deutlich beschleunigen, die zuvor entweder gar nicht oder nur mit erheblichen Problemen liefen.

Die Xbox 360 stellt eine ähnliche, wenn auch etwas andere Herausforderung dar. Die Entwicklung des Xenia-Emulators begann 2013 und brachte relativ schnell sein erstes kommerzielles Spiel auf den Markt. Doch 2018 steckten die Entwickler in der akkuraten Emulation der Xenos-GPU fest, was fast drei Jahre und eine komplette Überarbeitung des Grafikcodes erforderte, bevor sich die Leistung deutlich verbesserte. Der Grund für diese langen Entwicklungszyklen liegt nicht in Faulheit oder mangelndem Können, sondern darin, dass der Emulator Tausende von Sonderfällen, spezielle Befehle, Fehler in der Originalhardware, die Spieleentwickler unwissentlich oder absichtlich ausgenutzt haben, und Timing-Besonderheiten verstehen muss, die in keiner Dokumentation beschrieben werden, da es schlicht keine offizielle Dokumentation gibt.

Ein weiterer Faktor ist der juristische Druck. Nintendo ist besonders dafür bekannt, in solchen Fällen hart durchzugreifen. Im Februar 2024 reichte das Unternehmen Klage gegen die Entwickler des beliebten Emulators Yuzu ein und warf ihnen vor, den Verschlüsselungsschutz der Switch illegal umgangen zu haben. Als Beweis diente die Tatsache, dass Zelda: Tears of the Kingdom bereits vor dem offiziellen Release eine Million Mal heruntergeladen wurde.

Tropic Haze, das Unternehmen hinter Yuzu, stimmte einer Entschädigungszahlung von 2,4 Millionen US-Dollar zu und stellte den Emulator vollständig ein. Kurz darauf kontaktierte Nintendo persönlich den Hauptentwickler des Konkurrenzprojekts Ryujinx, um die Entwicklung zu stoppen, die Organisation zu entfernen und alle zugehörigen Assets zu löschen. Solche Fälle verdeutlichen, warum viele talentierte Entwickler lieber auf die „sichereren“ älteren Konsolen setzen, während neuere Projekte oft anonym bleiben oder sich in mehreren parallelen Abspaltungen desselben Originalprojekts aufteilen.

Warum sind manche Konsolen schwieriger zu knacken als andere?

Generell gilt: Je ähnlicher die interne Architektur einer Konsole einem Standard-PC ist, desto einfacher lässt sie sich emulieren. PlayStation 1 und 2 verwenden relativ konventionelle Prozessoren, wurden daher relativ früh emuliert und laufen heute selbst auf weniger leistungsstarker Hardware flüssig. Sobald Hersteller jedoch eigene, nicht standardisierte Lösungen wie Cell in der PS3 einsetzen, steigt die Komplexität exponentiell. Ähnlich verhält es sich mit der Nintendo Switch, die auf einem von Nvidia entwickelten Tegra-Chip basiert und ihre Eigenheiten im Speicher- und Grafikmanagement aufweist.

Die Situation ist bei der neuesten Generation, PlayStation 5 und Xbox Series X/S, noch komplexer, da diese Systeme zwar architektonisch modernen Computern ähnlicher sind (AMD Zen-Prozessoren und RDNA-Grafik), gleichzeitig aber durch deutlich fortschrittlichere Sicherheitsmechanismen geschützt sind als frühere Generationen. Aktuell gibt es praktisch keinen funktionierenden Emulator für diese beiden Konsolen, da die Entwickler noch immer die grundlegenden Sicherheitsebenen knacken – eine deutlich größere und langwierigere Herausforderung als die klassische Hardware-Emulation.

Gibt es Unterschiede zwischen der Emulation auf dem Handy und dem Computer?

Die Emulation auf Mobilgeräten birgt eine zusätzliche Hürde, die Nutzern oft entgeht: den Unterschied zwischen der ARM-Prozessorarchitektur, die in fast allen Smartphones zum Einsatz kommt, und der x86-Architektur, die bei PCs Standard ist. Führt man also einen x86- oder PowerPC-basierten Konsolenemulator auf einem Smartphone aus, muss das Programm gleichzeitig die Anweisungen von der ursprünglichen Architektur in ARM übersetzen. Dies bedeutet zusätzlichen Rechenaufwand, der auf einem PC, dessen Host-Prozessor häufig bereits x86 ist, nicht nötig ist.

Darüber hinaus hat Apple Emulatoren auf iPhones bis vor Kurzem praktisch verboten. Erst im April 2024 erlaubte Apple in seinen App-Store-Richtlinien erstmals explizit Emulatoren für Retro-Spielkonsolen, die nun auch Spiele-Downloads anbieten können. Zuvor war die einzige Möglichkeit, Emulationen auf einem iPhone zu nutzen, entweder ein Jailbreak oder ein komplizierter Umgehungsmechanismus über Web-Apps.

Auch nach dieser Änderung bestehen weiterhin Einschränkungen. Aus Sicherheitsgründen schränkt iOS die sogenannte JIT-Kompilierung, also die dynamische Generierung von Maschinencode während der Programmausführung, streng ein. Diese Methode ist jedoch die wichtigste Technik, um für anspruchsvollere Emulatoren eine akzeptable Geschwindigkeit zu erreichen. Daher laufen viele Emulatoren auf dem iPhone deutlich langsamer als dasselbe Projekt auf Android, wo solche Einschränkungen weitgehend fehlen und Entwickler seit vielen Jahren einen freieren Zugriff auf Systemressourcen haben.

Gibt es einen Windows-Emulator? Winlator, GameHub, GameNative...

Wer meine Handy-Tests kennt, weiß, dass ich neben Android- und Nintendo Switch-Spielen auch häufig verschiedene Windows-Spiele teste. In diesem Fall ist der Begriff „Emulator“ technisch nicht ganz korrekt. Es handelt sich eher um eine Reihe übereinanderliegender Kompatibilitätsschichten.

Winlator ist eine kostenlose Open-Source-Anwendung des Entwicklers BrunoSX (brunodev85), die Windows-Anwendungen (x86_64) und -Spiele direkt auf ARM-basierten Android-Geräten ausführt – ohne BIOS, ohne eine physische Windows-Installation und ohne Festplattenabbild. Winlator kombiniert stattdessen zwei separate Technologien, die jeweils einen Teil des Problems lösen. Die erste ist Wine, ein bekanntes Projekt, das seit Jahrzehnten Windows-API-Aufrufe (Befehle zum Öffnen von Dateien, Zugriff auf die Registry, Zeichnen von Grafiken via Direct3D oder Abspielen von Audio) in Befehle übersetzt, die vom Linux-Kernel verstanden werden, auf dem Android im Hintergrund läuft.

Die zweite Technologie ist Box86 oder Box64, die eine noch grundlegendere Aufgabe erfüllt. Sie übersetzt die Prozessorbefehle selbst in Echtzeit von der x86-Architektur in die ARM-Architektur, da kein Smartphone physisch über einen x86-Prozessor verfügt. Darüber hinaus gibt es eine Grafikschicht. Winlator verwendet den Mesin-Turnip-Treiber für Adreno-GPUs sowie die Tools DXVK und VKD3D, die DirectX-Aufrufe in Vulkan übersetzen, ähnlich wie Proton unter Linux.

Der Benutzer erstellt innerhalb der Anwendung einen sogenannten Container, eine Art isolierte virtuelle Umgebung, in der er die Auflösung, die virtuelle Menge an VRAM, die Anzahl der Prozessorkerne und die Treiber für jedes Spiel oder Programm separat festlegt.

Da zwei aufeinanderfolgende Übersetzungen erfolgen (zuerst API-Aufrufe, dann Prozessorbefehle), ist die Belastung der Smartphone-Hardware deutlich höher als bei klassischer Konsolenemulation. Aus diesem Grund läuft Winlator mit älteren oder weniger anspruchsvollen Spielen relativ gut, während es bei modernen AAA-Titeln mit rechenintensiven Grafik-Engines wie der Unreal Engine häufig zu Rucklern bei der Shader-Kompilierung und starker Geräteerhitzung kommt. Das RedMagic 11S Pro kam bisher am besten mit der Hitze zurecht, benötigte dafür aber einen Lüfter und eine Wasserkühlung.

Gibt es Unterschiede zwischen GameHub und GameNative?

Als Winlator genügend Popularität erlangte, entstanden Konkurrenten, die im Grunde die gleiche technologische Grundlage nutzten (Wine, Box64, Vulkan), sich aber darin unterschieden, wie benutzerfreundlich alles verpackt war.

GameNative entstand aus dem Pluvia-Projekt, einem inoffiziellen Steam-Client, der es Nutzern ermöglichte, sich über Winlator in ihren Steam-Account einzuloggen und Spiele direkt aus ihrer Bibliothek zu starten, ohne manuell online nach Installationsdateien suchen zu müssen. GameNative wurde als Ableger des Pluvia-Projekts entwickelt und wird aktuell schneller und aktiver als das ursprüngliche Projekt weiterentwickelt.

GameHub hat einen etwas anderen Ursprung. Die App, ehemals bekannt als GameFusion, stammt vom chinesischen Hersteller von Gaming-Controllern, Gamesir, und zeichnet sich vor allem durch ihre Benutzerfreundlichkeit aus. Sie unterstützt die Steam-Anmeldung, was der offizielle Winlator standardmäßig nicht ermöglicht, und auch die Vibrationsfunktion von Controllern. Da es sich um ein Produkt eines chinesischen Hardwareherstellers handelt, kamen in der Community Bedenken hinsichtlich des Datenschutzes auf. Daher wurde eine Version namens GameHub Lite ohne integrierte Tracking-Funktionen entwickelt.

Ist es besser, das Ergebnis oder das gesamte Gerät zu emulieren?

Emulatoren müssen nicht immer jeden Transistor des Originalsystems nachbilden. Sie verwenden häufig eine High-Level-Emulation (HLE). Anstatt eine gesamte Hardware oder Systemsoftware detailliert zu emulieren, erkennt der Emulator, was das Spiel erreichen möchte, und führt dieselbe Funktion mit einer eigenen Implementierung aus.

Das Gegenteil ist die LLE (Low-Level-Emulation), bei der der Entwickler versucht, dem tatsächlichen Verhalten der ursprünglichen Hardware oder Firmware so nahe wie möglich zu kommen.

HLE kann deutlich schneller sein. Das Problem entsteht, wenn das Spiel eine Funktion nicht wie vorgesehen nutzt. Wenn ein Spieleentwickler eine undokumentierte Besonderheit des realen Systems entdeckt und diese gezielt ausnutzt, kann eine elegante HLE-Implementierung zwar das „logisch korrekte“ Verhalten zeigen, die ursprüngliche Konsole aber etwas völlig anderes tun.

Warum funktioniert ein Spiel einwandfrei, während ein anderes gar nicht erst startet?

Wenn ein Emulator eine PlayStation 2 emulieren kann, warum sollte es dann überhaupt eine Rolle spielen, welches PS2-Spiel ich ausführe? Weil kein Spiel die Konsole auf exakt dieselbe Weise nutzt.

Ein Spiel nutzt möglicherweise nur die gängigsten Grafikfunktionen, während ein anderes ungewöhnliche Überblendungstechniken verwendet. Eines verwendet Standard-Gleitkommaarithmetik, ein anderes ein sehr spezielles Rundungsverfahren. Eines verwendet einen Standard-Controller, ein anderes ein Mikrofon oder ein spezielles Zubehör. Ein drittes könnte eine Renn-Engine enthalten, deren Funktion unbeabsichtigt von der präzisen zeitlichen Abstimmung eines Prozessorereignisses abhängt.

Das Testen eines Emulators ist daher nicht dasselbe wie das Testen einer regulären Anwendung. Ein wirklich guter Regressionstest besteht aus einer Bibliothek mit Hunderten oder Tausenden von Spielen.

Und dann kommt ein Patch, der endlich ein Spiel zum Laufen bringt, aber drei andere unspielbar macht.

Ironischerweise ist die „Fälschung“ oft besser als das Original.

Wenn ein Emulator genau genug ist, kann es vorkommen, dass das emulierte Spiel besser aussieht und sich besser spielen lässt als das Original.

Ein Spiel, das für 480p entwickelt wurde, kann mithilfe eines Emulators in 1440p oder 4K gerendert werden. Dieser kann Geometrie in einer höheren nativen Auflösung darstellen, die Texturfilterung verbessern, modernes Anti-Aliasing nutzen, das Seitenverhältnis korrigieren und in manchen Fällen die ursprüngliche Bildratenbegrenzung aufheben. Der Emulator bietet außerdem Schnellspeicherstände, Zeitrückspulfunktion, alternative Texturen, Fehlerbehebungen und Modifikationen, die auf der Originalkonsole nicht verfügbar waren.

Manchmal funktioniert der Emulator unter Linux besser als unter Windows.

Viele Emulatoren und Übersetzungsschichten, wie beispielsweise Proton, laufen unter Linux besser. Dies liegt vor allem an der Art und Weise, wie das Betriebssystem mit der Hardware kommuniziert. Vulkan, eine moderne und offene Grafikschnittstelle, bietet eine geringere CPU-Auslastung und eine direktere Steuerung der Grafikkarte als ältere, aber unter Windows immer noch weit verbreitete Ansätze. Zudem sind die Linux-Treiber für Vulkan in den letzten Jahren so weit ausgereift, dass sie oft weniger Systemlast verursachen als Windows-Treiber.

Das DXVK-Tool, das Teil von Proton ist, übersetzt DirectX-Aufrufe in Echtzeit nach Vulkan. Dies ist überraschenderweise oft schneller, als wenn Windows den nativen DirectX-Aufruf direkt ausführen würde, da bestimmte Betriebssystemebenen umgangen werden, die unter Linux nicht existieren. Linux ermöglicht zudem eine geringere Latenz in der Interprozesskommunikation und eine besser vorhersagbare Thread-Planung im Systemkernel. Dies ist ein wertvoller Vorteil für Emulatoren, die Dutzende paralleler Aufgaben in jedem Frame koordinieren müssen.

Um in die Emulatorentwicklung einzusteigen, muss man gleichzeitig ein Meister seines Fachs und verrückt sein.

Während man mit CPU-Befehlen, API-Aufrufen und Sicherheitsmechanismen jongliert und insgeheim hofft, dass Sony und Nintendo nicht anklopfen, muss man auch noch die hohen Erwartungen der Community ertragen, für die man einen Emulator ohne finanzielle Ansprüche entwickelt. Eine Minderheit, die sich sehr lautstark äußert, hat jedoch oft übertriebene und unbegründete Erwartungen, dass die Entwicklung solcher Software relativ einfach sei. Wenn es einen Emulator für die Nintendo Switch gibt, sollte die Entwicklung eines Emulators für die Nintendo Switch 2 doch nicht so schwierig sein, oder?

Jeder neue Durchbruch bedeutet in Wirklichkeit monatelanges Suchen nach Fehlern, das Lesen von Hex-Dumps des Maschinencodes und den Versuch, die Entscheidungen heutiger und vergangener Ingenieure zu verstehen, die vor zwanzig Jahren Code geschrieben haben, ohne daran zu denken, dass jemals jemand versuchen würde, ihn auf völlig anderer Hardware nachzubilden.

Die Kombination aus Hartnäckigkeit, Neugier und der Liebe zur Bewahrung des Gaming-Erbes ist der eigentliche Grund für die Existenz der Emulation und der Grund, warum der Kampf um jede neue Konsolengeneration fast vollständig von Neuem beginnt.