Software

Anwendungen und Tools rund um RISC OS

Neues von SparkFS

2023-03-28 23:28

Auf der Liste der unverzichtbaren Tools unter RISC OS gehört zweifellos SparkFS von David Pilling auf den ersten Platz. Schon im Juli vergangenen Jahres gab es die frohe Kunde, dass nun auch die Read-Write-Variante kostenlos zur Verfügung steht. Jetzt wird die nächste Stufe gezündet: Open Source unter der Ägide von RISC OS Open Ltd.

Zusätzlich hat David gerade zwei neue Features hinzugefügt: ZIP Encryption (bitte frühzeitigen Enhusiasmus vermeiden – es geht um die originäre Passwortverschlüsselung, die heute eher als “Data Scrambling” qualifiziert werden würde und keinesfalls höheren Sicherheitsansprüchen genügt) und Rename-Support. Nur für Tester im Moment verfügbar, aber hoffentlich demnächst auch etwas breiter. Gerade unter RPCEmu mit RISC OS 4.02 ausprobiert – tut. Encryption unter Windows gegengeprüft: funktioniert mit Windows 10-inbuilt-ZIP und 7-Zip und unter Java mit Zip4J (meines Wissens die einzige Pure-Java-Open-Source-Lib, die encrypted ZIP unterstützt).

David Pilling öffnet (erneut) die Schatzkiste

2022-07-28 12:15

Der vermutlich produktivste Entwickler kommerzieller Software für RISC OS, David Pilling – von seinen Kunden, Freunden und Verehrern auch liebevoll “St. Pilling” genannt – hat erneut seine Schatzkiste geöffnet bzw. die Öffnung derselben auf seiner Mailing-Liste angekündigt. Die nebenbei den vielsagenden Namen “softwarelist” trägt, eben weil David über viele Jahre eine so große Anzahl von phantastischen Anwendungen geschrieben hat, dass nur “Software” ein geeigneter Überbegriff ist. Es geht diesmal sowohl um den Sourcecode als auch die fertig gebaute Version von SparkFS und von Ovation Pro.

Kurzer Blick auf Davids Schaffen: Ovation und Ovation Pro, Spark und SparkPlug und SparkFS, TWAIN nebst Treibern von Parallel-Port über SCSI bis zu USB für diverse Scanner, David Pilling’s Scanning Software (dessen ursprünglicher Name nicht mehr genannt werden soll – wörtlich übersetzt hieß das Dingens mal “Meister des Bildes”), unverzichtbare Software zur Modemnutzung wie Hearsay und ArcFax, Trace zur Konvertierung von Bitmaps in Vektorgrafik – dazu jede Menge kleinerer Tools, die zum Sparpreis oder gar kostenlos angeboten wurden. Das letzte große Projekt war dann Ovation Pro für Windows, für Wanderer zwischen den Betriebssystemwelten wie mich eine sehr gute Sache. David war wirklich extrem produktiv über die Jahrzehnte, auch wenn das letzte Jahrzehnt eher durch Pflege als durch Weiterentwicklung geprägt war. Trotzdem essentiell in der RISC OS-Welt mit dem Umstieg auf RISC OS 5 und später ARMv7 und ARMv8 – die Software von David Pilling war unter den kommerziellen Paketen stets unter den ersten, die auf neuen Systemen liefen. In Anbetracht der Tatsache, dass die Nutzer schon seit 20 Jahren auf die 32bit-Version von Impression warten, ist das durchaus eine Erwähnung wert.

SparkFS hat schon seinen Platz auf der “Retired Software”-Seite mit der aktuellen Vollversion 1.46 zum freien Download, Ich denke Ovation Pro wird sich auch alsbald dazugesellen (bisher gibt es nur eine für den OvPro Impression Document Loader). Vielleicht wieder mit einem launigen Text dazu, üblicherweise eine bittersüße Mischung aus Desillusionierung, akkurater Historie und Nostalgie. Nerd-Detail: es wird nicht der gesamte Inhalt der Ovation Pro-Distribution (früher 8 Disketten, später eine CD) zur Verfügung gestellt, weil dort auch lizenzierte Drittanbieter-Dinge mit dabei waren wie Fonts, für die David keine Distributionsrechte der Marke “kostenlose Verteilung” hat.

Übrigens wird auch die Windows-Version von Ovation Pro freigegeben werden.

Und vielleicht findet sich ja jemand wie Chris Johnson im Falle von David Pilling’s Scanning Software, Snapper und SyncDiscs, der weiterhin Zeit investiert in die Pflege der Software.

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.

R-Comp Pre-Show News

2021-11-02 15:21

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

2021-05-28 20:25

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

2021-01-30 16:33

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

2021-01-01 15:19

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

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

SparkFS 1.46

2020-07-14 19:37

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.