Os

Entwicklungen im Betriebssystem selbst

Neues vom ROOL-Repository

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.

2 TiB auf einer FileCore-Partition

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.

RISC OS für Raspberry Pi RC15 verfügbar

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.

iMX6-HAL erreicht das ROOL-Repository

Ich hatte es früher schon erwähnt: es lohnt sich immer, die Bewegungen im ROOL-Repository im Auge zu behalten. Seit einiger Zeit hat nun endlich der iMX6-HAL seinen Weg dorthin gefunden. Nebenbei: man hofft, dass der Code fehlerärmer ist als die Commit-Kommentare.

Der iMX6, der im Herzen des ARMX6 von R-Comp (und ja, ich würde gerne auf eine ARMX6-Seite verlinken, aber R-Comp ist eben R-Comp) in Form des Wandboard Quad schlägt, erhielt seine RISC OS-Weihen in proprietärer Form von R-Comp. Klar, wer entwickelt, will damit auch Geld verdienen. Die kommerzielle RISC OS-Lizenz von Castle hat für diesen Fall eine Spezialklausel: gegen ein paar Euro (maximal 10 UKP pro verkaufter Lizenz) müssen geänderte OS-Quellen zunächst nicht an ROOL zurückfließen, sondern man kann sich bis zu 2 Jahre Zeit erkaufen. Die waren im Falle des iMX6 jetzt rum.

Nächste Aufgabe: iMX6-ROM bauen aus den aktuellen Quellen.

RISC OS auf Linux portiert

Zugegeben, die Überschrift klingt irgendwas zwischen merkwürdig und erklärungsbedürftig.

Timothy Baldwin hat im ROOL-Forum genau das angekündigt: ein RISC OS, das unter Linux läuft. Und zwar nicht in einem Emulator, sondern nativ (falls es sich um ARM Linux handelt, sonst wird QEMU genutzt).

Ich habe es noch nicht selbst ausprobiert, aber was dort zu lesen ist, klingt schon sehr interessant (wenn auch noch nicht ganz produktionsreif). Im Prinzip wird das RISC OS-ROM-Image quasi als Linux-Anwendung ausgeführt. Im User-Space wohlgemerkt. Als Standard-Linux-Prozess. Ein spezielles Dateisystem, genannt IXFS, sorgt für die Verbindung zum Linux-Dateisystem und kümmert sich auch um die Speicherung der RISC OS-Spezialitäten (Load/Exec bzw. Filetype) in den Metadaten. Video-, Maus- und Tastaturtreiber verbinden sich via Unix Domain Socket (Interprozesskommunikation nach POSIX-Art – auch IPC genannt) mit einem Prozess, der dann z.B. für die Darstellung des „Bildschirms“ SDL2 verwendet.

Das Posting nennt auch ein paar Bereiche, wo es noch Schwächen gibt. Aber immerhin ein erster Schritt, und einige Anwendungen laufen bereits.

Hier ist das GitHub-Projekt zu finden.

Wie immer bei neuen Entwicklungen gibt es jede Menge Unwägbarkeiten, und es ist sicher ein typisches 80-20-Softwareprojekt – obwohl schon zu 80% fertig, wird die Perfektionierung noch sehr lange dauern. Aber sollte die Perfektionierung gelingen, ist das Projekt fast schon eine Revolution im RISC OS-Bereich. Es vereinigt die Vorzüge einer Emulationslösung mit den Vorzügen einer nativen Lösung. Gerade im Bereich der ARM-Boards gibt es ja eine Vielzahl von Geräten, auf denen Linux läuft, aber auf denen RISC OS niemals laufen wird, weil die Manpower für die Portierung fehlt und/oder gar nicht ausreichend Informationen über das verwendete SoC zur Verfügung stehen, um überhaupt eine Portierung zu ermöglichen (typische Beispiele sind SoCs von Rockchip, MediaTek und Allwinner, aber auch die Tegras von NVIDIA oder das Qualcomm-Zeugs oder die Samsung Exynos).

Optimistisch gesprochen ist ab sofort Linux der Hardware Abstraction Layer für RISC OS. Eine Revolution.

Multicore-RISC OS für Experimentierfreudige

Zwei Wochen nach der ersten Ankündigung hat Jeffrey Lee Nägel mit Köpfen gemacht: hier ist Schritt zwei auf der langen Reise zu einem Multicore-RISC OS. Das dort verlinkte Archiv enthält die entsprechenden Sourcen und ein fertiges Raspberry Pi RISC OS-ROM-Image mit dem SMP-Modul, um auf RPi 2 und RPi 3 auf den drei bisher brachliegenden Cores Code zur Ausführung zu bringen.

Meine Zeiten als Low-Level-Frickler sind lange vorbei (mit der sporadischen Ausnahme, ATAPI/SCSI-Commands über den Bus zu schicken), und so überlasse ich gerne der Assembler-Fraktion das Feld für erste Experimente. Sagt mir Bescheid, sobald die Unterstützung für Ada-Tasking verfügbar ist :-)

Multicore ante portas

Jeffrey Lee war nicht faul über die Feiertage und macht uns aktuell das Maul wässrig.

Klar, es ist immer noch ein riesiges Stück entfernt vom eigentlichen Ziel, einem multi-threading multi-core all-singing all-dancing RISC OS. Aber ein Schritt nach dem anderen.

Frühjahrsputz im RISC OS Open-Repo

Es ist immer interessant, die Neuigkeiten im RISC OS Open-CVS zu beobachten. Zur Zeit ist der große Frühjahrsputz im Gange.

Es findet ein Merge statt zwischen dem „HAL-Branch“ – das ist der Branch, der anno 1998 durch Pace abgezweigt wurde, um das bisher hardwarespezifische RISC OS mit einem „Hardware Abstraction Layer“ zu versehen, um so von der engen Bindung an IOMD und VIDC20 wegzukommen, was letztlich den IYONIX pc erst möglich machte – und dem „Head“ (der ungebranchte Hauptzweig aller Versionen im CVS-Wording – amüsanterweise redet der Commit-Kommentar von „Trunk“, was auf den SVN-Hintergrund des Autors hinweist, wobei seit einigen Jahren auch der CVS-Head teilweise als „Trunk“ bezeichnet wird), der weiterhin ein „RiscPC/A7000-RISC OS“ darstellte. Das ist eine sinnvolle Bereinigung, denn der HAL-Branch hat sich über die Jahre als der Hauptentwicklungszweig herauskristallisiert, während der Head so vor sich hindümpelte und keine weitere Pflege geschweige denn Weiterentwicklung erfuhr – was ja auch Sinn ergibt, da es für IOMD/VIDC20-Systeme ja auch einen passenden HAL gibt.

Dazu wurden historische Flags für die bedingte Assemblierung z.B. von 26bit- vs. 32bit-Code, STB-Support, Arthur-Spezifika, Hacks für längst vergangene Hardware etc. entfernt, um den Code vernünftig wartbar zu machen.

Im Ergebnis sollte vor allem das Kernel-Zeugs deutlich übersichtlicher werden, wenn am Ende nur noch eine RISC OS-Variante übrig bleibt: 32bit mit HAL.

JPEG-Bounty: Testversion verfügbar

RISCOS Open Ltd. hat die Verfügbarkeit einer neuen Testversion des SpriteExtend-Updates zur Verbesserung des JPEG-Supports verkündet. Die Entwicklung erfolgt im Rahmen des Bounties „Update JPEG support“.

Worum geht es? RISC OS unterstützt nativ seit Anbeginn der Zeit nur ein einziges Bitmap-Format: das hauseigene „Sprite“-Format. Also das Äquivalent zu BMPs unter Windows. Mit RISC OS 3.6 änderte sich das: JPEG wurde ab da ebenfalls unterstützt. Und zwar mittels „on-the-fly-decoding“, also nicht wie frühere Tools wie ImageFS(2) per einmaliger Umwandlung ins Sprite-Format. Das hat besonderen Charme, weil es den Speicherverbrauch niedrig hält – das JPEG bleibt halt als JPEG im Speicher, und wann immer ein Redraw verlangt wird, wird dieser Bildschirmausschnitt aus den Originaldaten bepixelt. Man kann diesen Effekt schön sehen, wenn man in Draw einmal das JPEG reinzieht und einmal das in ein Sprite konvertierte JPEG verwendet – am Speicherverbrauch von Draw erkennt man sofort den Unterschied. Und auch bei der Redraw-Geschwindigkeit – da ist die native JPEG-Variante naturgemäß im Nachteil.

Wie so vieles in RISC OS (man denke an den Netzwerk-Stack) ist auch der JPEG-Support in die Jahre gekommen. Der Code basiert auf Version 4 der Library der Independent JPEG Group von 1993, also Steinzeit. Die neueste Version 9b dieser Bibliothek wurde gestern veröffentlicht. Nun ist alt nicht gleich schlecht, aber in diesem Falle sind eben alle JPEG-Weiterentwicklungen an RISC OS spurlos vorüber gegangen, z.B. die Unterstützung für andere Farbräume als YUV (RGB, CMYK), die progressive Codierung anstatt der normalen linearen (häufig genutzt auf Webseiten, so kann man schon während des Herunterladens eines Bildes dieses in zunehmend besserer Qualität darstellen), Interlace-Codierung, die neue arithmetische Codierung zur Verbesserung der Kompressionsrate, die neue lossless-Kompressionsvariante, vergrößerte Farbräume.

Die veraltete Unterstützung sorgte so für seltsame Blüten bei der Anwendungssoftware. In den allermeisten Fällen wurde entweder zuerst die JPEG-Decodierung dem Betriebssystem überlassen, und wenn das Format inkompatibel war, wurde auf eine eigene Implementierung zurückgegriffen. Oder es wurde gleich eine neuere Version der Referenzimplementierung verwendet. Irgendwann sind dann JPEGs aufgetaucht, die die OS-Implementierung in eine Endlosschleife geschickt haben statt einen Fehler zu produzieren. Kurz: die OS-Implementierung wurde eher hinderlich als nützlich.

Höchste Zeit also für den Frühjahrsputz. Den ersten Aktivitätsnachweis gab es Ende November letzten Jahres, gestern nun das Update. Viele Ziele des Updates sind bereits erreicht: Unterstützung für die Progressive- und Interlace-Codierung, andere Farbräume von RGB bis CMYK, die Arithmetic-Codierung. Das bereitgestellte Modul ist „softloadable“ auf allen Maschinen ab ARMv4, also im Prinzip für alles ab Risc PC.

tl;dr: Neues SpriteExtend-Modul, viel besser als das alte. Runterladen und ausprobieren.

Übrigens: nach dem Update ist vor dem Update. JPEG XT, JPEP-LS, JPEG 2000, JPEG XR, JBIG…

4 Mal Cortex-A15 für RISC OS

RISC OS Open Ltd. hat heute mit der Neuigkeit überrascht, dass eine bis dato (mir) unbekannte Firma namens Elesar Ltd. ein Board namens Titanium entwickelt hat. Basierend auf dem bekannten Dual-Cortex-A15-OMAP AM5728 von TI legt es etwas andere Schwerpunkte als die Konkurrenz. 2 GB RAM, sechs USB2.0-Host-Anschlüsse (plus zwei interne), 2x DVI-I, 2x Gigabit Ethernet, 8 MB interner Flash-Speicher, 2 serielle Ports und vier SATA-Ports lautet die interessante Mischung. Das Ganze in einem ATX-kompatiblen Package, mit I/O Shield zum Einbau in Standard-ATX-Gehäuse.

Der m.E. noch interessantere Teil der Nachricht: man macht sich nicht nur um Hardware Gedanken, sondern auch um Software. Piccolo Systems (zu Deutsch: Ben Avison) hat sich um eine anständige Treiberschicht für S-ATA gekümmert. Ein Meilenstein in der RISC OS-Geschichte, wenn wirklich das alte IDE-Gefummel in ADFS endlich abgelöst werden kann. Und wenn dadurch CDVDBurn tatsächlich mal mit „full speed“ des Brenners arbeiten könnte.

Nun gibt es also vier „Bewerber“ um den Preis „schnellste RISC OS-Hardware“, die allesamt auf dem TI OMAP5 basieren:

  • ISEE IGEPv5
  • TI OMAP5432 EVM
  • BeagleBoard-X15
  • Elesar Titanium

Hardware Overload. Gewisse Eigenschaften des Titanium-Boards lassen auf RISC OS-Herkunft schließen: das verhältnismäßig kleine interne Flash-ROM, die zusätzlichen 2K EEPROM, die geradezu „CMOS“ schreien. 2 GB RAM als größte sinnvolle Speichermenge, mit der RISC OS umgehen kann. Und tatsächlich: hinter Elesar Ltd. steckt niemand anderes als Robert P. Sprowson, auch als „Sprow“ bekannt.

Bin gespannt, was für Eindrücke von/nach der RISC OS London Show eintrudeln.