Emulation

Aemulor 2.40 ist da

Adrian Lees hat sein Versprechen wahr gemacht und hat aktuelle Entwicklungsversionen von Aemulor für alle relevanten Plattformen veröffentlicht. Hier gehts zu den Downloads. Zum ersten Mal ist auch der Pi3 (Cortex-A53, ARMv8) unter den unterstützten Plattformen. Ebenfalls sollte diese Aemulor-Version nun mit den neueren RISC OS-Versionen zurecht kommen – Stichwort Zero Page Protection und High Vectors.

Alle Plattformen, für die es jemals Aemulor gab? Nein, die Formulierung „alle relevanten Plattformen“ war mit Bedacht gewählt. Denn der A9home ist nicht darunter…arme kleine blaue Kiste.

 

RPCEmu demnächst Qt-basiert

Ü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.

ADFFS 2.62 verfügbar

Man mag mir meine kurze Blog-Abstinenz verzeihen, ich hatte kurzfristig mit einem entzündeten Schleimbeutel im Ellenbogen zu kämpfen. Zum Wiedereinsteig gibt es natürlich nichts besseres als ein altes Lieblingsthema von mir: ADFFS.

Gar nicht lange nach 2.61 hat Jonathan Abbott heute die Verfügbarkeit von Version 2.62 verkündet.

Es kehrt mehr Benutzerfreundlichkeit ein – ADFFS ist nicht mehr länger auf ein aktives SparkFS angewiesen, um die JFD-Images zu lesen, die technisch ja nichts anderes als ZIP-Archive sind. Das ist in vielerlei Hinsicht positiv – viele Problemmeldungen von Benutzern hatten mit nicht aktivem SparkFS zu tun, d.h. Jon hat jetzt weniger Arbeit beim Support. Zudem ist es speichertechnisch vor allem auf den alten Maschinen ein Segen, obwohl SparkFS jetzt kein ausgewiesener Speicherfresser war. Aber bei einem typischen Maximum von 4 MiB RAM zählt jedes Byte.

Weitere Verbesserungen im Detail beziehen sich vor allem auf die Kompatibilität mit neuesten RISC OS 5.23 Nightly Builds, wo es ja erneut Änderungen am Handling der Zero Page gab (Beitrag folgt noch). Bugfixes für einige Spiele sind auch inklusive, z.B. für Stunt Racer 2000 sowie einem Spiel, das m.W. in Deutschland immer noch nicht genannt werden darf.

Also: 2.62 runterladen und Spaß haben. Nicht vergessen: auf den Pis muss EDID deaktiviert werden, damit die GPU das Scaling übernimmt.

ADFFS 2.61 verfügbar

Ein gutes halbes Jahr ist vergangen seit dem Release von Version 2.60, und so hat Jonathan Abbott nach zahllosen Verbesserungen und Bugfixes heute die Verfügbarkeit von Version 2.61 verkündet.

Hauptänderung ist die Verwendung eines 26bit-BASIC-Moduls unter JIT-Kontrolle anstatt des bisherigen Ansatzes, das Original Maschinen-BASIC zu patchen. Außerdem wurden viele der Patch-Skripte verbessert, so dass nun eine ganze Reihe Spiele problemlos auf dem Pi laufen – Highlights sind hier sicherlich die StrongARM-Versionen von Chocks Away Compendium und Stunt Racer 2000, sowie Syndicate+ und X-Run.

Also, runterladen und ausprobieren. Läuft inzwischen auf jedem Pi inklusive des ARMv8-RPi 3. Man muss eigentlich nur beachten, dass bei zu neuen RISC OS-Versionen die Umschaltung der Auflösung weiterhin von der Pi-GPU übernommen wird, damit AnyMode sein Werk tun kann. Dazu braucht es die Zeile disable_mode_changes in der CMDLINE.TXT im Pi-Bootloader. Besitzer eines klassischen Archimedes müssen sich um solche Feinheiten natürlich nicht kümmern, dürfen zum Ausgleich aber lange Ausschau nach einem funktionierenden Monitor halten.

RISC OS auf Linux portiert

Zugegeben, die Überschrift klingt irgendwas zwischen merkwürdig und erklärungsbedürftig.

Timothy Baldwin hat im ROOL-Forum genau das angekündigt: ein RISC OS, das unter Linux läuft. Und zwar nicht in einem Emulator, sondern nativ (falls es sich um ARM Linux handelt, sonst wird QEMU genutzt).

Ich habe es noch nicht selbst ausprobiert, aber was dort zu lesen ist, klingt schon sehr interessant (wenn auch noch nicht ganz produktionsreif). Im Prinzip wird das RISC OS-ROM-Image quasi als Linux-Anwendung ausgeführt. Im User-Space wohlgemerkt. Als Standard-Linux-Prozess. Ein spezielles Dateisystem, genannt IXFS, sorgt für die Verbindung zum Linux-Dateisystem und kümmert sich auch um die Speicherung der RISC OS-Spezialitäten (Load/Exec bzw. Filetype) in den Metadaten. Video-, Maus- und Tastaturtreiber verbinden sich via Unix Domain Socket (Interprozesskommunikation nach POSIX-Art – auch IPC genannt) mit einem Prozess, der dann z.B. für die Darstellung des „Bildschirms“ SDL2 verwendet.

Das Posting nennt auch ein paar Bereiche, wo es noch Schwächen gibt. Aber immerhin ein erster Schritt, und einige Anwendungen laufen bereits.

Hier ist das GitHub-Projekt zu finden.

Wie immer bei neuen Entwicklungen gibt es jede Menge Unwägbarkeiten, und es ist sicher ein typisches 80-20-Softwareprojekt – obwohl schon zu 80% fertig, wird die Perfektionierung noch sehr lange dauern. Aber sollte die Perfektionierung gelingen, ist das Projekt fast schon eine Revolution im RISC OS-Bereich. Es vereinigt die Vorzüge einer Emulationslösung mit den Vorzügen einer nativen Lösung. Gerade im Bereich der ARM-Boards gibt es ja eine Vielzahl von Geräten, auf denen Linux läuft, aber auf denen RISC OS niemals laufen wird, weil die Manpower für die Portierung fehlt und/oder gar nicht ausreichend Informationen über das verwendete SoC zur Verfügung stehen, um überhaupt eine Portierung zu ermöglichen (typische Beispiele sind SoCs von Rockchip, MediaTek und Allwinner, aber auch die Tegras von NVIDIA oder das Qualcomm-Zeugs oder die Samsung Exynos).

Optimistisch gesprochen ist ab sofort Linux der Hardware Abstraction Layer für RISC OS. Eine Revolution.

Erste Schritte mit MAME und der Archimedes-Emulation

Zwei Tage ist es her, dass ich über die Archimedes-Emulation in MAME zuerst gestolpert und dann berichtet habe. Nun gibt es einen ersten Erfahrungsbericht über den langen, schmerzhaften Weg bis zum vertrauten Anblick des RISC OS-Desktops.

Zunächst: das MAME-Team scheint nicht viel von Dokumentation zu halten, zumindest die Dinge, die von der MESS-Seite eingebracht wurden sind sehr sparsam dokumentiert. Und irgendwie wird man das Gefühl nicht los, dass die MAME-Philosophie zwar sehr gut auf Spielautomaten-Emulation passt, bei Computern aber eher holprig ist. Aber aller Anfang ist ja bekanntlich schwer, und vermutlich liegt das nur an meinem einsetzenden Altersstarrsinn, dass sich doch gefälligst alle Emulatoren dieser Welt auch ähnlich verhalten sollten.

Aber ins Detail. Die Archimedes-Emulation (aa310 in der MAME-Abkürzung) hat zum Beispiel eine ganz genaue Vorstellung davon, welche Dateien unbedingt vorhanden sein müssen, bevor ein Start möglich ist. Dazu gehören ROM-Images und CMOS-Dateien. Die Dokumentation schweigt sich darüber aus, welche Dateien mit welchem Namen erwartet werden, aber man kann per

mame -listxml aa310

sich alles anzeigen lassen. Man erfährt dann, dass Arthur 0.30 und 1.20 sowie RISC OS 2.00, 2.01, 3.00, 3.10, 3.11 und 3.19 möglich sind. Benannt nach keinem einheitlichen Muster oder einheitlich in 4-ROMs-sind-4-Dateien-Form. Schade, schließlich gibt es ja die RISC OS Classic ROMs Collection, die hätte man ja durchaus als die kanonische Form verwenden können.

Merkwürdig: es wird auch eine CMOS-Datei erwartet (getrennt nach RISC OS 2 und RISC OS 3, aber keine speziell für Arthur), die ebenfalls – wie bei MAME üblich für ROMs – eine CRC und SHA1-Summe hinterlegt hat, also einen ganz bestimmten, vorbestimmten Inhalt haben muss. Seltsam für eine im Kern variable Datei – wöllte man fix gewisse Inhalte vorgeben, warum sie dann nicht gleich in MAME fest hinterlegen?

Wenn man dann sich entweder die benötigten Ressourcen selbst zusammengefrickelt hat (z.B. funktioniert es, wenn man die von anderen Emulatoren bekannten ic24.rom bis ic27.rom nebst cmos_riscos3.bin (z.B. von Arculator) ins Verzeichnis aa310 ins ROM-Verzeichnis kopiert) oder in den Weiten des Internets ein entsprechendes aa310.zip gefunden hat (nicht zu verwechseln mit dem alten, für MESS tauglichen a310.zip), kopiert man das in das ROM-Verzeichnis von MAME (egal ob noch im ZIP verpackt oder extrahiert in das Verzeichnis aa310).

So gerüstet, kann man nun das erste Mal die Emulation starten – entweder direkt MAME starten und sich durch die vielen emulierten Systeme hangeln, oder direkt per Kommandozeile

mame aa310 -bios 311

ein RISC OS 3.11 ordern. Nicht vom fehlschlagenden Selbsttest (roter Bildschirm) irritieren lassen, einfach kurz warten und das vertraute RISC OS-Startup-Banner begrüßt uns.

So weit, so gut. Und wie kriegt man jetzt die Software ins System? Wie immer bei Emulatoren: über Disketten-Images. MAME wird im Moment erweitert, um neben den üblichen ADF-Images auch APD und JFD zu unterstützen. Also ein paar ADFs nach mame\software kopiert, und man steht vor dem nächsten Rätsel: wie mounted man nun das Image? Des Rätsels Lösung: MAME bietet ein On-Screen-Menü, das man per Tastendruck auch „Scroll Lock“ aufrufen kann. Kleines Problem in meinem Falle: die Laptop-Tastatur hat keine „Scroll Lock“-Taste anzubieten. Aber es gibt Abhilfe: man kann über eine Kommandozeilenoption eine andere Taste definieren – exemplarisch für die Tab-Taste:

mame aa310 -uimodekey TAB -bios 311

Und schon kann man über den Menüpunkt „File Manager“ ein Floppy-Image auswählen, mit verschiedenen Mount-Optionen wie Read-Only oder Read-Write.

Ich wünsche fröhliches Experimentieren. Wer ein gescheites Frontend für MAME findet, bitte Meldung machen.

Archimedes-Emulation im MAME

Heißt es „im MAME“ oder „in MAME“? Ich kann mich nicht entscheiden. Egal.

Durch einen Thread auf stardot.org.uk bin ich darauf aufmerksam geworden, dass im MAME (Multi Arcade Machine Emulator) inzwischen auch ein Archimedes-Emulator („Driver“ nennt sich das in der MAME-Sprache) seine Heimat gefunden hat.

MAME entstand ursprünglich als Emulator-Framework zur Emulation von klassischen Spielautomaten. Später gab es ein Schwesterprojekt namens MESS, das sich mit der Emulation von Computersystemen und Spielekonsolen befasste. Inzwischen sind beide unter dem Dach von MAME vereinigt, der damit eher zum „MME“ wurde.

Das erste Mal mit MAME in Kontakt kam ich durch den RISC OS-Port von Gareth S. Long, der auch Mitinitiator des MESS-Projekts ist. Ich denke es war 1998, die MAME-Version war 0.30 und im spieleunterversorgten RISC OS-Reich war es einer der wenigen Lichtblicke. Klar, ein StrongARM war vonnöten, und die emulierten Arcade-Automaten waren älteren Datums (Pac-Man, Frogger, Donkey Kong, Zaxxon, Bomb Jack, 1942, Xevious…), aber es machte trotzdem eine Menge Spaß.

Nun gibt es also für Windows, Linux und Mac eine weitere Möglichkeit neben Arculator und ArcEm um die goldene Archimedes-Zeit per Emulator neu zu erleben.

Ein erster Erfahrungsbericht folgt demnächst.

ADFFS 2.60 verfügbar

Jon Abbott hat die Verfügbarkeit von ADFFS 2.60 verkündet. Wichtigste Neuerung ist die neue Implementierung der 50Hz-Synchronisation, um die originale Spielgeschwindigkeit in Verbindung mit tearing-freier Grafikdarstellung zu ermöglichen. Dazu kommen reichlich Bugfixes und die Vervollständigung der Kompatibilität auf den Pis zu solch großartigen Spielen wie Mig 29M Fulcrum oder Interdictor.

Leider zickt mein A3000 gerade etwas, so dass ich meine Testaktivitäten wohl hin zum RPi verlagern werde. Erste Maßnahme: Grafikausgabe auf echte 50Hz einstellen, ich hoffe mein Monitor spielt da mit.

ADFFS 2.59 verfügbar

Jon Abbott hat die Verfügbarkeit von ADFFS 2.59 angekündigt. Ab sofort wird der Raspberry Pi 3 (ARMv8, AArch32) unterstützt, und die Unterstützung für den RPi 2 (ARMv7) ist nun vollständig – was in der Theorie auch die Lauffähigkeit auf OMAP3 (BeagleBoard, BeagleBoard-xM, OpenPandora, BIK, ARMini), OMAP4 (PandaBoard, PIK, ARMiniX, PandaRO), iMX6 (ARMX6) und OMAP5 (Titanium, IGEPv5, TiMachine, RapidO Ti, RapidO Ig) ermöglicht, aber weitgehend ungetestet ist.

Auf den 32bit-Plattformen (also auch dem IYONIX) sollte nun durchgehend per Ctrl+Shift+F12 die Rückkehr aus dem Spiel zum Desktop möglich sein.

Ich bin inzwischen auch Teil des JASPP und unterstütze das Projekt durch Testaktivitäten – im Moment prüfe ich alle möglichen Spiele auf dem A3000 auf Lauffähigkeit mit ADFFS 2.59. Danach ist der RPi 3 dran.

Zeitgleich mit ADFFS 2.59 wurden auch noch folgende Spiele im Rahmen des JASPP freigegeben:

  • Blaston (1991) (Eterna)
  • Cartoon Line part one (1991) (Eterna)
  • Empire Soccer ’94 (1995) (Empire Software)
  • Oh, No! More Lemmings (1992) (Krisalis Software)

Spieleseitig sollte ADFFS nun (bis auf die unvermeidlichen Bugs) feature-complete sein – aber das Projekt heißt ja „software preservation“ und nicht „games preservation“. Mal sehen, was sich Jon als nächstes vornimmt. Er hat immer wieder angedeutet, auch WIMP-Dinge über ADFFS emulierbar zu machen.

VirtualRPC-DL – VirtualRPC ohne Nerv-Faktor

Es gibt bekanntlich zwei taugliche Emulatoren für die „moderne RISC OS-Welt“ (modern soll heißen: ab Risc PC, also nicht die alte Archimedes-Welt) – RPCEmu (ursprünglich von Tom Walker, inzwischen von den Howkins-Brüdern weiterentwickelt) und VirtualRPC (von VirtualAcorn, eine Weiterentwicklung von Red Squirrel).

Während RPCEmu erste Wahl für Linux-Benutzer und RISC OS 5-Liebhaber ist, dürfte für die meisten „normalen“ Windows-Nutzer VirtualRPC erste Wahl sein – Netzwerk funktioniert „out of the box“, flexibles HostFS, zügige CPU-Emulation.

Was sprach bisher gegen VirtualRPC? Aus meiner Sicht mindestens drei Dinge. Erstens: kein RISC OS 5 möglich, nur die mitgelieferte RISC OS-Version funktioniert. Zweitens: doch recht anspruchsvoller Preis von mindestens 50 UKP. Drittens: das nervige Registrierungssystem, es muss ein Registrierungscode angefordert werden, und dieser ist gebunden an die MAC-Adresse des ersten von VirtualRPC gefundenen Netzwerkadapters, das ganze noch versüßt durch lausige Turnaround-Zeiten, wo zwischen Anforderung und Lieferung des Registrierungscodes schon mal eine Woche liegen kann – in der man dann die für teuer Geld gekaufte Software nicht benutzen kann.

Die freudige Nachricht: es gibt nun VirtualRPC-DL zu kaufen, im Prinzip eine „Download Only“-Variante von VirtualRPC-SE. Keine lästige Registrierung mehr, und der Preis liegt nun bei erträglichen 25 UKP. Die Einschränkung bezüglich des Betriebssystems bleibt hingegen bestehen – VirtualRPC-DL bleibt festgenagelt auf RISC OS 4.02, es sei denn man freundet sich mit Softload-Optionen für RISC OS 4.39 oder RISC OS SIX an. RISC OS 5 ist weiterhin „no-go“.

Zwei Dinge irritieren: die Featureliste auf der Webseite verliert kein Wort über die Netzwerkfähigkeit – läuft bei mir aber einwandfrei (und das Handbuch dokumentiert auch die Netzwerkfähigkeit). Ebenso wird behauptet, dass maximal 64MiB Hauptspeicher emuliert werden kann – bei mir laufen aber auch 128MiB problemlos.

Erwähnt werden sollte auch noch, dass im Gegensatz zu VirtualRPC-SE die DL-Variante nicht upgradefähig ist z.B. auf VirtualRPC-AdjustSA.