Develop

Entwickeln für RISC OS

StrongHelpViewer auf GitHub

2022-06-19 17:19

Irgendwie hatte ich dieses Release (doch auch schon Mai 2021, wie die Zeit vergeht…) meinerseits gar nicht hier ge-/verbloggt. Das hole ich mal schnell nach.

StrongHelpViewer, eine in Java geschriebene Software, erlaubt es auf Plattformen mit einigermaßen aktueller Java SE Runtime (mindestens Java 7, also Windows XP und neuer, Linux, MacOSX, OS/2, Solaris, AIX…) den Inhalt von StrongHelp-Dateien sowohl zu extrahieren als auch nach HTML zu konvertieren oder mit einem grafischen Viewer – in Java Swing geschrieben – zu betrachten. Den Quellcode habe ich unter die “Unlicense” gestellt und auf GitHub veröffentlicht.

Wer es nicht weiß: StrongHelp ist der inoffizielle Standard für Online-Hilfe unter RISC OS. Es erlaubt bare-bones Hilfe-Content-Entwicklung mit einem einfachen Texteditor. Die StrongHelp-Datei ist ein Image-Filing-System, d.h. man wirft einfach seinen Hilfe-Content in Dateiform in das “Verzeichnis” (die StrongHelp-Datei, die bei Anwesenheit von StrongHelp zum Quasi-Verzeichnis wird). Die verwendete Auszeichnungssprache erinnert entfernt an sowas wie AsciiDoc oder Markdown oder Wikitext oder HTML. Aber teilweise schon mit sehr spezifischen RISC OS-Eigenheiten wie Sprites oder Drawfiles für Grafiken, Direktzugriff auf RISC OS-Fonts, Squash zur Komprimierung von Hilfe-Content-Dateien.

Da das StrongHelp-Format recht gut dokumentiert ist (natürlich im StrongHelp-Format…), und ich eine natürliche Abneigung gegen Formate habe die ich nur auf einem Betriebssystem lesen kann, habe ich also als erstes ein paar Zeilen Code geschrieben, um das Image-Filing-System-Format zu decodieren. Dann ein paar Zeilen Code, um das StrongHelp-Content-Format nach Minimal-HTML-mit-CSS zu wandeln. Dann noch ein paar Zeilen Code, um eine Swing-UI drumrumzustricken. Fertig war der StrongHelpViewer.

Es gibt noch Lücken im Moment, die ich gedenke irgendwann zu schließen. Der Sprite-Support ist noch nicht integriert. Zu Drawfiles habe ich nur Ideen, aber noch keinen Code (Draw-to-SVG und dann SVG Salamander für die Swing-UI und SVG für den Browser liegen nahe). Einige sehr spezifische RISC OS-Spezifika wie das Ersetzen von OS-Variablen mit deren aktuellem Inhalt oder dem Ausführen von Utility-Code werden wohl nie unterstützt werden, sind aber auch in freier Wildbahn eher selten gesehen. Mein Ziel ist eher, einen möglichst komfortablen Browser für RISC OS-Doku zu bauen (die typischen SWI-Manuals), den ich Seite an Seite mit einem Emulator offen haben kann, um schnell was nachzuschlagen. Oder auch ohne Emulator. Oder auch als Service im Internet, denn die Konvertierung nach HTML schreit ja geradezu nach einem “StrongHelp-Server” – URL zu irgendeinem Manual eingeben und losstöbern.

Im GitHub-Repo findet sich derzeit nur der Source – wer die Software also nutzen will, muss selbst kompilieren. Das sollte sich demnächst ändern, Leser dieses Blogs werden zeitnah informiert werden.

Vielleicht werde ich irgendwann auch noch SwingHelpViewer mit StrongHelpViewer fusionieren, beide haben schließlich dasselbe Thema, allerdings sind die Strukturen nicht ad-hoc kompatibel – SwingHelpViewer kommt ja von TOC-Chapter-Topic-Keyword-strukturierten Hilfeinhalten her, während StrongHelp eher so dem unstrukturierten Hypertext-Ansatz folgt.

Wer Screenshots sehen will: ich hatte im RISC OS Open-Forum mal was gepostet.

Toolbox-Gadget-Update

2022-01-26 00:54

Eine der größten RISC OS-Miseren ist vermutlich der Zustand der Entwicklungswerkzeuge. Die Community ist zersplittert in mehrere Fraktionen: die BBC BASIC-Fraktion, die seit den 80ern auf den BBC-8-Bittern auf die Kraft des Interpreters vertraut. Die Norcroft-Fraktion, die C-und-ein-wenig-Assembler-im-Bedarfsfall favorisiert, also dem althergebrachten Acorn-Style vertraut und vermutlich auf einen großen Sack voll selbstgebauter Bibliotheken. Und zuletzt die GCC-Fraktion, die C oder C++ nutzt, gegen die Unzulänglichkeiten der Portierung kämpft, sich mit ELF anfreunden muss, aber dafür potenziell Zugriff auf viele Open-Source-Bibliotheken aus aller Welt hat, die mittels GCCSDK-Autobuilder auch leidlich automatisiert auf dem aktuellsten Stand gehalten werden können.

Mitte der 90er, nachdem Acorn genug Beweise für das Scheitern des RISCOSLib-Ansatzes gesammelt hatte, machte man dort einen neuen Versuch: die “User Interface Toolbox” – kurz “Toolbox” sollte es richten. Eine prinzipiell programmiersprachenneutrale Sammlung aus Modulen und Tools, erweiterbar mit neuen Oberflächenelementen, “Gadgets” genannt, sollte sowohl die C-/C++-Fraktion (C++ nur im allerweitesten Sinne, das DDE mit dem Norcroft-C-Compiler im Kern nutzt dafür das schon damals hoffnungslos veraltete CFront) als auch die Hardcore-Assembler-Fraktion als auch die BBC-BASIC-Fraktion unter einem gemeinsamen Banner vereint in die wunderbare Zukunft moderner UI-Technologie leiten.

Dieser Plan scheiterte. Die Toolbox sprang an zu vielen Stellen zu kurz: nur die wenigsten Entwickler konnten davon überzeugt werden, ihre Neuentwicklung auf die Toolbox zu stützen oder gar ihre Bestandssoftware umzustellen. Zum Erscheinungszeitpunkt der Toolbox hatte jeder Entwickler schon in eigene Bibliotheken investiert, die typischerweise schon deutlich leistungsfähiger als die Toolbox war. Dazu kamen zu viele Bugs, zu langsames Bugfixing, schlechte Doku vor allem bezüglich der Nutzung der Modularität zwecks Erweiterung durch eigene Gadgets, zu viel Speicherbedarf für die damals noch weitverbreiteten 4-MiB-RISC OS 3.1-Maschinen, zu wenig Nutzen wegen akuter Feature-Armut, Zwang zum DDE-Kauf weil der “GUI-Designer” namens ResEd nur im Paket mit diesem zu haben war, zu wenig Abstraktion (man war deutlich zu nah am WIMP), durch die Realisierung als Module lief plötzlich viel Code einer App im OS-Kontext, zu unsicher die Zukunft einer Acorn-closed-source-Lösung – jeder Entwickler hatte seine individuelle Liste an Gründen, die Toolbox nicht einzusetzen. Ein kurzer Hoffnungsschimmer flammte noch 1997/1998 auf mit dem heroischen Weiterentwicklungsakt getrieben durch Java und Browse, als tatsächlich Fortschritt sichtbar war an der UI-Front vom Nested-WIMP über neue Gadgets bis hin zu frei zugänglicher Dokumentation, wie man denn diese Gadgets richtig schreibt. Too little, too late.

Gewisse Problemfelder der Toolbox sind inzwischen nicht mehr so problematisch zu sehen – dank des Open-Sourceings von RISC OS sind nun sowohl ResEd als auch die Module für jedermann frei zugänglich und sowohl erweiter- als auch fixbar, und nach 25 Jahren Stabilisierung ist auch das Thema Bugs weitestgehend gegessen. Auch einige größere Anwendungen sind auf Toolbox-Basis geschrieben und beweisen deren Stabilität und grundsätzliche Tauglichkeit, und es gibt ein paar Bibliotheken oder Frameworks drumrum, die die Arbeit erleichtern. OSLibSupport sei hier zu nennen, TBX, oder auch AppBasic. Und RISC OS 3.1-Kompatibilität und Speicherfeilschen im einstelligen Kilobyte-Bereich ist Gott sei Dank auch nur eine vage Erinnerung an eine längst vergangene dunkle Periode, allgemein bekannt als “die schlechte alte Zeit”.

Nun hat Rik Griffin verlauten lassen, dass er zwei seiner Toolbox-Gadgets, “Tabs” und “Tree”, als Open Source auf GitHub veröffentlicht (und vermutlich auch noch andere Software aus seiner Feder). Unter BSD-Lizenz. Eine gute Sache, bietet es doch die Möglichkeit, die Module in RISC OS 5 zu integrieren und damit das Thema “Auslieferung” für den geneigten Entwickler deutlich zu vereinfachen. Den Anfang macht das Tabs-Gadget, und dank der aufmerksamen Community sollte der jetzt veröffentlichte Stand self-contained von jedem DDE-Nutzer in Objektcode überführbar sein.

In einem anderen Thread im ROOL-Forum hat Tank aka Robert Kinton diese freudige Nachricht zum Anlass genommen, sein DateGadget (ein Date-Picker-Toolbox-Objekt) aktualisiert zum Download bereitzustellen. Noch ohne Source Code, aber was nicht ist kann ja noch werden.

Eine späte Renaissance der Toolbox? Man wird sehen. In Gerphs RISC OS-Rambles gibt es ja auch das Toolbox-Thema in einigen Beiträgen, da kann man sehen was möglich gewesen wäre, wenn es nur ausreichend Entwicklerkapazität zum richtigen Zeitpunkt gegeben hätte.

CDVDBurn 3 Status-Update

2020-10-17 17:10

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

GCC 8.2.0-Update

2020-04-12 16:33

Im Oktober letzten Jahres hatte ich über erste Anzeichen auf eine baldige Verfügbarkeit von GCC 8.2.0 für unser aller Lieblingsbetriebssystem berichtet. Es gibt hier erfreuliche Fortschritte zu vermelden. Lee Noar ist fleißig am Werkeln und es steht nun ein experimenteller nativer Build zur Verfügung, sprich ein Compiler, der unter RISC OS selbst läuft und nicht nur als Crosscompiler unter Linux.

Allerdings gibt es noch einige Einschränkungen: GCC 8.2.0 kann noch keine Module erzeugen und ist zudem zwingend auf UnixLib angewiesen, compilieren und linken gegen die SharedCLibrary geht (noch?) nicht.

Auch das gute alte GNU Fortran, schon seit Urzeiten Teil von GCC, wurde der bekannten C/C++-Fraktion hinzugefügt. Zumindest “Hello World” war erfolgreich compilierbar, vermeldete die GCCSDK-Mailingliste. Mein unerschütterlicher Optimismus lässt mich auf einen aktuellen GNAT hoffen, aber da gibt es so oft Unpässlichkeiten generell auf ARM-Plattformen, dass es schon unverschämtes Glück wäre, wenn das was werden würde.

Wer es genauer wissen will, kann die Änderungen im GCCSDK-SVN verfolgen.

Erste Anzeichen für GCC 8.2.0

2019-10-16 14:22

Bekanntlich ist die neueste für RISC OS verfügbare GCC-Version die 4.7.4. So alt, so gut. Normalerweise ist das auch kein größeres Problem, RISC OS ist ja eher so retro und verfolgt nicht gerade den Ansatz, alles was nicht bei drei auf den Bäumen ist aus der Linux-Ecke zu portieren. Aufgrund der Unterschiedlichkeit der Ansätze von RISC OS und Linux macht das sowieso nur Ärger und Aufwand (vom Dateisystem bis zu so profanen Dingen wie Forken neuer Prozesse), und das Resultat ist oft auch gerade performancetechnisch unbefriedigend. Aber gerade bei C++ ist die Zeit nicht stehen geblieben, und da wäre ein aktueller Compiler schon von Vorteil. Ganz zu schweigen von neuen hippen Sprachen wie D oder Go, die von neuen GCC-Versionen unterstützt werden.

Ich vermute aufgrund der beteiligten Personen, dass die aktuellen Browser-Projekte (WebKit-Portierung und OWB-WebKit-Portierung) aufgrund der C++-Problematik nun Bemühungen getriggert haben, eine aktuellere GCC-Version an den Start zu bringen. Lee Noar, seines Zeichens Mastermind hinter dem RISC OS-ELF-Support, hat aktuell im riscos.info-GCCSDK-Repo eine ganze Menge Änderungen einfließen lassen, die auf eine baldige Verfügbarkeit von GCC 8.2.0 für unser aller Lieblingsbetriebssystem hoffen lassen. Hier die Details. Wie immer erst die GCCSDK-Version zum Crosscompile, dann hoffentlich auch eine native Version.

Was sind die Fortschritte zwischen 4.7.x und 8.x.x? Für eine Einschätzung des Versionssprunges ist zunächst wichtig zu wissen, dass das GCC-Projekt irgendwann mal das System der Versionsvergabe umgestellt hat. Früher wurde nur alle Schaltjahre mal die Major-Version erhöht – 2.x erblickte 1992 das Licht der Welt (die gängigen Versionen für RISC OS waren 2.3.3, 2.4.5, 2.7.2 und 2.95), 3.x dann ab 2001, 4.x ab 2005, und ab 5.x (2015) gab es dann die Major-Versionen in schnellerer Folge, ungefähr jährlich. Von 4.7.x ist es also nicht ganz so weit bis zur aktuellsten 9.x-Version wie es zunächst den Anschein haben könnte. Auch C++ hat bei der Standardisierung von neuen Versionen ja einen Zahn zugelegt, da passt beides recht gut zusammen. Beispielsweise die Variante C++11 wurde experimentell seit GCC 4.8 unterstützt, GCC 5.x enthielt erste Unterstützung für C++14, GCC 6.x hatte dann C++14 schon als Default und enthielt erste Features von C++17. GCC 8.x beginnt schon mit Draft-Features aus C++2X, das vermutlich 2020 als Standard C++20 verabschiedet werden wird.

Also: Daumen drücken, dass das RISC OS-GCC-Ein-Mann-Team bald Erfolge vermelden kann. Eine aktuelle C++-Toolchain wird immer gebraucht. Wenn jetzt noch jemand sich an LLVM und Clang versuchen würde…und dem aktuellen GCC wieder die Erzeugung von ARMv2-Code nahebringen könnte…aber wer mal das ARM-Backend des GCC angeschaut hat, das ist eine 30000-Zeilen-Codewüste…

Der RISC OS-Quellcode lebt jetzt in Git

2019-08-24 15:45

RISC OS hat bekanntlich eine lange Historie. Und alle Softwareprojekte mit Historie haben normalerweise auch eine Historie was die Quellcodeverwaltung angeht. So auch RISC OS. Ursprünglich mit RCS unterwegs (quasi der Urvater der Unix-VCS-Welt nach SCCS, das auf System/370 entwickelt wurde) und dann zum natürlichen RCS-Nachfolger CVS gewechselt, ist man jetzt den heutzutage quasi unvermeidlichen Weg weiter zu Git gegangen. Als Schnittstelle zur Außenwelt wird GitLab verwendet. GitLab hat natürlich noch ein paar andere Features für all das, was man heute unter “DevOps” zusammenfasst, was davon Stand heute von RISC OS Open Ltd. verwendet wird entzieht sich meiner Kenntnis. Die Nightly Builds der RISC OS-ROM-Images ist ja ein eher komplexer Prozess, da RISC OS weiterhin nur mit der Norcroft-Toolchain baubar ist zuzüglich ein paar exotischer nur nativ unter RISC OS laufender Tools. Wenn ich mich recht erinnere ist deshalb eine Spezialversion von ArcEm noch mit am Start, um den kompletten Build unter unixoiden Plattformen überhaupt zu ermöglichen. Inwiefern das zur vorgedachten GitLab-Build-Pipeline passt – keine Ahnung. Stand heute wird das CI/CD-Zeugs von GitLab jedenfalls nicht (öffentlich einsehbar) verwendet.

Was mich daran erinnert, dass es wirklich mal ein schönes Projekt wäre, RISC OS komplett mit GCC und asasm baubar zu machen.

Die von CVS gewohnte, übersichtliche Historie der Änderungen über das Webinterface ist nun leider nicht mehr da, die Git-Struktur scheint etwas komplexer zu sein, mit dem selten genutzten Git-Feature “Submodules”. Vermutlich bräuchte es da etwas Code, der die Aufbereitung für Rails (die technische Plattform der RISC OS Open-Webpräsenz) übernimmt. Allerdings ist es schon viel besser geworden – also nicht vergessen: regelmäßig hier nachschauen was es Neues im RISC OS-Code gibt. Man kann direkt über das GitLab-Interface auch die akzeptierten Merge-Requests anschauen, das ist auch manchmal erhellend.

Und wie greift man nun von RISC OS aus auf Git zu? Jeffrey Lee hat dazu SimpleGit portiert.

Und noch was nebenbei, weil ich öfter Teil solcher Diskussionen war: “Veraltetes CVS” war eine der gerne genutzten Ausreden, warum man ja leider nix zu RISC OS beitragen könne. Vermutlich nach “die Castle-Lizenz ist nicht echtes Open Source” am öftesten gehört. Beides ist nun Geschichte. Nun bleibt noch “ich muss für das DDE bezahlen” – mal sehen, wann diese Ausrede auch Geschichte ist. Dann wird man sehen, dass es trotz bester Rahmenbedingungen nur sehr wenige Menschen gibt, die sich in der gebotenen Tiefe mit einem Randgruppenbetriebssystem in ihrer Freizeit befassen wollen.

Wieder nix in 2018, neuer Versuch in 2019

2018-12-23 19:52

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.

Ada, RISC OS und ARMv8

2017-03-10 19:17

CDVDBurn ist in Ada geschrieben. Und wird mit dem einzigen Ada-Compiler compiliert, der je unter RISC OS existiert hat: GNAT 3.03, basierend auf GCC 2.7.2.1. Also Technik von 1996. Natürlich nicht 32bit-kompatibel, ich compiliere also entweder auf dem dicken PC im Emulator, oder per Aemulor auf dem ARMX6. Durch glückliche Fügung erzeugt der Compiler 32bit-kompatiblen Code (zumindest meistens – es gibt einige Ada-Features die man besser nicht nutzen sollte wie z.B. Representation Clauses) – das ARM-Backend des GCC konnte das eh schon länger, die GCC-Runtime habe ich damals 2002 als der IYONIX pc erschien aus einem GCC 2.95 extrahiert, und die GNAT-Runtime hat mir Martin Würthner persönlich auf Binärebene angepasst.

Nun hat sich allerdings in den letzten Tagen herausgestellt, dass der erzeugte Code doch nicht so ganz hasenrein war, was die 32bit-Kompatibilität angeht. Ein Sack voll deprecated LDM-Instruktionen haben sich in der GCC-Runtime gefunden, die zwar auf bisherigen 32bit-Maschinen – vom IYONIX über den Pi 1 bis zum ARMX6 – trotzdem funktioniert haben, aber beim Pi 3 mit einem gnadenlosen “Undefined Instruction” abgebügelt werden. Konsultation mit Experten und nähere Analyse mit ARMalyser zeigten den Schuldigen: die GCC-Runtime enthält im main-Entrycode non-32bit-Code. Die Suche nach Sourcecode, auf dem die Runtime basiert, war leider nicht erfolgreich, und so versuchte ich mein Glück mit händischem Binär-Patch.

Scheint mein Glückstag gewesen zu sein: CDVDBurn läuft nun einwandfrei auf dem Raspberry Pi 3. Ich hoffe inständig, dass das auch so bleibt falls RISC OS auf weiteren ARMv8-Plattformen stattfinden wird. Ich bin zu alt für diesen Scheiß.

CDVDBurn für Titanium

2017-02-12 00:55

Die letzten Tage habe ich ein paar Stunden investiert, um CDVDBurn so anzupassen, dass S-ATA-Geräte am Titanium-Board unterstützt werden.

Die Anpassung an “yet another transport system” ist eine regelmäßig wiederkehrende und zuweilen nervige Arbeit. Historisch hat CDVDBurn, als es noch CDBurn hieß und man das Jahr 1997 schrieb, nur SCSI-Laufwerke unterstützt. Die gute alte Zeit. Egal welche SCSI-Karte, alle unterstützten die von Acorn vorgegebene API, und es gab nur wenige böse Überraschungen (der Connect32 war mit frühen Firmwareversionen bei größeren Blockgrößen etwas instabil, und das EESOX-SCSI-Podule hatte etwas abweichende Vorstellungen, wie der SCSI_Op genau bestückt wird).

Dann kam IDE. Risc PC und A7000 verwenden ADFS zum Zugriff, bei Simtec- und APDL-IDE-Podules wurde jeweils eine ganz eigene API rund um das dort verwendete IDEFS verwendet. Das RapIDE-Podule hatte wieder eine andere Idee, immerhin war dort die ATAPI-API sehr ähnlich der bewährten SCSI-API. Also: 4 unterschiedliche Transporter für den Eintritt ins IDE-Zeitalter.

Dann kam neue Hardware, aber zum Glück verwendeten die RiscStation-Maschinen die Simtec-API und die MicroDigital-Maschinen die APDL-API. Erst der IYONIX pc machte das Fass wieder auf – aber die Anpassung war initial einfach: CD_SCSIUserOp wurde ins CDFS reingedengelt, mit einer SCSI-ähnlichen API, aber man musste CDFS-Control-Blocks verwenden statt der SCSI-ID. Erst nach und nach kamen Einschränkungen ans Licht, vor allem bezüglich der Auswertung von Fehlern per Sense-Request. Auch unschön: CDFS musste das Laufwerk auch tatsächlich erkennen, was nicht immer der Fall war. Der IYONIX hatte aber eine Alternative zu bieten: dort hat ADFS in der Version 3 das IDE-Zepter geschwungen, und hatte endlich eine ATAPI-API anzubieten (beim ADFS von Risc PC und A7000 musste man noch Magic betreiben, um ATAPI-Kommandos abzusetzen).

Dann fing wieder die Glückssträhne an: die RISC OS 5-API für USB setzte sich durch, und dort wurden die Geräte schlicht als SCSI-Geräte behandelt. RISC OS 5 hatte nämlich den klassischen Acorn-SCSIDriver so erweitert, dass nun – ähnlich der softloadable drivers bei CDFS – per SCSISwitcher unterschiedliche Hardwaretreiber eingebunden werden konnten. So hätte das von Anfang an laufen sollen, IDE-Geräte wären nur spezielle SCSI-Devices gewesen und alle wären glücklich und zufrieden. Also: alles klar bei BeagleBoard, PandaBoard, Raspberry Pi und Konsorten. Auch beim ARMX6 gab es kein neues Problem – der bindet S-ATA-Geräte (oder besser: DAS S-ATA-Gerät, denn er hat nur einen S-ATA-Anschluss und S-ATA-Multiplexer werden derzeit nicht unterstützt) per softloadable SCSI driver ein. Aber da niemand seine schnelle S-ATA-Platte gegen ein S-ATA-DVD-Laufwerk tauschen will, ist das nur ein theoretischer Glücksfall.

Wer nun aber dachte, dass die softloadable SCSI drivers der Weg der Zukunft sein würde, sah sich mit dem Erscheinen des Titanium-Boards eines Besseren belehrt. ADFS 4 wurde aus der Taufe gehoben. Mehr oder weniger kompatibel zum alten ADFS, aber nicht kompatibel genug: CDVDBurn fand beim Drive-Scan keine Laufwerke.

Gott sei Dank gab es aber eine einfache Möglichkeit, den IYONIX-ADFS-Transport so aufzubohren, dass nun sowohl der IYONIX als auch das Titanium-Board mit einem Transport-System unterstützt werden können. Angenehmer Nebeneffekt: statt jedes Laufwerk einer ATAPI-Erkennungsprozedur zu unterziehen, wird jetzt auf die Ergebnisse, die ADFS beim Device-Scan erzielt, direkt zugegriffen (per ADFS_IDEDeviceInfo). Die Testergebnisse meiner Titanium-Tester sind noch durchwachsen, aber das könnte andere Gründe haben.

Wer zufällig ein Titanium-Board sein eigen nennt und beim Testen helfen will – E-Mail genügt.

Multicore-RISC OS für Experimentierfreudige

2017-01-18 15:30

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 🙂