Grundsystem
- SD-Karte mit Raspberry Pi OS (64-bit) vorbereitet
- Performance Mode für maximale CPU-Leistung aktiviert
- Grafiksystem von Wayland auf X11 umgestellt
- Benötigte Softwarepakete installiert
SOFTWARE / SYSTEMAUFBAU
01
Linux darunter.
Linux darunter.
90er darüber.
BrickDOS basiert auf Raspberry Pi OS. Sichtbar werden soll davon im normalen Betrieb möglichst nichts.
Nach dem Einschalten erscheint zunächst der BrickDOS-Splash-Screen, während im Hintergrund Raspberry Pi OS startet. Anschließend übernimmt LightDM automatisch die Anmeldung und startet eine schlanke OpenBox-Sitzung. Über den OpenBox-Autostart wird schließlich ein Vollbild-Terminal geöffnet, in dem ein simuliertes Boot-Script mit Festplattenerkennung und RAM-Check ausgeführt wird. Danach erscheint die ASCII-Oberfläche von BrickDOS.
Die Spiele werden aus dieser Oberfläche über eigene Start-Scripte aufgerufen. DOS-Titel laufen mit individuellen Konfigurationen unter DOSBox-X, während unterstützte Adventures direkt über ScummVM gestartet werden. Für den Nutzer bleibt der technische Unterschied zwischen beiden Laufzeitumgebungen dabei weitgehend unsichtbar.
01 / 04
↓
02
BOOT-PROZESS
Vom Einschalten bis zum Spiel
Der sichtbare Start von BrickDOS besteht aus mehreren aufeinanderfolgenden Schichten. Raspberry Pi OS und die grafische Linux-Umgebung bilden dabei nur den technischen Unterbau – der Nutzer soll möglichst direkt in die BrickDOS-Oberfläche gelangen.
01
START
Splash Screen
+
Direkt nach dem Einschalten erscheint der BrickDOS-Splash-Screen. Er ersetzt die normalerweise sichtbaren Linux-Bootmeldungen und bildet damit die erste sichtbare Ebene des Systems.
Technisch wird dafür der Splash-Screen von Plymouth durch die BrickDOS-Grafik ersetzt.
Wie man leicht sicherlich leicht erkennen kann, ist das Logo von der KI erzeugt.
02
HOST OS
Raspberry Pi OS
+
Im Hintergrund startet Raspberry Pi OS (64-bit) und übernimmt den technischen Unterbau des Systems. Linux stellt unter anderem Treiber, Dateisystem, USB-Unterstützung sowie die Laufzeitumgebung für DOSBox-X und ScummVM bereit.
Das Betriebssystem selbst soll für den Nutzer im normalen Betrieb nicht sichtbar werden.
03
LOGIN MANAGER
LightDM / Autologin
+
LightDM übernimmt die Anmeldung am grafischen System. Dabei erfolgt automatisch ein Login mit dem BrickDOS-Benutzer, sodass keine Anmeldemaske sichtbar wird.
Als Sitzung wird direkt OpenBox gestartet.
04
WINDOW MANAGER
OpenBox
+
OpenBox stellt eine möglichst schlanke X11-Umgebung bereit. Ein vollständiger Linux-Desktop wird nicht benötigt. Der Fenstermanager dient lediglich als technische Basis für die Skripte und Programme, die später im Vollbild ausgeführt werden.
Nach dem Start von OpenBox wird dessen Autostart-Konfiguration ausgeführt. Dort werden unter anderem die Bildschirmdarstellung angepasst und anschließend ein Vollbild-Terminal gestartet. Dieses Terminal führt danach der Fake-Boot von BrickDOS gestartet.
05
SIMULATED BOOT
Fake Boot
+
Der Fake Boot erzeugt innerhalb des Vollbild-Terminals einen simulierten Bootvorgang. Dieser ist im Stil eines klassischen PCs, inklusive RAM-Check, Festplattenerkennung, etc. Dieser Schritt ist rein für die Darstellung zuständig. Der eigentliche Linux-Systemstart ist zu diesem Zeitpunkt bereits abgeschlossen.
Der Fake Boot dauert etwa 10 Sekunden. Es erzeugt den zwar einen coolen Effekt, dadurch dauert es allerdings deutlich länger, bis das System betriebsbereit ist.
06
USER INTERFACE
ASCII-Oberfläche
+
Nach dem simulierten Bootvorgang erscheint die eigentliche BrickDOS-Oberfläche. Sie besteht aus klassischen ASCII-Menüs und bildet den zentralen Einstiegspunkt für die Spielauswahl. Die Bedienung erfolgt bewusst schlicht und tastaturorientiert, damit sich das System möglichst wenig wie ein moderner Linux-PC anfühlt.
Während der Entwicklung war ursprünglich der Einsatz von Windows 98 vorgesehen, dies scheiterte allerdings an der grafischen Emulation der Windows-Spiele und musste daher vorerst aufgegeben werden. Daraufhin habe ich mich für ein schlichtes ASCII-Menü entschieden. Was erst einmal sehr simpel wirkt hat sich in der Entwicklung herausfordernd dargestellt, da es nicht einfach war alle Spiele in den Menüs unterzubringen.
07
GAME LAUNCHER
DOSBox-X / ScummVM
+
Jedes Spiel besitzt sein eigenes Startskript. Sobald ein Spiel über die ASCII-Oberfläche ausgewählt wird, wird dieses Skript gestartet. Abhängig von der enthaltenen Konfiguration wird dann das jeweilige Spiel auf unterschiedliche Arten gestartet.
DOSBox-X wird für klassische DOS-Spiele verwendet. Jeder Titel kann dabei eine eigene Konfiguration für CPU, Grafik, Sound und weitere Einstellungen besitzen.
ScummVM startet unterstützte Adventures direkt über die jeweilige Engine. Für den Nutzer bleibt dieser technische Unterschied unsichtbar.
02 / 04
↓
03
INSTALLATION & EINRICHTUNG
Was für BrickDOS eingerichtet wurde
Software & Spieldaten
- DOSBox-X installiert
- ScummVM installiert
- OpenBox und benötigte X11-Komponenten installiert
- FluidSynth und MIDI-Unterstützung installiert
- Vorbereitete Spiele, Start-Scripte und Manuals über das Netzlaufwerk übertragen
Darstellung
- BrickDOS-Splash-Screen eingerichtet
- Retro-Schriftarten installiert
- Bildschirmauflösung fest auf 1024 × 768 eingestellt
- Grafikausgabe für das eingebaute Display angepasst
Systemstart
- LightDM für automatischen Login konfiguriert
- OpenBox als automatische Sitzung eingerichtet
- OpenBox-Autostart für BrickDOS konfiguriert
- Fake-Boot und ASCII-Oberfläche in den Startablauf eingebunden
03 / 04
↓
04
ERFAHRUNGEN
Erkenntnisse und Verbesserungen
Windows 98
Ursprünglich sollte Windows 98 SE die zentrale sichtbare Oberfläche von BrickDOS werden. Die Idee war, von dort sowohl DOS- als auch Windows-98-Spiele zu starten. Die Emulation erwies sich auf der ARM-Plattform jedoch nicht als zuverlässig genug. Vor allem die grafische Darstellung bereitete Probleme. Windows 98 wurde deshalb aus dem finalen Konzept entfernt.
Daraus ergab sich leider auch eine ganze Liste von Spielen, die es dadurch nicht in das finale System geschafft haben, obwohl die Leistung des Systems vermutlich ausreichend gewesen ist.
DOSBox-X
Einige Probleme wurden zunächst als Leistungsgrenze des Raspberry Pi interpretiert. Später stellte sich jedoch heraus, dass ein wesentlicher Teil durch die zuvor verwendete klassische DOSBox-Version verursacht wurde. Der Wechsel zu DOSBox-X löste diese Einschränkungen.
Ursprünglich war der Wechsel zu DOSBox-X eigentlich nur, weil diese Version Windows 98 deutlich besser unterstützt. Bei den ersten Tests damit stellte sich aber heraus, dass auch die Spiele zum Teil deutlich besser laufen.
Unsichtbares Linux
Die größte Herausforderung beim Gesamteindruck ist weniger die eigentliche Emulation als der Übergang zwischen den einzelnen Ebenen. Schon kurz sichtbare Fenster, Desktops oder Konsolenausgaben stören die Illusion eines eigenständigen Retro-Rechners. Der Systemstart und die Übergänge zwischen Menü und Spiel wurden deshalb so weit wie möglich reduziert und verdeckt.
Einige vereinzelte aufblizende Fensterrahmen konnte ich am Ende dennoch nicht komplett verhinden. Vor allem bei der Nutzung von ScummVM fällt auf, dass einige Rahmen kurz sichtbar sind. Dies scheint aber nicht am Start von ScummVM selbst zu liegen, sondern wird von ScummVM selbst während der Laufzeit verursacht.
Klare Trennung
Konfigurationen, Spieldateien und Start-Scripte werden bewusst getrennt voneinander abgelegt. So existieren eigene Bereiche für DOS und ScummVM, sowie die dazugehörigen Skripte.
Diese Struktur erleichtert Änderungen und verhindert, dass spielespezifische Einstellungen direkt in die Menüoberfläche eingebaut werden müssen.
Start-Scripte
Die zusätzliche Script-Ebene hat sich als besonders praktisch erwiesen. Ein Spiel kann unabhängig von der Oberfläche angepasst werden, ohne den zentralen Menücode verändern zu müssen.
Gleichzeitig lassen sich darüber unterschiedliche Emulatoren verwenden, obwohl sie für den Nutzer über dieselbe Oberfläche gestartet werden.
Weniger Ebenen
Der Wegfall von Windows 98 als zusätzlicher sichtbarer Ebene hat das System am Ende nicht nur stabiler, sondern auch konzeptionell sauberer gemacht.
Für BrickDOS gilt deshalb inzwischen: Je weniger sichtbar zwischen Einschalten, Spielauswahl und Spielstart passiert, desto überzeugender funktioniert das Gesamtkonzept.
04 / 04