Emulation

Arculator v2.1

Knapp 2 Jahre nach dem Meilenstein Arculator v2.0 hat Sarah Walker vor knapp zwei Monaten die Verfügbarkeit von Arculator v2.1 verkündet. Download wie immer von hier.

Neuigkeiten gibt es aus dem bunten Sammelsurium an emulierten Podules. Neben neuen Varianten bei IDE-und SCSI-Podules gibt es nun auch die Möglichkeit, diverse damals beinahe unbezahlbare Erweiterungen wie das Aleph 1 PC-Podule oder die Computer Concepts Colour Card Gold oder ihr noch seltenerer Cousin State Machine G16 virtuell in seine Wunsch-Archie-Konfiguration aufzunehmen. Zusätzlich werden jetzt für die originalgetreue Emulation von A3000, A3010, A3020 und A4000 auch Mini-Podules emuliert, das Acorn AKF12 User Port/MIDI-Upgrade und zwei IDE-Mini-Podules stehen zur Auswahl. Diese eingeschränkte Auswahl spiegelt die Realität Anfang der 90er bei der zur Verfügung stehenden Hardware recht gut wider…

Wie schon im RPCEmu-Post erwähnt werden nun auch HFE-Floppy-Images unterstützt. Für Leute, die sowohl mit Emulatoren als auch mit realer Hardware arbeiten ein echter Gewinn, sofern man die HxC-/Gotek-/FlashFloppy-Hardware mit seinem Archimedes verheiratet bekommt.

Auch die Freunde der präzisen Emulation seltener Hardware kommen auf ihre Kosten. Nicht nur ist jetzt der A4 im Angebot (BatMan!), auch der A500, der Prototyp der Archimedes-Reihe mit einigen subtilen Unterschieden vom VIDC über den Floppy-Controller bis zur ST-506-Anbindung, wird nun originalgetreu emuliert. Apropos originalgetreu: ein Bug in der MEMC1-Emulation bezüglich des Timings wurde ebenfalls behoben.

Der Quellcode ist ja inzwischen zu GitHub umgezogen. Schaut man sich die Commits seit dem Release an, kann man schon erahnen, wohin die Reise geht bei v2.2. Podules, HFEv3, Bugfixes.

RPCEmu 0.9.4

[Update 2021-11-04 – s.u.]

Wie ich den Blog-Annalen entnehme, habe ich 0.9.3 irgendwie nicht be-/verbloggt…komisch. Also gleich auf zur brandneuen Version 0.9.4, deren Verfügbarkeit Matthew und Peter Howkins passend zur RISC OS London Show 2021 verkündet haben. Download von der bekannten Stelle, auch wieder verfügbar als “Easy Starter”-Bundle entweder mit RISC OS 5 im RISC OS Direct-Gewand oder zeitgenössisch als RISC OS 3.71-Bundle mit !Browse, !Java 1.0.2, Acorn Advance, Pipedream, Fireworkz und Star Fighter 3000. Also allem, was man damals so auf einem gut gepflegten StrongARM-Risc PC so hatte.

Eine funktionale Neuerung sticht heraus, beigesteuert von Sarah Walker (Ur-Autor von RPCEmu und Developer von Arculator): die Unterstützung für das HFE-Format, das Sarah auch im neuesten Arculator 2.1 unterstützt (Blog-Post zu Arculator folgt demnächst). Dieses Format stammt von den HxC-Floppy-Emulatoren, deren Billig-Abklatsch “Gotek” allüberall die überalterten Diskettenlaufwerke ersetzt, um komfortabel eine Hundertschaft Disketten platzsparend auf einer SD-Karte dem tendenziell festplattenlosen Host-Rechner zur Nutzung darzubieten. Das HFE-Format ist im Gegensatz zu den sektororientierten Formaten ADF und IMG ein streamorientiertes Format, das im Prinzip auf der Ebene der Magnetschicht der Diskette arbeitet und eine naturgetreue Emulation des Floppy-Controllers voraussetzt, dafür aber alle schmutzigen Kopierschutzvarianten aus der Hochzeit der 80er und 90er inkludieren kann.

Wie der detaillierten Änderungshistorie auf VCS-Ebene zu entnehmen ist, war die HFE-Erweiterung ziemlich grundlegend, inklusive FDC-Abstraktion. Das bereitet den Boden für kommende Erweiterungen zur direkten Nutzung anderer gängiger oder weniger gängiger Formate wie JFD, APD oder IPF. Sofern das außer mir noch jemand gerne hätte.

Ebenfalls eine erwähnenswerte funktionale Erweiterung ist die Unterstützung für Port-Forwarding beim seit Version 0.9.2 eingeführten, NAT-basierten “Easy Networking”. Damit können nun TCP/IP-basierte Server auf der Emulator-Seite betrieben werden wie Samba oder Moonfish.

Die restlichen Änderungen betreffen Low-Level-Details wie Bugfixes und Refactorings im Dynarec-JIT sowohl für x86 als auch x64. Der x64-Dynarec ist jetzt bezüglich der Intrincs auf dem selben Level der der x86-Dynarec angekommen. Der lästige Bug beim RISC OS 5-Shutdown/Restart gehört nun auch der Vergangenheit an. In der “kein VRAM”-Konfiguration stehen nun für die Freunde der A7000-Emulation bis zu 4 MiB für den VIDC20 zur Verfügung.

Nachgetragen (weil: s.o.) noch die Änderungen in 0.9.3: Unterstützung für die 360 KiB-Varianten von DOS- und Atari ST-Floppyimages (*.img). Bessere Separierung der CPU-Emulation nach ARMv3 und ARMv4 (also ARM610/710 vs. StrongARM). Erstmalige Verfügbarkeit der “Easy Starter”-Bundles.

Und das Wichtigste zum Schluss: man kann sich nun einfach bei den Entwicklern via BuyMeACoffee finanziell erkenntlich zeigen. Mögen die Spenden reichlich fließen.

[Update 2021-11-04]

Timothy Coltman hat direkt eine frische Version von RPCEmu 0.9.4 für MacOS X nachgelegt, zu finden zum Download auf GitHub als 0.9.4a. Die Interpreter-Version ist dabei ein “Universal Binary”, also auch für ARM64 aka “Apple Silicon” geeignet. Den Dynarec gibt es weiterhin nur für x86/x64.

ADFFS 2.73 (auch via PackMan) verfügbar

Jon Abbott vom JASPP hat gestern die Verfügbarkeit von ADFFS 2.73 verkündet. Über ein Jahr hat es gedauert seit 2.72 das Licht der Welt erblickt hat. Und die detaillierte Liste der Änderungen ist demzufolge fast endlos, ich will nur einige wenige aufgreifen.

Hauptpunkt ist der aufgerüstete JIT für StrongARM-kompatiblen Code. Damit erreicht ADFFS in der Emulation für solchen Code nahezu die Originalgeschwindigkeit der Host-CPU. Beeindruckend. Wenn auch unklar, für welchen Anwendungsfall genau das jetzt unbedingt notwendig war, denn so ein Raspberry Pi war auch vorher schon allemal schnell genug, eins der ganz wenigen Spiele die einen StrongARM voraussetzten in akzeptabler Geschwindigkeit zu emulieren. Aber wer Jon kennt, weiß, was für ein Perfektionist er in solchen Dingen ist. Legendär sein Verbesserungsprojekt für Zarch, weiterhin Musterbeispiel und Benchmark zum Thema “was ist beim Reverse-Engineering möglich, wenn man sich nur lange genug reinfuchst”.

2.72 fügte die Lesemöglichkeit von DOS- und Atari-Floppyimages hinzu, 2.73 kann nun auch schreibenderweise zugreifen.

Zusammen mit den unzähligen Bugfixes ergibt sich eine doch überraschend große Menge an Spielen, die nun unter RISC OS 5 (also am besten auf dem Pi – Jon weist darauf hin, dass die OMAP-Plattformen derzeit ungetestet sind) funktionieren. Ich bin mir aber nicht ganz sicher, ob die Liste diesmal wirklich stimmt, denn einige waren schon bei 2.72 als “funktioniert” geführt. “FORAY!” von 1992 ist jedenfalls definitiv ein Neuzugang. Kennt allerdings auch keine Sau. Jon hat aber ein YouTube-Video davon produziert. OK, muss man auch nicht kennen nach dem ersten Eindruck.

RPCEmu für MacOS X

Für die Freunde des angebissenen Apfels aus Cupertino gibt es eine gute Nachricht: Timothy Coltman hat die Verfügbarkeit von RPCEmu 0.9.2 für Mac OS X verkündet. Binaries (DMGs 0 “Disc ImaGe”, wie sie im MacOS-Jargon heißen, quasi ein Anwendungs-Bundle in Form eines Mini-Festplattenimages) sind auf GitHub verfügbar, alle bekannten Probleme mit MacOS sollten damit behoben sein, von Tastaturproblemen (Low-Level-Gedöns in Qt, das nur unter Windows gut funktionierte) über die Netzwerkanbindung, den Follow-Host-Mouse-Modus bis zu einem alternativen Hotkey zum Verlassen des Fullscreen-Modes, damit die armen MacBook-Anwender auch vernünftig arbeiten können. Ein größeres gelöstes Problem war wohl der Recompiler, der aufgrund von verschärften Sicherheitsvorkehrungen in Mac OS X 10.13 aka “High Sierra” nicht mehr funktionierte.

Meines Wissens sind die Patches noch nicht zurück im Hauptentwicklungsrepo von RPCEmu angekommen, die Sourcen sind aber auch unter o.g. GitHub-Link verfügbar für die “ich compiliere selbst”-Fraktion.

Im Laufe der Diskussion hat Andrew Hodgkinson von ROOL, selbst Mac-User und Autor einiger Patches für RPCEmu, übrigens am Rand erwähnt, dass RISC OS 5.28 quasi in der Finalisierungsphase ist. Da 5.28 released werden sollte, sobald der RPi4-Support vollständig ist, ist das eine sehr gute Nachricht.

Aemulor 2.53 verfügbar

Der erste Artikel im neuen Jahr erst Ende Februar. Schande über mich.

Adrian Lees hat die Verfügbarkeit der neuesten “Development Version” (also eine Testversion im weitesten Sinne) von Aemulor mit der schönen Versionsnummer 2.53 verkündet. Download wie immer hier.

Die große Neuigkeit ist die Verfügbarkeit einer Variante für den Raspberry Pi 4 (und das vor offiziellem Release der RISC OS-Version für diese Maschine!) und ggf. weitere Boards mit einem Cortex-A72 als ARM-Core. Ansonsten gab es kleinere UI-Verbesserungen und einfacherer Zugang zur Online-Dokumentation sowie etwas hilfreichere Fehlermeldungen beim Start der RPCEmu-Version in Verbindung mit ungepatchten RISC OS 5-Versionen. Wenn ich es richtig verfolgt habe, müssen die allerneuesten RISC OS 5.27-Varianten nicht mehr gepatcht werden.

Die Veröffentlichung von 2.51 hatte ich noch hier auf dem Schirm, aber 2.52 ist mir irgendwie durchgerutscht. Die damaligen Verbesserungen betrafen hauptsächlich Impression, sobald die upgedateten 32bit-Module wie GDraw und DitherExtend am Start waren anstatt der originalen 26bit-Varianten, um auf RGB-Zielsystemen wie Titanium und ARMbook stets korrekte Farben auf den Bildschirm zu bringen.

Und irgendwann schreibe ich auch noch einen Blogartikel über das RISC OS-Spriteformat und BGR-vs.-RGB. Versprochen.

In der Zwischenzeit: Happy Aemuloring!

Arculator v2.0 ist da

Sarah Walker hat heute die Verfügbarkeit von Arculator v2.0 verkündet. Die letzte releaste Version, 0.99, hatte Mitte des Jahres 10 Jahre Geburtstag gefeiert. Wahnsinn. Sollte jemand Arculator noch nicht kennen: während RPCEmu sich um die Emulation der Maschinengeneration Risc PC und A7000 kümmert (und damit um RISC OS-Versionen ab 3.50 aufwärts), nimmt sich Arculator dem Namen entsprechend der Generation Archimedes an – vom A310 bis zum A5000, also alles, was mit RISC OS bis einschließlich Version 3.19 lief.

Was ist neu in der Version 2.0? Ein so großer Versionssprung legt ja doch gewisse tiefgreifende Verbesserungen nahe, aber Zahlen sind bekanntlich geduldig. Also gehen wir ins Detail. Ich habe noch nicht alles durchgetestet, das ist nur ein erster Eindruck. Vorab: die Beschäftigung mit der neuen Version lohnt auf jeden Fall!

Neu ist die Maschinenkonfiguration. Bisher startete Arculator mit den letzten Einstellungen, was maschinenspezifische Dinge anging – ARM2 oder ARM3, old-style I/O (A540 und früher) oder new-style I/O (A5000 und später), Betriebssystemversion, RAM. Gewisse Dinge waren dann fest mit anderen Details verhenkelt – wenn man beispielsweise old-style I/O konfigurierte, wurde automatisch das Risc Developments IDE-Podule emuliert mit IDEFS, bei new-style I/O hingegen das IDE-Interface vom A5000 über ADFS. Beide verwendeten hartcodiert hd4.hdf und hd5.hdf als Festplattenimages. Jetzt ist alles anders: man kann eine beliebige Anzahl von zu emulierenden Maschinen konfigurieren – man nimmt eine Basismaschine (A310, A540, A3000, A5000…) und stellt dann die Details ein – ARM2 oder ARM3, welche Frequenz. MEMC1 oder MEMC1a, RAM mit 8 MHz oder 12 MHz, FPA10 oder nicht, welches Betriebssystem steckt drin (Arthur 0.30 bis RISC OS 3.19), wieviel RAM ist an Bord, gibt es ein Joystick-Interface und sind Podules aktiv. Vor allem letztes eröffnet schöne neue Möglichkeiten, denn es wird eine illustre Reihe an Podules angeboten: das klassische Acorn SCSI-Podule, das sowohl Festplatten als auch CD-ROMs emulieren kann (virtuell oder aufs Host-CD-Laufwerk mappend – für die Detailverliebten: es wird ein Toshiba XM3301 emuliert, ein alter Caddy-Recke, der von den stets mit CDFS gelieferten CDFSSoftEESOX-Treibern unterstützt wird). Verschiedene IDE-Podules. Das Acorn ST506-Podule (MFM-Platten, die Älteren erinnern sich). Dazu noch das Wild Vision Midi-Podule und das Computer Concepts Lark-Podule, eine in freier Wildbahn selten gesehene Sound-Erweiterung (auch von Wild Vision designed) mit MIDI, 16bit-Stereo-Output und 16bit-Sound-Sampler. Eher exotisch: das HCCS Ultimate CD-ROM-Podule, das den Betrieb eines der damals gängigen Mitsumi-Laufwerken erlaubte, bevor IDE-ATAPI-CD-ROMs die Herrschaft übernahmen. Auch hier kann man ein physisches oder virtuelles Laufwerk zuordnen, aber da es diese Möglichkeit ja auch schon beim SCSI-Podule gibt, ist der Zusatznutzen eher gering.

Bei der Maschinenkonfiguration ist zu beachten, dass man nicht beliebig kombinieren kann – so ist ein A3000 mit Arthur als OS nicht möglich, genausowenig wie mit dem MEMC1. Ein ARM3 geht stets nur mit dem MEMC1a zusammen. FPA10 erfordert zwingend einen ARM3. Und in einen A5000 kann man keinen ARM2 reinkonfigurieren. So viel Realismus muss sein.

Und noch mehr Liebe zum Detail ist erkennbar: so kann man pro Maschine die “Unique ID” einstellen. Das ist eine Acorn-Erfindung, die seit dem A5000 sein Unwesen treibt. Damit konnte Software sich bei der Installation an diese ID binden und so als eine Art Kopierschutz fungieren. Da aber ältere Maschinen ohne diese ID kamen, haben clevere Zeitgenossen einfach die ID so manipuliert, dass sie als nicht initialisiert galt und damit der Software vorgaukelte, eine alte Maschine ohne ID zu sein. Kurz gesagt: eine Flop-Idee. Allerdings könnte es natürlich sein, dass jemand noch Originaldisketten im Bestand hat, die an eine bestimmte ID gebunden sind. Von daher ist die Simulation der ID eine lobenswerte Sache für diese seltenen Fälle.

Was gibt es unter der Haube zu vermelden? Das ungeliebte Allegro-Framework ist Geschichte, jetzt ist alles SDL2-basiert, mit wxWidgets für die grafische Oberfläche. Daran ist höchstens schade, dass damit eine Portierung nach RISC OS sehr aufwändig wird, weil beide Bibliotheken noch(?) nicht portiert wurden. Aber unter RISC OS gibt es mit ArcEm, ArchiEmu und ADFFS ja sowieso reichlich Auswahl zum Zwecke der Retro-Archimedes-Emulation.

Jedenfalls soll die CPU- und MEMC-Emulation nun deutlich präziser sein, weshalb die feine Unterscheidung von MEMC1 und MEMC1a jetzt Sinn ergibt. ARM2 mit 8 MHz, ARM250 mit 12 MHz, ARM3 mit irgendwas zwischen 20 und 35 MHz (je nach konfigurierter Basismaschine ist die Auswahl beschränkt), dazu ein Turbo-RAM-Modus mit 16 MHz – alles ist möglich. Der direkte Floppy-Zugriff wurde auch neu implementiert.

Auch videotechnisch sind einige Optionen dazugekommen, Direct3D und OpenGL kann nun als Methode ausgewählt werden, was letztlich der SDL2-Basis zu verdanken ist. Aber auch Software-Rendering ist weiterhin möglich.

Noch eine gute Nachricht: das sich öfter etwas merkwürdig verhaltende ArculFS als native Zugriffsmöglichkeit auf das Host-Dateisystem wurde kurzerhand durch HostFS von RPCEmu ersetzt. Eine gute Entscheidung.

Und zum guten Schluss: es gibt nun Floppy-Geräusche!

Sowohl die Windows- als auch die Linux-Version gibt es direkt zum Download, Sourcecode ist mit im Archiv. Also, downloaden und experimentieren.

MIST Archimedes-Core jetzt mit IDE

MIST und MISTer, die beiden genialen Open-Source-FPGA-Plattformen zur Emulation bzw. Simulation älterer Computer, Spielkonsolen und Arcade-Automaten waren schon mehrfach hier und in meinem IT-Blog Thema. Seit 2015 experimentiere ich mit dem MIST und dort vor allem mit dem Archimedes-Core.

Jetzt hat dank Slingshot aka gyurco (Usernamen aus dem Atari-Forum bzw. von GitHub) der Archimedes-Core einen großen Schritt nach vorne gemacht. Es ist jetzt ein Risc Developments IDE-Podule integriert, so dass man mit von den Emulatoren bekannten Festplattenimages (typischerweise mit der .hdf-Extension) arbeiten kann – gegenüber der bisherigen Floppy-Images-Only-Betriebsweise ein riesiger Schritt nach vorne.

Der Core kann auch ein CMOS.RAM von der MIST-SD-Karte laden, leider aber geänderte Settings noch nicht speichern.

Zur Feier des Tages habe ich ein entsprechendes Image zusammengebaut und zur Verfügung gestellt. Es basiert auf dem RISC OS 3.1-UniBoot aus den letzten Acorn-Tagen inklusive aller Standardanwendungen wie ChangeFSI oder Printers, zusätzlich angereichert um aktualisierte Toolbox-Module, den lebensnotwendigen Utilities wie SparkPlug, die Read-Only-Version von SparkFS und PackDir. Und dazu noch drei der inzwischen freigegebenen Spieleklassikern: Burn’Out, Elite und Star Fighter 3000. Ersteres und letzteres zeigen allerdings, dass noch etwas Feintuning am ARM-Core notwendig ist, um hier adäquate Performance für diese Spiele bereitzustellen.

Ich gedenke, das Image noch weiter anzureichern mit lizenztechnisch unproblematischen Dingen – GCC, Template-Editoren, Zap und StrongEd, DrawPlus, Ovation, Impression Style (vor kurzem kostenlos freigegeben), Pipedream sowie ein paar der essentiellen Tools, an die ich mich schon gar nicht mehr erinnere – da muss ich mal wieder den FTP-Server der Uni Stuttgart konsultieren sowie mein altes A3000-Image. Der Test von ADFFS steht noch aus, jetzt wo nicht mehr ADFS-Floppy das einzige unterstützte Medium ist gibt es da durchaus Hoffnung, und das würde bezüglich der möglichen Retro-Experience die Sache stark vereinfachen.

Für die Detaildiskussion kann man alles im Atari-Forum (quasi das offizielle MIST-Forum, weil das MIST bekanntlich mit dem Atari-ST-Core geboren wurde) nachlesen. Hier der Link zum GitHub-Repo des Archimedes-Core.

Natürlich gibt es weiterhin viele zusätzliche Wünsche an den Core – schnellere CPU (der verwendete Amber-ARM-Core hat eigentlich einen Cache a la ARM3 intus, aufgrund von Zuverlässigkeitsproblemen ist der aber derzeit deaktiviert), Quad-MEMC-Emulation für bis zu 16 MiB RAM, Anbindung des MIST-Scandoublers um auch auf VGA-Monitoren die 15 kHz-Modes ohne Letterboxing und RAM-bandbreitenfressende Bildwiederholrate verwenden zu können, und natürlich das Schreiben der CMOS-Values. Direkte Unterstützung der zwei anderen Disketten-Image-Formaten APD und JFD wäre super. FPA10-Emulation wäre wohl eher aus der Kategorie “weil man es kann”, bekanntlich konnte man Floating-Point-intensive Software mit der Lupe suchen. Endgültig Kür wäre dann Netzwerkunterstützung, das wäre dann aber eher der Bereich des MISTer, für den der aktuelle Core aber noch nicht portiert wurde. Und wie wäre es mit Econet?

RPCEmu 0.9.2 ist da – mit vereinfachter Netzwerkunterstützung!

Gestern wurde die neue Version von RPCEmu veröffentlicht, namentlich 0.9.2. Aus meiner Sicht als Windows-Benutzer ein riesiger Fortschritt.

Wie schon in meinem Artikel zu Version 0.9.1 angekündigt und sehnlichst erhofft, ist die Hauptneuigkeit ein Modus zur vereinfachten Netzwerkanbindung zur Host-Maschine. Bisher war das – zumindest unter Windows – eine sehr komplexe bis fehlerträchtige Angelegenheit, wo man von Hand nach der Installation einer bestimmten Version von OpenVPN (bzw. dessen TAP-Treiber) eine Netzwerk-Bridge im Windows anlegen musste. Die dann manchmal verschwand, manchmal auch das restliche Netzwerken von Windows beeinflusste, und generell sehr unpopulär war. Unter Linux war das Tunneling, das eigentlich einfacher sein sollte, seit neuestem faktisch unmöglich weil die Root-Elevation nicht mehr korrekt mit Qt funktionierte. Ein sehr unbefriedigender Zustand.

Jetzt ist alles neu und besser und hört auf den Namen “NAT networking”. Noch immer nicht ganz so problemlos und elegant integriert wie bei V-RPC, aber deutlich einfacher als vorher. Aber ein wichtiger Hinweis: man sollte nicht “wie gewohnt” das RISC OS-Netzwerk konfigurieren (wie ich es zunächst erfolglos versucht habe), da es sich tatsächlich um echte NAT handelt – intern bekommt das emulierte RISC OS also eine eigene IP-Adresse, die immer 10.10.10.10 ist, und RPCEmu faked drumrum einen Router (10.10.10.2) und einen DNS-Server (10.10.10.3) dazu, und die Host-Maschine bekommt im Prinzip nichts davon mit. Also unbedingt die (sehr gute) Anleitung lesen. Hat man ein RISC OS, das DHCP unterstützt (also RISC OS 4.29 aka “Select 1” aufwärts), ist es wirklich sehr einfach.

Wichtige Einschränkungen: ping funktioniert nicht, ShareFS funktioniert nicht (weil nicht auf routebarem IP basierend), und die RISC OS-Maschine ist von außerhalb z.B. als Server nicht ansprechbar, weil kein Port-Forwarding implementiert ist. Die Abwesenheit von ShareFS ist natürlich bitter, weil oft die mit Abstand einfachste Möglichkeit, zwischen RISC OS-Rechnern Dateien zu sharen. Aber es braucht ja noch Luft für die 0.9.3.

Eine kleine Verbesserung wartet im Bereich “Diskettenlaufwerk” – hier kann jetzt neben dem bekannten .adf auch .img, also gewöhnliche DOS-Images, als virtuelles Diskettenlaufwerk gemountet werden.

Ein kleiner Wermutstropfen ist die Tatsache, dass aufgrund der verwendeten neuen Qt-Version nun nur noch Windows ab Version 7 aufwärts offiziell unterstützt wird. Für Retro-Zwecke leicht suboptimal, weil die PCs, die noch eine “echte” Floppy intus haben (und damit Filecore-formatierte Disketten vernünftig ansprechen können), oft unter Windows XP laufen. Aber es gibt ja Alternativen (wenn schon Retro, dann Arculator oder VA5000).

Neue Testversion von Aemulor verfügbar

Korrektur 2019-09-24: die vormals hier stehenden Infos zum ARMBook von R-Comp waren falsch. Es basiert auf dem Pinebook, nicht auf dem Pinebook Pro wie vormals fälschlicherweise hier geschrieben (vermutlich war der Wunsch Vater des Gedankens – eine sehr optimistische Interpretation der vorliegenden Informationen). Was wieder zeigt, dass auch knapp fünf Jahre nach diesem Blogeintrag die Problematik der Transparenz von Informationen weiterhin gegeben ist.

Adrian Lees, Entwickler von Aemulor (wer aus unverständlichen Gründen nicht weiß, was Aemulor ist und wozu es gut ist, kann es hier detailliert nachlesen), hat die Verfügbarkeit einer neuen Test- bzw. Entwicklungsversion verkündet. 2.51 ist die Versionsnummer, Download von hier.

Was ist neu? Eine der ungünstigen Nebenwirkungen von Aemulor war immer, dass nicht nur der Application Memory Slot (aka Wimpslot) für die emulierten 26bit-Anwendungen auf die unter RISC OS 4 und früher üblichen 28 MiB RAM eingeschränkt wurde, sondern auch der für alle anderen Anwendungen. Die neue Entwicklungsversion schafft hier nun etwas mehr Platz als früher: durch Anpassungen der Memory Map stehen nun 52 MiB RAM im Wimpslot zur Verfügung. Diese Anpassung ist optional, man kann auch mit der alten Konfiguration arbeiten.

Für die nicht-so-RISC OS-Erfahrenen: das 28 MiB-Limit kommt aus der 26bit-Zeit, also alles bis einschließlich RISC OS 4, als die CPU wie zu Zeiten des ARM2 1986 den Programmcode nur innerhalb der ersten 64 MiB ausführen konnte – weil der Program-Counter, also das Register (R15 übrigens), das die derzeitige Ausführungsadresse enthält, nur die unteren 26bit für die Adresse verwendete. Und dann hat Acorn zur Vereinfachung der restlichen Hardware (damit die MMU genannt “MEMC” eben nur diese adressieren können muss) kurzerhand diese 64 MiB in gewisse Blöcke aufgeteilt wie die RMA, das ROM, den System-Heap und IO-Bereiche. Hier ist die vollständige Übersicht zu sehen. Wenn man so will, ganz ähnlich wie die DOS-Memory-Map mit ihrem 640 KiByte-Problem.

Und um keine Missverständnisse aufkommen zu lassen: das 28 MiB-Limit bedeutet nicht, dass eine Anwendung nur 28 MiB nutzen kann. Es bedeutet nur, dass der ausgeführte Programmcode maximal 28 MiB groß sein darf – Daten können auch (seit RISC OS 3.5 und dem ARM6xx – seither können nämlich die vollen 32 Bit adressiert werden) in den sogenannten “dynamic areas” liegen. Die Erhöhung von 28 MiB auf 52 MiB ist also bei den RISC OS-typischen eher kleinen Programmen tatsächlich nur für spezielle Anwendungen interessant. Dort aber potenziell lebensrettend.

Und wie läuft er nun, der neue Aemulor? Kann ich noch nicht sagen. Bin mitten in den Vorbereitungen für die DoReCo-Party kommendes Wochenende, da ist für die Kür erst Zeit, wenn die Pflicht erledigt ist. Interessant auf jeden Fall, dass diese Aemulor-Version auf dem brandneuen ARMBook von R-Comp (ein Pinebook mit RISC OS) schon getestet wurde. Im Pinebook dreht ein Allwinner A64, also grob gesagt Cortex-A53 mit Mali-400, coretechnisch also identisch mit dem Raspberry Pi 3(+). Solange also “bekannte” Cores am Start sind, scheint die Produktion von kompatiblen Aemulor-Versionen für Adrian keine besondere Herausforderung zu sein.

ADFFS 2.72 (auch via PackMan) verfügbar

Jon Abbott vom JASPP hat heute (yeah, brandaktuelle News in meinem bescheidenen Blog!) die Verfügbarkeit von ADFFS 2.72 verkündet. Wieder stand die Stabilität im Vordergrund, ebenso Abrundungen bezüglich Kompatibilität. Auch DOS- und Atari-Images können nun gelesen werden. Als neu unter RISC OS 5 unterstützte Spiele kamen Sim City 2000 und Burn’Out dazu. Vor allem das saubere Beenden von Spielen unter ADFFS-Kontrolle per Ctrl+Shift+F12 funktioniert nun in viel mehr Fällen. Ebenso werden nun Abstürze im Spielecode, während der ADFFS-JIT aktiv ist, sauber abgefangen um einen sauberen Systemzustand nach dem kontrollierten Beenden des gecrashten Spiels sicherzustellen.

Auch die Unterstützung für WIMP-basierte Spiele hat Fortschritte gemacht, ist aber noch lange nicht rund, wie Jon nicht müde wird zu betonen. Und eine merkwürdige Unverträglichkeit mit StrongEd wurde behoben.

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

Aufmerksame Beobachter fragen sich jetzt, wo denn Version 2.71 geblieben ist? Jon sind schlicht die Buchstaben ausgegangen – er “nummeriert” die Entwicklungsversionen nach dem Muster 2.71a..2.71z durch, und nach 2.71z kam eben 2.72a, und erst mit 2.72k war Jon glücklich, woraus dann die jetzt veröffentlichte 2.72-Release-Version entstand.