Doom auf Fliegenhirn & Co.: 5 kuriose Experimente

IDDQD, IDKFA und Co. Diese auf den ersten Blick sinnlosen Buchstabenfolgen haben sich in mein Gehirn gebrannt. Geht es Ihnen auch so? Falls nicht, haben Sie entweder nie Doom gespielt, keine Cheats verwendet oder Ihr Gehirn merkt sich solche Dinge schlicht nicht. Darum würde ich Sie allerdings ein Stück weit beneiden. Doch zurück zum Spiel. Mehr als 30 Jahre nach seiner Veröffentlichung sorgt Doom noch immer für Schlagzeilen. Allerdings geht es dabei meist nicht um neue Inhalte, sondern um die ständig wachsende Liste ungewöhnlicher Systeme, auf denen der Shooter irgendwie ausgeführt werden kann. Manche davon haben es bereits in unser „Video der Woche“ geschafft.

Doom trifft Fruchtfliege

Das jüngste Beispiel heißt Doomfly. Das Open-Source-Projekt koppelt eine Simulation des Nervensystems einer männlichen Fruchtfliege an eine speziell eingerichtete Spielumgebung auf Basis von ViZDoom. Das Spiel selbst wird dabei auf gewöhnlicher Computerhardware ausgeführt. Die Simulation des Nervensystems übernimmt jedoch die Rolle des Controllers.

Grundlage ist MaleCNS v1.0, ein digitaler Verschaltungsplan des zentralen Nervensystems von Drosophila melanogaster, einem Arbeitspferd der Biologen (Grüße an meine alte Welt gehen raus). Er umfasst rund 166.700 Neuronen vom Gehirn über die optischen Loben bis zum ventralen Nervenstrang sowie etwa 125 Millionen synaptische Kontakte. An dem Datensatz arbeiteten unter anderem HHMI Janelia, die University of Cambridge, das MRC Laboratory of Molecular Biology und Google Research. MaleCNS v1.0 wurde am 8. Juni 2026 veröffentlicht, die zugehörige wissenschaftliche Publikation folgte am 3. September 2026. Doomfly speist Bilder aus dem Spiel in modellierte Fotorezeptoren ein. Die dabei entstehenden Aktivitätsmuster breiten sich durch das simulierte Netzwerk aus und werden anschließend über ausgewählte Neuronen in Befehle wie Drehen, Bewegen und Schießen übersetzt.

Diese Zuordnung ist allerdings eine technische Entscheidung der Entwickler. Sie entspricht keiner nachgewiesenen natürlichen Motorfunktion der betreffenden Nervenzellen. Die Simulation bildet also nicht die tatsächliche Steuerung einer Fliege nach, sondern nutzt Teile des modellierten Nervensystems als Signalgeber für das Spiel. Inzwischen experimentiert Doomfly zudem mit einer begrenzten dopamingesteuerten Plastizitätsregel. Dabei lässt sich ein kleiner Teil der vorhandenen Verbindungen während des Spiels verändern. Einen erfolgreichen Lernprozess konnte das Projekt bislang jedoch nicht nachweisen. Die aktuelle Variante scheiterte nach Angaben der Entwickler an den eigenen Tests für visuelle Verarbeitung, Konditionierung und Überlebensleistung. Von einer digitalen Fruchtfliege, die Doom „verstanden“ oder das Spielen erlernt hat, kann daher keine Rede sein.

Trotzdem reiht sich Doomfly in eine inzwischen lange Tradition ein. Sobald ein Gerät über etwas Rechenleistung, eine Anzeige oder zumindest im Entferntesten über eine Form der Ein- und Ausgabe verfügt, scheint früher oder später dieselbe Frage aufzukommen: Läuft darauf Doom?

Wie wird ein Ladegerät zur Doom-Konsole?

2025 brachte der Hardware-Hacker Aaron Christophel Doom auf einem Anker Prime Charger zum Laufen. Das Desktop-Ladegerät besitzt ein 2,26 Zoll großes Farbdisplay mit einer Auflösung von 480 × 200 Pixeln sowie einen Synwit-SWM34S-SoC. Dessen Arm-Cortex-M33-Kern arbeitet mit einer Taktfrequenz von 150 MHz. Hinzu kommen 8 MB SDRAM und 16 MB Flash-Speicher. Für einen angepassten Doom-Port ist das offenbar mehr als genug.

Interessant ist, dass Christophel keine zusätzliche Rechenhardware in das Gehäuse einbauen musste. Die Doom-Engine wird tatsächlich auf dem Prozessor des Ladegeräts ausgeführt. Die Software spielte er über dessen Debug-Schnittstelle ein. Selbst der vorhandene Drehregler dient als Eingabegerät. Durch Drehen, Drücken und verschiedene Kombinationen daraus lassen sich Spielfigur, Waffen und Türen steuern. Lediglich auf Sound muss der Spieler verzichten.

Von wegen Landwirtschaft: Doom auf einem John-Deere-Traktor

Mehr technische und politische Bedeutung hatte ein Projekt des australischen Sicherheitsforschers Sick Codes. Auf der DEF CON 2022 zeigte er eine an das landwirtschaftliche Umfeld angepasste Doom-Version auf dem Display eines John-Deere-Traktors. Der Shooter war in diesem Fall vor allem der weithin sichtbare Beweis für einen erfolgreichen Jailbreak. Sick Codes hatte sich tiefgehenden Zugriff auf das eigentlich abgeschottete System verschafft und konnte darauf eigenen Code ausführen. Damit wurde nicht der gesamte Traktor zur Spielekonsole. Doom lief vielmehr auf dem modifizierten Display- und Steuerungssystem der Maschine. Gerade diese Differenzierung ist wichtig, denn der Port demonstrierte vor allem, wie weitreichend der Zugriff auf das zuvor geschlossene System war.

Das Experiment erhielt dadurch zusätzliche Bedeutung in der Right-to-Repair-Debatte. In dieser spielt John Deere seit Jahren eine zentrale Rolle, weil das Unternehmen Diagnose, Softwarezugriff und Reparaturen seiner Maschinen stark kontrolliert. Doom war in diesem Fall weniger ein Spiel als ein öffentlichkeitswirksames Symbol für die Frage, wem die Kontrolle über gekaufte Hardware eigentlich gehört.

Nicht nur Spielerei: Was Doom mit einer Sicherheitslücke im Drucker zu tun hat

2014 brachte der Sicherheitsforscher Michael Jordon (ja, mit O) Doom auf einem Canon-Pixma-Drucker zum Laufen. Jordon arbeitete damals für das britische Sicherheitsunternehmen Context Information Security. Bei dem Projekt handelte es sich weniger um eine technische Spielerei als um einen Proof of Concept. Jordon hatte Schwachstellen im Firmware-Update-Prozess der Drucker entdeckt. Darüber ließ sich eigener Code auf das Gerät einschleusen und ausführen.

Der Doom-Port machte auf kaum zu übersehende Weise sichtbar, wie umfassend sich der Drucker manipulieren ließ. Ein Angreifer hätte denselben Zugang allerdings auch für deutlich weniger unterhaltsame Zwecke nutzen können.

Das Beispiel zeigt damit eine weitere Funktion ungewöhnlicher Doom-Portierungen: Der Shooter dient als anschaulicher Beweis dafür, dass jemand die Kontrolle über ein eigentlich geschlossenes System übernommen hat. Ein blinkender Text oder eine einfache Testausgabe würde technisch denselben Zweck erfüllen. Doom macht das Ergebnis jedoch wesentlich verständlicher und öffentlichkeitswirksamer.

Money, Money! Wie wird ein Geldautomat zur Doom-Konsole?

Ebenfalls 2014 verwandelten australische Bastler einen ausrangierten Geldautomaten des Typs NCR Personas in eine Doom-Maschine. Besonders reizvoll war die Einbindung der ursprünglichen Bedienelemente. Die seitlichen Tasten und Teile des PIN-Pads übernahmen verschiedene Funktionen im Spiel. Der Geldautomat arbeitete mit Windows XP. Ein I-PAC2-Controller, wie er normalerweise bei selbst gebauten Arcade-Automaten eingesetzt wird, übersetzte die Eingaben des Automaten in gewöhnliche Tastaturbefehle. Rechnerisch war der Doom-Geldautomat damit weniger exotisch als viele andere Projekte. Schließlich steckte in dem Gerät ein vergleichsweise normaler PC. Optisch gehört der Automat aber bis heute zu den einprägsamsten Beispielen. Schließlich rechnet man an einem Geldautomaten eher mit einer Kontostandsanzeige als mit Dämonen, Schrotflinten und Feuerbällen.

Gesund und brutal: Wie viele Kartoffeln braucht Doom?

Doom auf einem TI-84-Grafiktaschenrechner wäre für sich genommen kaum noch ungewöhnlich genug für diese Liste. Der YouTuber Equalo ergänzte das Projekt deshalb um eine zusätzliche Herausforderung: Der Rechner sollte seinen Strom aus Kartoffeln beziehen. Ursprünglich wollte Equalo mit der Kartoffelbatterie einen Raspberry Pi Zero versorgen. Dafür wurden rund 100 Pfund beziehungsweise etwa 45 Kilogramm Kartoffeln gekocht, zerteilt und mithilfe von Kupfer und Zink zu einer riesigen Batterie verschaltet.

Für den Raspberry Pi reichte die erzeugte Leistung trotzdem nicht zuverlässig aus. Der deutlich sparsamere TI-84 ließ sich mit der Konstruktion dagegen einschalten. Auf ihm konnte schließlich Doom ausgeführt werden, versorgt mit Strom aus Kartoffeln. Die Kartoffeln führten dabei natürlich keine Berechnungen aus. Sie dienten lediglich als elektrochemische Energiequelle. Trotzdem verbindet das Experiment zwei beliebte Technikfragen auf besonders absurde Weise: Wie bekommt man Doom auf möglichst ungewöhnlicher Hardware zum Laufen, und wie lässt sie sich mit einer möglichst ungewöhnlichen Stromquelle betreiben?

Auf welchen ungewöhnlichen Geräten läuft Doom außerdem?

Bei fünf Beispielen lässt sich die Geschichte kaum belassen. Die Liste ungewöhnlicher Doom-Portierungen ist inzwischen so lang, dass sich damit problemlos ein eigener Katalog füllen ließe.

• Entwickler Adam Bell brachte Doom 2016 auf der lediglich 60 Pixel hohen Touch Bar eines MacBook Pro zum Laufen. Auch eine Kodak DC260 aus dem Jahr 1998 schafft den Shooter mit ihrem 66 MHz schnellen PowerPC-Prozessor.

• Beim Keysight-Oszilloskop DSOX1102G öffnete der Zugriff auf das zugrunde liegende Windows CE den Weg zur Ausführung des Spiels. Wie bei anderen Portierungen auf Mess- und Industriegeräte lag der Reiz dabei weniger in der tatsächlichen Spielbarkeit als in der Demonstration, dass sich auf der Hardware eigene Software starten lässt.

• 2025 folgte DoomPDF. Dabei handelt es sich um einen Doom-Source-Port, dessen C-Code mithilfe von Emscripten in JavaScript beziehungsweise asm.js übersetzt wurde. Die Grafikausgabe entsteht über zahlreiche Textfelder mit ASCII-Zeichen. DoomPDF funktioniert allerdings nicht in jedem beliebigen PDF-Programm. Das Projekt ist auf PDF-Umgebungen angewiesen, die ausreichend umfangreiche JavaScript-Funktionen unterstützen. Das trifft vor allem auf bestimmte Chromium-basierte Browser zu. Technisch läuft Doom damit zwar innerhalb einer PDF-Datei, aber nur, weil der verwendete Viewer den eingebetteten Code ausführt. Die PDF-Datei dient also als ungewöhnlicher Container und als Laufzeitumgebung, soweit der jeweilige Viewer dies zulässt.

• Auch eine Ikea-Trådfri-Lampe musste bereits für Doom herhalten. 2021 portierte Entwickler Nicola Wrachien den Shooter auf das in einer smarten GU10-Lampe verbaute Funkmodul MGM210L von Silicon Labs. Dessen Arm-Cortex-M33 arbeitet mit 80 MHz und verfügt über lediglich 108 kB RAM sowie 1 MB internen Flash-Speicher. Ganz ohne Zusatzhardware kam das Projekt allerdings nicht aus. Für die Doom-Daten ergänzte Wrachien einen 8 MB großen SPI-Flash-Speicher. Außerdem schloss er ein TFT-Display mit einer Auflösung von 160 × 128 Pixeln sowie Taster für die Steuerung an.Die eigentliche Doom-Engine wurde jedoch auf dem Mikrocontroller der Lampe ausgeführt. Damit ist das Projekt trotz der zusätzlichen Komponenten ein echter Port auf die vorhandene Rechenhardware und nicht nur ein Einbau fremder Elektronik in das Lampengehäuse.

• Cortical Labs zeigte zudem, wie ein neuronaler Biocomputer auf Bildsignale aus Doom reagiert. Dabei werden lebende Nervenzellen mit einer digitalen Umgebung gekoppelt. Die Aktivität der Zellen dient als Grundlage für Reaktionen innerhalb des Systems. Auch hier ist eine nüchterne Einordnung wichtig. Die Nervenzellen verstehen weder Doom noch treffen sie Entscheidungen auf dieselbe Weise wie ein menschlicher Spieler. Solche Experimente untersuchen vielmehr, wie biologische neuronale Netzwerke auf elektrische Reize und Rückmeldungen reagieren und ob sich ihr Verhalten durch Feedback beeinflussen lässt.

Warum wird ausgerechnet Doom auf alles portiert?

Dass ausgerechnet Doom immer wieder auf ungewöhnliche Hardware übertragen wird, hat technische, historische und kulturelle Gründe. Der wichtigste technische ist der zugängliche Quellcode. id Software veröffentlichte am 23. Dezember 1997 den Sourcecode der Linux-Version von Doom. Zunächst galt eine restriktive Lizenz, die nur eine nichtkommerzielle Nutzung erlaubte. Am 3. Oktober 1999 folgte eine erneute Veröffentlichung unter der GNU General Public License. Damit entstand die Grundlage für eine bis heute aktive Landschaft sogenannter Source Ports. Diese angepassten Versionen der Engine erleichtern es Entwicklern, Doom auf neue Betriebssysteme und Hardwareplattformen zu übertragen. John Carmack beschrieb den Code bereits bei der Veröffentlichung als vergleichsweise portabel. Er erwartete, dass sich die Engine auf nahezu jede Plattform übertragen lasse, und schlug Portierungen auf weitere Betriebssysteme ausdrücklich als mögliche Projekte vor.

Dazu passen die technischen Voraussetzungen. Große Teile der Engine sind in C geschrieben. Die Anforderungen an Rechenleistung und Speicher wirken aus heutiger Sicht überschaubar. Zahlreiche vorhandene Source Ports nehmen Entwicklern außerdem einen erheblichen Teil der Arbeit ab. Für experimentelle Hardware müssen häufig vor allem die Grafikausgabe, die Eingabeverarbeitung, das Timing, die Speicherverwaltung und weitere systemabhängige Funktionen angepasst werden. Genau darin besteht bei vielen Projekten der technische Reiz.

Ein weiterer Grund ist die klare Abgrenzung zwischen Engine und Spieldaten. Der veröffentlichte Quellcode umfasst nicht automatisch sämtliche urheberrechtlich geschützten Inhalte des Spiels. Für die Ausführung sind weiterhin entsprechende Spieldaten erforderlich, die typischerweise in WAD-Dateien vorliegen. Alternativ können freie Datensätze verwendet werden, die mit der Doom-Engine kompatibel sind.

Entscheidend ist aber auch der hohe Wiedererkennungswert. Ein blinkendes „Hello World“ beweist lediglich, dass ein Prozessor Code ausführen kann. Doom demonstriert auf einen Blick erheblich mehr: Das System berechnet Grafik, verarbeitet Eingaben, verwaltet Spieldaten und führt ein vergleichsweise komplexes Programm in Echtzeit aus. Außerdem erkennen selbst viele Menschen, die Doom nie selbst gespielt haben, die markante Darstellung sofort. Dadurch eignet sich der Shooter hervorragend als öffentlichkeitswirksame Technik-Demonstration. Aus einem Computerspiel wurde so über Jahrzehnte eine Art inoffizieller Kompatibilitäts-, Embedded- und Hacker-Benchmark. Die Frage lautet längst nicht mehr: „Kann dieses Gerät grundsätzlich Spiele ausführen?“ Sie lautet einfach: Can it run Doom?