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.

RISC OS 5 User Guide endlich als PDF-Download

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

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.

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.

RISC OS Awards: and the winner is…

Wer kennts sie nicht, die RISC OS Awards. Ursprünglich eine Auszeichnung, die vom Drobe Launchpad (lange Zeit noch im “Archive”-Modus verfügbar, im Moment gerade down) vergeben wurde auf Basis einer User-Online-Abstimmung. Inzwischen hat Vince M. Hudd von Soft Rock/Riscository diese ehrenvolle Aufgabe übernommen, gerne immer leicht verspätet – die 2020-Award-Ergebnisse wurden erst kürzlich veröffentlicht. Man erinnert sich ja kaum noch an 2020. Und mein Blogbeitrag dazu kommt natürlich im Gegensatz dazu kaum verspätet.

Jedenfalls habe ich dort zum ersten Mal den ersten Platz abgeräumt in der eher weniger konkurrenzträchtigen Klasse “Best foreign language resource”. Knapp aber deutlich mit 33% zu 30% gegen riscos.fr durchgesetzt. Man soll ja angeblich auf dem Höhepunkt aufhören – aber dieser Ratschlag bringt bekanntlich das Problem mit sich, dass man mangels Glaskugel leider nicht weiß, ob es sich bereits um den Höhepunkt handelt, oder ob der erst noch kommt. Vielleicht sind es nächstes Jahr 34%? Hätte Michael Schumacher nach seinem ersten Weltmeistertitel aufhören sollen? Oder nach seinem ersten Grand-Prix-Sieg? Eben.

Ich war gar in zwei weiteren Kategorien mit CDVDBurn 3 nominiert, bei “Best new development” mit dem Blu-Ray-Support und bei “Best commercial software” mit CDVDBurn selbst, aber da war mit so einem Randgruppenthema wie “Scheiben brennen” natürlich nichts zu erben.

Nun könnte ich also das “Sieger-Cog” hier im Blog irgendwo dekorativ integrieren. Allerdings habe ich ein sehr gespaltenes Verhältnis zu Grafiken im Web – man hätte früher ja begründet vermuten können, dass das schlicht Faulheit ist, aber jetzt wäre die Grafik ja schon vorgefertigt, und damit taugen die RISC OS Awards prima als Indiz für die völlige Abwegigkeit dieser Vermutung.

Raspberry Pi Zero 2 W

Die Pi Foundation hat heute den brandneuen Raspberry Pi Zero 2 W angekündigt. Bei den üblichen Verdächtigen wie Reichelt Elektronik wird ein Preis von etwas über 15€ aufgerufen (official RRP: 15 US$) und eine Lieferung für Anfang November in Aussicht gestellt. Wenn man sich an den ersten Pi Zero erinnert, und noch die derzeitige Chipknappheit mit in Betracht zieht, dürfte die Verfügbarkeit anfangs sich eher schwierig gestalten.

Neben der zwar logischen, aber immer schwerer unfallfrei zu reproduzierenden Nomenklatur (zweite Auflage des Pi Zero, und mit Wireless (sowohl 802.11b/g/n als auch BT 4.2), aber CPU-technisch eher ein Pi 3, aber speicherausbautechnisch eher ein Pi 1, und speichergeschwindigkeitstechnisch weiß man es noch nicht) kann sich der geneigte Pi-Freund auf einen kräftigen Performance-Boost für alle multicore-fähigen Workloads freuen nebst VFPv4 und NEON. Aber auch für uns RISC OSler ist die deutlich bessere Single-Core-Performance nicht zu verachten – obwohl wie sein Vorgänger mit lediglich 1 GHz taktend, ist ein ARMv8-Cortex-A53 dank superskalarer Ansätze deutlich flotter unterwegs als das ARMv6-ARM11-Derivat des Ur-Zero(W)-Modells. Bemerkenswert finde ich das Packaging: die 512 MiB DDR2-RAM stecken im SoC, also kein PoP wie sonst typischerweise bei den kleinen SBCs zu sehen.

Mal sehen, ob RISC OS Anpassungen benötigt. Die Zero-Modelle sind für RISC OS-Zwecke nie so richtig beliebt gewesen – außer für Kompatibilitätssicherstellung wegen “ARMv6 ist wie ARMv5 sprich IYONIX”. Und da ist der neue ARMv8-Cortex-A53 natürlich eher kontraproduktiv. Auf der anderen Seite wären die 512 MiB mehr als ausreichend für die üblichen RISC OS-Dinge, während ein Linux da eher mal in Platznot gerät.

Spannend aus meiner Sicht auch, ob das Runtertakten auf 1 GHz hilft, um die Hitzeentwicklung im Zaum zu halten. Der Pi 3 war schließlich der erste Pi, wo ein Lüfter eher anzuraten war, vor allem in der +-Ausprägung.

Update 2021-10-29

Chris Gransden berichtet von einem erfolgreichen RISC OS-Lauf auf dem Pi Zero 2 W. Benchmarkergebnis legt nahe, dass die RAM-Geschwindigkeit gegenüber den alten Zero-Modellen sehr deutlich zugelegt hat. Ungefähr auf Pi3-Niveau, also deutlich schneller als beispielsweise ein Wandboard aka ARMX6, ein Pi 2, ein PandaBoard oder ein BeagleBoard-xM.

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.