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.

RISC OS Awards: and the winner is…

2021-10-28 23:04

Wer kennts sie nicht, die RISC OS Awards. Ursprünglich eine Auszeichnung, die vom Drobe Launchpad (lange Zeit noch im „Archive“-Modus verfügbar, im Moment gerade down) vergeben wurde auf Basis einer User-Online-Abstimmung. Inzwischen hat Vince M. Hudd von Soft Rock/Riscository diese ehrenvolle Aufgabe übernommen, gerne immer leicht verspätet – die 2020-Award-Ergebnisse wurden erst kürzlich veröffentlicht. Man erinnert sich ja kaum noch an 2020. Und mein Blogbeitrag dazu kommt natürlich im Gegensatz dazu kaum verspätet.

Jedenfalls habe ich dort zum ersten Mal den ersten Platz abgeräumt in der eher weniger konkurrenzträchtigen Klasse „Best foreign language resource“. Knapp aber deutlich mit 33% zu 30% gegen riscos.fr durchgesetzt. Man soll ja angeblich auf dem Höhepunkt aufhören – aber dieser Ratschlag bringt bekanntlich das Problem mit sich, dass man mangels Glaskugel leider nicht weiß, ob es sich bereits um den Höhepunkt handelt, oder ob der erst noch kommt. Vielleicht sind es nächstes Jahr 34%? Hätte Michael Schumacher nach seinem ersten Weltmeistertitel aufhören sollen? Oder nach seinem ersten Grand-Prix-Sieg? Eben.

Ich war gar in zwei weiteren Kategorien mit CDVDBurn 3 nominiert, bei „Best new development“ mit dem Blu-Ray-Support und bei „Best commercial software“ mit CDVDBurn selbst, aber da war mit so einem Randgruppenthema wie „Scheiben brennen“ natürlich nichts zu erben.

Nun könnte ich also das „Sieger-Cog“ hier im Blog irgendwo dekorativ integrieren. Allerdings habe ich ein sehr gespaltenes Verhältnis zu Grafiken im Web – man hätte früher ja begründet vermuten können, dass das schlicht Faulheit ist, aber jetzt wäre die Grafik ja schon vorgefertigt, und damit taugen die RISC OS Awards prima als Indiz für die völlige Abwegigkeit dieser Vermutung.

Raspberry Pi Zero 2 W

2021-10-28 21:52

Die Pi Foundation hat heute den brandneuen Raspberry Pi Zero 2 W angekündigt. Bei den üblichen Verdächtigen wie Reichelt Elektronik wird ein Preis von etwas über 15€ aufgerufen (official RRP: 15 US$) und eine Lieferung für Anfang November in Aussicht gestellt. Wenn man sich an den ersten Pi Zero erinnert, und noch die derzeitige Chipknappheit mit in Betracht zieht, dürfte die Verfügbarkeit anfangs sich eher schwierig gestalten.

Neben der zwar logischen, aber immer schwerer unfallfrei zu reproduzierenden Nomenklatur (zweite Auflage des Pi Zero, und mit Wireless (sowohl 802.11b/g/n als auch BT 4.2), aber CPU-technisch eher ein Pi 3, aber speicherausbautechnisch eher ein Pi 1, und speichergeschwindigkeitstechnisch weiß man es noch nicht) kann sich der geneigte Pi-Freund auf einen kräftigen Performance-Boost für alle multicore-fähigen Workloads freuen nebst VFPv4 und NEON. Aber auch für uns RISC OSler ist die deutlich bessere Single-Core-Performance nicht zu verachten – obwohl wie sein Vorgänger mit lediglich 1 GHz taktend, ist ein ARMv8-Cortex-A53 dank superskalarer Ansätze deutlich flotter unterwegs als das ARMv6-ARM11-Derivat des Ur-Zero(W)-Modells. Bemerkenswert finde ich das Packaging: die 512 MiB DDR2-RAM stecken im SoC, also kein PoP wie sonst typischerweise bei den kleinen SBCs zu sehen.

Mal sehen, ob RISC OS Anpassungen benötigt. Die Zero-Modelle sind für RISC OS-Zwecke nie so richtig beliebt gewesen – außer für Kompatibilitätssicherstellung wegen „ARMv6 ist wie ARMv5 sprich IYONIX“. Und da ist der neue ARMv8-Cortex-A53 natürlich eher kontraproduktiv. Auf der anderen Seite wären die 512 MiB mehr als ausreichend für die üblichen RISC OS-Dinge, während ein Linux da eher mal in Platznot gerät.

Spannend aus meiner Sicht auch, ob das Runtertakten auf 1 GHz hilft, um die Hitzeentwicklung im Zaum zu halten. Der Pi 3 war schließlich der erste Pi, wo ein Lüfter eher anzuraten war, vor allem in der +-Ausprägung.

Update 2021-10-29

Chris Gransden berichtet von einem erfolgreichen RISC OS-Lauf auf dem Pi Zero 2 W. Benchmarkergebnis legt nahe, dass die RAM-Geschwindigkeit gegenüber den alten Zero-Modellen sehr deutlich zugelegt hat. Ungefähr auf Pi3-Niveau, also deutlich schneller als beispielsweise ein Wandboard aka ARMX6, ein Pi 2, ein PandaBoard oder ein BeagleBoard-xM.

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.

Interessante Projekte – heute: DARIC von Daryl Dudey

2021-03-17 00:34

Gestern habe ich – Pandemie sei Dank – im Rahmen des monatlichen Online-Meetings der RISC OS User Group of London, liebevoll ROUGOL abgekürzt, einem interessanten Vortrag von Daryl Dudey lauschen können. Er stellte sein Projekt DARIC vor, das kurz gesagt eine BASIC-artige Programmiersprache für Windows und RISC OS nebst Laufzeitumgebung basierend auf einer virtuellen Maschine darstellt. Mit einem starken Fokus auf die Grafikfähigkeiten, im Geiste von Klassikern wie AMOS (und natürlich dessen Cousin STOS) oder BlitzBasic, aber jetzt auch mit 3D-Grafikunterstützung. Syntaktisch mit deutlicher Verwandtschaft zu BBC BASIC.

Da ich derartige Vorträge zur Entspannung anhöre und nicht zwecke Blogberichterstattung, habe ich natürlich keinerlei Notizen gemacht. Alles, was jetzt folgt, basiert auf der fehlerhaften Erinnerung eines mittlerweile in die Jahre gekommenen Gedächtnisses. You have been warned.

Die Kernpunkte von Daryls Bemühungen, quasi die dahinterliegende Philosophie, ist für mich persönlich gar nicht so interessant. Er strebt eine sehr interaktive Sprache an, also ein klassischer Interpreter mit einer integrierten Ausführungsumgebung mit klassischem Zeileneditor, wo man die Befehle direkt eintippen oder auch ausführen kann. Außerdem soll die Sprache reichlich Schlüsselwörter bieten, mit allem was das Programmiererherz begehrt („batteries included“-Ansatz, wie Daryl es nannte), ohne dass man erst zig Bibliotheken runterladen muss. Also durchaus BBC BASIC nicht unähnlich, aber insbesondere für Einsteiger noch nutzerfreundlicher. Klare Zielrichtung: 2D- und 3D-Grafikunterstützung, derzeit alles in Software gerendert, und mit identischen Ergebnissen egal ob die Ausführung unter RISC OS oder Windows erfolgt.

Also: da bin ich nicht Zielgruppe. Den Kreativbereich im Grafikbusiness sollen andere abdecken, ich bin eher so der Anwendersoftware-mit-grafischer-Oberfläche-Entwickler. Für mich sind andere Details interessant. Zum Beispiel die Tatsache, dass Daryl „mal kurz“ eine eigene VM entwickelt hat, die zudem recht performant zu sein scheint. Und in einer Hochsprache /C++) implementiert. Mit Ansätzen eines JITs. Mit einem Parser, der per ANTLR4 generiert wird. Letztlich wird hier der Nachweis erbracht, dass mit modernen Werkzeugen ein solches Projekt – Sprache, VM, Laufzeitumgebung – selbst für einen einzelnen Entwickler im Bereich des Machbaren liegt. Wobei natürlich zu beachten ist, dass es vom weitgehend funktionierenden Zwischenstand hin zu einer wirklich ausgereiften stabilen Version noch ein ganzes Wegstück sein wird. Die Grundidee „schnelle VM mit erweitertem BASIC“ ist jedenfalls für RISC OS-Zwecke hochinteressant.

Sehr erfrischend fand ich Daryls Pragmatismus an vielen Ecken. Er hat sich nicht jahrelang Gedanken gemacht über sprachtheoretische Feinheiten oder eine effiziente GC-Implementierung oder ob man nicht besser eine vorhandene VM portieren sollte oder oder oder. Er hat einfach mal angefangen zu implementieren, auch Irrwege in Kauf genommen, mit einer klaren Philosophie im Hintergrund, und was dabei rausgekommen ist, kann sich sehen lassen. Auch interessant: einfach mal auf C++ 14 als Implementierungssprache gesetzt, was unter RISC OS schon anspruchsvoll ist, weil es GCC 8 voraussetzt.

Wer den Stand der Dinge begutachten mag: der Sourcecode ist komplett auf GitHub verfügbar, da kann man auch diverse kleine Beispiele und Demos in Augenschein nehmen – nichts illustriert Syntax besser als lebender Code. Die Website zur Sprache scheint derzeit leider offline zu sein.

Witzige Randnotiz zum Abschluss: Der Erfinder von AMOS ist gerade auch am Schrauben und hat AOZ Studio aus der Taufe gehoben, ursprünglich „AMOS 2“ genannt. Ich traue mich noch nicht, die große BASIC-Renaissance auszurufen, aber es könnte sich hier ein Trend abzeichnen. Ein ganz kleiner Randgruppentrend zumindest.

Ein Interview für The Icon Bar

2021-02-13 21:20

Als mich Mark von „The Icon Bar“ fragte, ob ich nicht eins der mittlerweile klassischen RISC OS-Interviews machen würde (also kein Live-Interview – das wäre mir auf Englisch etwas zu heikel – sondern eins wo man einen Sack voll Fragen schriftlich bekommt und diese in aller Ruhe und Ausführlichkeit beantwortet), habe ich nach kurzer Bedenkzeit zugesagt.

Das Ergebnis ist jetzt online und ist womöglich das geschwätzigste Interview seiner Art aller Zeiten. Ich habe die Fragen genutzt, um ein wenig zu philosophieren, ohne dass einem – wie in Foren beispielsweise – direkt widersprochen wird 🙂

Ich wünsche eine angenehme und vielleicht sogar erhellende Lektüre.

175 Ausgaben GAG-News auf einer DVD

2021-02-08 20:08

Seit wirklich langer Zeit begleitet mich die GAG-News als Informationsquelle rund um RISC OS – egal ob Neuigkeiten, Berichterstattung diverser RISC OS-Shows, Soft- und Hardware-Tests, Programmierkurse. Seit April 1992 die erste Ausgabe erschien, gibt es mit gnadenloser Konstanz alle zwei Monate eine neue Ausgabe. Und so wird dann im Mai 2021 die 175. Ausgabe erscheinen. Zur Feier dieses Jubiläums erscheint eine DVD mit allen 175 Ausgaben als PDF, für Abonnenten zum Vorzugspreis, und für Schnellbesteller (Stichtag ist der 21.02.2021 – heilige Datumssymmetrie!) gibt es noch einen Extra-Rabatt. Das Ereignis ist so wichtig, dass sogar die internationale Presse bei der Berichterstattung dabei war.

Ich erinnere mich dunkel, dass ich nicht ab Ausgabe 1 ein Abo hatte, aber irgendwo zwischen Ausgabe 2 und 4 eingestiegen bin und die Vorausgaben gleich nachbestellt habe. Und so habe ich alle GAG-News-Ausgaben hier lagernd, inklusive der ersten glaube ich 6 Ausgaben, die noch als Lose-Blatt-Sammlung ins Haus kamen bevor auf den schönen grünen Umschlag mit der großen Acorn-Eichel umgestellt wurde. Mit einer kurzen Zwischenabweichung des farbigen Covers irgendwann zwischen 1996 und 1998, als auf Wunsch diverser deutscher RISC OS-Händler (ja, das gab es mal…Mehrzahl! Händler! Damals gab es sogar ganzseitige Händler-Anzeigen in der GAG-News!) für eine repräsentativere Auslage im Ladengeschäft ein buntes Blau-Rot-Grün-Cover verwendet wurde.

Im deutschsprachigen RISC OS-Bereich ist die GAG-News seit sehr langer Zeit konkurrenzlos – frühere Konkurrenz in Form von Druckerzeugnissen (die Markt&Technik-Hobby-Computer-„Archimedes“-Specials, das Risc PC-Magazin von Peter Klein, das Risc-Power-Magazin von Matthias Seifert) sind schon lange Geschichte, und die Zeit der Disc-Magazine, die in Vor-Internet-und-Mailbox-Zeiten auf Floppy weitergegeben wurden (ich nenne mal die ArcGames von Matthias Seifert und den Hardliner von Bytepool Productions/Tim Juretzky & Co), ging ja auch eher rasch zu Ende.

Dass die zweimonatliche Erscheinungsweise zuverlässig wie ein Uhrwerk durchgehalten wurde, ist in erster Linie natürlich dem Herausgeber Herbert zur Nedden zu verdanken, der in Schwachlastzeiten die Seiten einfach durch mehr eigene Beiträge füllt. Sogar gegenüber der englischsprachigen Konkurrenz wie der Archive mit ähnlich langen Erscheinungszeiträumen ist das schon bemerkenswert. Da ist mal ein großes „Dankeschön“ fällig für die Jahrzehnte der guten Arbeit. Seit einigen Jahren liefere ich auch regelmäßig Beiträge zu, da Herbert einzelne meiner Blogeinträge mehr oder weniger direkt als GAG-News-Beiträge verwenden darf und soll.

Hier http://www.gag.de/gagdisc.html gibt es alle Details zu den Bestellformalitäten.

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.

RISC OS 5.28 auf dem Raspberry Pi 400

2021-01-10 22:23

Es ist schon fast ein Jahr her, als ich über den aktuellen Stand von RISC OS 5.xx auf dem Raspberry Pi 4 berichtet hatte. Damals noch sehr rudimentär ausgeprägt, zwar lauffähig aber wegen unvollständiger USB-Unterstützung fingen die Probleme schon bei der Stromversorgung an.

Die meisten der unvollständigen Dinge wurden schon mit RISC OS 5.28 gelöst – USB tut nun ohne Tricks, d.h. man kann USB-C wie gedacht für die Stromversorgung nutzen und die „normalen“ USB-Ports eben für USB. Auch das Ethernet ist inzwischen stabil und auch recht schnell, und die 4 GiB-Variante funktioniert nun auch problemlos. Selbst die 8 GiB-Variante tut nun, aufgrund seiner 32bit-Natur kann RISC OS aber in Ermangelung einer Unterstützung der Aarch32-„Large Physical Address Extension“-Technik nur 4 GiB nutzen. Fehlt also nur echte USB3-Unterstützung, aber da braucht es wohl das Großreinemachen im USB-Stack (also z.B. die Neuportierung des aktuellen BSD-Stacks, wie in diesem ROOL-Bounty skizziert).

Kurz nach dem Release von 5.28 kam dann die Raspberry Pi Foundation um die Ecke mit ihrer neuesten Kreation, dem Raspberry Pi 400. Erstmalig eine Abkehr des Konzepts „nackte Platine, der Rest findet sich“. Das hatte sich ja schon abgezeichnet, gibt es doch inzwischen ein „offizielles Netzteil“, ein „offizielles Gehäuse“, eine „offizielle Tastatur“ und eine „offizielle Maus“. Wenn man das jetzt alles kombiniert und im Hinterkopf behält, warum seit der ersten Variante des Raspberry Pi es ein „Model A“ und ein „Model B“ gibt – fertig ist das neue Produkt „Raspberry Pi 400 Kit“. Man könnte es die „jüngste Hommage an die große Zeit der 8/16-Bit-Heimcomputer“ nennen. Oder auch der 32bit-Heimcomputer, wenn man an den Acorn A3010 oder 3020 denkt.

Wer es nicht mitbekommen hat: der Pi 400 ist im Prinzip ein Pi 4 in der 4 GiB RAM-Variante in einem kompakten Tastaturgehäuse. Alle Anschlüsse befinden sich auf der Rückseite, der analoge Soundausgang ist weggefallen, sonst alles da – vom GPIO über die 2 microHDMI bis zum Ethernet. Und nur 3 statt 4 USB-Buchsen, weil die Tastatur ist ja schon integriert. Auch die microSD-Karte wird hinten eingesteckt, und endlich mal wieder mit einem vernünftigen Feder-Slot-Mechanismus wie es zuletzt beim RPi B+ zu finden war. Dank der intern verbauten Kühlbleche konnte man den Takt etwas höher ansetzen, 1,8 GHz gegenüber 1,5 GHz. Man kann den 400 in zwei Varianten kaufen, als nacktes Gerät oder als „Kit“ inklusive gedrucktem Einsteiger-Handbuch, Netzteil, microSD-Karte mit vorinstalliertem Raspbian und microSD-SD-Adapter mit Raspberry Pi-Logo, microHDMI-Kabel und der bekannten himbeerrot-weißen USB-Maus. Verschiedene lokalisierte Varianten sind verfügbar, was bei einer integrierten Tastatur ja auch eine gute Idee ist. Ich habe mich für die DE-Variante entschieden.

RISC OS Open Ltd. hat kurz nach Weihnachten verkündet, dass es eine entsprechende Distribution von RISC OS Pi auf Basis eines leicht aktualisierten RISC OS 5.28 mit einem fancy pinboard backdrop zur Verfügung steht – und das auch über den offiziellen Raspberry Pi Imager. D.h. der RISC OS-Installationsvorgang kann über einen PC der Wahl über den Imager mit wenigen Clicks erfolgen. Das habe ich tatsächlich mal ausprobiert, und es funktioniert völlig problemlos. Profi-Tipp: Linux herunterfahren, Karte tauschen und wieder die Power-Taste drücken reicht nicht, vermutlich weil der Rechner nur in einer Art Standby-Modus ist. Man muss das Dingens kurz stromlos machen, dann wird die RISC OS-Karte klaglos akzeptiert.

Leider haben die fertigen Images den Makel, dass sie die Kapazität der microSD-Karte in keinster Weise ausnutzen können – es bleibt stets bei der vom Image vorgedachten Größe, im vorliegenden Fall knapp 2 GiB. RISC OS unterstützt noch immer keine echten Partitionen (sonst könnte man ja den restlichen Platz einfach als zweite Partition einrichten), und das Filecore-Format ist der Alptraum einer jeden Partition-Resizer-Anwendung, weshalb es schlicht keine gibt. Deshalb taugt aus meiner Sicht für RISC OS im Moment weiterhin nur das Vorgehen „von Hand“: vorhandenen Pi mit RISC OS drauf nehmen, microSD-Karten-Leser und leere große microSD-Karte, SystemDisc, microSD entsprechend einrichten (ich empfehle einen großen FAT-Bereich, den kann man prima für Datentransfer mit anderen Betriebssystemen nutzen, solange das Netzwerk noch nicht funktioniert), config/txt und cmdline/txt anpassen, HardDisc4-ZIP entpacken. Wie immer hatte ich bei meinem Setup wenig Glück mit EDID und der RISC OS-Idee der automatischen Bildschirmerkennung, und so konfiguriere ich den richtigen Bildschirmmodus immer fest in die config/txt und verwende disable_mode_changes, weil das für ADFFS in Verbindung mit AnyMode der viel problemlosere Betriebsmodus ist.

Die „Power“-Funktion über die Tastatur (Fn + F10) erfordert übrigens die Mitarbeit des Betriebssystems, unter RISC OS gibt es hier noch keine Unterstützung. Schade, Shutdown mit nachfolgendem Power-Off wäre schön.

Auch in die Raspbian-Distribution – inzwischen „Raspberry Pi OS“ genannt – habe ich einen Blick geworfen, finde es aber nach wie vor für ein Massenprodukt erstaunlich unrund, was hauptsächlich zu merken ist, wenn man „Deutsch“ als Sprache auswählt. Denn auch danach geht es erschreckend oft in Englisch weiter. Ganz gut gelungen ist hingegen die deutsche Übersetzung des dem „Kit“ beliegenden Einsteiger-Handbuchs (auch wenn ich nie auf die Idee gekommen wäre, das urdeutsche Wort „Overscan“ durch „Übertastung“ zu ersetzen). Interessierte können es als PDF runterladen, dafür muss man nicht das „Kit“ kaufen. Man beachte, dass auch viele der Screenshots die jeweilige deutsche Version zeigen, da hat jemand mitgedacht und mit Plan gearbeitet. Wenn jetzt noch jemand ein entsprechendes Handbuch, angepasst an RISC OS und mit BBC BASIC-Beispielen schreiben würde…

Und die Hardware? Macht alles einen recht soliden Eindruck. Die Tastatur ist Laptop-artig mit hartem Anschlag und kurzen Tastenwegen, jedoch für meinen Geschmack etwas zu steil im Winkel angestellt – aber klar, irgendwo muss ja auch die Hauptplatine hin. Es ist ein sehr kompaktes Layout, und für RISC OS-Zwecke nervig, da es nur Platz für 10 F-Tasten hat und so die oft genutzte F12-Taste nur per Modifier (hier „Fn“ genannt, in Kombination mit F2 ergibt sich dann die F12-Taste) zugänglich ist. Aber immerhin wird das Auge nicht durch ein Windows-Logo beleidigt, denn dort befindet sich logischerweise die allseits beliebte Himbeere. Die Maus ist im besten Sinne unspektakulär, höchstens das etwas kurze Kabel könnte nervig sein. Die microSD-Karte ist ein Markenprodukt von SanDisk, stellt aber keine Geschwindigkeitsrekorde auf. Das Netzteil funktioniert wie zu erwarten prima, genau wie das (auch eher kurze) microHDMI-HDMI-Kabel.

Ist der Pi 400 – ob nackt oder als „Kit“ – nun sein Geld wert? Das muss jeder selbst entscheiden, der Aufpreis gegenüber der nackten 4 GiB-Platine hält sich schließlich in Grenzen. Wer wie ich das Basteln gewöhnt ist, und wenn das Rechner-Setup rund um einen KVM-Switch gebaut ist und deshalb die integrierte Tastatur keinen Vorteil darstellt – nun gut, wie gesagt der Aufpreis hält sich in Grenzen, und wenn man den Rechner „mal schnell“ woanders mit hinnehmen will, ist das All-in-one-Design vielleicht doch von Vorteil. Schade ist aus meiner Sicht, dass man den neu gewonnenen Platz nicht dafür genutzt hat, die frickeligen microHDMI-Ports durch ihre Full-Size-HDMI-Pendants zu ersetzen. Man muss nicht jeden Holzweg konsequent zu Ende gehen – bei der nacken Pi4-Platine gab es immerhin noch die „wir hatten keinen Platz“-Ausrede.

Vielleicht passt eines der neueren Pi 4-Gehäuse besser zu meinen Ansprüchen – liegt inzwischen mit allen notwendigen Materialien hier rum und wartet auf Zusammensetzung: ein Alu-Gehäuse mit USB3-M.2-SATA-Adapter und Power-Taster namens „Argon One M2“, ein Pi 4 in der 8 GiB-Variante, und eine Samsung M.2-SATA-SSD mit 512 GiB die hoffentlich gut ins Gehäuse passt. In diesem Falle ein Gehäuse mit zwei Full-Size-HDMI-Buchsen, dazu ein eingebauter IR-Sensor, ein softwaresteuerbarer Lüfter, und der analoge Soundausgang bleibt auch erhalten. Dazu eine recht intelligente Lösung für die GPIO-Pins. Vielversprechend.

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.