Software

Anwendungen und Tools rund um RISC OS

Neuer RPCEmu-Fork

Update 2026-08-03: Workaround Windows Tastaturproblem: in Windows das Tastaturlayout auf Englisch(UK) stellen, *keyboard germany unter RISC OS, schon funktioniert alles – Issue dazu in GitHub angelegt

Dank einiger alter RISC OS-Mitstreiter bin ich auf einen neuen Fork von RPCEmu aufmerksam geworden: „RPCEmu Spork Edition“ oder „rpcemu-extended“ oder „RPCEmu Extened“ [sic!] – wie auch immer. Jedenfalls lebt das Projekt auf GitHub, initiiert und gepflegt von Andrew Timmins. Und, wie es aussieht, unter tätiger Mithilfe von Claude. Vermutlich deshalb ist die Doku zu Code und Funktionalität nicht so sparsam wie bei üblichen 1-Entwickler-Projekten.

Und „Extended“ ist hier wirklich ernstgemeint. USB- und Seriell- und Parallel-Port-Emulation, Kinetic-Emulation (endlich 512 MB RAM…), eine Viewfinder-artige Grafikkarte zur Erweiterung der beschränkten VIDC20-Fähigkeiten, ShareFS/Access-Unterstützung, Clipboard-Unterstützung, Mausrad-Unterstützung, integrierter Debugger, VNC-Server für Remote-/Headless-Betrieb, zwei HostFS-Mounts gleichzeitig, integrierter Package-Manager (sprich: läuft auf Ebene des Emulators, nicht unter RISC OS selbst wie beispielsweise !Packman, nutzt aber dieselben Package-Quellen), MacOSX-Build, ARM64-Dynarec, integrierter MCP-Server für die KI-Freunde, vollständige FPA10-Emulation, Multi-Machine-Frontend zum Anlegen und zur Pflege verschiedener Emulationskonfigurationen nebst der Möglichkeit, eine aktuelle RISC OS 5-Installation zu erzeugen (ROM und Harddisc-Image), Suspend/Resume…das ist schon eine ganze Menge. Unter der Haube wurde das ungeliebte Qt durch wxWidgets ersetzt, man könnte sagen, RPCEmu verbrüdert sich jetzt wieder mit Arculator. Von Arculator wurden auch ein paar Podules geerbt, mal sehen was da noch kommt.

Die neueste Version 1.1.12 jedenfalls läuft bei mir überwiegend problemlos mit RISC OS 5 und RISC OS 4.02. ShareFS/Access mag noch nicht funktionieren, egal gegen was (Paolos ShareFS-Server, RISC OS-Maschinen, Andrews ShareFS-Server). Bei der Tastaturunterstützung gibt es auch noch Probleme (deutsche Umlaute? Tasten tot Workaround gefunden!). Aber für einen ersten Wurf: sehr interessant und weiter zu beobachten. Nachdem der erste RPCEmu-Fork („Spoon Edition“, das Projekt der Howkins-Brüder, die die letzten Jahre RPCEmu am Leben erhalten haben) durch eher gletscherartige Weiterentwicklungsgeschwindigkeit „glänzt“ und der davon geforkte Fork von Cloverleaf auch nach kurzer Aktivismusphase seit etwa 4 Jahren wieder eingeschlafen ist, ist mir fast jeder Fortschritt recht.

Mir scheint allerdings, dass Windows nicht gerade die primäre Plattform ist und die Features vermutlich unter Linux durch den Entwickler (und vermutlich auch die KI) besser getestet werden. Mal sehen, ob ich Zeit finde, beim Test zu unterstützen. Die Taktzahl ist jedenfalls hoch: die erste Version 1.0.1 wurde am 16. Juni diesen Jahres veröffentlicht, und die oben genannte 1.1.12 am 2026-07-31. Beeindruckend, erklärt aber auch, warum manche Features noch „am Reifen“ sind und noch nicht 10% zuverlässig in allen Konstellationen laufen.

Große Retro-Software-Welle im Anrollen

Aus alter Verbundenheit bin ich immer noch stiller Mitleser diverser RISC OS-Mailinglisten. Auf einer derer kam vor wenigen Tagen die Ankündigung, dass die über 10 Jahre dauernden (also ein echtes Projekt aus der RISC OS-Welt – man wartet ewig drauf, und wenn es dann fertig ist, interessiert sich keiner mehr dafür) Bemühungen, die Reste von APDL nach dem Tod von APDL-Gründer und Inhaber David Holden 2014 wieder gesammelt zur Verfügung zu stellen, sich jetzt der Finalisierung nähern. Was natürlich auch bedeuten kann, dass es nochmal ein Jahr dauert, man wird sehen.

Wer sich nicht mehr an APDL erinnert: die „Archimedes Public Domain Library“ begann Ende der 80er damit (als man noch der irrigen Annahme war, „Public Domain“ würde im europäischen Copyright-Kontext irgendeine Bedeutung haben und man generell das Thema Software-Lizenzierung eher freihändig handhabte), kostenlose Software sowie Shareware und Careware auf Disketten gegen kleinen Obulus per Mail-Order in die weite Welt zu verschicken. Nach und nach übernahm APDL auch andere PD-Libraries und schließlich auch den Vertrieb diverser kommerzieller Software, die dann oftmals auch kostenlos zur Verfügung gestellt wurden. Beispiele dafür sind Dansoft, Alligata, Clares, iSV Products, DataStore, RISC Developments (ex-Beebug) und ProAction (selbst schon Resterampe für diverse Software-Einzelstücke unterschiedlichster Provenienz).

Einige der ehemals kommerziell erhältlichen Software-Produkte wurden auch noch überarbeitet und 32bit-fähig gemacht. Wir dürfen gespannt sein. Zusammen mit dem geretteten Inhalt des alten ftp.uni-stuttgart.de-Acorn-Archivs, der Arcade BBS (über archive.org) und arcarc.nl (nur echt mit CDBurn- und CDVDBurn-Raubkopien!) dürfte die Retro-Fraktion auf absehbare Zeit genug Futter haben.

Ovation Pro ist jetzt Open Source

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

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

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

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

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.

R-Comp Pre-Show News

Nun sind wir dank meiner Lahmarschigkeit nicht mehr Pre-Show sondern Post-Show („Show“ im Sinne der RISC OS London Show 2021 am vergangenen Wochenende), aber ein paar Infos aus dem Premieren-R-Comp-YouTube-Video, das am vergangenen Donnerstag live gestreamed wurde, wollte ich noch notiert haben. Schön zu sehen, dass auch in den letzten Resten der kommerziellen RISC OS-Welt langsam die neuen Möglichkeiten zur Produktpräsentation genutzt werden.

Softwareseitig lag der Hauptfokus auf Fireworkz, von R-Comp in der Geschmacksrichtung „Fireworkz Pro“ verkauft (ich hatte über die diversen Details schon 2015 gebloggt). Die Ex-Colton-Software wird neben seinem älteren Bruder Pipedream vom Originalentwickler Stuart Swales liebevoll gepflegt und ist inzwischen bei Version 2.31 angekommen. Das „Pro“ in „Fireworkz Pro“ ist der Datenbank-Teil dieses Softwarepakets, das man für nicht-RISC OS-ler vermutlich am besten als „Microsoft Works-Konkurrent“ beschreiben könnte, für nur-RISC OS-ler konsequenterweise als „Acorn Advance-Konkurrent“. Textverarbeitung und Tabellenkalkulation sind eng integriert, und im „Pro“-Falle kommt noch ein Datenbankteil dazu, der von DataPower (ebenfalls inzwischen bei R-Comp) abstammt. Solche integrierten Pakete gab es in der IT-Steinzeit der späten 80er zuhauf, beispielsweise in der 8-Bit-Zeit als Mini-Office oder Star-Writer, zu DOS-Zeiten waren Lotus Symphony und StarOffice im Rennen, später wurden meist Einzelprogramme als „Office-Paket“ zusammengefasst wie bei Lotus SmartSuite, WordPerfect Office oder auch den freien Produkten OpenOffice bzw. LibreOffice, die aus StarOffice hervorgegangen sind. Aber ich schweife ab.

Passend zu Fireworkz hat R-Comp in Zusammenarbeit mit Andrew Conroy, der die diverse Software aus der Feder des 2009 verstorbenen Paul Vigay pflegt, Webworkz wiederauferstehen lassen. Webworkz erlaubt die Erzeugung eines Standalone-HTML/CSS-Pakets, um Fireworkz-Dokumente möglichst einfach ins Web zu bringen. Sah jetzt auf den ersten Blick nicht so spektakulär aus, eben HTML-Export. Die Software stammt ursprünglich aus den Nullerjahren, war früher Shareware und wird jetzt zusammen mit Fireworkz Pro gebündelt. Wenn ich es richtig verstanden habe, soll aber auch eine freie Version publiziert werden, sobald Andrew Conroy die Zeit dazu findet.

Ein Update zu Messenger Pro 8 wurde ebenfalls verkündet, mir ist nur „hauptsächlich Bugfixes“ im Ohr geblieben.

Die Hardware-Seite von R-Comp war für mich schon immer interessanter, und hier gibt es sowohl Fertiges als auch Ausblick zu berichten. Bereits bekannt sind der 4té – ein RPi 4 in einem interessant aussehenden Gehäuse mit einem durchaus interessanten Softwarepaket inklusive Trade-In-Möglichkeit, falls man schon einen RPi 4 besitzt – und der TIX Duet, eine „Zwei-Boards-in-einem-Gehäuse“-Maschine bestehend aus einem Titanium-Board und einem PC-Board nach Kundenwahl. Letzteren gibt es nicht von der Stange, er wird individuell nach Kundenwunsch zusammengebaut, und es wurde mehr als einmal betont, dass die Maschine je nach Ausstattung recht preisintensiv ausfallen kann. Kein Wunder, denn der Basispreis wird ja schon durch das Titanium-Board auf schlappe 500 UKP festgezimmert, und da ist noch kein Gehäuse und kein Netzteil und keine Montage dabei.

Die „+1“-oder „Plus One“-Cartridge ist eine kleine Erweiterungsbox für den Raspberry Pi 400, bestehend aus einem RTC-Modul (das neumodische Zeugs bezieht aktuelles Datum und aktuelle Uhrzeit ja immer aus dem Netz, was für Standalone-Betrieb nicht immer günstig ist) und einem kleinen Schalter, der ohne microSD-Karten-Tausch ein Umschalten zwischen zwei Betriebssystemen beim Booten ermöglicht. Der Name „+1“ ist eine Reminiszenz an eine Acorn-Erweiterungsbox namens Acorn Plus 1 Expansion module für den Acorn Electron.

R-Comp zusammen mit Cloverleaf arbeitet schon länger an einer Portierung von RISC OS auf den Rockchip RK3399-SoC, der nicht nur auf zahlreichen SBCs verwendet wird, sondern vor allem im Pinebook Pro, dem Nachfolger des inzwischen nicht mehr produzierten Pinebook, das als „ARMBook“ von R-Comp verkauft wurde und auf einem Allwinner-SoC basierte. Es gibt hier noch einige Probleme auszuräumen, bis die Rockchip-Portierung die Verkaufsreife erlangt. Besonders im Bereich USB gibt es Lücken (nur der USB2-Port funktioniert), und fehlende Treiber für den NVMe-Slot sowie das integrierte eMMC wurden genannt – wobei auch von microSD gebootet werden kann, so dass letzteres vermutlich kein Showstopper wäre.

Das Beste kommt zum Schluss, und so vermeldete R-Comp Fortschritte bei der Produktion ihres ITX-Boards für das Pi 4 Compute Module. Die Raspberry Pi Foundation verkauft den Pi bekanntlich in drei Geschmacksrichtungen: „Normal“ wie die den meisten bekannten A(+)- und B(+)-Modelle, „Klein“ wie die Zero-Modelle und „als Modul“ wie die Compute Modules. Letztere sind eine Art Steckplatine oder neudeutsch Daughterboard, die nicht Standalone funktioniert, sondern eben als Modul auf ein Motherboard gesteckt wird. Standardmäßig gibt es da ein I/O-Board, das aber in Kombination mit dem Pi 4 CM wenig mehr bietet als ein Pi 4 oder Pi 400 – Full-Size HDMI, ein PCIe-Steckplatz und die unvermeidliche RTC. Die R-Comp-Variante soll hingegen die für unsereins wichtigen Features nachrüsten: S-ATA und ein Standard-Formfaktor des Boards, so dass es in Gehäuse „off the shelf“ passt. Das gezeigte Bild des Boards hatte einen internen M.2-Konnektor (S-ATA only – NVMe wäre nochmals teurer, für RISC OS gibt es noch keine Treiber, und der Performancegewinn ist im RPi-CM-Umfeld fragwürdig) und 3 S-ATA-Sockets neben dem „üblichen“ wie Power, USB und Ethernet sowie einem PCIe-x1-Slot. Bemerkenswert war noch, dass „Load“-Anschlüsse vorgesehen waren, um für zickige Netzteile ggf. zusätzliche Last zu erzeugen. Wer sich an die Probleme bei IYONIX und Titanium erinnert bei der Verwendung diverser ATX-Netzteile darf hier aufatmen. Naheliegender Performance-Engpass an dieser Stelle ist natürlich die eine verfügbare PCIe-Lane mit nominell 5 Gbps, aber für schnelles S-ATA und dazu noch USB3 sollte es für RISC OS-Zwecke dicke ausreichen.

Im Moment liegt das Produktionsdatum im November, und man darf auf den Preis gespannt sein. Pi 4 CM (die 4 GiB-RAM-Variante liegt schon bei 65€, und da man tendenziell ein Dual-OS-System will, ist für Linux eher die 8 GiB-RAM-Variante anzuraten, die in der WLAN+BT-Variante bei knapp 100€ liegt) und ITX-Motherboard zusammen werden wohl kaum preislich signifikant unter einem Titanium-Board liegen, wenn ich mal meine Laieneinschätzung zum Besten geben darf. Es ist nicht zu erwarten, dass R-Comp hier 1000er Stückzahlen produzieren lässt, und obwohl auch bestückte Boards in kleinen Stückzahlen inzwischen sehr preiswert in Fernost gefertigt werden können, werden allein die Spezialkomponenten wie der PCIe-Switch und die CM-Connectors den Materialpreis unangenehm in die Höhe treiben, insbesondere in der derzeitigen angespannten Chip-Situation.

Das Titanium-Board ist ja nun auch schon ein paar Jahre alt, und das dort verwendete TI-OMAP5-SoC ist vor allem videotechnisch inzwischen (und eigentlich auch schon damals) hinterm Mond und wurde performancetechnisch vom Pi 4 überholt, zumindest was CPU und Speicher angeht. Die Kombination ITX-Motherboard mit RPi 4 CM-Daughterboard könnte das nun auch bei der Plattenperformance schaffen, so dass ein schönes rundes System entstehen könnte. R-Comp hätte auch die Chance, dieses ITX-Board an der Linux-Front zu verkaufen, denn es gibt schlicht derzeit (noch?) nichts Vergleichbares auf dem Markt. Allerdings ist dieser Teil des Computer-Marktes eher preissensibel, so dass der Erfolg keineswegs sicher ist. Zumal dort die traditionellen R-Comp-Stärken „RISC OS-Support“ und „RISC OS-Software-Bundle“ keinen Mehrwert begründen. Und für die Linuxer gibt es natürlich an der ARM-Front deutlich mehr Alternativen zum Raspberry Pi. Wenn es für die neuen ARM-Macs mal ein schmerzfreies Linux gibt, werden diese Geräte allein aus Performancegründen die erste Wahl werden.

Jedenfalls könnte die Kombination ITX-Motherboard mit RPi 4 CM-Daughterboard auf längere Sicht die Spitze der RISC OS-kompatiblen ARM-32bit-Maschinen sein, und da hilft die garantierte Verfügbarkeit des RPi 4 CM bis 2028 sicherlich. Eine schöne Überbrückung hin zum langen beschwerlichen Weg von RISC OS in die 64bit-ARM-Welt.

Raster-Copper-Dingsbums leicht gemacht

Ich denke, das ist einer der seltenen Premieren-Artikel – zu einem Thema, das ich bisher in keinem der fünf Blogs gestreift habe. Vermutlich deshalb, weil ich da von echtem Expertentum doch ziemlich entfernt bin, aber das hat mich noch nie davon abgehalten, klug daherzuschwätzen.

Das heutige Thema dreht sich um einen Effekt, den ich zum ersten Mal auf dem C64 in einem Cracker-Intro gesehen habe, und der damals (1984?) allgemein unter dem Begriff „Raster-Balken“ lief. Im Prinzip farbige, animierte horizontale Linien, die lustige Bewegungen auf dem Bildschirm vollführten und wahlweise im Vorder- oder Hintergrund von anderen Grafiken – statisch oder ebenfalls animiert – dargestellt wurden. Wer sich noch an die eher gletscherartige Zugriffsgeschwindigkeit der CPU auf den Bildschirmspeicher zur damaligen 8-Bit-Zeit erinnert, weiß sofort: da wurde mit Hardware-Tricks gearbeitet. Sicheres Erkennungsmerkmal: die „Raster Bars“ füllten nicht nur den normalerweise beschreibbaren Bildschirmbereich, sondern auch den Rahmen, der normalerweise nur einfarbig sein konnte.

Als dann der Amiga die Szene betrat, wurden die Effekte nochmal deutlich ausgefeilter und liefen unter dem Oberbegriff „Copper Effects“, wobei der „Copper“ ein Teil von Agnus war, einem der Amiga-Coprozessoren. Die Architektur des Amiga erlaubte es über DMA-Mechanismen diesen Coprozessoren im Prinzip CPU-unabhängig lustige Dinge zu veranstalten. Im Falle des Coppers z.B. die komplette Umkonfiguration von Bildschirmparametern wie Farbpalette, Auflösung, Farbtiefe und so weiter während des Bildschirmaufbaus zu ändern, und zwar auf Pixelebene, und nicht wie früher auf dem C64 nur auf Zeilenebene.

Auf dem Archimedes waren solche Effekte zwar möglich, aber sehr kompliziert, weil man eben keinen Raster-Interrupt zur Verfügung hatte und keinen Copper, d.h. man musste das Timing „zu Fuß“ hinbekommen. Im Prinzip warten auf VSync, und dann die richtige Zeit abwarten, um den VIDC mit neuen Parametern zu versorgen. Nicht gerade leichter gemacht dadurch, dass das Timing der Kisten ja alles andere als einheitlich war: ARM2 mit 8 MHz bis ARM3 mit 36 MHz, Video-DMA je-nach-Bildschirmmodus, dazu die Variabilitäten durch die RISC OS-Interruptbehandlung…

Rasterman to the rescue: kürzlich hat Steve Harrison (den Szene-Insidern vielleicht auch noch unter seinem Pseudonym Phoenix der Demo-Coder-Gruppe Quantum bekannt), den einige vielleicht aufgrund seiner früheren Schöpfungen QTMTracker und AnyMode kennen, endlich den Sourcecode für Rasterman freigegeben, inklusive Beispielen und Dokumentation und einem Versionsupgrade auf 0.21. Man kann sich auf der Seite auch zwei YouTube-Videos anschauen, die einige mögliche Effekte schön illustrieren.

Haken an der Sache: ohne reale Archimedes-Hardware hat man nur den halben Spaß, weil Arculator auch in der Version 2 vom Timing her noch nicht ganz präzise genug ist, um alle Effekte unfallfrei zu emulieren. Notiz für mein zukünftiges Ich, das viel mehr Freizeit hat: mal auf dem Archimedes-Core des MIST(er) nachprüfen, wie genau da emuliert bzw. simuliert wird.

Randnotiz: der Acorn Archimedes erinnert in dieser Hinsicht stark an den Schneider/Amstrad CPC, der auch ganz ohne Hardwareunterstützung Tricks wie Raster Bars „zu Fuß“ erledigen musste. Insofern war mein Umstieg vom CPC zum Acorn A3000 damals irgendwie folgerichtig.

RISC OS Direct für Raspberry Pi 4 und 400

Andrew Rawnsley hat verkündet, dass endlich die RISC OS Direct-Distribution auch „out of the box“ auf den Raspberry Pi-Modellen 4 und 400 läuft. Bisher war das RISC OS dieser Distribution auf dem Stand Februar 2020, jetzt dreht darin RISC OS 5.28 in der für den Pi 400 angepassten Version.

Hier geht es zum Download. Welcher von den drei Links? Da kann man nur raten…

In letzter Zeit gibt es ja fast eine Art Distributionitis für RISC OS, neben RISC OS Direct gibt es noch die „Easy Starter“-Bundles für RPCEmu und natürlich die angekündigte Cloverleaf RISC OS-Distribution. Fast ein bisserl wie bei Linux. Nur bei der regelmäßigen Aktualisierung hapert es gewaltig – die Pi 4-kompatible RISC OS-Version ist ja nun schon ein paar Monate alt, und was viel schlimmer ist, die Webseite von RISC OS Direct schwieg sich dezent darüber aus, dass das Image nicht für den Pi 4 taugt. Gerade bei einer Distribution, die eher „normale“ Nutzer im Visier hat als Entwickler-Frickler, ist das irgendwas zwischen peinlich und schädlich.