Über die Haltbarkeit optischer Medien

2024-12-17 14:14

Weil ich gerade einen kleinen „Retro-Flash“ habe und an verschiedenen dazugehörigen Dingen arbeite, kann ich jetzt vom Stand meiner ältesten CD-R-Medien berichten. OK, nicht die allerältesten (1996 – da war fast meine einzige Anwendung Audio-CDs fürs Auto zu brennen, nicht zufällig damit zusammentreffend, dass CDBurn https://www.hubersn-software.com/cdburn.html noch keinen eigenen ISO9660-Formatter an Bord hatte, aber schon gute Audio-Möglichkeiten), aber ziemlich alt. Oktober 1998 um genau zu sein.

Ich bin da ja insgesamt am Thema nicht ganz unbeteiligt, und habe den Käufern von CDBurn und CDVDBurn und CDVDBurn 3 immer erzählt, dass ein Backup auf einem optischen Datenträger nie schadet – erstens weil man den magnetischen Medien nie trauen kann, zweitens damit sie ihr RISC OS-Zeugs auch auf anderen Systemen bequem und „für immer“ über ISO9660 standardisiert ausgelesen bekommen, und drittens weil es bis auf absehbare Zeit auf jeden Fall funktionierende Lesegeräte gibt. Wenn man das im Vergleich zu den 1997 üblichen Backupmöglichkeiten für größere Datenmengen vergleicht, zeigt sich der einzigartige Vorteil der CD-R: wer heute noch irgendwo QIC- oder DAT-Tapes findet, kann froh sein, wenn die Dinger nicht bandmäßig zusammengepappt sind, man überhaupt noch umspulen kann und die Magnetisierung nicht verloren gegangen ist. Und dann muss man noch ein Gerät finden, dass die vielleicht noch einwandfreien Bänder auch wieder in Daten verwandelt. Oh, schade wenn man einen QIC-Floppystreamer hatte und keinen Rechner mehr mit echtem Floppyanschluss. Oder das DAT natürlich SCSI hatte. Oder der Lesekopf leider etwas „neben der Spur“ ist. Oder es an schnödem Softwareproblem scheitert – spezielles Archivformat, deren Kompression nur die damalige Software kennt? Das sind alles keine unüberwindlichen Schwierigkeiten, wie die Retro-Szene vorbildlich zeigt. Aber bei CD kann ich einfach bei Amazon einen neuen DVD-Brenner bestellen für unter 30€, an USB anschließen, fertig. Auslesbar mit jedem OS der Welt – sogar mit RISC OS.

Voraussetzung natürlich: man hat auf Qualitätsmedien gesetzt, wie ich es immer gepredigt habe. Ich habe hier aus 1998 jetzt eine ganze Menge TDK-Medien fehlerfrei ausgelesen, allesamt die 74-Minuten-aka-650-MiB-Variante aus der „Reflex“-Serie, die damals als sehr brennerkompatibel, auslesefreundlich und langzeitstabil galt. Ein Qualitätsmedium eben.

Ob die ersten gebrannten DVD-R und DVD+R aus meinem Sammelsurium sich genauso gut schlagen, erzähle ich dann in knapp 10 Jahren. Um die M-Disc-BD-R zu prüfen, kann ich mir noch mehr Zeit lassen.

Nachdem mein Interesse geweckt war, habe ich dann aus meinem Archiv auch noch die älteste gepresste Audio-CD rausgeholt. Gekauft 1987. Wird tiptop fehlerfrei ausgelesen.

RISC OS Direct 5.31

2024-12-07 19:11

Seit Ende Oktober gibt es ein neues Release (v3, wie sie mancherorts genannt wird) von RISC OS Direct, basierend auf der aktuellen „unstable“-Entwicklungsversion von RISC OS 5.31. Eine Weile war das etwas aufwändiger in der Installation – man musste erst mal das v2-Image auf eine microSD-Karte bringen, obwohl die RISC OS-Partition nur knapp 8 GiB groß war war die Image-Datei leider so groß, dass man normalerweise eine 32GB-Karte brauchte, und dann musste man davon booten und mittels des v3-Update-ZIPs unter RISC OS dann das Update auf Direct 5.31 durchführen. Zudem war die RPi-Firmware zu alt für die neueste Pi4-Revision, so dass manche Hardware erst gar nicht damit booten konnte.

Seit kurzem geht das nun viel einfacher, weil endlich das Image aktualisiert wurde und man nun direkt v3 herunterladen kann.

Damit kommt nun auch Otto-Normal-User in den Genuss einer aktuellen RISC OS-Distribution, die nun sowohl WLAN-Unterstützung hat (auch dank des aktuellen und zudem IPv6-fähigen TCP/IP-Stack von RISC OS Developments) als auch mit vorinstalliertem Iris kommt, dem bisher sich noch im Beta-Stadium befindlichen WebKit-basierten Browser.

Nun bin ich nicht gerade Fan von solchen Distributionen, aber es hat definitiv Vorteile, dass es nun eine problemlos lauffähige und recht komplette RISC OS-Installationsmöglichkeit für Leute gibt, die sich keinen Kopf machen wollen oder einfach nur mal reinschnuppern wollen in den Urvater aller ARM-Betriebssystem. Oder endlich verstehen wollen, was es mit dem heiligen Zap vs. StrongEd-Krieg auf sich hat (der kleine Bruder von vi vs. Emacs).

Ovation Pro ist jetzt Open Source

2024-12-07 16:23

Lange nichts mehr gebloggt zum Thema RISC OS – insofern ist das „jetzt“ im Titel relativ zu sehen. Bevor ich die 1,5 Jahre Pause aufarbeite, dachte ich, es sei nur fair, wenn ich erst mal das Pilling-Triple vollende. Drei Blog-Posts in Folge (die ursprüngliche „Freigeben als Open Source“-Meldung, dann das Open Source-Release von SparkFS, jetzt der aktuelle Artikel) rund um die Software des vermutlich produktivsten Entwicklers der RISC OS-Szene – niemand hat das mehr verdient als David Pilling, von seinen Fans gerne „St. Pilling“ genannt.

Die Kurzfassung: David Pilling hat sein umfassendes Portfolio der einstmals kommerziellen Software nun als Open Source bereitgestellt, zusammen mit teils sehr kurzweilig zu lesenden Beschreibungen des historischen Kontextes. Sein größtes Softwareprojekt gehört jetzt auch dazu: Ovation Pro.

Wer es nicht weiß: Ovation Pro war und ist die beste und leistungsfähigste DTP-Software unter RISC OS, und im Gegensatz zum Erzfeind Impression (egal ob Style, Publisher oder Publisher+) auch schon seit 2002 – noch vor dem Release des IYONIX – vollständig 32bit-kompatibel. Und als zusätzlichen Bonus gibt es auch eine Windows-Version, die weitestgehend dateiaustauschkompatibel ist – man muss bei den Fonts etwas aufpassen, aber sonst ist das alles problemlos. Zu Risc PC-Zeiten war das mal mein Lebensretter, als ich ein vielseitiges Dokument mit großer Bilderdichte hoher Auflösung kreiert hatte, das unter RISC OS an Speicher- und Geschwindigkeitsgrenzen stieß. Auf den PC geschoben, dort einfach weitergearbeitet – super.

Man kann David Pilling gar nicht genug dafür lobpreisen, dass er in starkem Kontrast zu anderen ehemaligen oder aktuellen RISC OS-Marktteilnehmern den Aufwand getrieben hat, seine Meisterstücke wie SparkFS, Ovation Pro, Hearsay und David Pilling’s Scanning Software erstens über die Jahrzehnte kompatibel mit der neuesten RISC OS-Hardware zu halten (und Updates fast immer kostenlos zur Verfügung gestellt zu haben!) und jetzt die ganzen Sourcen compilefähig zusammengestellt zu haben. Und auch für die historisch Interessierten die damalige Referenzsoftware TWAIN für SCSI-Scanner und ArcFax für die weiterhin bevorzugte Datenübertragungstechnologie deutscher Behörden bereitzustellen. Oder wer es noch klassischer braucht: seine archaische Kermit-Portierung. Danke, danke, danke.

Vielleicht findet sich ja jemand, der die Pflege von Ovation Pro übernimmt – Chris Johnson hat ja David Pilling’s Scanning Software adoptiert, SparkFS ist bei RISC OS Open Ltd. gelandet.

Neues von SparkFS

2023-03-28 23:28

Auf der Liste der unverzichtbaren Tools unter RISC OS gehört zweifellos SparkFS von David Pilling auf den ersten Platz. Schon im Juli vergangenen Jahres gab es die frohe Kunde, dass nun auch die Read-Write-Variante kostenlos zur Verfügung steht. Jetzt wird die nächste Stufe gezündet: Open Source unter der Ägide von RISC OS Open Ltd.

Zusätzlich hat David gerade zwei neue Features hinzugefügt: ZIP Encryption (bitte frühzeitigen Enhusiasmus vermeiden – es geht um die originäre Passwortverschlüsselung, die heute eher als „Data Scrambling“ qualifiziert werden würde und keinesfalls höheren Sicherheitsansprüchen genügt) und Rename-Support. Nur für Tester im Moment verfügbar, aber hoffentlich demnächst auch etwas breiter. Gerade unter RPCEmu mit RISC OS 4.02 ausprobiert – tut. Encryption unter Windows gegengeprüft: funktioniert mit Windows 10-inbuilt-ZIP und 7-Zip und unter Java mit Zip4J (meines Wissens die einzige Pure-Java-Open-Source-Lib, die encrypted ZIP unterstützt).

David Pilling öffnet (erneut) die Schatzkiste

2022-07-28 12:15

Der vermutlich produktivste Entwickler kommerzieller Software für RISC OS, David Pilling – von seinen Kunden, Freunden und Verehrern auch liebevoll „St. Pilling“ genannt – hat erneut seine Schatzkiste geöffnet bzw. die Öffnung derselben auf seiner Mailing-Liste angekündigt. Die nebenbei den vielsagenden Namen „softwarelist“ trägt, eben weil David über viele Jahre eine so große Anzahl von phantastischen Anwendungen geschrieben hat, dass nur „Software“ ein geeigneter Überbegriff ist. Es geht diesmal sowohl um den Sourcecode als auch die fertig gebaute Version von SparkFS und von Ovation Pro.

Kurzer Blick auf Davids Schaffen: Ovation und Ovation Pro, Spark und SparkPlug und SparkFS, TWAIN nebst Treibern von Parallel-Port über SCSI bis zu USB für diverse Scanner, David Pilling’s Scanning Software (dessen ursprünglicher Name nicht mehr genannt werden soll – wörtlich übersetzt hieß das Dingens mal „Meister des Bildes“), unverzichtbare Software zur Modemnutzung wie Hearsay und ArcFax, Trace zur Konvertierung von Bitmaps in Vektorgrafik – dazu jede Menge kleinerer Tools, die zum Sparpreis oder gar kostenlos angeboten wurden. Das letzte große Projekt war dann Ovation Pro für Windows, für Wanderer zwischen den Betriebssystemwelten wie mich eine sehr gute Sache. David war wirklich extrem produktiv über die Jahrzehnte, auch wenn das letzte Jahrzehnt eher durch Pflege als durch Weiterentwicklung geprägt war. Trotzdem essentiell in der RISC OS-Welt mit dem Umstieg auf RISC OS 5 und später ARMv7 und ARMv8 – die Software von David Pilling war unter den kommerziellen Paketen stets unter den ersten, die auf neuen Systemen liefen. In Anbetracht der Tatsache, dass die Nutzer schon seit 20 Jahren auf die 32bit-Version von Impression warten, ist das durchaus eine Erwähnung wert.

SparkFS hat schon seinen Platz auf der „Retired Software“-Seite mit der aktuellen Vollversion 1.46 zum freien Download, Ich denke Ovation Pro wird sich auch alsbald dazugesellen (bisher gibt es nur eine für den OvPro Impression Document Loader). Vielleicht wieder mit einem launigen Text dazu, üblicherweise eine bittersüße Mischung aus Desillusionierung, akkurater Historie und Nostalgie. Nerd-Detail: es wird nicht der gesamte Inhalt der Ovation Pro-Distribution (früher 8 Disketten, später eine CD) zur Verfügung gestellt, weil dort auch lizenzierte Drittanbieter-Dinge mit dabei waren wie Fonts, für die David keine Distributionsrechte der Marke „kostenlose Verteilung“ hat.

Übrigens wird auch die Windows-Version von Ovation Pro freigegeben werden.

Und vielleicht findet sich ja jemand wie Chris Johnson im Falle von David Pilling’s Scanning Software, Snapper und SyncDiscs, der weiterhin Zeit investiert in die Pflege der Software.

StrongHelpViewer auf GitHub

2022-06-19 17:19

Irgendwie hatte ich dieses Release (doch auch schon Mai 2021, wie die Zeit vergeht…) meinerseits gar nicht hier ge-/verbloggt. Das hole ich mal schnell nach.

StrongHelpViewer, eine in Java geschriebene Software, erlaubt es auf Plattformen mit einigermaßen aktueller Java SE Runtime (mindestens Java 7, also Windows XP und neuer, Linux, MacOSX, OS/2, Solaris, AIX…) den Inhalt von StrongHelp-Dateien sowohl zu extrahieren als auch nach HTML zu konvertieren oder mit einem grafischen Viewer – in Java Swing geschrieben – zu betrachten. Den Quellcode habe ich unter die „Unlicense“ gestellt und auf GitHub veröffentlicht.

Wer es nicht weiß: StrongHelp ist der inoffizielle Standard für Online-Hilfe unter RISC OS. Es erlaubt bare-bones Hilfe-Content-Entwicklung mit einem einfachen Texteditor. Die StrongHelp-Datei ist ein Image-Filing-System, d.h. man wirft einfach seinen Hilfe-Content in Dateiform in das „Verzeichnis“ (die StrongHelp-Datei, die bei Anwesenheit von StrongHelp zum Quasi-Verzeichnis wird). Die verwendete Auszeichnungssprache erinnert entfernt an sowas wie AsciiDoc oder Markdown oder Wikitext oder HTML. Aber teilweise schon mit sehr spezifischen RISC OS-Eigenheiten wie Sprites oder Drawfiles für Grafiken, Direktzugriff auf RISC OS-Fonts, Squash zur Komprimierung von Hilfe-Content-Dateien.

Da das StrongHelp-Format recht gut dokumentiert ist (natürlich im StrongHelp-Format…), und ich eine natürliche Abneigung gegen Formate habe die ich nur auf einem Betriebssystem lesen kann, habe ich also als erstes ein paar Zeilen Code geschrieben, um das Image-Filing-System-Format zu decodieren. Dann ein paar Zeilen Code, um das StrongHelp-Content-Format nach Minimal-HTML-mit-CSS zu wandeln. Dann noch ein paar Zeilen Code, um eine Swing-UI drumrumzustricken. Fertig war der StrongHelpViewer.

Es gibt noch Lücken im Moment, die ich gedenke irgendwann zu schließen. Der Sprite-Support ist noch nicht integriert. Zu Drawfiles habe ich nur Ideen, aber noch keinen Code (Draw-to-SVG und dann SVG Salamander für die Swing-UI und SVG für den Browser liegen nahe). Einige sehr spezifische RISC OS-Spezifika wie das Ersetzen von OS-Variablen mit deren aktuellem Inhalt oder dem Ausführen von Utility-Code werden wohl nie unterstützt werden, sind aber auch in freier Wildbahn eher selten gesehen. Mein Ziel ist eher, einen möglichst komfortablen Browser für RISC OS-Doku zu bauen (die typischen SWI-Manuals), den ich Seite an Seite mit einem Emulator offen haben kann, um schnell was nachzuschlagen. Oder auch ohne Emulator. Oder auch als Service im Internet, denn die Konvertierung nach HTML schreit ja geradezu nach einem „StrongHelp-Server“ – URL zu irgendeinem Manual eingeben und losstöbern.

Im GitHub-Repo findet sich derzeit nur der Source – wer die Software also nutzen will, muss selbst kompilieren. Das sollte sich demnächst ändern, Leser dieses Blogs werden zeitnah informiert werden.

Vielleicht werde ich irgendwann auch noch SwingHelpViewer mit StrongHelpViewer fusionieren, beide haben schließlich dasselbe Thema, allerdings sind die Strukturen nicht ad-hoc kompatibel – SwingHelpViewer kommt ja von TOC-Chapter-Topic-Keyword-strukturierten Hilfeinhalten her, während StrongHelp eher so dem unstrukturierten Hypertext-Ansatz folgt.

Wer Screenshots sehen will: ich hatte im RISC OS Open-Forum mal was gepostet.

Toolbox-Gadget-Update

2022-01-26 00:54

Eine der größten RISC OS-Miseren ist vermutlich der Zustand der Entwicklungswerkzeuge. Die Community ist zersplittert in mehrere Fraktionen: die BBC BASIC-Fraktion, die seit den 80ern auf den BBC-8-Bittern auf die Kraft des Interpreters vertraut. Die Norcroft-Fraktion, die C-und-ein-wenig-Assembler-im-Bedarfsfall favorisiert, also dem althergebrachten Acorn-Style vertraut und vermutlich auf einen großen Sack voll selbstgebauter Bibliotheken. Und zuletzt die GCC-Fraktion, die C oder C++ nutzt, gegen die Unzulänglichkeiten der Portierung kämpft, sich mit ELF anfreunden muss, aber dafür potenziell Zugriff auf viele Open-Source-Bibliotheken aus aller Welt hat, die mittels GCCSDK-Autobuilder auch leidlich automatisiert auf dem aktuellsten Stand gehalten werden können.

Mitte der 90er, nachdem Acorn genug Beweise für das Scheitern des RISCOSLib-Ansatzes gesammelt hatte, machte man dort einen neuen Versuch: die „User Interface Toolbox“ – kurz „Toolbox“ sollte es richten. Eine prinzipiell programmiersprachenneutrale Sammlung aus Modulen und Tools, erweiterbar mit neuen Oberflächenelementen, „Gadgets“ genannt, sollte sowohl die C-/C++-Fraktion (C++ nur im allerweitesten Sinne, das DDE mit dem Norcroft-C-Compiler im Kern nutzt dafür das schon damals hoffnungslos veraltete CFront) als auch die Hardcore-Assembler-Fraktion als auch die BBC-BASIC-Fraktion unter einem gemeinsamen Banner vereint in die wunderbare Zukunft moderner UI-Technologie leiten.

Dieser Plan scheiterte. Die Toolbox sprang an zu vielen Stellen zu kurz: nur die wenigsten Entwickler konnten davon überzeugt werden, ihre Neuentwicklung auf die Toolbox zu stützen oder gar ihre Bestandssoftware umzustellen. Zum Erscheinungszeitpunkt der Toolbox hatte jeder Entwickler schon in eigene Bibliotheken investiert, die typischerweise schon deutlich leistungsfähiger als die Toolbox war. Dazu kamen zu viele Bugs, zu langsames Bugfixing, schlechte Doku vor allem bezüglich der Nutzung der Modularität zwecks Erweiterung durch eigene Gadgets, zu viel Speicherbedarf für die damals noch weitverbreiteten 4-MiB-RISC OS 3.1-Maschinen, zu wenig Nutzen wegen akuter Feature-Armut, Zwang zum DDE-Kauf weil der „GUI-Designer“ namens ResEd nur im Paket mit diesem zu haben war, zu wenig Abstraktion (man war deutlich zu nah am WIMP), durch die Realisierung als Module lief plötzlich viel Code einer App im OS-Kontext, zu unsicher die Zukunft einer Acorn-closed-source-Lösung – jeder Entwickler hatte seine individuelle Liste an Gründen, die Toolbox nicht einzusetzen. Ein kurzer Hoffnungsschimmer flammte noch 1997/1998 auf mit dem heroischen Weiterentwicklungsakt getrieben durch Java und Browse, als tatsächlich Fortschritt sichtbar war an der UI-Front vom Nested-WIMP über neue Gadgets bis hin zu frei zugänglicher Dokumentation, wie man denn diese Gadgets richtig schreibt. Too little, too late.

Gewisse Problemfelder der Toolbox sind inzwischen nicht mehr so problematisch zu sehen – dank des Open-Sourceings von RISC OS sind nun sowohl ResEd als auch die Module für jedermann frei zugänglich und sowohl erweiter- als auch fixbar, und nach 25 Jahren Stabilisierung ist auch das Thema Bugs weitestgehend gegessen. Auch einige größere Anwendungen sind auf Toolbox-Basis geschrieben und beweisen deren Stabilität und grundsätzliche Tauglichkeit, und es gibt ein paar Bibliotheken oder Frameworks drumrum, die die Arbeit erleichtern. OSLibSupport sei hier zu nennen, TBX, oder auch AppBasic. Und RISC OS 3.1-Kompatibilität und Speicherfeilschen im einstelligen Kilobyte-Bereich ist Gott sei Dank auch nur eine vage Erinnerung an eine längst vergangene dunkle Periode, allgemein bekannt als „die schlechte alte Zeit“.

Nun hat Rik Griffin verlauten lassen, dass er zwei seiner Toolbox-Gadgets, „Tabs“ und „Tree“, als Open Source auf GitHub veröffentlicht (und vermutlich auch noch andere Software aus seiner Feder). Unter BSD-Lizenz. Eine gute Sache, bietet es doch die Möglichkeit, die Module in RISC OS 5 zu integrieren und damit das Thema „Auslieferung“ für den geneigten Entwickler deutlich zu vereinfachen. Den Anfang macht das Tabs-Gadget, und dank der aufmerksamen Community sollte der jetzt veröffentlichte Stand self-contained von jedem DDE-Nutzer in Objektcode überführbar sein.

In einem anderen Thread im ROOL-Forum hat Tank aka Robert Kinton diese freudige Nachricht zum Anlass genommen, sein DateGadget (ein Date-Picker-Toolbox-Objekt) aktualisiert zum Download bereitzustellen. Noch ohne Source Code, aber was nicht ist kann ja noch werden.

Eine späte Renaissance der Toolbox? Man wird sehen. In Gerphs RISC OS-Rambles gibt es ja auch das Toolbox-Thema in einigen Beiträgen, da kann man sehen was möglich gewesen wäre, wenn es nur ausreichend Entwicklerkapazität zum richtigen Zeitpunkt gegeben hätte.

RISC OS 5 User Guide endlich als PDF-Download

2021-11-02 20:47

RISC OS Open Ltd. hat die lang erwartete Verfügbarkeit des „RISC OS 5 User Guide“ als PDF-Download bekanntgegeben. Download über diese Seite, für die aktuelle Version passend zu RISC OS 5.28 tut auch dieser Direktlink.

Bisher wurde der freie PDF-Download durch ein Font-Lizenzproblem torpediert (die Lizenz erlaubte nur Publikation durch den Lizenznehmer selbst, also ROOL, und auch nur in Print, aber nicht Online), aber eine Spende von CJE Micro’s für ein Lizenzupgrade hat diese Problematik jetzt entschärft. Also los, rund 600 Seiten warten auf den geneigten Leser.

Auch physische Varianten, also in der Form „Dead Tree Publishing“ sind erhältlich. In Post-Brexit-Zeiten dank des unseligen EU-Protektionismus nun mit einem erheblichen Europa-Aufschlag für die Kontinent-Bewohner behaftet.

Arculator v2.1

2021-11-02 18:26

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

2021-11-02 17:27

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