Emulation

Jon Abbott vom JASPP hat (schon vor einiger Zeit) die Verfügbarkeit von ADFFS 2.70 verkündet. Hauptsächlich Bugfixes fanden Einzug, damit funktionieren nun auch einige weniger populäre Spiele neueren Datums wie “DragonBall”, “Sally und Wally” oder die StrongARM-kompatible Version von “Saloon Cars Deluxe” aus dem Jahr 2000.

Wie schon 2.69 ist auch 2.70 über PackMan verfügbar, ebenso die bisher unter JASPP-Flagge re-releasten Spiele-Klassiker.

ISO-Images können nun direkt aus ADFFS erzeugt werden – das muss ich dringend mal testen. Leicht verbessert zeigt sich die Integration von USBJoystick, die ich leider immer noch nicht getestet habe. Aber demnächst bestimmt…

Jon arbeitet bereits an 2.71, das verbesserte Unterstützung für Spiele, die zunächst ins WIMP starten, mitbringen soll. Aldebaran, Elite, Karma, Sim City…da sind ein paar interessante Kandidaten dabei. Ist aber aufgrund der Art und Weise, wie ADFFS die Emulation implementiert, eine ziemlich harte Nuss zu knacken, weil man sich um die ganze WIMP-Environment-Handler-Grütze kümmern und mit anderen Anwendungen friedlich koexistieren muss.

Ich muss noch ein paar aktualisierte Versionen nachliefern, beginnend mit dem Emulator der Herzen, dem RPCEmu.

Vor kurzem wurde die Version 0.9.1 veröffentlicht. Hauptsächlich Feinarbeit und kleinere Bugfixes prägen das Changelog. Der Netzwerk-Pseudo-Podule-Treiber wurde nun besser integriert, ist 26/32bit-neutral und SharedCLib-neutral und kann deshalb problemlos per Podule-Loader ohne explizites Softloading ins System gebracht werden. Etwas später wurden auf der Mailingliste noch Patches gereviewed, um unter MacOSX die Tastaturunterstützung wieder sauber zu ziehen, da gab es bei der Umstellung von Allegro auf Qt ein paar Verwerfungen. Eventuell sind die Patches auch hilfreich für die RISC OS-Portierung von RPCEmu, die mal experimentell von Chris Gransden durchgeführt wurde – dort haperte es auch an der Tastaturunterstützung.

Bei meinen Versuchen unter Linux bin ich letztens gescheitert beim Versuch, das Netzwerk wie hier beschrieben einzurichten – die chown-root-Methode funktioniert mit der von mir verwendeten Qt-Version nicht mehr, Qt lehnt das Starten der Anwendung mit Root als Owner schlicht ab. Es zeichnet sich allerdings ab, dass eine alternative Netzwerk-Lösung seinen Weg in den RPCEmu finden könnte, auf Basis von Slirp, das auch von QEMU und VirtualBox verwendet wird. Das wäre dann die lang ersehnte “zero config”-Variante, mit der sich RPCEmu direkt in das Netzwerk der Hostmaschine integrieren könnte, ganz ohne Tunelling und Bridging und das ganze unhandliche Gedöns. Wir hoffen weiter!

Im Oktober 2017 gab es die erste RPCEmu-Testversion, die auf Qt statt auf Allegro basierte – hier meine damalige kurze Zusammenfassung der Vorteile der Qt-Implementierung gegenüber Allegro. Vor allem die neue Software-Skalierung im Fullscreen-Modus ist Gold wert, weil es im Windows-Umfeld sehr sauber und problemlos funktioniert, und die Software-Skalierung oft sogar bessere Ergebnisse liefert als die Skalierungsfunktion von Betriebssystem oder Bildschirmhardware.

Heute ist RPCEmu 0.9.0 erschienen, die erste Qt-basierte Release-Version nach einer Reihe von Testversionen, um diverse obskure Bugs zu fixen. Der Qt-Branch wurde gleichzeitig wieder in das Hauptrepository (Mercurial) gemergt .

Meine Wünsche für die Version 1.0:

• konfigurierbarer Pfad für HostFS – dann kann es auch wieder einen Windows 7ff-tauglichen Installer geben, damit die Software nach “Programme” und die Daten woandershin können
• Unterstützung von MimeMap in HostFS (ich arbeite noch dran, die RPCEmu-Entwickler davon zu überzeugen, dass das eine gute Idee ist)
• multiple Mounts für HostFS – System-Profile-Definitionen, um einfach zwischen verschiedenen RISC OS-Versionen, RAM-Configs und HostFS-Mounts zu wechseln
• Bug bezüglich IDE-Emulation für RISC OS 5 fixen
• Erscheinungsdatum noch 2018 🙂

Update: ich habe meine Seite “Emulatoren für RISC OS” auch auf den neuesten Stand gebracht.

Jon Abbott hat ADFFS 2.65 als “public beta” zum Download bereitgestellt. Ein großer Schritt nach vorne, arbeitet es doch eng verzahnt mit Richard Walkers USBJoystick-Modul zusammen, um endlich die Freuden des Knüppels abseits der Originalhardware bereitzustellen.

Joystick-Unterstützung war immer ein schwieriger Fall bei Acorns 32bittern. Erst der A3010 hatte eingebaute Joystick-Ports, und erst mit dem darauf ausgelieferten RISC OS 3.10 bequemte sich Acorn dazu, eine SWI-Schnittstelle zur sauberen Joystick-Unterstützung bereitzustellen. Offenbar waren Spiele auf Computern zu unseriös für die auf den Bildungsmarkt zielenden Acornianer.

Der geneigte Joystick-Nutzer und Archimedes-Zocker war also lange Zeit (wie schon auf den BBC-8bittern) auf 3rd party Interfaces angewiesen – The Serial Port, Vertical Twist, RTFM, Voltmace, LogikJoy, Gamer’s Upgrade, JoyConnect…man ahnt es schon, jedes einzelne nur zu sich selbst kompatibel. Eine Ausnahme – RTFM und LogikJoy, beide steckte man in den meist ungenutzten Econet-Steckplatz, waren Hardware-kompatibel. Und später gab es immerhin für fast alle Hardware-Interfaces ein Modul, welches Kompatibilität mit den Acorn-SWIs herstellte. Nicht unerwähnt soll auch Ian Haylocks Joystick-Interface für den Parallel-Port bleiben, das hatte ich jahrelang erfolgreich am Risc PC betrieben.

Jedenfalls hat sich Jon Abbott die Mühe gemacht, quasi alle Spiele die es je für RISC OS gab auf ihre Joystick-Kompatibilität zu prüfen. Ursprünglich basiert das auf der Analyse des Codes und welche SWIs drin genutzt werden, inwieweit diese Liste inzwischen experimentell erhärtet wurde weiß ich nicht.

Unverzichtbar auf den modernen Plattformen ist Richard Walkers USBJoystick-Modul. Im Prinzip unterstützt es alle HID-kompatiblen USB-Joysticks, egal ob analog oder digital. Im Moment muss ggf. noch händisch gemappt werden, welcher Knopf denn nun Feuerknopf 1 ist und welche Achsenbewegungen auf x- und y-Achse wirken. Als Besonderheit im Zusammenwirken mit ADFFS kann ADFFS die über USBJoystick bereitgestellten Informationen so bereitstellen, als wenn ein RTFM-Interface diese ausgelesen hätte – notwendig für einige Spiele älteren Datums, die direkt die Hardware des RTFM-Interfaces angesprochen haben.

Wenn man Jons Erkenntnisse so im Zusammenhang liest, muss man sich teilweise wundern, dass die Spiele damals überhaupt auf der Originalhardware liefen. Dass damals gerne mal am Betriebssystem vorbei programmiert wurde, ist ja lange leidvolle Erfahrung und ein steter Quell von Inkompatibilitäten aller Art.

Meine eigenen Experimente mit ADFFS und meinen diversen USB-Joysticks stehen noch aus. Ich muss mal in den diversen Bastelkisten kramen, aber ich habe auf jeden Fall folgendes am Start:

• Competition Pro USB (in der goldenen Jubiläums-Edition)
• PS3-Joypad
• USB-PS2-Joypad-Adapter
• diverse USB-Gameport-Adapter und ebenso diverse Gameport-Joysticks vom Competition Pro (Mini) bis zum Gravis Analog Joystick

Über die RPCEmu-Mailingliste kam heute die Bitte von Peter Howkins, sich am Test von RPCEmu 0.8.99 zu beteiligen.

Was ist neu in dieser Version von RPCEmu? Endlich wurde die unselige Allegro-Bibliothek über Bord geworfen, stattdessen wird jetzt Qt5 verwendet. Was gleichzeitig dazu führt, dass das UI (Menüs, Einstellungen) jetzt unter Windows, Mac und Linux vollwertig ist und nur einmal gepflegt werden muss.

Das Screenmode-Handling wurde im Fullscreen-Modus dahingehend geändert, dass nun auf die native Auflösung skaliert wird und nicht mehr der Bildschirmmodus selbst verändert wird, was bekanntlich unter nicht-RISC OS-Betriebssystemen erstaunlich oft zu Problemen führt – in meinem Fall hat Windows regelmäßig fälschlicherweise nach Rückkehr aus dem Fullscreen-Modus gemeldet, ich würde nicht die native Auflösung des Displays verwenden und solle das doch bitte ändern.

Gleichzeitig wurde auf das Qt-Threadingmodell umgestellt, so dass nun die Emulation sauber im Hintergrund weiterläuft, während man die Menüs öffnet oder Einstellungen anpasst. Auch gefreut hat mich der neue Warndialog, der einen auf den bevorstehenden Reset hinweist wenn man die Einstellungen ändert.

Ein paar Bugfixes bei der ARM-Emulation sind auch eingeflossen.

Ironischerweise hilft die Umstellung von Allegro auf Qt5 auch für eine RISC OS-Portierung – Chris Gransden, Meister der tausend Portierungen, hat direkt die Maschinerie angeworfen und eine mehr oder weniger lauffähige “RISC OS 5 on RISC OS 5”-Emulation vermeldet. Performancetechnisch sparsam (angezeigte 18 MIPS auf einem Titanium, also etwa ARM3-Speed – kein Wunder, enthält RPCEmu doch nur einen x86/x64-JIT und muss bei ARM-on-ARM rein interpretierend arbeiten), mit einigen Nicklichkeiten wie nicht funktionierender Tastatureingabe, aber ansonsten funktionsfähig.

Update

Chris Gransden hat einen Teaser-Screenshot veröffentlicht, RISC OS 4 in RPCEmu auf RISC OS 5-Titanium.