Software

Anwendungen und Tools rund um RISC OS

R-Comp Pre-Show News

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

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

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

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

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

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

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

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

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

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

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

Raster-Copper-Dingsbums leicht gemacht

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

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

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

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

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

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

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

RISC OS Direct für Raspberry Pi 4 und 400

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

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

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

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.

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”.

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.

Frischfleisch: FontInfo von Anton Reiser

Anton “Toni” Reiser hat die Verfügbarkeit eines neuen Tools verkündet, und FontInfo ist der Name.

Der Name ist Programm: FontInfo zeigt allerhand nützliche Informationen zu beliebigen RISC OS Outline-Fonts an, und zwar auf Glyphen-Basis. Dazu zieht man entweder die Outline-Datei eines Fonts auf das FontInfo-Icon auf der Iconbar, oder man bedient sich des Menüs zur Auswahl eines beliebigen dem System bekannten Font. Es öffnet sich ein Übersichtsfenster aller Glyphen, die im jeweiligen Font definiert sind. Eine Glyphe kann dann zusätzlich per Click (Tipp: es gibt einen cleveren Unterschied zwischen Links- und Rechtsclick) im Detail inspiziert werden, mit verschiedenen Visualisierungsoptionen: nur die Outline oder “richtig” gefüllt, die Baseline, die Bounding Box, die Definition der Outline mit den Scaffolds und den Handles – eben alles, was so eine Glyphe im RISC OS-Fontmanager ausmacht. Zusätzlich können die Glyphen als Draw-Datei exportiert werden.

Auf der Fontebene gibt es zusätzliche Informationen zu den Unicode-Blocks, zu denen die Glyphen jeweils gehören. Klickt man einen Block an, werden die zugehörigen Glyphen farbig hinterlegt.

Vorsichtig, wie Toni ist, heißt die derzeitige Versionsnummer 0.02. Für dieses frühe Stadium macht das Tool aber schon einen sehr schicken Eindruck. Also: runterladen und Fonts inspizieren gehen.

Aemulor 2.53 verfügbar

Der erste Artikel im neuen Jahr erst Ende Februar. Schande über mich.

Adrian Lees hat die Verfügbarkeit der neuesten “Development Version” (also eine Testversion im weitesten Sinne) von Aemulor mit der schönen Versionsnummer 2.53 verkündet. Download wie immer hier.

Die große Neuigkeit ist die Verfügbarkeit einer Variante für den Raspberry Pi 4 (und das vor offiziellem Release der RISC OS-Version für diese Maschine!) und ggf. weitere Boards mit einem Cortex-A72 als ARM-Core. Ansonsten gab es kleinere UI-Verbesserungen und einfacherer Zugang zur Online-Dokumentation sowie etwas hilfreichere Fehlermeldungen beim Start der RPCEmu-Version in Verbindung mit ungepatchten RISC OS 5-Versionen. Wenn ich es richtig verfolgt habe, müssen die allerneuesten RISC OS 5.27-Varianten nicht mehr gepatcht werden.

Die Veröffentlichung von 2.51 hatte ich noch hier auf dem Schirm, aber 2.52 ist mir irgendwie durchgerutscht. Die damaligen Verbesserungen betrafen hauptsächlich Impression, sobald die upgedateten 32bit-Module wie GDraw und DitherExtend am Start waren anstatt der originalen 26bit-Varianten, um auf RGB-Zielsystemen wie Titanium und ARMbook stets korrekte Farben auf den Bildschirm zu bringen.

Und irgendwann schreibe ich auch noch einen Blogartikel über das RISC OS-Spriteformat und BGR-vs.-RGB. Versprochen.

In der Zwischenzeit: Happy Aemuloring!

Neue Testversion von Aemulor verfügbar

Korrektur 2019-09-24: die vormals hier stehenden Infos zum ARMBook von R-Comp waren falsch. Es basiert auf dem Pinebook, nicht auf dem Pinebook Pro wie vormals fälschlicherweise hier geschrieben (vermutlich war der Wunsch Vater des Gedankens – eine sehr optimistische Interpretation der vorliegenden Informationen). Was wieder zeigt, dass auch knapp fünf Jahre nach diesem Blogeintrag die Problematik der Transparenz von Informationen weiterhin gegeben ist.

Adrian Lees, Entwickler von Aemulor (wer aus unverständlichen Gründen nicht weiß, was Aemulor ist und wozu es gut ist, kann es hier detailliert nachlesen), hat die Verfügbarkeit einer neuen Test- bzw. Entwicklungsversion verkündet. 2.51 ist die Versionsnummer, Download von hier.

Was ist neu? Eine der ungünstigen Nebenwirkungen von Aemulor war immer, dass nicht nur der Application Memory Slot (aka Wimpslot) für die emulierten 26bit-Anwendungen auf die unter RISC OS 4 und früher üblichen 28 MiB RAM eingeschränkt wurde, sondern auch der für alle anderen Anwendungen. Die neue Entwicklungsversion schafft hier nun etwas mehr Platz als früher: durch Anpassungen der Memory Map stehen nun 52 MiB RAM im Wimpslot zur Verfügung. Diese Anpassung ist optional, man kann auch mit der alten Konfiguration arbeiten.

Für die nicht-so-RISC OS-Erfahrenen: das 28 MiB-Limit kommt aus der 26bit-Zeit, also alles bis einschließlich RISC OS 4, als die CPU wie zu Zeiten des ARM2 1986 den Programmcode nur innerhalb der ersten 64 MiB ausführen konnte – weil der Program-Counter, also das Register (R15 übrigens), das die derzeitige Ausführungsadresse enthält, nur die unteren 26bit für die Adresse verwendete. Und dann hat Acorn zur Vereinfachung der restlichen Hardware (damit die MMU genannt “MEMC” eben nur diese adressieren können muss) kurzerhand diese 64 MiB in gewisse Blöcke aufgeteilt wie die RMA, das ROM, den System-Heap und IO-Bereiche. Hier ist die vollständige Übersicht zu sehen. Wenn man so will, ganz ähnlich wie die DOS-Memory-Map mit ihrem 640 KiByte-Problem.

Und um keine Missverständnisse aufkommen zu lassen: das 28 MiB-Limit bedeutet nicht, dass eine Anwendung nur 28 MiB nutzen kann. Es bedeutet nur, dass der ausgeführte Programmcode maximal 28 MiB groß sein darf – Daten können auch (seit RISC OS 3.5 und dem ARM6xx – seither können nämlich die vollen 32 Bit adressiert werden) in den sogenannten “dynamic areas” liegen. Die Erhöhung von 28 MiB auf 52 MiB ist also bei den RISC OS-typischen eher kleinen Programmen tatsächlich nur für spezielle Anwendungen interessant. Dort aber potenziell lebensrettend.

Und wie läuft er nun, der neue Aemulor? Kann ich noch nicht sagen. Bin mitten in den Vorbereitungen für die DoReCo-Party kommendes Wochenende, da ist für die Kür erst Zeit, wenn die Pflicht erledigt ist. Interessant auf jeden Fall, dass diese Aemulor-Version auf dem brandneuen ARMBook von R-Comp (ein Pinebook mit RISC OS) schon getestet wurde. Im Pinebook dreht ein Allwinner A64, also grob gesagt Cortex-A53 mit Mali-400, coretechnisch also identisch mit dem Raspberry Pi 3(+). Solange also “bekannte” Cores am Start sind, scheint die Produktion von kompatiblen Aemulor-Versionen für Adrian keine besondere Herausforderung zu sein.

Wieder nix in 2018, neuer Versuch in 2019

2018 neigt sich dem Ende, und im Jahresendspurt passiert erfahrungsgemäß vor lauter anderen Verpflichtungen eher wenig. Nachfolgend die Liste der Softwareprojekte, die ich “eigentlich” in 2018 erledigen wollte, die aber weiter ihrer Finalisierung harren. Oft fehlen nur Kleinigkeiten, oder “nur noch das letzte Feature”, oder etwas Feinschliff.

CDVDBurn

Der Klassiker gleich zu Anfang. Das letzte offizielle Release, Version 2.02b (auch wenn als Beta gelabeled), war Feburar 2007. Seither plane ich ein neues Release. Was ist seither passiert? DVD-RAM kann geschrieben werden. Blu-Ray kann als BD-R und BD-RE geschrieben werden. Ein Extraktor ist nun integriert, mit dem man unabhängig von CD(ROM)FS Daten-CDs/DVDs/BDs anschauen kann und Dateien extrahieren kann, inklusive Unterstützung für Joliet und ein Subset der Rockridge-Extensions (soweit unter RISC OS sinnvoll). Dazu wurde die Lauffähigkeit unter ARMv7 und ARMv8 sichergestellt (ein echtes Abenteuer mit dem uralten Ada-Compiler). USB-Unterstützung für RISC OS 5 ist an Bord, ebenfalls S-ATA-Unterstützung fürs neue ADFS (z.B. auf Titanium und IGEPv5).

Ich hatte die Hoffnung, auf zumindest einem gängigen USB- und S-ATA-Laufwerk das DVD-R-Schreiben hinzukriegen, bin aber gescheitert. Einen Versuch habe ich mir noch vorgenommen (Incremental Writing statt DAO/TAO mit reserved track), und dann wird endgültig released, egal ob mit oder ohne DVD-R-Unterstützung. Dual-Layer-Unterstützung für BD-R und BD-RE wäre auch noch schön. Das Update wird kostenpflichtig werden, ich hatte einige Investitionen in Laufwerke und andere Hardware.

TapirMail

David Llewellyn-Jones hat 2018 den Sourcecode für TapirMail auf GitHub freigegeben. Mein Plan war, den Sourcecode etwas aufzuräumen, mit aktueller OSLib und aktuellem GCC und DDE baubar zu machen (so richtig mit Makefile und so…) und dann per Pull-Requests die weitere Entwicklung voranzutreiben. Beispielsweise die Unterstützung für Secure POP3/SMTP, und ggf. auch IMAPS. Da bin ich mittendrin steckengeblieben – bauen tut alles, aber Weiterentwicklung ist nicht geschehen, und ich stecke noch in den Überlegungen, wie so ein RISC OS-Projekt unter GitHub anständig strukturiert sein sollte. Jetzt, mit Jeffreys Git-Client (oh, darüber wollte ich ja auch noch bloggen…), ergeben sich da neue Möglichkeiten.

Isofier

Aus der Reihe “Java-basierte Software für RISC OS, aber nicht unter RISC OS”: ein ISO9660/Joliet-Image-Erzeuger. Die Kommandozeilenvariante funktioniert prächtig, das grafische UI nicht so wirklich. Die Besonderheit ist die volle Unterstützung für die HostFS-Implementierungen von RPCEmu und VirtualRPC, es werden also die Filetype-Extensions automatisch in CDFS-Extensions gewandelt, unter Berücksichtigung der VRPC-extensions-Konfiguration und einer MimeMap-Datei.

ImageTransformer

Aus der Reihe “Java-basierte Software für RISC OS, aber nicht unter RISC OS”: ein Konverter für das CDVDBurn-Fake-Image-größer-als-2-GiB-Format. In beide Richtungen natürlich. Nützlich, um unter RISC OS erzeugte Images dann auf dem PC brennen zu können, oder auf dem PC erzeugte Images (z.B. mit oben genanntem Isofier) unter RISC OS brennen zu können.

SpriteConverter/SpriteViewer

Aus der Reihe “Java-basierte Software für RISC OS, aber nicht unter RISC OS”: SpriteConverter ist ein Kommandozeilentool zur Konvertierung einer Sprite-Datei (also allen oder einzelnen Sprites darin) in PNG, JPEG, GIF oder was auch immer als Java ImageIO-Plugin zur Verfügung steht. SpriteViewer setzt auf demselben Code auf und zeigt in einer grafischen Oberfläche den Inhalt einer Sprite-Datei an, einmal in einer !Paint-artigen Übersicht, dann aber auch per Doppelclick in Originalgröße mit Zoommöglichkeit und Palette. Man kann einzelne Sprites daraus auch direkt als PNG, JPEG oder GIF exportieren. Geplant als kostenlose Software.

ArchiveViewer

Aus der Reihe “Java-basierte Software für RISC OS, aber nicht unter RISC OS”: eine grafische Oberfläche zur Anzeige der Inhalte typischer RISC OS-Archivdateien wie Spark, ArcFS, PackDir, Squash und ZIP, mit voller Filetype-Unterstützung. Basiert hauptsächlich auf der großartigen Vorarbeit namens riscosarc von James Woodcock. Geplant als kostenlose Software.

BBC BASIC Detokenizer

Aus der Reihe “Java-basierte Software für RISC OS, aber nicht unter RISC OS”: ein kleines Tool, um tokenisiertes BBC BASIC V/VI in plain text umzuwandeln. Mit oder ohne Zeilennummern. Geplant als kostenlose Software.

FilecoreImageReader

Software, um Sprites zu lesen, um Archive zu lesen, um BBC BASIC zu lesen…wofür das alles? Auslöser war der vorerst letzte Teil aus der Reihe “Java-basierte Software für RISC OS, aber nicht unter RISC OS”: ein mächtiges Werkzeug, um Filecore-Images (.adf, .hdf) anzuschauen und Dateien und/oder Verzeichnisse daraus zu extrahieren. Unterstützt D, E(+) und F(+)-Format, minimaler Speicherverbrauch auch bei riesigen Images. Anzeige des Verzeichnisbaumes mit den “echten” RISC OS-Icons. Anzeige der Inhalte von Sprite-Dateien, Archiv-Dateien, Plain-Text-Dateien und BASIC-Dateien (andere Dateitypen werden in einer Hexdump-View angezeigt). Im Moment baue ich gerade echte Acorn Latin 1 Codepage-Unterstützung, um sowohl die Plain-Text-Anzeige als auch die Konvertierung der Dateinamen besser hinzukriegen. Und ich hätte gerne eine Filer-like-Ansicht für einige Inhalte, damit das eleganter aussieht. Und es gibt noch irgendwo einen Bug, der bei einem Disc-Image das mir vorliegt bei, Scannen der Verzeichnisstruktur in eine Endlosschleife gerät. Mindestens das Erkennen der Endlosschleife mit sauberem Abbruch des Lesevorgangs wäre Voraussetzung für ein baldiges Release. Außerdem würde ich gerne automatisch die !Sprites-Dateien von Apps direkt zur Visualisierung verwenden.

Ein Projekt wie FilecoreImageReader ist natürlich in ständiger Gefahr, dem “Feature Creep” zu erliegen. Man könnte doch bekannte Filetypes aus der PC-Welt auch noch direkt als Inhalt anzeigen (Grafikformate, PDF, PostScript…). Und generell die UI Filer-like machen. Und noch ein RISC OS-artiges Look&Feel für Swing bauen. Und eine Anzeige von Draw-Files ermöglichen. Und Templates. Und Impression…und Artworks…

Auf jeden Fall wird es eine kostenpflichtige Version mit all den coolen Features geben, und eine freie Version wo man nur den nackten Verzeichnisbaum mit Extraktionsmöglichkeit hat, möglicherweise auch limitiert auf Floppy-Images.