Os

Auch in 2018 habe ich ein Auge auf das ROOL-CVS-Repo, weil man dort aus den Commit-Kommentaren und den geänderten oder hinzugefügten Sources recht gut ablesen kann, wo in der RISC OS-Welt (m Sinne von Kern-OS) gerade Hand angelegt wird.

ADFS wurde gepatcht, um etwas unempfindlicher gegenüber neueren Devices zu sein – bekanntlich scheren sich viele Geräte nicht um Standards, vor allem nicht um veraltete wie den ATA-Standard aus der Zeit von PIO-Mode 0. Der Patch basiert auf Vorarbeiten und -Analysen von Jon Abbott mit RISC OS 3.1 und dem ewigen Rätsel, warum in A3020/A4000/A5000 das ADFS so wählerisch mit vielen CompactFlash-Karten und manchen Platten ist, während 3rd-party-IDE-Podules damit eher weniger Probleme haben. DRQ-Timeout-Handling ist das Stichwort. Jedenfalls steht jetzt ein ROMPatch für die ADFS-Versionen von RISC OS 3.50 bis 4.02 zur Verfügung.

Der NFS-Client für OmniClient wurde wiedererweckt – vermutlich ist jemand über eine Diskette mit Quellcode von 1992 gestolpert…alle normalen Menschen verwenden seit Urzeiten ImageNFS und etwas später dann Sunfish als NFS-Client.

Das EtherUSB-Backend für den Pegasus-Chipsatz wurde gefixed, da gab es seit dem letzten EtherUSB-Update Probleme. Wenn ich mich recht erinnere, betraf das u.A. das BeagleBoard-xM. Erfahrene RISC OS-Ethernet-Geschädigte haben natürlich immer eine große Auswahl an USB-Adaptern mit unterschiedlichen Chipsätzen in der Bastelkiste, um gegen derartige Unfälle gewappnet zu sein.

Im Bereich VFP gab es einen merkwürdigen Bug, wo das WIMP beim Taskswitching in Verbindung mit Poll-Post-Filtern den VFP-Kontext nicht richtig behandelte. Symptom: SciCalc semmelte bei Tastatureingabe ab, wenn gleichzeitig das KeyExtend-Modul (wird z.B. von StrongEd benötigt) aktiv war. Jeffrey Lee hat es souverän analysiert und gefixed – ich will nicht wissen, wie lange das gedauert hat, diese abstruse Kombination zu debuggen.

Weiterhin gibt es Bewegung und Aufräumen in Richtung RISC OS 5.24, vor allem beim Wandboard (aka ARMX6). Ich bin leider immer noch nicht dazu gekommen, einen der Nightly Builds fürs Wandboard auszuprobieren.

Das Bounty-System von ROOL ist nicht gerade erfolgsverwöhnt. Es mangelt neben Spendenbereitschaft vor allem an interessierten und ausreichend talentierten Entwicklern, die sich der zahlreichen Aufgaben annehmen wollen.

Eine der aus meiner Sicht wichtigsten Bounties kreist rund um USB. Bekanntlich stammt das RISC OS 5-USB-Subsystem genau wie der Netzwerkstack von *BSD ab, wurde aber schon längere Zeit nicht auf den aktuellen Stand der Dinge gebracht, abgesehen von gezielten Codeübernahmen aus dem Original. Hauptsächlich deshalb, weil es kein “plain port” ist, sondern aufgrund der maximalen nicht-UNIX-heit von RISC OS eben großflächig angepasst werden musste. Das erschwert das Synchronhalten mit der Quelle erfahrungsgemäß enorm.

Nun wurde für Teil 1 des USB-Bounties Vollzug gemeldet. Hier zum Nachlesen der Umfang von Teil 1. Neben den notwendigen strukturellen Änderungen, um näher am BSD-Original zu sein und eine saubere Trennung zwischen den Hardware-Treibern und dem eigentlichen Stack halte ich die Bereinigung des Chaos rund um das bisherige Schmalspur-USB-wenn-gebootet-wird für besonders erwähnenswert. Schon auf dem IYONIX pc war das ein Ärgernis – es funktionierten zum Boot-Zeitpunkt nur ganz einfache Tastaturen an einem ganz bestimmten USB-Port.

In Colin Granvilles USB-Ecke gibt es entsprechende Updates, um den Isochronous-Modus nutzen zu können. USB Audio ist weiterhin ein Stiefkind im RISC OS-Universum, aber irgendwann werden hoffentlich die entscheidenden Lücken geschlossen werden. Vermutlich um dieselbe Zeit, wenn USB3-, WLAN- und Bluetooth-Unterstützung Einzug in RISC OS hält.

Warten wir also geduldig und hoffen auf die alsbaldige Vollzugsmeldung bei USB-Bounty Teil 2!

Wer sich nicht mehr erinnert – seit Juli 2015 haben alle RISC OS 5-Development-Builds die Zero-Page verschoben und laufen in der sogenannten “high processor vectors”-Konfiguration. Das ermöglicht einen deutlich stabileren OS-Betrieb, führt aber dazu, dass so manche Software, die bisher einwandfrei lief, aufgrund von (vermutlich) unkritischen NullPointer-Zugriffen den Abgang macht. Auch zu Diagnosezwecken, aber auch zur Wahrung der Rückwärtskompatibilität wurde deshalb das ZeroPain-Modul erfunden, das Zugriffe auf die Zero Page loggt. So mancher Uralt-Bug wurde dadurch erfolgreich ausgemerzt.

Ursprünglich war angedacht, ab 1.1.2016 ZeroPain wieder abzuschaffen. Das war wohl viel zu optimistisch, und es gab meines Wissens erheblichen Widerstand von R-Comp und CJE, die bekanntlich fertige RISC OS-Rechner inklusive eigens getesteter RISC OS 5-Versionen für die weniger bastelfreudigen User verkaufen. Letztlich das alte RISC OS-Problem: zuwenige Entwickler, die sich um die Pflege der Software kümmern können, dazu einige Software ohne verfügbaren Quellcode.

Jetzt gibt es eine neue Marschrichtung: einen Kompatibilitätsmodus, “compatibility page” genannt. Per OS_Memory 20 auch softwaremäßig kontrollierbar. Ich denke, das ist ein guter Kompromiss – es ermöglicht allen Parteien, zu einem gemeinsamen ROM-Build zurückzukehren und je nach Zielgruppe zwischen maximaler Rückwärtskompatibilität oder gescheiter Entwicklerunterstützung einfach umschalten zu können. Software, die zu Emulationszwecken die Zero Page selbst simulieren will (ADFFS ist da ein Kandidat, siehe Post zur Verfügbarkeit von Version 2.62), kann ebenfalls entsprechend agieren. ZeroPain ist für Entwickler und Benutzer, die Entwickler unterstützen wollen, weiterhin verfügbar.

Immer wieder habe ich ein Auge auf das ROOL-CVS-Repo, weil man dort aus den Commit-Kommentaren und den geänderten oder hinzugefügten Sources recht gut ablesen kann, wo in der RISC OS-Welt (m Sinne von Kern-OS) gerade Hand angelegt wird.

Aktuell wird am Filecore nebst ADFS und HForm rumgeschraubt, um idlen auf 21 Bits zu erhöhen. Damit kann man dann die maximal erlaubte Anzahl von Objekten in einer Filecore-Partition hochschrauben, was es wiederum erlaubt, bei gleicher Partitionsgröße die LFAU etwas kleiner zu wählen, was wiederum die Platznutzung vor allem bei vielen kleineren Dateien (und was würde RISC OS mehr auszeichnen als die Vielzahl kleiner Dateien – nicht nur die !Run- und !Boot-Skripte sind sehr klein, sondern auch !Sprites und !RunImage und leider oft auch !Help – ich spreche aus Erfahrung) deutlich verbessert. Allerdings wird die Map auch wieder entsprechend größer.

Es scheint auch etwas in Richtung USB3-Unterstützung zu geschehen, am XHCI-Treiber wird gearbeitet. Ab und an sind auch Einsprenkel aus den Arbeiten rund um die Multicore-Unterstützung zu sehen. Und sogar der gute alte Maestro hat eine Pflegekraft gefunden. Wohl nur Teilzeit, aber immerhin.

Auch die Access-Einbindung in OmniClient könnte demnächst ein Comeback feiern – wenn ich mich recht erinnere, lagen die Rechte für den Code bei einer anderen Firma, offensichtlich hat man sich da nun geeinigt.

Es gibt nun ein BASICVFP-Modul, quasi ein BASIC64 mit VFP statt FPE.

Zuletzt wurde noch ein interessanter Bug im EDID-Umfeld gefixed – die Bootsequenz kam zum Erliegen mit einem bösen Absturz, wenn man keinen Monitor angestöpselt hatte bzw. dieser keine sinnvollen EDID-Daten zurücklieferte (z.B. EDID-Infos mit Länge 0, was laut Standard wohl valide ist). Es gibt jetzt einen sicheren Fallback in Form des klassischen Mode 27 – quasi wie beim PC-BIOS.

Limits von Hardware und Betriebs- sowie Dateisystemen haben in der IT eine lange Tradition. Die 32MiB-pro-Partition-Grenze von alten DOS-Versionen (ich glaube bis Version 3.2). Die 504MiB-Grenze der alten PC-BIOSe. Die 512MiB-Grenze von FileCore bis einschließlich RISC OS 3.5. Die 256GiB-Grenze von RISC OS ab 3.6. Die “DMA nur bis 128GiB”-Grenze des IYONIX pc wegen der ALi-Southbridge. Dazu die LBA28/40/48-Problematik.

ROOL hat angekündigt, dass ab demnächst die neue Grenze 2 TiB pro FileCore-Partition sein wird. Das geht ohne Änderung der internen FileCore-Adressierung, weil FileCore nun mit 4 KiB-Blöcken umgehen kann und ADFS nun auch die (S-ATA-)Hardware entsprechend ansteuern kann. Zuvor wurden 512 Byte-Blöcke verwendet, wie sie lange Zeit bei IDE- und S-ATA-Festplatten auch nativ verwendet wurden.

Bisher konnten derartige Plattengrößen nur bei Dateisystemen über SCSI (also aktuell vor allem USB-Massenspeicher) unter Benutzung von Fat32FS verwendet werden, und das war auch eher getrickst über eine clevere Verwendung von Partitionsoffsets in SCSIFS.

Jetzt noch Partitionsunterstützung unter Ausnutzung der neuen FileCore-Freiheiten seit RISC OS 5 (256 statt 8 “Laufwerke” aka dann hoffentlich Partitionen), dann könnte man ohne größere Verrenkungen Platten (ok, 256 Laufwerksicons…) bis 512 TiB verwenden. Im Moment sind gängige Retail-Größen mit gutem Preis-/Größenverhältnis 2 TiB und 4 TiB, d.h. man hätte sich wieder etwas Luft verschafft im RISC OS-Universum bevor man an den nächsten größeren FileCore-Umbau gehen muss.

Lange hat es gedauert. RC14 erschien im Februar 2015 noch basierend auf RISC OS 5.21 und war “out of the box” so richtig gut nur auf dem ersten RPi lauffähig – der RPi 2 war nominell unterstützt, aber es hakte an der ein oder anderen Stelle. Seither war die RPi Foundation nicht untätig und hat quasi im Jahresrhythmus neue Gerätschaften auf den Markt gebracht: RPi Zero, RPi 3, die aktualisierte Variante des RPi 2 auf Basis desselben SoCs wie RPi 3, und zuletzt den RPi Zero W.

Nun konnte natürlich jeder gefuchste Anwender mit Heimwerkerhintergrund “problemlos” (zumindest wenn man SystemDisc von Piccolo Systems hat) eine neuere RISC OS-Version für RPi 3 und Co zusammendengeln. Aber bekanntlich ist der RPi ja auch in den Händen von RISC OS-Noobs, die nur mal kurz unser schönes alternatives Betriebssystem ausprobieren wollen. Für die war die NOOBS-Distribution bisher große Klasse, aber leider basiert diese auch auf RC14. Der zweitbeste Weg um RISC OS auszuprobieren war das RC14-Disc-Image von ROOL selbst, aber wie gesagt – nicht wirklich tauglich für die neuen Modelle, und relativ kompliziert auf einen neueren Stand zu bringen.

Jetzt ist die Warterei vorbei, RC15 wurde veröffentlicht (hier die offizielle Ankündigung). Endlich ist also wieder eine Distribution verfügbar, die man “einfach so” auf alle aktuellen RPi-Modelle bringen kann. Super!

Jetzt muss man nur noch erklären, warum RISC OS nur 2 GiB der üblicherweise viel größeren (micro)SD-Karte nutzen kann – hoffentlich kann man diese Frage auch bald beantworten mit “geht doch”, sobald FileCore und die diversen Dateisysteme anständig mit Partitionen umgehen können.