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.

RISC OS 5.28 auf dem Raspberry Pi 400

Es ist schon fast ein Jahr her, als ich über den aktuellen Stand von RISC OS 5.xx auf dem Raspberry Pi 4 berichtet hatte. Damals noch sehr rudimentär ausgeprägt, zwar lauffähig aber wegen unvollständiger USB-Unterstützung fingen die Probleme schon bei der Stromversorgung an.

Die meisten der unvollständigen Dinge wurden schon mit RISC OS 5.28 gelöst – USB tut nun ohne Tricks, d.h. man kann USB-C wie gedacht für die Stromversorgung nutzen und die “normalen” USB-Ports eben für USB. Auch das Ethernet ist inzwischen stabil und auch recht schnell, und die 4 GiB-Variante funktioniert nun auch problemlos. Selbst die 8 GiB-Variante tut nun, aufgrund seiner 32bit-Natur kann RISC OS aber in Ermangelung einer Unterstützung der Aarch32-“Large Physical Address Extension”-Technik nur 4 GiB nutzen. Fehlt also nur echte USB3-Unterstützung, aber da braucht es wohl das Großreinemachen im USB-Stack (also z.B. die Neuportierung des aktuellen BSD-Stacks, wie in diesem ROOL-Bounty skizziert).

Kurz nach dem Release von 5.28 kam dann die Raspberry Pi Foundation um die Ecke mit ihrer neuesten Kreation, dem Raspberry Pi 400. Erstmalig eine Abkehr des Konzepts “nackte Platine, der Rest findet sich”. Das hatte sich ja schon abgezeichnet, gibt es doch inzwischen ein “offizielles Netzteil”, ein “offizielles Gehäuse”, eine “offizielle Tastatur” und eine “offizielle Maus”. Wenn man das jetzt alles kombiniert und im Hinterkopf behält, warum seit der ersten Variante des Raspberry Pi es ein “Model A” und ein “Model B” gibt – fertig ist das neue Produkt “Raspberry Pi 400 Kit”. Man könnte es die “jüngste Hommage an die große Zeit der 8/16-Bit-Heimcomputer” nennen. Oder auch der 32bit-Heimcomputer, wenn man an den Acorn A3010 oder 3020 denkt.

Wer es nicht mitbekommen hat: der Pi 400 ist im Prinzip ein Pi 4 in der 4 GiB RAM-Variante in einem kompakten Tastaturgehäuse. Alle Anschlüsse befinden sich auf der Rückseite, der analoge Soundausgang ist weggefallen, sonst alles da – vom GPIO über die 2 microHDMI bis zum Ethernet. Und nur 3 statt 4 USB-Buchsen, weil die Tastatur ist ja schon integriert. Auch die microSD-Karte wird hinten eingesteckt, und endlich mal wieder mit einem vernünftigen Feder-Slot-Mechanismus wie es zuletzt beim RPi B+ zu finden war. Dank der intern verbauten Kühlbleche konnte man den Takt etwas höher ansetzen, 1,8 GHz gegenüber 1,5 GHz. Man kann den 400 in zwei Varianten kaufen, als nacktes Gerät oder als “Kit” inklusive gedrucktem Einsteiger-Handbuch, Netzteil, microSD-Karte mit vorinstalliertem Raspbian und microSD-SD-Adapter mit Raspberry Pi-Logo, microHDMI-Kabel und der bekannten himbeerrot-weißen USB-Maus. Verschiedene lokalisierte Varianten sind verfügbar, was bei einer integrierten Tastatur ja auch eine gute Idee ist. Ich habe mich für die DE-Variante entschieden.

RISC OS Open Ltd. hat kurz nach Weihnachten verkündet, dass es eine entsprechende Distribution von RISC OS Pi auf Basis eines leicht aktualisierten RISC OS 5.28 mit einem fancy pinboard backdrop zur Verfügung steht – und das auch über den offiziellen Raspberry Pi Imager. D.h. der RISC OS-Installationsvorgang kann über einen PC der Wahl über den Imager mit wenigen Clicks erfolgen. Das habe ich tatsächlich mal ausprobiert, und es funktioniert völlig problemlos. Profi-Tipp: Linux herunterfahren, Karte tauschen und wieder die Power-Taste drücken reicht nicht, vermutlich weil der Rechner nur in einer Art Standby-Modus ist. Man muss das Dingens kurz stromlos machen, dann wird die RISC OS-Karte klaglos akzeptiert.

Leider haben die fertigen Images den Makel, dass sie die Kapazität der microSD-Karte in keinster Weise ausnutzen können – es bleibt stets bei der vom Image vorgedachten Größe, im vorliegenden Fall knapp 2 GiB. RISC OS unterstützt noch immer keine echten Partitionen (sonst könnte man ja den restlichen Platz einfach als zweite Partition einrichten), und das Filecore-Format ist der Alptraum einer jeden Partition-Resizer-Anwendung, weshalb es schlicht keine gibt. Deshalb taugt aus meiner Sicht für RISC OS im Moment weiterhin nur das Vorgehen “von Hand”: vorhandenen Pi mit RISC OS drauf nehmen, microSD-Karten-Leser und leere große microSD-Karte, SystemDisc, microSD entsprechend einrichten (ich empfehle einen großen FAT-Bereich, den kann man prima für Datentransfer mit anderen Betriebssystemen nutzen, solange das Netzwerk noch nicht funktioniert), config/txt und cmdline/txt anpassen, HardDisc4-ZIP entpacken. Wie immer hatte ich bei meinem Setup wenig Glück mit EDID und der RISC OS-Idee der automatischen Bildschirmerkennung, und so konfiguriere ich den richtigen Bildschirmmodus immer fest in die config/txt und verwende disable_mode_changes, weil das für ADFFS in Verbindung mit AnyMode der viel problemlosere Betriebsmodus ist.

Die “Power”-Funktion über die Tastatur (Fn + F10) erfordert übrigens die Mitarbeit des Betriebssystems, unter RISC OS gibt es hier noch keine Unterstützung. Schade, Shutdown mit nachfolgendem Power-Off wäre schön.

Auch in die Raspbian-Distribution – inzwischen “Raspberry Pi OS” genannt – habe ich einen Blick geworfen, finde es aber nach wie vor für ein Massenprodukt erstaunlich unrund, was hauptsächlich zu merken ist, wenn man “Deutsch” als Sprache auswählt. Denn auch danach geht es erschreckend oft in Englisch weiter. Ganz gut gelungen ist hingegen die deutsche Übersetzung des dem “Kit” beliegenden Einsteiger-Handbuchs (auch wenn ich nie auf die Idee gekommen wäre, das urdeutsche Wort “Overscan” durch “Übertastung” zu ersetzen). Interessierte können es als PDF runterladen, dafür muss man nicht das “Kit” kaufen. Man beachte, dass auch viele der Screenshots die jeweilige deutsche Version zeigen, da hat jemand mitgedacht und mit Plan gearbeitet. Wenn jetzt noch jemand ein entsprechendes Handbuch, angepasst an RISC OS und mit BBC BASIC-Beispielen schreiben würde…

Und die Hardware? Macht alles einen recht soliden Eindruck. Die Tastatur ist Laptop-artig mit hartem Anschlag und kurzen Tastenwegen, jedoch für meinen Geschmack etwas zu steil im Winkel angestellt – aber klar, irgendwo muss ja auch die Hauptplatine hin. Es ist ein sehr kompaktes Layout, und für RISC OS-Zwecke nervig, da es nur Platz für 10 F-Tasten hat und so die oft genutzte F12-Taste nur per Modifier (hier “Fn” genannt, in Kombination mit F2 ergibt sich dann die F12-Taste) zugänglich ist. Aber immerhin wird das Auge nicht durch ein Windows-Logo beleidigt, denn dort befindet sich logischerweise die allseits beliebte Himbeere. Die Maus ist im besten Sinne unspektakulär, höchstens das etwas kurze Kabel könnte nervig sein. Die microSD-Karte ist ein Markenprodukt von SanDisk, stellt aber keine Geschwindigkeitsrekorde auf. Das Netzteil funktioniert wie zu erwarten prima, genau wie das (auch eher kurze) microHDMI-HDMI-Kabel.

Ist der Pi 400 – ob nackt oder als “Kit” – nun sein Geld wert? Das muss jeder selbst entscheiden, der Aufpreis gegenüber der nackten 4 GiB-Platine hält sich schließlich in Grenzen. Wer wie ich das Basteln gewöhnt ist, und wenn das Rechner-Setup rund um einen KVM-Switch gebaut ist und deshalb die integrierte Tastatur keinen Vorteil darstellt – nun gut, wie gesagt der Aufpreis hält sich in Grenzen, und wenn man den Rechner “mal schnell” woanders mit hinnehmen will, ist das All-in-one-Design vielleicht doch von Vorteil. Schade ist aus meiner Sicht, dass man den neu gewonnenen Platz nicht dafür genutzt hat, die frickeligen microHDMI-Ports durch ihre Full-Size-HDMI-Pendants zu ersetzen. Man muss nicht jeden Holzweg konsequent zu Ende gehen – bei der nacken Pi4-Platine gab es immerhin noch die “wir hatten keinen Platz”-Ausrede.

Vielleicht passt eines der neueren Pi 4-Gehäuse besser zu meinen Ansprüchen – liegt inzwischen mit allen notwendigen Materialien hier rum und wartet auf Zusammensetzung: ein Alu-Gehäuse mit USB3-M.2-SATA-Adapter und Power-Taster namens “Argon One M2”, ein Pi 4 in der 8 GiB-Variante, und eine Samsung M.2-SATA-SSD mit 512 GiB die hoffentlich gut ins Gehäuse passt. In diesem Falle ein Gehäuse mit zwei Full-Size-HDMI-Buchsen, dazu ein eingebauter IR-Sensor, ein softwaresteuerbarer Lüfter, und der analoge Soundausgang bleibt auch erhalten. Dazu eine recht intelligente Lösung für die GPIO-Pins. Vielversprechend.

Sunfish und Moonfish auf GitHub unter MIT-Lizenz

Man soll das Jahr ja immer mit guten Nachrichten beginnen. Mit der Überschrift ist eigentlich auch schon alles gesagt: Alex Waugh hat seine unverzichtbaren Tools Sunfish und Moonfish auf GitHub publiziert und umlizenziert von der ungeliebten GPLv2 auf die sehr viel liberalere MIT-Lizenz. Hier ist der Sourcecode.

Wer es nicht weiß: Sunfish ist ein NFS-Client für RISC OS ab Version 3.11. NFSv2 und NFSv3 werden unterstützt, sowohl über TCP als auch über UDP. Alles Notwendige für saubere Cross-Platform-Behandlung von Dateinamen und -typen ist an Bord, und es gibt ganz feingranulare Konfigurationsoptionen, damit sich die RISC OS-Seite mit der Unix-Natur von NFS gut versteht. Man kann Sunfish sowohl im “Dateisystem auf der Iconbar”-Modus betreiben als auch als “Image-File als Mountpoint in einem beliebigen Verzeichnis”-Modus. Ja, man wünscht sich einen aktuellen SMB-Client, der auch alle diese Optionen unterstützen würde.

Moonfish ist das Gegenstück, ein NFS-Server. Auch NFSv2 und NFSv3 (hier sogar mit partieller Unterstützung für NFSv4), sowohl über UDP oder TCP.

Ich verwende Sunfish seit ewigen Zeiten zum Zugriff aller physischen und virtuellen RISC OS-Maschinen auf mein NAS. Sowohl bei der Entwicklung von Software als auch z.B. für Backup-Zwecke und zum allgemeinen Datenaustausch absolut unverzichtbar. Durch dieses Setup musste ich bisher Moonfish nie verwenden, weil das NAS als Server ja “always on” ist. Wer aber einen Ersatz für ShareFS sucht (z.B. weil RPCEmu es nicht gut unterstützt), kann mit der Sunfish-Moonfish-Combo den Peer-to-Peer-Ansatz von ShareFS nachbauen.

Wie es aussieht, hat Alex die Gelegenheit genutzt und gleich all seinen Sourcecode auf GitHub abgelegt. Am bekanntesten dürfte der SVN-Client und WebJames sein. Sehr schön!

In diesem Sinne: ich wünsche allen Lesern ein erfolgreiches, friedliches und gesundes neues Jahr 2021.

Cloverleaf Kickstarter gestartet

Viele haben vermutlich schon auf anderen Kanälen vom Cloverleaf Project gehört, initiiert von einem alten Bekannten in der RISC OS-Szene – zumindest für die, die schon zu Archimedes-Zeiten dabei waren: Stefan Fröhling, früher bekannt für die Entwicklung und den Verkauf des ersten IDE-(Mini-)Podules für Archimedes-Rechner vom A3xx/A4xx bis zum A3000 unter dem Namen “Evolution Computer GmbH” aus dem schönen Olpe im Sauerland.

Nun wurde der Cloverleaf Kickstarter gestartet, eine klassische “crowdfunding campaign”, die in der RISC OS-Szene für einige Fragezeichen gesorgt hat. Vermutlich auch deshalb, weil die Kampagne sehr viele Dinge auf einmal versucht zu tun – ich will versuchen, hier ein wenig Kontext zu liefern zur Herangehensweise von Cloverleaf, den Chancen, den Risiken und den Unklarheiten.

Stefan Fröhling war lange Zeit in der Szene nicht aktiv, grob hat er rund 20 Jahre ausgesetzt, zwischen 1998 und 2018, also “Ende Acorn” bis “RISC OS unter Apache-Lizenz freigegeben”. So eine lange Abwesenheit hat Vor- und Nachteile. Auf jeden Fall den Vorteil, nicht allzu viel historischen Ballast mitzubringen und zudem als aktiver Nutzer anderer Computersysteme und Betriebssysteme eine Idee davon zu haben, was heutzutage ein RISC OS-Neueinsteiger von einem Betriebssystem erwartet. Auf jeden Fall ist es aber auch von Nachteil, die diversen Befindlichkeiten innerhalb der RISC OS-Szene nicht so genau zu kennen. RISC OS ist ja tendenziell eher ein Einzelkämpfer-Biotop denn eine Community, die an einem Strang zieht, und die Nutzerschar ist klein, meinungsstark und sehr divers. Divers bezogen auf die Ansprüche – den einen kann die Modernisierung des OS nicht schnell genug gehen, die anderen beschwören die Wichtigkeit der heiligen Rückwärtskompatibilität und des “Anderssein” gegenüber anderen Betriebssystemen. Wer bei Erscheinen des “Style Guide” zu RISC OS 3 damals mitverfolgt hat, wie der Wechsel von Select-Copy-Move zu Cut-Copy-Paste als Paradigma der Blockoperationen heiß diskutiert wurde, wird wissen was ich meine. Oder hat vielleicht jemand noch Lust auf eine wochenlange Diskussion über Vor- und Nachteile von kooperativem Multitasking gegenüber präemptivem Multitasking? Ich bin sicher, auf Google Groups finden sich noch die Threads aus dem Usenet, comp.sys.acorn.* war damals viel frequentiert, lange bevor diese neumodischen “Webforen” auftauchten.

Und da sind wir schon bei einem wichtigen Punkt der Cloverleaf-Idee: Stefan geht aus von den Bedürfnissen eines RISC OS-Neueinsteigers und hat sich überlegt, was denn in und um RISC OS fehlt, um zumindest vom Prinzip her ein OS bereitzustellen, das nicht schon kurz nach dem Erstkontakt als “nice try” wieder in der Schublade verschwindet. Und dass das ein tatsächliches Problem darstellt, sieht man ja am Ausbleiben des dramatischen Nutzeranstiegs nach Verfügbarkeit der Raspberry-Pi-Version von RISC OS. Kostenlos verfügbar für Millionen von RPi-Besitzern und -Nutzern, aber kaum jemand nimmt von RISC OS Notiz.

Und so gibt es (mindestens) vier Zielrichtungen des Cloverleaf-Projektes, die m.E. unglücklicherweise alle in derselben Crowdfunding-Kampagne gelandet sind: 1. Die Weiterentwicklung von RISC OS an den diversen neuralgischen Punkten. Diese sind leider zahlreich: WLAN, IPv6, USB3, Bluetooth, UTF-8, Internationalisierung, Cacheing, Dateisystem (Partitionierung, Fremddateisysteme wie exFat und ext2/3), Multi-Core-Unterstützung und natives Multithreading, Security-Features, Prozessisolation, moderne Fontformate, Unterstützung solch schnöder Hardware wie aktuelle Drucker…die Liste ist endlos. 2. Die Bereitstellung neuer Hardware, auf der RISC OS läuft. Das “Kitten”-System ist noch einfach in Reichweite, ist es doch schlicht ein Raspberry Pi 4 in einem schicken Gehäuse. Bei Puma, Laptop und All-in-one-System sieht es aber schon anders aus: auf Basis eines Rockchip-SoCs, dazu noch mit Mali-GPU, das ist um zwei bis drei Größenordnungen anspruchsvoller. 3. Die Bereitstellung von Software, damit zumindest für den “normalen” Benutzer keine allzu großen Lücken bestehen in dem, was man so täglich nutzt. Und das beginnt beim modernen Browser und hört bei der Office-Suite und einer Bildverarbeitungssoftware noch lange nicht auf. Selbst in Bereichen, wo RISC OS Mitte bis Ende der 90er noch recht gut aufgestellt war – Musik, E-Mail, DTP – gibt es heute entsetzliche Lücken. 4. Die Bereitstellung einer “Cloverleaf RISC OS-Distribution” für alle RISC OS-Systeme vom Emulator (RPCEmu) bis zum Raspberry Pi.

Die ganze Kickstarter-Beschreibung liest sich wie ein Wunschzettel, der herauskommt, wenn man 100 RISC OS-Benutzer fragt, was ihres Erachtens das größte Problem der Plattform ist. Die Kickstarter-Kampagne läuft damit Gefahr, es allen recht machen zu wollen. Kein Fokus. All things for all people. Keine klare Message, keine klaren Ziele.

Es soll das niemand falsch verstehen. Alle diese Ziele sind valide. Sie werden gebraucht. Sie müssen umgesetzt werden. RISC OS hat eine Menge aufzuholen gegenüber anderen Betriebssystemen, und die genannten Dinge sind nur ein Anfang. Aber die Frage ist: kann man eine solche Diversität an Zielen sinnvoll und klar kommunizieren? Das Feedback sagt m.E. eher: nein, es ist zu komplex, es ist zu erklärungsbedürftig, es ist zu unübersichtlich. Schon das Feedback in Richtung “warum werden dort Sachen verkauft, die doch eigentlich kostenlos sind” zeigt das Problem. Oder die Frage, ob es dann ein “Cloverleaf RISC OS” gibt als Fork des altbekannten “RISC OS 5”. Oder die Frage, ob die angedachte Multi-Core-Unterstützung in Konkurrenz zu den bisherigen Bemühungen von Jeffrey Lee stehen (Antwort: nein, es SIND die Bemühungen von Jeffrey Lee, die im Rahmen der Cloverleaf-Ziele direkt verwendet werden sollen!). Oder die Frage, warum man 300€ für einen RPi 4 im schicken Gehäuse zahlen soll (Antwort: es ist Crowdfunding um RISC OS weiterzuentwickeln, nicht ein schnöder Hardware-Verkauf!).

Aus meiner Sicht war es höchste Zeit, dass jemand die RISC OS-Szene mit neuen Ideen aufmischt. Stefan verwendet hier einen eher managementorientierten Ansatz, was ihn deutlich vom “üblichen”, eher ingenieurs-bis-bedenkenträgerischen RISC OS-Ansatz abhebt, und vermutlich eckt er deshalb auch öfter mal an oder kann sein Anliegen nicht so klar und trotzdem diplomatisch formulieren, dass es breit verstanden wird. Stefan hat erkannt: um in endlicher Zeit Nägel mit Köpfen machen zu können, braucht es neue Leute. Neue Entwickler und neue User. Am einfachsten findet man neue User, wenn man ihnen interessante Produkte anbietet oder mindestens in Aussicht stellt. Am einfachsten findet man z.B. Entwickler, wenn man ihnen Geld bezahlt. Heraus kam mit ChatCube eine RISC OS-Anwendung, die von Entwicklern geschrieben wurden, die völlig ohne RISC OS-Vorkenntnisse an die Sache herangegangen sind. Es ist der Beweis, dass die Herangehensweise funktioniert. Ob sie auch für das OS selbst funktioniert, bleibt abzuwarten. Und ob am Ende die Bemühungen in einen signifikanten Anstieg an RISC OS-Nutzern münden – schön wäre es. Aber wetten würde ich nicht drauf. Seit Acorn-Zeiten wird versucht, diverse RISC OS-Merkmale zur Besetzung von Nischen gewinnbringend einzusetzen. Besonders erfolgreich war man damit zu keiner Zeit.

Erfrischend finde ich, wie Cloverleaf die “neuen Medien” für sich nutzt. Ob Facebook-Gruppe oder Kickstarter, oder auch ChatCube als Telegram-Client – da weht gar ein Hauch von Modernität durch die angestaubten RISC OS-Hallen.

Weil ich ein prinzipiell detailversessener Mensch bin, stören mich allerdings auch diverse Kleinigkeiten am Cloverleaf-Auftritt, die aus meiner Sicht unsauber und damit unnötig angreifbar sind. Und für nicht-RISC OS-Experten auch irreführend sein könnten. Zum Beispiel die Screenshot-Seite – wäre hier nicht ein Hinweis vonnöten, dass die dort gezeigte Software teilweise kommerziell und nicht ganz billig ist? “Excellent for Retro Gaming” – in welcher Hinsicht, außer klassische RISC OS-Spiele, wäre das denn tatsächlich der Fall? Wäre es nicht gut, präzise auszuführen, was denn nun Cloverleaf anschieben und machen will, und was eh schon anderweitig auf dem Weg ist? Wäre es nicht hilfreich, die genaue Position im RISC OS-Universum zwischen beispielsweise RISC OS Open Ltd., RISC OS Developments, R-Comp, Elesar und RISC OS Direct zu definieren? Oder die Liste der “available software” auf der Kickstarter-Seite – Impression Style als 26bit-Software aufzuführen, die bekanntlich nur unter Aemulor dreht, ist schon etwas verwegen. Dazu der hohe “Rauschanteil” auf der Kickstarter-Seite – warum die vielen Dinge nennen, die einen Menschen aus der Zielgruppe “neuer potenzieller Benutzer” überhaupt nicht interessieren oder zumindest gar nichts sagen – PlingStore, Packman, …. Oder warum wird eine mögliche klare Message verwässert durch Nichtigkeiten wie “ein freies Exemplar des Archive-Magazins” oder “ein Cloverleaf-T-Shirt” oder “ein RISC OS-Einsteiger-Buch”? Und auch das Loblied auf die RISC OS-Fonttechnologie wirkt doch seltsam aus der Zeit gefallen, haben hier doch alle anderen Plattformen RISC OS schon lange überholt. Seit ungefähr 20 Jahren.

Am Ende überwiegt aber mein Optimismus, dass diese neue Herangehensweise durchaus von Erfolg gekrönt sein kann. Und das Schöne am Crowdfunding ist ja, dass das persönliche Risiko eng begrenzt ist, und trotzdem im Erfolgsfall eine schöne Summe zustande kommen kann, mit der einiges bewegt werden kann. Wie gesagt, die Ziele an sich sind absolut valide. Und deshalb werde auch ich eine der Kickstarter-Optionen von Cloverleaf unterstützen. Ich weiß nur noch nicht welche. Die Timeline halte ich für sehr optimistisch, das ist kaum zu schaffen, egal wieviel Geld man in die Sache investiert – Softwareentwicklung ist nicht beliebig parallelisierbar, und im RISC OS-Universum müssen teilweise erst mal mühsam die Basics geschaffen werden (z.B. Entwicklerwerkzeuge) von einer sehr begrenzt verfügbaren Anzahl von kompetenten Entwicklern, bevor man an andere Aufgaben gehen kann. Und dennoch: ich bleibe optimistisch. Wer es versucht, kann scheitern. Wer es nicht versucht, ist schon gescheitert.

Übrigens ist auch dieser Blogbeitrag ein schönes Beispiel dafür, wie schwierig es ist, komplexe Sachverhalte klar und verständlich zu beschreiben. Beim nochmaligen Durchlesen bleiben dann doch Zweifel…

(Nicht mehr ganz so) Neues von der RISC OS London Show 2020

Die jährlich stattfindende RISC OS London Show wurde 2020 als “virtueller” Event in Form eines Zoom-Meetings abgehalten, mit YouTube-Livestreams für diejenigen, die nur “konsumieren” wollten und nicht aktiv partizipieren. Die Idee war, die beliebten “Show Theatre Presentations” remote abzuhalten – mit physischem Kauf toller Produkte hat man virtuell ja immer noch keine befriedigende Lösung gefunden, aber verschiedene Präsentatoren erwähnten als Ersatz “Show Price”-Aktionen, um dem sonst gewohnten Messe-Feeling etwas näher zu kommen.

Der Livestream ist für Interessierte natürlich immer noch bei YouTube abrufbar, einfach die Show-Website besuchen.

Was wurde an Neuigkeiten vorgestellt? Hier der Schnelldurchlauf, mit Fokus auf den Themen, die ich persönlich für interessant halte. Subjektiv, wie immer.

Elesar/Robert Sprowson zeigte Neuigkeiten in Prophet, einem Software-Paket für die Buchhaltung und Abbildung von typischen Business-Prozessen für kleine Unternehmen. Logischerweise nahe an den Erfordernissen bezüglich “Tax system in UK”. Ebenfalls gezeigt wurden diverse Hardware-Erweiterungen für den Pi im “HAT”-Format wie dem parallel/serial-HAT und dem Wifi-HAT. Natürlich jeweils mit allen notwendigen Hardware-Treibern für den Einsatz unter RISC OS. Wer also seinen alten 9-Nadel-Drucker an den Pi anschließen will…Sprow scheint einen gewissen Hang zu Parallelports zu haben, auch für das Titanium-Board gibt es eine PCI-Express-Karte mit Parallel-Port und passendem Treiber. Und wenn ich mich recht erinnere gab es früher von ihm auch eine PCI-Karte für den IYONIX.

Stefan Fröhling vom Cloverleaf Project stellte die Projektziele und die (damals noch: anstehende, aktuell: gerade gestartete) Kickstarter-Kampagne für das Projekt vor. Dazu werde ich demnächst einen eigenen Artikel veröffentlichen, da es sehr viel Unklarheiten rund um dieses Projekt sowie Kickstarter-Kampagnen generell zu geben scheint.

Phil Pemberton erzählte von den Bemühungen der ABug (Acorn and BBC User Group), sich um das Thema “Software Preservation” für RISC OS zu kümmern. Während Jon Abbott ja das Thema “Spiele” mit JASPP vorbildlich gemeistert hat (bzw. immer noch meistert, weil noch lange nicht alle alten Spiele für die Öffentlichkeit frei zugänglich sind) und gar mit ADFFS einen nahezu perfekten Emulator für den Raspberry Pi geschaffen hat, der die problemlose Ausführung der alten Schätze auf neuer Hardware ermöglicht, gab es bisher beim Thema Anwendersoftware eine große Lücke. Phil zeigte eine sehr professionelle Präsentation mit vielen Details bezüglich der Vorgehensweise (z.B. in welcher Struktur man sowas wie Zeitschriften, Handbücher, Softwareverpackungen, Diskettenlaben usw. sichert), der Ziele und der Schwierigkeiten. Cool auch, dass direkt in der anschließenden Diskussion John Cartmell, ehemals Macher von Qercus, die Erlaubnis gab die alten Ausgaben dieser Zeitschrift öffentlich verfügbar zu machen. Die Präsentation ist hier separat verfügbar.

Danach kam Andrew Rawnsley mit dem Doppelschlag – sowohl RISC OS Developments als auch R-Comp. Da gehe ich aufgrund der Breite der Themen etwas genauer drauf ein.

Das größte und m.E. wichtigste Projekt von RISC OS Developments ist momentan der “Iris”-Browser. Basierend auf WebKit, ist es im Gegensatz zu den “plain ports” wie Otter-browser und QupZilla ein “polished port”, also ein echtes RISC OS WIMP-Programm, das WebKit nur zum Rendering der Webseite an sich nutzt und sich sauber in das Betriebssystem einklinkt. Das sieht alles sehr vielversprechend aus, aber leider tut es das auch schon sehr lange, ohne dass bisher für den Normalbenutzer eine Version verfügbar gemacht wäre. Im Moment ist Iris nur in den Händen der RISC OS Developments-Shareholders, vor Weihnachten soll es an die OBrowser-Nutzer gehen, wann es dann allgemein verfügbar ist, weiß noch niemand. Ich verstehe diese Vorgehensweise durchaus, denn man will etwas bekannt Unfertiges nicht einfach in der Breite ausrollen – und eine Entwicklerversion ist natürlich etwas anderes als eine sorgfältig getestete, stabile und runde Produktivversion die man gerne verteilen würde. Aber es ist dahingehend frustrierend, dass man weiß, dass es da etwas schon ganz gut Funktionierendes gibt, man es aber nicht ausprobieren kann. Mastermind hinter Iris ist Lee Noar, der sich rund um GCC und ELF-Support verdient gemacht hat und von dem auch die Qt-Portierung stammt, die für Otter und QupZilla ja die Grundlage darstellt. Lee ist ebenfalls dabei, GCC 8.2 und GCC 10 an den Start zu bringen, und Iris ist quasi das Pilotprojekt dafür.

Pinboard 2.0 war sein nächstes Thema, eine Evolution des Pinboards das uns seit Urzeiten (RISC OS 3.1?) begleitet. Es ist Teil der Bemühungen, gewisse Workflows die man von anderen Betriebssystemen her kennt auch unter RISC OS verfügbar zu machen, z.B. das direkte Speichern von Dateien auf den Desktop wie unter Windows. Aus meiner Sicht ein guter Schritt in Richtung mehr Usability. Manche – vor allem die alten RISC OS-Hasen – mögen solche Bemühungen geringschätzen, ich finde sie hingegen sehr lobenswert. Wer schon einmal gesehen hat, wie schwer sich manche Windows- und Linux-Benutzer tun, wenn sie mit RISC OS arbeiten wollen, sieht sicher die Notwendigkeit ein, diverse Dinge von diesen Systemen zu übernehmen, ohne das bekannte RISC OS-Look&Feel grundlegend zu ändern. Je kleiner der Bruch ist, desto größer die Wahrscheinlichkeit, dass ein Benutzer zumindest ab und zu RISC OS als das richtige Betriebssystem für gewisse Tätigkeiten nutzen will. Und auch für Menschen wie mich, die nicht die Hauptzeit mit RISC OS verbringen sondern mit Windows und Linux, ist eine gewisse Angleichung von Vorteil. Pinboard 2.0 ist gerade im Test, wer mithelfen will kann Andrew mailen. Auf Sicht soll Pinboard 2.0 auch für alte RISC OS-Versionen zur Verfügung stehen (zumindest RISC OS 4, wie Andrew sagte).

RISC OS Direct wurde ebenfalls angesprochen mit dem kommenden Update für das Raspberry Pi 4. Wer es nicht weiß: es handelt sich hier um eine RISC OS-Distribution basierend auf dem gewohnten Harddisc-Image von RISC OS 5 wie man es von ROOL herunterladen kann, aber mit einer Menge zusätzlicher kostenloser Software und diversen Erleichterungen für den Neueinsteiger. Verfügbar ist das ganze als Ready-to-run-Image, das man einfach auf eine 16GB-microSD-Karte schreibt und in den Pi steckt. Es gibt auch eine Reihe von Erklärvideos dazu, die den Einstieg erleichtern sollen. Schöne, unkomplizierte Sache für Neueinsteiger.

Dann eine aus meiner Sicht besonders schöne Neuigkeit: das lang ersehnte Update des RISC OS TCP/IP-Stack. Basierend auf dem aktuellen OpenBSD-Stack, ist es ein wichtiger “Enabler” für diverse Dinge wie IPv6 und WLAN/Wifi. Besonders wichtig: aus Sicht der Anwendungssoftware sollte der Wechsel des Stacks komplett transparent sein, alles funktioniert wie vorher. Nur besser. Der derzeitige Stand ist “ping tut, NetSurf tut”. Wenn alles glatt läuft, wird der Stack seinen Weg ins “normale” RISC OS 5 finden. Wann das sein wird – man wird sehen. Der Netzwerk-Stack ist natürlich ein sensibles Teil, da sollte man am Testaufwand nicht sparen. Laut Andrew wird der neue Stack von einem “commercial customer” finanziert, d.h. das existierende Bounty bei ROOL muss nicht angekratzt werden. Ich hoffe, dass – sofern die Qualität stimmt – es dann keine Schwierigkeiten gibt bei der Integration in RISC OS 5 durch ROOL.

Eine ganz andere gute Nachricht, aber auch passend dem Netzwerk-Thema, ist das Open-Sourcing von LanMan98, dem guten alten LanMan-Client (LanMan als Synonym für SMB, Samba, CIFS…) mit Warm Silence Software-Vergangenheit. Der Quellcode sollte demnächst verfügbar sein. Leider kommt das ein paar Jahrzehnte zu spät, weil dank vor allem Colin Granville der klassische LanManFS-Code, der Teil von RISC OS 5 ist, inzwischen dieselben Features unterstützt. Gemeinsam ist beiden, dass sie mit aktuellen Authentifizierungsmethoden im SMB-Universum nichts anfangen können, was die Nutzung z.B. gegen Windows 10 oder aktuelle NAS-Systeme immer schwieriger macht. Da muss noch Arbeit geleistet werden.

Dann: Python 3. Chris Johns ist gerade dabei, Python 3 zu portieren und sicherzustellen, dass es sich nahtlos in RISC OS integriert, ähnlich wie es zuvor Dietmar Schwertberger mit Python 2 gelungen war. Das sieht alles schon recht gut aus, auch wenn mich die Performance beim ersten Draufschauen nicht umgehauen hat. Aber das gilt ja fast systemübergreifend. Schwierigkeiten machen natürlich die “nativen” Bibliotheken, die normalerweise nur für x86/x64 zur Verfügung stehen. Prinzipiell ist es natürlich wünschenswert, eine so weit verbreitete Sprache wie Python unter RISC OS verfügbar zu haben – im Moment gibt es ja mit RiscLua und BBC BASIC nicht unbedingt die großen Kracher.

Kurz gestreift wurde auch das Thema “RISC OS auf AArch64”, ohne hier die große neue Idee einzubringen. Vermutlich, weil es diese Idee niemals geben wird – RISC OS in die 64bit-Welt zu bringen wird harte Arbeit werden, und es wird eine virtuelle Maschine benötigen, um den alten Code unfallfrei laufen zu lassen. Ein nettes Arbeitspaket für 10 Jahre auf einer einsamen Insel.

Unter der R-Comp-Flagge stellte Andrew diverse neue Hardware vor. Der 4té ist eigentlich “nur” ein nettes Gehäuse für den RPi 4 mit dem üblichen R-Comp-Service inklusive – Disc-Image, einfacher Update-Mechanismus für OS- und Anwendungsupdates, und eine Reihe von gebundelter Software sowie der persönlichen Support-Note. Natürlich nicht ganz so preiswert wie die nackte RPi 4-Platine, aber in der Range der RISC OS-Systeme von R-Comp der Preisbrecher. Wenn man seinen existierenden RPi 4 bereitstellt, gibt es auch einen schönen Rabatt.

Ein weiteres Stück Hardware hört auf den Namen “TiX Duet”. Im Prinzip ein ATX-Gehäuse, in dem sowohl ein Titanium-Board als auch ein “normales” PC-Board lebt. Komplett “built to order”, d.h. man kann sich die Komponenten selbst aussuchen, die man auf der PC-Seite gerne haben will. Hier ist mir die Zielgruppe nicht ganz klar – die Systeme teilen außer Gehäuse und Netzteil ja keine gemeinsamen Komponenten, d.h. außer “es ist nur ein Gehäuse” ist so direkt jetzt kein Vorteil zu erkennen gegenüber zwei separaten Maschinen. Bei denen man dann statt des Titanium ja auch einen preiswerten Pi 4 verwenden könnte, der CPU-technisch auch noch schneller ist. Und 4K-Auflösungen unterstützt. Aber einen Vorteil hat der “TiX Duet” für die reinen Anwender schon: denn R-Comp bundelt natürlich diverse Software vorkonfiguriert mit, z.B. UniPrint, UniScan, UniLaunch, UniClip, LanMan98 und eine VNC-Lösung um von einem System auf das andere zuzugreifen. Bis man das selbstkonfiguriert am Laufen hat, kann das schon ein wenig dauern. Und Zeit ist bekanntlich auch Geld.

Beim ARMBook, dem ersten nativen RISC OS-Laptop (basierend auf dem Pinebook) seit dem Acorn A4, zeichnet sich laut Andrew ein Lieferengpass ab, weil die Produktion zum Pinebook Pro hin verlagert wird – dafür gibt es aber noch kein angepasstes RISC OS, weil es auf einem anderen SoC basiert (RockChip RK3399 statt Allwinner A64). R-Comp hat aber noch ein paar Exemplare auf Lager.

RISCube, SpaceCube und RISCbook wurden auch kurz erwähnt, aber PCs mit RISC OS-Emulator finde ich nicht so spannend. Interessant war die Aussage von Andrew, dass die PC-als-RISC OS-Maschine-Produktlinie immer noch 50-60% der verkauften Hardware ausmachen. Das finde ich deshalb interessant, weil dort der Mehrwert ja noch viel schwerer zu erkennen ist als bei Geräten wie dem ARMX6 oder dem ARMBook. Man steckt halt nicht drin im Briten.

Software war auch am Start bei R-Comp. Die neue FireworkzPro-Version kann nun vernünftig OLE, das erleichtert den Datenaustausch mit anderen Programmen um beispielsweise Tabellen in Techwriter oder Impression zu importieren.

Der Folgevortrag von David Herreros Cerro von der Universität Cantabria aus Spanien handelte von !UCDebug, einem Debugger für ARM-Assembler-Code, natürlich unter RISC OS. Die Software wird an dieser Uni verwendet, um den Studenten Low-Level-Programmierung auf dem Raspberry Pi nahezubringen. Das gerade unter RISC OS zu tun ist natürlich exotisch, für die RISC OS-Community aber super, weil dieses schöne Stück Software dabei abgefallen ist. Das Projekt wird auf GitHub veröffentlicht und gepflegt. Als jahrzehntelanger Assembler-Abstinenzler (zuletzt größere Assembler-Dinge waren in Z80-Assembler und dann noch ein klein wenig HP-PA-RISC-Assembler an der Uni, ARM-Assembler habe ich nur oberflächlich kennengelernt und mein Glück dann stattdessen in Hochsprachen gesucht) kann ich bezüglich Nützlichkeit leider keine Auskunft geben.

RISCOSbits kam danach. Eine unglaubliche Anzahl von Gehäusen rund um RISC OS-taugliche Entwicklerboards, sehr kreativ und durchaus nicht teuer. Mit wunderbaren Namen wie “Deuce”, “Thorin”, “Slim Jim”, “Delta”, “Ghostly” und “Disq”. In den meisten Fällen sind noch Adapterplatinen dabei, damit alle Ports auf einer Seite zur Verfügung stehen anstatt “rundrum” wie es beispielsweise beim Pi und anderen kleinen, kompakten SBCs üblich ist.

Steve Revill von RISC OS Open Ltd. gab den Schnelldurchlauf rund um die Bemühungen, RISC OS 5 als Open Source-Projekt in die Zukunft zu begleiten. Das Bounty-System war altbekanntes Terrain mit kurzem Überblick über die derzeit aktiven Bounties von !Paint-Verbesserungen bis zu PNG-Export. RISC OS 5.28 hatte ich schon anderswo thematisiert – die Kurzfassung: “läuft prima auf dem Pi 4”. DDE30 war auch Thema, der gute alte Norcroft C-Compiler hat den Umgang mit C17 gelernt, dem neuesten Standard im C-Universum – verwirrenderweise erst im Juni 2018 finalisiert d.h. von der ISO publiziert, da ist der Name mal nicht Programm (und um die Verwirrung noch zu steigern, reden viele Leute trotzdem von C18, aber Wikipedia liegt diesmal richtig mit C17). Ein kurzer Ausblick in die Zukunft von RISC OS rundete den Vortrag ab und streifte auch altbekannte Themen getreu der Weisheit “Die wirklich großen Probleme haben keine Lösung, sondern Geschichte”: Multi-Core-Unterstützung, Multi-Monitor-Unterstützung, Erweiterungen in BBC BASIC bezüglich Strukturen (also quasi Record-Typen) und dynamischer Speicherallokation. Und zum guten Schluss die 32bit-64bit-Transformation, die in den nächsten Jahren (oder Jahrzehnten?) ansteht. Schwieriges Thema. Es wird sich nicht von allein und auf magische Weise lösen, jede denkbare Lösung hat auch gravierende Schwächen, solange man nicht mindestens die Ressourcen von Apple auf das Thema ansetzt – siehe deren Transformation von 680×0 nach PowerPC, von PowerPC nach x86/x64, und jetzt von x86/x64 nach AArch64.

Matthew Phillips von Sine Nomine Software präsentierte hauptsächlich Erweiterungen für RiscOSM, der “OpenStreetMap”-Anzeigesoftware für RISC OS. Neu verfügbar dafür ist nun !Recce, ein Zusatztool um Geolocation-Metadaten rund um Karten anzuzeigen wie Google Streetview- und Flickr-Bilder. Da kann ich wenig weiter Erhellendes dazu beitragen. RiscOSM befindet sich seit 2014 in aktiver Entwicklung, wer sich dafür interessiert sollte sich das anschauen, aber auch Thomas Milius’ MapView nicht vergessen. Sine Nomine hat auch freie Software im Angebot, ein Besuch der Website lohnt sich.

Steve Fryatt stellte diverse Software vor, die entweder aus seiner Feder stammen (Launcher, Clipboard-Tools) oder deren Wartung er übernommen hat (WinEd – ursprünglich von Tony Houghton, dann gepflegt von Adam Richardson). Was mich daran erinnert, mal vom altbewährten TemplEd auf WinEd umzusteigen. Und Launcher sieht durchaus so aus, dass es irgendwann das altbewährte AppDock auf meinem Desktop mal ablösen könnte. Sehr interessant sind seine Bemühungen, alle seine Open-Source-Software als “turnkey buildable” auf GitHub zur Verfügung zu stellen. Jeder, der schon mal versucht hat, irgendeinen Quellcode durchzubauen, der in früheren Tagen immer nur aus dem Buildsystem des jeweiligen Entwicklers auf genau dessen Rechner herausgefallen ist, versteht die Komplexität dieses Unterfangens und wünscht ausreichend Geduld und Engagement, um das wirklich idiotensicher bereitzustellen.

Vince M Hudd von Soft Rock Software, inzwischen hauptsächlich bekannt für RISCOSitory als News-Seite rund um RISC OS und jährlicher Veranstaltungsort für die RISC OS-Awards erzählte ein wenig aus der Soft Rock-Vergangenheit und der Software, die dabei entstand.

Den Abschluss machte Chris Evans von CJE Micro’s mit diversen “tollen Dingen zu kaufen” – CJE ist ja bekannt für “we have it in stock”, und hat eine unglaubliche Menge an Hardware und Software im Angebot, manches allerdings zu Preisen die für meinen Geschmack etwas ambitioniert sind. In Deutschland ist der Spitzname glaube ich “Insel-Apotheke”, aber wie bei Apotheken auch gibt es eben Produkte, die es nur dort gibt – oder auf eBay gebraucht und ohne Garantie, wenn mam Glück hat. Jedenfalls hat CJE seit einiger Zeit auch einen Blog, den man sicher ab und an besuchen sollte. Information Overload braucht keiner zu befürchten angesichts der bisherigen Posting-Frequenz von zuletzt einem Artikel pro 2-4 Jahren.

Ich hoffe, das war ein angemessener Überblick mit einigen Details, die sich beim bloßen Anschauen vielleicht nicht direkt erschließen. Und nun einfach nachlesbar sind, wenn einige Details nicht mehr präsent sind – dafür ist schließlich Video als Medium denkbar ungeeignet.

Noch’n Blog: hubersn Software

Um meine neu erwachten Aktivitäten rund um CDVDBurn 3 entsprechend zu begleiten, habe ich kurzerhand einen neuen Blog gestartet, derzeit mit den Themen “CDVDBurn 3 – das Produkt” und “CDVDBurn 3 – die Entwicklung”.

Als Krönung des ganzen Unterfangens habe ich mich zielgruppengerecht dazu entschieden, die Texte auf Englisch zu verfassen. Man möge mir etwaige sprachliche Unschärfen nachsehen. Englischsprachige Leser meines deutschen RISC OS-Blogs hier haben mir mitgeteilt, dass die Texte mittels Google Translate gut lesbar seien. Ob das andersrum ebenso gut funktioniert?

RISC OS 5.28

RISC OS Open Ltd. hat die Verfügbarkeit der neuen als “stable” gekennzeichneten Version von unser aller Lieblingsbetriebssystem RISC OS verkündet. Die neue Nummer lautet 5.28 – RISC OS 5 wird ja seit einiger Zeit nach dem Schema “development – ungerade Zahlen, stable – gerade Zahlen” versioniert, die Entwicklungsversion ist also ab sofort 5.29.

Das wichtigste Feature von 5.28 ist natürlich die inzwischen stabile Unterstützung des nicht mehr ganz so neuen Raspberry Pi 4. Dafür war ein komplett neuer USB-Treiber und ein komplett neuer Ethernet-Treiber notwendig, sowie größere Umbauten beim Interrupt-Controller – der Pi 4 wurde nicht umsonst als das größte Update der Pi-Architektur bezeichnet. USB3-Unterstützung fehlt weiterhin, aber das muss wohl auf das große Update des USB-Stacks warten.

6 von 8 grundsätzlich unterstützten Plattformen kamen nun in den Genuss der “stable”-Version: Risc PC/A7000/IOMD-Plattformen (also auch RPCEmu), IYONIX pc, Titanium, OMAP3 (z.B. BeagleBoard), OMAP4 (z.B. PandaBoard) und die erwähnten Varianten des Raspberry Pi. Den “Cut” nicht geschafft haben die iMX6-Plattform (Wandboard) und die OMAP5-Plattform (IGEPv5), wobei es hauptsächlich an Kleinigkeiten und Unsauberkeiten scheitert, nicht an größeren Stabilitätsproblemen. R-Comp wird sicherlich für ARMX6 und mini.m, die ja prinzipiell auf der iMX6-Plattform basieren, zeitnah eine entsprechende stabile Version ausliefern.

Die Neuerungen im Feature-Bereich in RISC OS 5.28 sind eher übersichtlich für diejenigen, die regelmäßig die Entwicklungsversionen einspielen. Verbesserungen in !Paint, SLL/TLS-Modul im OS direkt integriert, anständige Clipboard-Unterstützung systemweit und auch in Eingabefeldern (und das war ein langer Kampf), dazu die Unterstützung von ARMv8-Opcodes im Assembler von BBC BASIC. Die vollständige Liste inklusive Links zu plattformspezifischen Anpassungen kann man hier sehen.

Evolution statt Revolution könnte man sagen. Wir wünschen uns für das nächste stabile Release die Integration des neuen sich in Entwicklung befindlichen TCP/IP-Stack bevorzugt inklusive WLAN-Unterstützung natürlich, ebenso ein Update des USB-Stack für die USB3-Unterstützung in Titanium und Pi 4. Fortschritte an der Dateisystemfront – vor allem die anständige Unterstützung von Partitionen – wären auch gerne gesehen, das würde die zukünftige Integration in Multi-Boot-Situationen z.B. beim Raspberry Pi erleichtern.

Tatsächlich stelle ich fest, dass die “Nightly Builds” von RISC OS 5 üblicherweise so stabil sind, dass ich regelmäßig aktualisiere, ohne jetzt groß auf die nächste “stable”-Version hinzufiebern. Aber für meine neuerlichen Bemühungen rund um CDVDBurn ist es natürlich gut, eine stabile Basis zu haben, damit das Testen etwas einfacher fällt und man mindestens für die ungeübten Benutzer einen guten Fallback hat.

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.