Dragonbox-Pyra-Macher im Interview: Die Linux-Spielekonsole aus Deutschland

Tragbare PC-Spielekonsolen sind im Trend. Seit dem GPD Win gibt es immer mehr Hersteller, die Laptop-Hardware im Hosentaschen-Formfaktor präsentieren – mal mit mehr, mal mit weniger Erfolg.

Dabei zeigte ein Hobbyprojekt schon vor über zehn Jahren, was mit Linux und in Eigenregie zusammengestellten Komponenten möglich ist: die Open Pandora.

Einer ihrer Initiatoren ist Michael Mrozek aus Ingolstadt. Der gelernte Mediengestalter betreibt seit vielen Jahren unter dem Alias EvilDragon einige Foren und den Dragonbox-Shop für Retrogaming und Handheld-Konsolen.

Der Nachfolger der Open Pandora sollte besser, schneller – und vor allem besser und schneller lieferbar sein. Das hat nicht ganz geklappt. Wir haben uns mit Michael Mrozek in seinem Büro zu einem langen Gespräch über die Widrigkeiten und die positiven Seiten der Entwicklung von Spiele-Hardware abseits des Massenmarktes getroffen.

Golem.de: Fünf Jahre ist es her, dass wir über den Produktionsstart der Dragonbox Pyra berichtet haben. Im Dezember 2020 war es dann endlich so weit, die ersten Geräte wurden ausgeliefert. Daher unsere erste Frage: Warum hat das so lange gedauert?

Michael Mrozek: Wir hatten in einigen Bereichen viel Pech oder einfach schlechtes Timing. Zum Beispiel beim Prozessor: Wir haben ja den OMAP 5 von TI genommen, der damals State of the Art war und das Schnellste, was man bekommen konnte.

Firmen wie Qualcomm verkaufen erst ab Mengen von 100.000, das geht bei so einem Projekt natürlich nicht. Klar: Wenn ich gesagt hätte, ich mache das – wie es andere Firmen gemacht haben – auf Indiegogo und hole mir dementsprechend viele Vorbesteller und ein paar Investoren, wäre das vielleicht möglich gewesen. Aber das wollte ich nie.

So habe ich den Vorteil, dass mir nicht die ganze Zeit ungeduldige Backer im Nacken hocken und ich mir Zeit lassen kann. Dafür habe ich aber natürlich weniger Geld zur Verfügung, andererseits ist das Risiko niedriger.

Beim Projektstart wollten wir die mobile Version haben, die schon als Prototyp draußen war; wir waren mitten in der Entwicklung und Produktion, als es plötzlich hieß: Der OMAP 5 mobil kommt doch nicht mehr, es kommt nur noch der normale OMAP 5 – die Automotive Version.

Dazu muss man wissen: Andere Hersteller, wie Rockchip, hatten damals noch keinerlei Linux-Unterstützung, Texas Instruments galt da als vorbildlich, sie hatten ja auch den Chip für die Pandora und das Nokia N900 geliefert. Allerdings ist dann mehr und mehr auch die Unterstützung für den OMAP 5 weggefallen, weil bei Texas Instruments der mobile Markt weggebrochen ist. Wir mussten trotzdem dabeibleiben, weil wir bereits viel Entwicklungsaufwand betrieben hatten. Der Chip hatte einiges an Hard- und Softwarebugs, die an uns hängenblieben. Das hat uns immense Verzögerungen beschert.

Ein anderer Punkt, der uns viel Zeit gekostet hat, war die Bildschirmrotation. Wir dachten: Okay, der Chip kann das in Hardware leisten, er kann skalieren, rotieren und so weiter. Das funktionierte sogar prinzipiell mit dem Standardtreiber – allerdings nur mit zwölf Bildern pro Sekunde, was für eine Spielekonsole nicht reicht.

Das Problem ist zudem, dass alle kleinen Displays ab 720p Auflösung grundsätzlich im Porträtmodus arbeiten; es gibt keine Landscape-Displays. Ich habe wirklich intensiv gesucht, aber dank der Smartphone-Industrie sind alle Displays nur noch auf Hochkant ausgelegt. Das heißt: Wenn ich ein Bild darstellen will, muss ich rotieren, weil ich am Computer kein Hochkantbild haben möchte.

Wir haben sechs Monate gebraucht, um eine Alternative zu finden. Der neue Rotationschip funktionierte zunächst gut, aber dann tauchten immer leichte Bildfehler auf – was einfach daran lag, dass der Chip nicht mit der Bildausgabe synchronisiert war. So kamen wir also auch nicht weiter.

Gerettet hat uns jemand aus der Community, der meinte, dass er sich das Problem im OMAP 5 noch einmal low level ansieht. Er hat geschafft, woran selbst der Hersteller des Chips gescheitert war, und innerhalb von zwei Tagen einen Proof of Concept gemacht. Damit funktionierte die Rotation und wir brauchten den Zusatzchip nicht mehr.

Anderes Beispiel: der Speicher. Auch das hat uns wieder ein Jahr gekostet, nur weil jemand gefragt hatte, ob wir nicht 4 GByte verwenden wollten. Ich dachte: 2 oder 4 GByte – ist doch egal, denn der Prozessor unterstützt das. Mein Ansatz war: Das ist bestimmt wie beim PC, stecke ich halt einen Riegel rein – ja, das geht, wenn das Bios das unterstützt, und in dem Fall ist das halt dann die Firmware vom Prozessor. Das Problem war, das hatte noch keiner mit dem SoC getestet.

So waren also die größeren Speicherchips drauf und wir haben ein Jahr gebraucht, um alles vernünftig zum Laufen zu bringen. Wir mussten auf der Hardware-Seite optimieren, weil es Störungen in den Leitungen gab. Und zum anderen war das in der Software noch nicht wirklich implementiert, weswegen der Chip dann regelmäßig eingefroren ist.

Hinzu kamen Fertigungsprobleme. Es gibt vieles, was physikalisch noch nicht passt, weil sich ein Gehäusehersteller nicht an meine Toleranzvorgaben gehalten hat. Jetzt ist es so eng gebaut, dass ich bei zehn Pyras, die ich zusammenbaue, bei acht Schwierigkeiten bekomme, weil irgendwo was schleift. Ich muss tatsächlich extrem viel am Gehäuse von Hand bearbeiten.