CDVDBurn 3 Status-Update

Seit 2007 arbeite ich – mit schwankender Intensität, auch mal mit jahrelanger Pause bei der Codierung – an einem “großen” Update von CDVDBurn, das ich zunächst mal CDVDBurn 3 getauft habe – das originale CDVDBurn begann ja mit Version 2.00, als Kontinuität von CDBurn, das von 0.99 bis 1.64 versioniert daherkam.

Jetzt habe ich in den letzten Tagen ein wenig Aufwand investiert, um vor allem mal in der Breite USB-Laufwerke auf ARNX6, Raspberry Pi und Titanium zu testen. Und auf dem Raspberry Pi 4, bekanntlich der erste Cortex-A72 im RISC OS-Universum, zwar auch ARMv8 wie sein Vorgänger RPi 3, aber man weiß ja nie – auf dem RPi 3 hat es ja eine böse Überraschung gegeben, da wird man vorsichtig. Die gute Nachricht: tut bisher alles einwandfrei auf dem neuesten Pi, auch die RISC OS-Version scheint schon stabil. Famous last words…

Laufwerke, mit denen ich bisher getestet habe, allesamt USB-Modelle (also nicht S-ATA-mit-USB-Adapter):

  • Samsung DVD-Brenner
  • LG DVD-Brenner
  • Samsung BD-Brenner
  • LG BD-Brenner
  • Asus BD-Brenner
  • Pioneer BD-Brenner

Die schlechte Nachricht ist, dass keiner dieser Brenner “out-of-the-box” so gut funktionierte wie es mal die Lite-On-IDE-Brenner auf dem IYONIX pc und dem Risc PC taten. Die gute Nachricht ist, dass CDFS inzwischen fast problemlos mit allen Laufwerken funktioniert, ebenso der “Disc Extractor” von CDVDBurn. Und auch die Extraktion von Audio-Tracks ist problemlos.

Beim Schreiben war es dann ganz duster. Daten-CD war noch meistens funktionierend, Audio-CD im Track-at-once-Verfahren eher durchwachsen, Audio-CD im Disc-at-once-Verfahrung (genauer: Session-at-once) hat bei keinem dieser Brenner funktioniert.

Inzwischen konnte ich aber durch Anpassungen der Disc-at-once-Schreibroutine die Kompatibilität teilweise erhöhen, zumindest was die Asus- und die Samsung-Laufwerke angeht. Das fühlt sich fast wie ein Meilenstein an. Und ich konnte gleich eine Merkwürdigkeit fixen, wo trotz prinzipiell multitaskendem buffer-inspection-driven-writing mit Hourglass und partiellem single-tasking gearbeitet wurde.

Was ist noch zu tun? Mindestens die Prüfung von DVD+RW, DVD-RAM, DVD+R, BD-R und BD-RE, dann kann ich über ein initiales Release nachdenken. Ich fürchte, das wird die Liste der unterstützten Laufwerke weiter eindampfen. Ein Schwerpunkt bei den Laufwerken wird wohl Samsung sein (inzwischen “TSSTcorp” – “Toshiba Samsung Storage Technology”), weil sowohl R-Comp beim ARMX6 als auch Elesar beim Titanium diese Laufwerke standardmäßig verbauen.

Im Bereich “Kür” verbleiben dann: DVD-R (DL), DVD-RW, DVD+R DL, BD-R DL und XL, BD-RE DL, Titanium S-ATA, IYONIX IDE, S-ATA-Laufwerke an USB-S-ATA-Adapter, Performance-Verbesserungen (vor allem beim Disc Extractor), und natürlich die Verbesserung diverser UI-Nicklichkeiten, die die letzten Jahre unbeschadet überdauert haben. Aber diese Liste ist lang. Wobei man sich an UI-Hakeleien eher gewöhnen kann als an “brennt nicht”.

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.

SparkFS 1.46

David Pilling hat einen nicht unwichtigen Bug in SparkFS gefixed. Erstaunlich, dass nach all den Jahren hier immer noch Unschärfen auftreten, aber es ist ja immer ein gutes Zeichen, wenn Software fleißig auch in neuen Szenarien genutzt wird sowie Bugs gefixed werden – auch 28 Jahre nach dem ersten Release der Software.

Der Bug tritt auf, wenn sehr viele Archive gleichzeitig geöffnet sind – das kann z.B. passieren, wenn eine Suchsoftware über viele Archive läuft und auch – dank Image Filing System – deren Inhalte durchsucht.

Also: updaten. Die Read-Only-Version gibt es zum freien Download. Über die pillingsche Mailing-Liste haben die Nutzer der Vollversion auch einen Update-Link bekommen.

Die finale Nagel’sche Archive-Ausgabe

Vor einiger Zeit – genauer gesagt im März diesen Jahres – erreichte die RISC OS-Szene die betrübliche Nachricht vom Tode von Jim Nagel, Herausgeber der Archive (einem der ältesten Magazine rund um RISC OS, 20 Jahre lang ab 1987 (und damit sogar älter als RISC OS 2) von Paul Beverley herausgegeben und unter anderem bekannt für den “God Slot”) seit 2007 und damit auch schon 13 lange Jahre. Vorher hatte Jim die Acorn-Fahne im “Computer Shopper” hochgehalten, eines der größten IT-Magazine auf der Insel.

Wer es nicht weiß: Jim hatte Verwandschaft in Deutschland und tauchte unter anderem deshalb ab und an auf RISC OS-Treffen hierzulande auf. Ich habe ihn mal auf einem A.U.T.O in Wolfen getroffen und konnte mich länger mit ihm unterhalten – unsere Unterredungen auf Messen auf der Insel waren meist nur ganz kurz, weil er stets in journalistischer Mission unterwegs war. Ein stets angenehmer und sympathischer Zeitgenosse. Nicht zuletzt natürlich, weil er durchaus öfter lobende Worte zu CDBurn fand.

Zurück zur Archive. Nun hat der Rest der Nagel-Familie mit Jims Sohn Bart als Herausgeber die Ausgabe 24:6 fertiggestellt und zum Gedenken an Jim frei zum Download verfügbar gemacht – hier kann man das Exemplar vollständig als PDF in Augenschein nehmen.

Ab der kommenden Ausgabe 25:1 wird Gavin Smith die Archive weiterführen. Ich wünsche ihm alles Gute bei diesem Unterfangen, und möge er zukünftig die korrekte Groß-/Kleinschreibweise von “RISC OS” berücksichtigen, und möge das der einzige Bruch mit der Archive-Tradition sein.

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.

Frischfleisch: FontInfo von Anton Reiser

Anton “Toni” Reiser hat die Verfügbarkeit eines neuen Tools verkündet, und FontInfo ist der Name.

Der Name ist Programm: FontInfo zeigt allerhand nützliche Informationen zu beliebigen RISC OS Outline-Fonts an, und zwar auf Glyphen-Basis. Dazu zieht man entweder die Outline-Datei eines Fonts auf das FontInfo-Icon auf der Iconbar, oder man bedient sich des Menüs zur Auswahl eines beliebigen dem System bekannten Font. Es öffnet sich ein Übersichtsfenster aller Glyphen, die im jeweiligen Font definiert sind. Eine Glyphe kann dann zusätzlich per Click (Tipp: es gibt einen cleveren Unterschied zwischen Links- und Rechtsclick) im Detail inspiziert werden, mit verschiedenen Visualisierungsoptionen: nur die Outline oder “richtig” gefüllt, die Baseline, die Bounding Box, die Definition der Outline mit den Scaffolds und den Handles – eben alles, was so eine Glyphe im RISC OS-Fontmanager ausmacht. Zusätzlich können die Glyphen als Draw-Datei exportiert werden.

Auf der Fontebene gibt es zusätzliche Informationen zu den Unicode-Blocks, zu denen die Glyphen jeweils gehören. Klickt man einen Block an, werden die zugehörigen Glyphen farbig hinterlegt.

Vorsichtig, wie Toni ist, heißt die derzeitige Versionsnummer 0.02. Für dieses frühe Stadium macht das Tool aber schon einen sehr schicken Eindruck. Also: runterladen und Fonts inspizieren gehen.

GCC 8.2.0-Update

Im Oktober letzten Jahres hatte ich über erste Anzeichen auf eine baldige Verfügbarkeit von GCC 8.2.0 für unser aller Lieblingsbetriebssystem berichtet. Es gibt hier erfreuliche Fortschritte zu vermelden. Lee Noar ist fleißig am Werkeln und es steht nun ein experimenteller nativer Build zur Verfügung, sprich ein Compiler, der unter RISC OS selbst läuft und nicht nur als Crosscompiler unter Linux.

Allerdings gibt es noch einige Einschränkungen: GCC 8.2.0 kann noch keine Module erzeugen und ist zudem zwingend auf UnixLib angewiesen, compilieren und linken gegen die SharedCLibrary geht (noch?) nicht.

Auch das gute alte GNU Fortran, schon seit Urzeiten Teil von GCC, wurde der bekannten C/C++-Fraktion hinzugefügt. Zumindest “Hello World” war erfolgreich compilierbar, vermeldete die GCCSDK-Mailingliste. Mein unerschütterlicher Optimismus lässt mich auf einen aktuellen GNAT hoffen, aber da gibt es so oft Unpässlichkeiten generell auf ARM-Plattformen, dass es schon unverschämtes Glück wäre, wenn das was werden würde.

Wer es genauer wissen will, kann die Änderungen im GCCSDK-SVN verfolgen.

Aktueller Status RISC OS auf Raspberry Pi 4

Nachdem nun schon Aemulor in einer RPi 4-kompatiblen Version verfügbar ist, wie steht es derzeit denn um RISC OS selbst auf dieser vielversprechenden Plattform?

Zunächst eine kurze Zusammenfassung, warum man überhaupt einen RPi 4 haben will gegenüber einem seiner zahlreichen Vorgängern. Die CPU ist deutlich schneller, sowohl pro Takt als auch im Maximaltakt, und die Caches sind größer. Speicher ist deutlich schneller und bis zu 4 GiB groß (das vermutlich wichtigste Feature für die Linux-Jünger, und das vermutlich unwichtigste Feature für RISC OS-Nutzer). Gigabit Ethernet über einen schnellen internen Bus. USB3 über PCIe. Offizielle Unterstützung für 4K@60Hz-Bildschirmauflösung (früher war das eher Glücksache @30Hz). Dual-Head-Unterstützung.

Schon der derzeitige Zustand von RISC OS zeigt deutliche Fortschritte in den Benchmarks. Man darf sich also nicht nur auf theoretische Performancegewinne freuen, sondern tatsächlich auf spürbare Verbesserungen in der Praxis. Die CPU liegt auf einem Niveau mit den bisher schnellsten RISC OS-tauglichen Boards mit TI OMAP5 (Cortex-A15-Basis – Titanium und IGEPv5). An der Grafikbeschleunigung lässt sich sicher noch arbeiten, aber das ist “nur” eine Softwarefrage.

Und wie weit ist diese Praxis nun noch entfernt? Es fehlt prinzipiell an zwei Dingen: USB3 und Ethernet. D.h. man kann sich heute “from source” ein RPi 4-kompatibles ROM bauen, aber man muss Ethernet über das alte USB2.0 anbinden, ebenso wie zusätzliche Massenspeicher jenseits des microSD-Slots. Das ist aber nicht ganz einfach, weil alle “normalen” USB-Ports des Boards über den kombinierten USB3/USB2-Chip (VIA VL805) gehen, für den es eben noch keinen Treiber gibt. Das alte USB2.0 ist nur über den USB-C OTG verfügbar, über den auch die Stromversorgung normalerweise läuft. Deshalb sind bei der Inbetriebnahme noch ein paar Handstände vonnöten, beispielsweise indem man die GPIOs für die Stromversorgung nimmt und den USB-C stattdessen als USB-Port statt zur Stromversorgung.

Wer eher Code-affin ist, kann hier in Gitlab die Entwicklung nachverfolgen. Wer eher auf verständlichere Prosa setzt, verfolgt die Entwicklung im ROOL-Forum oder schaut sich den Port-Status im ROOL-Wiki an.

Bleibt noch die Frage: warum dauert es denn nun so lange? Da gibt es eine Vielzahl an Gründen. Beispielsweise hatte RISC OS bisher keinen XHCI-USB-Treiber (für USB3). Beispielsweise ist die Memory Map für die 4-GiB-Variante zu berücksichtigen (alle bisherigen 4 GiB-Plattformen hatten die “oberen” 2 GiB außerhalb des 4 GiB-Adressbereichs). Beispielsweise sind die Datenblätter bis heute nicht in der notwendigen Ausführlichkeit zu haben. Beispielsweise scheint es im PCIe-Bereich interessante Bugs in der Pi-Firmware gegeben zu haben. Selbst die Aktivierung des UARTs für serielles Debugging gestaltete sich als schwierig. Letztlich also eine ungewöhnliche Anzahl von nicklichen Detailproblemen, die dem geneigten Entwickler den Tag vermiesen. Aber wenn ich die Commits richtig deute, ist die Zielgerade nicht mehr weit entfernt.

Und dann wird es spannend, inwiefern RISC OS ebenfalls – vor allem in schlecht kühlbaren Gehäusen – in “thermal throttling”-Probleme laufen wird, die so manchem experimentierfreudigen RPi4-Besitzer fast schon klassisches PC-Feeling inklusive Lüfter eingebrockt hat. Gut gekühlt kann der RPi4 wohl durchaus 2 GHz und mehr ab, bei Einsatz aller 4 Cores. Ungekühlt in den üblichen beinahe dichten Plastikgehäusen könnte es eher schwierig werden mit den neuen Performance-Höhen.

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.