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.

Aktueller Status RISC OS auf Raspberry Pi 4

2020-02-29 03:11

Nachdem nun schon Aemulor in einer RPi 4-kompatiblen Version verfügbar ist, wie steht es derzeit denn um RISC OS selbst auf dieser vielversprechenden Plattform?

Zunächst eine kurze Zusammenfassung, warum man überhaupt einen RPi 4 haben will gegenüber einem seiner zahlreichen Vorgängern. Die CPU ist deutlich schneller, sowohl pro Takt als auch im Maximaltakt, und die Caches sind größer. Speicher ist deutlich schneller und bis zu 4 GiB groß (das vermutlich wichtigste Feature für die Linux-Jünger, und das vermutlich unwichtigste Feature für RISC OS-Nutzer). Gigabit Ethernet über einen schnellen internen Bus. USB3 über PCIe. Offizielle Unterstützung für 4K@60Hz-Bildschirmauflösung (früher war das eher Glücksache @30Hz). Dual-Head-Unterstützung.

Schon der derzeitige Zustand von RISC OS zeigt deutliche Fortschritte in den Benchmarks. Man darf sich also nicht nur auf theoretische Performancegewinne freuen, sondern tatsächlich auf spürbare Verbesserungen in der Praxis. Die CPU liegt auf einem Niveau mit den bisher schnellsten RISC OS-tauglichen Boards mit TI OMAP5 (Cortex-A15-Basis – Titanium und IGEPv5). An der Grafikbeschleunigung lässt sich sicher noch arbeiten, aber das ist „nur“ eine Softwarefrage.

Und wie weit ist diese Praxis nun noch entfernt? Es fehlt prinzipiell an zwei Dingen: USB3 und Ethernet. D.h. man kann sich heute „from source“ ein RPi 4-kompatibles ROM bauen, aber man muss Ethernet über das alte USB2.0 anbinden, ebenso wie zusätzliche Massenspeicher jenseits des microSD-Slots. Das ist aber nicht ganz einfach, weil alle „normalen“ USB-Ports des Boards über den kombinierten USB3/USB2-Chip (VIA VL805) gehen, für den es eben noch keinen Treiber gibt. Das alte USB2.0 ist nur über den USB-C OTG verfügbar, über den auch die Stromversorgung normalerweise läuft. Deshalb sind bei der Inbetriebnahme noch ein paar Handstände vonnöten, beispielsweise indem man die GPIOs für die Stromversorgung nimmt und den USB-C stattdessen als USB-Port statt zur Stromversorgung.

Wer eher Code-affin ist, kann hier in Gitlab die Entwicklung nachverfolgen. Wer eher auf verständlichere Prosa setzt, verfolgt die Entwicklung im ROOL-Forum oder schaut sich den Port-Status im ROOL-Wiki an.

Bleibt noch die Frage: warum dauert es denn nun so lange? Da gibt es eine Vielzahl an Gründen. Beispielsweise hatte RISC OS bisher keinen XHCI-USB-Treiber (für USB3). Beispielsweise ist die Memory Map für die 4-GiB-Variante zu berücksichtigen (alle bisherigen 4 GiB-Plattformen hatten die „oberen“ 2 GiB außerhalb des 4 GiB-Adressbereichs). Beispielsweise sind die Datenblätter bis heute nicht in der notwendigen Ausführlichkeit zu haben. Beispielsweise scheint es im PCIe-Bereich interessante Bugs in der Pi-Firmware gegeben zu haben. Selbst die Aktivierung des UARTs für serielles Debugging gestaltete sich als schwierig. Letztlich also eine ungewöhnliche Anzahl von nicklichen Detailproblemen, die dem geneigten Entwickler den Tag vermiesen. Aber wenn ich die Commits richtig deute, ist die Zielgerade nicht mehr weit entfernt.

Und dann wird es spannend, inwiefern RISC OS ebenfalls – vor allem in schlecht kühlbaren Gehäusen – in „thermal throttling“-Probleme laufen wird, die so manchem experimentierfreudigen RPi4-Besitzer fast schon klassisches PC-Feeling inklusive Lüfter eingebrockt hat. Gut gekühlt kann der RPi4 wohl durchaus 2 GHz und mehr ab, bei Einsatz aller 4 Cores. Ungekühlt in den üblichen beinahe dichten Plastikgehäusen könnte es eher schwierig werden mit den neuen Performance-Höhen.

Aemulor 2.53 verfügbar

2020-02-29 03:02

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

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

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

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

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

In der Zwischenzeit: Happy Aemuloring!

Arculator v2.0 ist da

2019-11-09 20:30

Sarah Walker hat heute die Verfügbarkeit von Arculator v2.0 verkündet. Die letzte releaste Version, 0.99, hatte Mitte des Jahres 10 Jahre Geburtstag gefeiert. Wahnsinn. Sollte jemand Arculator noch nicht kennen: während RPCEmu sich um die Emulation der Maschinengeneration Risc PC und A7000 kümmert (und damit um RISC OS-Versionen ab 3.50 aufwärts), nimmt sich Arculator dem Namen entsprechend der Generation Archimedes an – vom A310 bis zum A5000, also alles, was mit RISC OS bis einschließlich Version 3.19 lief.

Was ist neu in der Version 2.0? Ein so großer Versionssprung legt ja doch gewisse tiefgreifende Verbesserungen nahe, aber Zahlen sind bekanntlich geduldig. Also gehen wir ins Detail. Ich habe noch nicht alles durchgetestet, das ist nur ein erster Eindruck. Vorab: die Beschäftigung mit der neuen Version lohnt auf jeden Fall!

Neu ist die Maschinenkonfiguration. Bisher startete Arculator mit den letzten Einstellungen, was maschinenspezifische Dinge anging – ARM2 oder ARM3, old-style I/O (A540 und früher) oder new-style I/O (A5000 und später), Betriebssystemversion, RAM. Gewisse Dinge waren dann fest mit anderen Details verhenkelt – wenn man beispielsweise old-style I/O konfigurierte, wurde automatisch das Risc Developments IDE-Podule emuliert mit IDEFS, bei new-style I/O hingegen das IDE-Interface vom A5000 über ADFS. Beide verwendeten hartcodiert hd4.hdf und hd5.hdf als Festplattenimages. Jetzt ist alles anders: man kann eine beliebige Anzahl von zu emulierenden Maschinen konfigurieren – man nimmt eine Basismaschine (A310, A540, A3000, A5000…) und stellt dann die Details ein – ARM2 oder ARM3, welche Frequenz. MEMC1 oder MEMC1a, RAM mit 8 MHz oder 12 MHz, FPA10 oder nicht, welches Betriebssystem steckt drin (Arthur 0.30 bis RISC OS 3.19), wieviel RAM ist an Bord, gibt es ein Joystick-Interface und sind Podules aktiv. Vor allem letztes eröffnet schöne neue Möglichkeiten, denn es wird eine illustre Reihe an Podules angeboten: das klassische Acorn SCSI-Podule, das sowohl Festplatten als auch CD-ROMs emulieren kann (virtuell oder aufs Host-CD-Laufwerk mappend – für die Detailverliebten: es wird ein Toshiba XM3301 emuliert, ein alter Caddy-Recke, der von den stets mit CDFS gelieferten CDFSSoftEESOX-Treibern unterstützt wird). Verschiedene IDE-Podules. Das Acorn ST506-Podule (MFM-Platten, die Älteren erinnern sich). Dazu noch das Wild Vision Midi-Podule und das Computer Concepts Lark-Podule, eine in freier Wildbahn selten gesehene Sound-Erweiterung (auch von Wild Vision designed) mit MIDI, 16bit-Stereo-Output und 16bit-Sound-Sampler. Eher exotisch: das HCCS Ultimate CD-ROM-Podule, das den Betrieb eines der damals gängigen Mitsumi-Laufwerken erlaubte, bevor IDE-ATAPI-CD-ROMs die Herrschaft übernahmen. Auch hier kann man ein physisches oder virtuelles Laufwerk zuordnen, aber da es diese Möglichkeit ja auch schon beim SCSI-Podule gibt, ist der Zusatznutzen eher gering.

Bei der Maschinenkonfiguration ist zu beachten, dass man nicht beliebig kombinieren kann – so ist ein A3000 mit Arthur als OS nicht möglich, genausowenig wie mit dem MEMC1. Ein ARM3 geht stets nur mit dem MEMC1a zusammen. FPA10 erfordert zwingend einen ARM3. Und in einen A5000 kann man keinen ARM2 reinkonfigurieren. So viel Realismus muss sein.

Und noch mehr Liebe zum Detail ist erkennbar: so kann man pro Maschine die „Unique ID“ einstellen. Das ist eine Acorn-Erfindung, die seit dem A5000 sein Unwesen treibt. Damit konnte Software sich bei der Installation an diese ID binden und so als eine Art Kopierschutz fungieren. Da aber ältere Maschinen ohne diese ID kamen, haben clevere Zeitgenossen einfach die ID so manipuliert, dass sie als nicht initialisiert galt und damit der Software vorgaukelte, eine alte Maschine ohne ID zu sein. Kurz gesagt: eine Flop-Idee. Allerdings könnte es natürlich sein, dass jemand noch Originaldisketten im Bestand hat, die an eine bestimmte ID gebunden sind. Von daher ist die Simulation der ID eine lobenswerte Sache für diese seltenen Fälle.

Was gibt es unter der Haube zu vermelden? Das ungeliebte Allegro-Framework ist Geschichte, jetzt ist alles SDL2-basiert, mit wxWidgets für die grafische Oberfläche. Daran ist höchstens schade, dass damit eine Portierung nach RISC OS sehr aufwändig wird, weil beide Bibliotheken noch(?) nicht portiert wurden. Aber unter RISC OS gibt es mit ArcEm, ArchiEmu und ADFFS ja sowieso reichlich Auswahl zum Zwecke der Retro-Archimedes-Emulation.

Jedenfalls soll die CPU- und MEMC-Emulation nun deutlich präziser sein, weshalb die feine Unterscheidung von MEMC1 und MEMC1a jetzt Sinn ergibt. ARM2 mit 8 MHz, ARM250 mit 12 MHz, ARM3 mit irgendwas zwischen 20 und 35 MHz (je nach konfigurierter Basismaschine ist die Auswahl beschränkt), dazu ein Turbo-RAM-Modus mit 16 MHz – alles ist möglich. Der direkte Floppy-Zugriff wurde auch neu implementiert.

Auch videotechnisch sind einige Optionen dazugekommen, Direct3D und OpenGL kann nun als Methode ausgewählt werden, was letztlich der SDL2-Basis zu verdanken ist. Aber auch Software-Rendering ist weiterhin möglich.

Noch eine gute Nachricht: das sich öfter etwas merkwürdig verhaltende ArculFS als native Zugriffsmöglichkeit auf das Host-Dateisystem wurde kurzerhand durch HostFS von RPCEmu ersetzt. Eine gute Entscheidung.

Und zum guten Schluss: es gibt nun Floppy-Geräusche!

Sowohl die Windows- als auch die Linux-Version gibt es direkt zum Download, Sourcecode ist mit im Archiv. Also, downloaden und experimentieren.

MIST Archimedes-Core jetzt mit IDE

2019-11-09 15:54

MIST und MISTer, die beiden genialen Open-Source-FPGA-Plattformen zur Emulation bzw. Simulation älterer Computer, Spielkonsolen und Arcade-Automaten waren schon mehrfach hier und in meinem IT-Blog Thema. Seit 2015 experimentiere ich mit dem MIST und dort vor allem mit dem Archimedes-Core.

Jetzt hat dank Slingshot aka gyurco (Usernamen aus dem Atari-Forum bzw. von GitHub) der Archimedes-Core einen großen Schritt nach vorne gemacht. Es ist jetzt ein Risc Developments IDE-Podule integriert, so dass man mit von den Emulatoren bekannten Festplattenimages (typischerweise mit der .hdf-Extension) arbeiten kann – gegenüber der bisherigen Floppy-Images-Only-Betriebsweise ein riesiger Schritt nach vorne.

Der Core kann auch ein CMOS.RAM von der MIST-SD-Karte laden, leider aber geänderte Settings noch nicht speichern.

Zur Feier des Tages habe ich ein entsprechendes Image zusammengebaut und zur Verfügung gestellt. Es basiert auf dem RISC OS 3.1-UniBoot aus den letzten Acorn-Tagen inklusive aller Standardanwendungen wie ChangeFSI oder Printers, zusätzlich angereichert um aktualisierte Toolbox-Module, den lebensnotwendigen Utilities wie SparkPlug, die Read-Only-Version von SparkFS und PackDir. Und dazu noch drei der inzwischen freigegebenen Spieleklassikern: Burn’Out, Elite und Star Fighter 3000. Ersteres und letzteres zeigen allerdings, dass noch etwas Feintuning am ARM-Core notwendig ist, um hier adäquate Performance für diese Spiele bereitzustellen.

Ich gedenke, das Image noch weiter anzureichern mit lizenztechnisch unproblematischen Dingen – GCC, Template-Editoren, Zap und StrongEd, DrawPlus, Ovation, Impression Style (vor kurzem kostenlos freigegeben), Pipedream sowie ein paar der essentiellen Tools, an die ich mich schon gar nicht mehr erinnere – da muss ich mal wieder den FTP-Server der Uni Stuttgart konsultieren sowie mein altes A3000-Image. Der Test von ADFFS steht noch aus, jetzt wo nicht mehr ADFS-Floppy das einzige unterstützte Medium ist gibt es da durchaus Hoffnung, und das würde bezüglich der möglichen Retro-Experience die Sache stark vereinfachen.

Für die Detaildiskussion kann man alles im Atari-Forum (quasi das offizielle MIST-Forum, weil das MIST bekanntlich mit dem Atari-ST-Core geboren wurde) nachlesen. Hier der Link zum GitHub-Repo des Archimedes-Core.

Natürlich gibt es weiterhin viele zusätzliche Wünsche an den Core – schnellere CPU (der verwendete Amber-ARM-Core hat eigentlich einen Cache a la ARM3 intus, aufgrund von Zuverlässigkeitsproblemen ist der aber derzeit deaktiviert), Quad-MEMC-Emulation für bis zu 16 MiB RAM, Anbindung des MIST-Scandoublers um auch auf VGA-Monitoren die 15 kHz-Modes ohne Letterboxing und RAM-bandbreitenfressende Bildwiederholrate verwenden zu können, und natürlich das Schreiben der CMOS-Values. Direkte Unterstützung der zwei anderen Disketten-Image-Formaten APD und JFD wäre super. FPA10-Emulation wäre wohl eher aus der Kategorie „weil man es kann“, bekanntlich konnte man Floating-Point-intensive Software mit der Lupe suchen. Endgültig Kür wäre dann Netzwerkunterstützung, das wäre dann aber eher der Bereich des MISTer, für den der aktuelle Core aber noch nicht portiert wurde. Und wie wäre es mit Econet?

RPCEmu 0.9.2 ist da – mit vereinfachter Netzwerkunterstützung!

2019-10-27 22:46

Gestern wurde die neue Version von RPCEmu veröffentlicht, namentlich 0.9.2. Aus meiner Sicht als Windows-Benutzer ein riesiger Fortschritt.

Wie schon in meinem Artikel zu Version 0.9.1 angekündigt und sehnlichst erhofft, ist die Hauptneuigkeit ein Modus zur vereinfachten Netzwerkanbindung zur Host-Maschine. Bisher war das – zumindest unter Windows – eine sehr komplexe bis fehlerträchtige Angelegenheit, wo man von Hand nach der Installation einer bestimmten Version von OpenVPN (bzw. dessen TAP-Treiber) eine Netzwerk-Bridge im Windows anlegen musste. Die dann manchmal verschwand, manchmal auch das restliche Netzwerken von Windows beeinflusste, und generell sehr unpopulär war. Unter Linux war das Tunneling, das eigentlich einfacher sein sollte, seit neuestem faktisch unmöglich weil die Root-Elevation nicht mehr korrekt mit Qt funktionierte. Ein sehr unbefriedigender Zustand.

Jetzt ist alles neu und besser und hört auf den Namen „NAT networking“. Noch immer nicht ganz so problemlos und elegant integriert wie bei V-RPC, aber deutlich einfacher als vorher. Aber ein wichtiger Hinweis: man sollte nicht „wie gewohnt“ das RISC OS-Netzwerk konfigurieren (wie ich es zunächst erfolglos versucht habe), da es sich tatsächlich um echte NAT handelt – intern bekommt das emulierte RISC OS also eine eigene IP-Adresse, die immer 10.10.10.10 ist, und RPCEmu faked drumrum einen Router (10.10.10.2) und einen DNS-Server (10.10.10.3) dazu, und die Host-Maschine bekommt im Prinzip nichts davon mit. Also unbedingt die (sehr gute) Anleitung lesen. Hat man ein RISC OS, das DHCP unterstützt (also RISC OS 4.29 aka „Select 1“ aufwärts), ist es wirklich sehr einfach.

Wichtige Einschränkungen: ping funktioniert nicht, ShareFS funktioniert nicht (weil nicht auf routebarem IP basierend), und die RISC OS-Maschine ist von außerhalb z.B. als Server nicht ansprechbar, weil kein Port-Forwarding implementiert ist. Die Abwesenheit von ShareFS ist natürlich bitter, weil oft die mit Abstand einfachste Möglichkeit, zwischen RISC OS-Rechnern Dateien zu sharen. Aber es braucht ja noch Luft für die 0.9.3.

Eine kleine Verbesserung wartet im Bereich „Diskettenlaufwerk“ – hier kann jetzt neben dem bekannten .adf auch .img, also gewöhnliche DOS-Images, als virtuelles Diskettenlaufwerk gemountet werden.

Ein kleiner Wermutstropfen ist die Tatsache, dass aufgrund der verwendeten neuen Qt-Version nun nur noch Windows ab Version 7 aufwärts offiziell unterstützt wird. Für Retro-Zwecke leicht suboptimal, weil die PCs, die noch eine „echte“ Floppy intus haben (und damit Filecore-formatierte Disketten vernünftig ansprechen können), oft unter Windows XP laufen. Aber es gibt ja Alternativen (wenn schon Retro, dann Arculator oder VA5000).

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…

DoReCo Party #11 – Ein Rückblick

2019-09-21 20:34

Vergangenes Wochenende fand – unter überraschend großer Beteiligung diverser RISC OS-Nutzer – die DoReCo-Party #11 statt. Drei Tage Retro-Spaß, Freitag bis Sonntag. Mit Aufbau Freitag und Abbau Sonntag, also Samstag als Hauptkampftag. Und mitten im Nirgendwo mit dem schönen Ortsnamen „Anröchte-Altenmellrich“ in der dortigen Schützenhalle. Es waren also keine externen Ablenkungen zu befürchten.

Michael Hönsch hatte die ehrenvolle Idee, das schon länger ins Auge gefasste RISC OS-Bundestreffen (mit allen noch aktiven RISC OS-Nutzern in Deutschland, also einer hohen einstelligen Zahl) dort abzuhalten – quasi die Party in der Party – und übernahm die organisatorischen Details wie Tische und Reservierung, und Herbert zur Nedden schlug vor das gleich mit dem GAG-Treffen 2019 in einen Topf zu werfen. Und so geschah es.

Typischerweise standen in der Vergangenheit die GAG-Treffen mehr im Zeichen neuer Hard- und Software und der jeweils aktuellsten Version von RISC OS. Diesmal hatte ich mir vorgenommen, passend zum Retro-Thema unserer Gastgeber (ähnlich wie damals bei der Classic Computing 2016 zu Nordhorn), eher eine Mischung aus alten und neuen Geräten an den Start zu bringen. Am Ende war es ein A5000, der per 10b2-Ethernet über Access mit einem Raspberry Pi B+ (RISC OS 5.26) und einem Core i3-Windows 7-Netbook (V-RPC Adjust, also RISC OS 4.39) redete. Dazu noch ein MISTer mit dem Archimedes-Core, der „Zarch“ als Daueraufgabe bekam. Dazu zwei Monitore, und schon war der Tisch voll.

Thomas war mit an Bord mit KlappPi (einem Laptop-Eigenbau auf Raspberry Pi-Basis), BiKo (BeagleBoard im Koffer, akkubetrieben) und einer RiscStation R7500 mit der seltenen ISA-USB-Karte. Also im Prinzip drei Einzelstücke. Und Michael hatte aus dem Bereich „aktuelle RISC OS 5-Systeme“ seinen ARMX6 dabei, nach wie vor eines der besten und ausgewogensten Geräte aus der neuen RISC OS-Rechner-Generation.

Einige aktuelle und ehemalige RISC OS-Benutzer kamen ebenfalls zu Besuch. Vor allem der Risc PC ist vielen noch in guter Erinnerung. Impression, TechWriter und Artworks kennen und lieben die meisten, dazu die nostalgische Verklärtheit bei der Erwähnung der PC-Karten-Lösung. Alle sind sich immer noch einig, dass RISC OS – bei all den bekannten Schwächen – was die grafische Oberfläche angeht nach wie vor der Benchmark ist. Mit Thomas L., den ich aus dem VzEkC-Acorn-Forum kannte, unterhielt ich mich wirklich lange über unsere diverse RISC OS-Hardware und die Zicken, die die alte Hardware ab und an macht.

Die erste Aufgabe: Mark (mit dem ich vorab schon Mailkontakt hatte wegen einer Acorn-Maus), ein Stammgast auf der DoReCo-Party, hatte seinen A3010 mitgebracht und wollte ein Parallelport-ZIP-Laufwerk (100 MB) anschließen. Mit Bootdiskette und so. Also eine Übung in Datentransfer zwischen alten und neuen Systemen mit erhöhtem Schwierigkeitsgrad, denn mein A5000 hat unglücklicherweise einen Batterieschaden der den internen Floppy- und IDE-Controller bzw. die Buchsen und/oder was drumrum gekillt hat, und so war der direkte Weg – schreiben einer Diskette – verbaut. Zusätzliche Hürde: der A3010 hatte nur 2 MiB RAM, womit viele Ideen, die die RAM-Disc als Zwischenspeicher nutzen, direkt flach fallen. Der Plan: einen Weg austüfteln, um aus dem Internet heruntergeladene .adf- und .apd- und .jfd-Floppy-Images auf dem A3010 lauffähig zu bekommen. Nicht trivial, weil die RAM-Knappheit die Nutzung des offensichtlichen Wegs – auf einem PC auf ein DOS-ZIP-Medium die Disc-Images zu packen und dann auf dem A3010 mittels ADFFS zur Verfügung zu stellen – leider verunmöglichte. Da musste ich erst mal drüber schlafen. Inzwischen habe ich mehrere Varianten ausgetüftelt, die allerdings eher komplex erscheinen – ich werde demnächst einen eigenen Artikel dazu veröffentlichen. An alle anderen der Ratschlag: alte RISC OS-Rechner außer in Sonderfällen immer gleich mit 4 MiB RAM kaufen. Das erspart eine Menge Probleme, selbst wenn man auf den ersten Blick „nur spielen“ will.

Zwischenzeitlich diskutierte ich mit dem Eigner über seine eigentliche Leidenschaft, den guten alten Commodore Plus/4, der es seinerzeit bekanntlich gegen den C64 nicht geschafft hat, sich aber in Retro-Kreisen steigender Beliebtheit erfreut (man schaue sich mal das aktuelle Spiel „Alpharay“ an, ein R-Type-artiger Shooter – sehr beeindruckend). Überraschend, an wie viele Details von früher ich mich erinnerte, ohne jemals einen C16 oder C116 oder Plus/4 besessen zu haben – von den 121 Farben über den TED, BASIC V3.5 bis zur 1551. Und natürlich die nur zu sich selbst kompatiblen Spezialjoystick-Ports. Ein schrulliges Gerät, mit dem sich Acorn-Fans natürlich eher identifizieren können als mit einem erfolgreichen Produkt wie dem C64.

Beim A3010 zeigte sich auch ein momentan nicht erklärbares Phänomen: das von RetroBargains aktuell verkaufte Busmaus-USB-Adapterchen („ArcMouse“ – man beachte: die daran angeschlossene USB-Maus muss einen PS/2-Modus besitzen!) verweigerte seinen Dienst am A3010, funktionierte aber ganz prima an meinem A5000 bzw. dessen Tastatur. Sehr dubios. Kurz entschlossen tauschte ich einen meiner PS2MouseMini-Adapter inklusive klassischer Logitech-3-Tasten-ohne-Mausrad-Maus gegen den ArcMouse-Adapter nebst optischer Microsoft-USB-Maus. So kann ich demnächst mal prüfen, was dieser Adapter an anderen Gerätschaften wie einer Ur-A310-Tastatur, einem A3000 oder einem Risc PC macht. Es wäre mir nicht bekannt, dass es bei den Mäusen in irgendeiner Weise Inkompatibilitäten zwischen den verschiedenen Acorn-Rechnern gab.

Das andere Problem mit diesem A3010: zuerst war er über den HF-Ausgang mit dem Monitor verbunden, der gleichzeitig einen TV-Tuner hatte. Aber die so erzielbare Qualität ist natürlich unterirdisch. Über dessen VGA-Eingang gab es aber nix zu sehen. Dubios. Mit meinem BenQ-TFT vom A5000 funktionierte hingegen der A3010 wunderprächtig, der Videoausgang war also einwandfrei. Es stellte sich heraus: es lag am Kabel. Tausch des VGA-Kabels, und auch der Monitor des Besitzers funktionierte.

Die zweite Aufgabe: ein etwas indisponierter Risc PC, den einer der anderen Teilnehmer (Tom Phobos) mitgebracht hatte und der beim Hochfahren nur die berühmte Diskette anzeigte (für Uneingeweihte: man muss dann eine Boot-Diskette mit dem konfigurierten Territory einlegen, damit es weiter geht) – typisches Anzeichen für entweder kaputtes CMOS oder kaputtes Bootmedium. Kurze Inspektion – das Board war in sehr gutem Zustand, der Akku wurde rechtzeitig entfernt und durch einen separaten AAA-Batteriehalter ersetzt. Zwei Podules waren drin, ein MCS Connect32 SCSI-Controller und ein Simtec/STD Unipod. Eine klassische Ein-Slice-Maschine mit dem schwächeren Netzteil (70W). Als 5,25″-Laufwerk war ein SCSI-CD-Brenner eingebaut. Einen CMOS-Reset später, und die Kiste bootete sauber durch, allerdings mit mehreren Disc Error 21-Meldungen, was typischerweise auf eine Festplatte in den letzten Zügen hinweist. Es stellte sich dann aber zunächst heraus, dass der Stützakku hinüber war und die CMOS-Werte nicht behalten wurden. Kurz ausgetauscht gegen eine Eneloop Pro aus meinem Bestand – lief. Und dann begann die Jagd nach den rätselhaften Phänomenen. Wo kam der Disc Error 21 her? Erst mal die Maschine runtergestrippt und nur mit der Festplatte selbst betrieben – also ohne Podules und ohne Backplane und ohne Floppy. Ergebnis: lief einwandfrei, keine Fehler mehr. Aha. Also erstmal optimistisch wieder alles zusammengebaut, und der Fehler war wieder da. Hmmm. CD-Brenner abgeklemmt und den Connect32 rausgeworfen: Fehler ist weg. Hmmmmmm. Also mit dem Besitzer geredet und den Plan gefasst: wenn schon ein IDE-Unipod drinsteckt, und ansonsten keine SCSI-Geräte gebraucht werden, am besten ein IDE-CD-ROM einbauen. Ein paar Minuten später lagen zwei zur Auswahl auf dem Tisch, ich entschied mich für das mit dem niedrigeren Stromverbrauch – denn das schwächere Risc PC-Netzteil bringt auf der 12V-Schiene nur 2,05A, dann sind Laufwerke die da mal locker 2A ziehen nicht zu gebrauchen. Durch eine großzügige Spende eines nichtessentiellen IDE-Kabels aus meinem A5000 das Laufwerk an das Unipod angeschlossen und…Disc Error 21. Sollte es doch am Netzteil liegen? Schnell das IDE-CD-ROM mit einem externen Netzteil versorgt (und dabei festgestellt, dass der Mechanismus der Laufwerkschublade zu allem Überfluss auch nicht mehr funktionierte) und…immer noch Disc Error 21. So langsam wurde es rätselhaft. Das IDE-CD-ROM vom Flachbandkabel entfernt – immer noch Disc Error 21. Das Flachbandkabel aus dem Unipod gezogen – jetzt lief es wieder. Was??? Gegenprobe mit dem Connect32. SCSI-Kabel steckt drin -> Disc Error 21. SCSI-Kabel steckt nicht drin -> alles lief. Nun gut. Manche Phänomene muss man wohl einfach hinnehmen. Ich habe keine Vorstellung, was hier der Grund sein könnte, schließlich hing die IDE-Platte mit den Fehlern ja im internen IDE – vielleicht hätte ein Wünschelrutengänger bei der Analyse helfen können? Wie dem auch sei, der Besitzer war leidlich glücklich mit der neuen Situation – ein einwandfrei laufender Risc PC, aber eben ohne CD-Laufwerk. Man kann sich Schlechteres vorstellen. Übrigens hatte dieser Risc PC ein äußerst seltsames VRAM intus, das ich so noch nicht gesehen habe – 2 MiB, und irgendwie „asymmetrisch“ gebaut. Die linke Platinenhälfte war niedriger als die rechte, die Chips links waren waagrecht angeordnet und die Chips rechts senkrecht. Keine Ahnung, was für ein Spezialteil das war.

Am Samstag gab es einige Vorträge zu diversen Retro-Themen. Besonders interessant fand ich einen Vortrag von Slamy, der über seine Entwicklung eines Spiels namens „Tiny Little Slug“ für den Amiga berichtete. Ein Jump’n’Run im weitesten Sinne (Held der Geschichte ist eine Schnecke, was mit „Springen“ und „Rennen“ nun normalerweise nicht direkt in Verbindung gebracht wird – hier mehr Infos zum Spiel), für einen Amiga 500 in der Basisausstattung. Was bedeutet: mehr als 512 KiB RAM stehen nicht zur Verfügung. Eine echte Herausforderung, zumal das Spiel komplett in C bzw. C++ per Crosscompile mit GCC unter x86-Linux entstehen sollte. Was mich später zu einem längeren Gespräch mit Slamy veranlasste, der allerlei interessante Details zu GCC, dem 68k-Backend, Bare-Metal-NDOS-Entwicklung, AmigaOS, MorphOS und einer Toolchain-Automatisierung namens Yocto zu erzählen wusste. Kurze Abschweifungen inklusive – zu USB-Floppycontrollern, CAN-Bus, FlexRay, ARM-Core-Varianten, aktuelle Entwicklungen in der Welt von C++, Ada und GNAT…sehr erfrischend und spannend. Mit vielen interessanten Einblicken vor allem in die Welt des Amiga, wo die „backward compatibility breaking changes“ noch häufiger als unter RISC OS stattgefunden haben.

Ein C64-Fan stellte mir den aktuellen Stand der Dinge an dieser Front vor. Entsprechende Peripherie vorausgesetzt, kann man sich inzwischen über WLAN in Internet-Mailboxen „einwählen“. Auf dem C64 eine besondere Herausforderung, weil die Bildschirmauflösung für eine anständige 80-Zeichen-pro-Zeile-Darstellung nicht ausreicht. Jedenfalls gibt es hier eine aktive Retro-BBS-Szene, da lohnt sich mal ein genauerer Blick drauf. Ich habe ja eine FidoNet- und Mailbox-Vergangenheit, vielleicht mal den Kollegen Stefan Brück fragen, ob er noch ein Backup der ArcPool-Mailbox (damals in Wolfsburg beheimatet) hat. In der RISC OS-Welt ist meines Wissens die Arcade BBS die einzige Überlebende der glorreichen Mailbox-Zeit.

Interessant auch ein Acorn BBC Model B, den mir Markus (Fragg) zeigte, der am Tube-Port einen Raspberry Pi mit dem Pi-Tube-Kit (auch als „co-processor tube hat adapter“ bekannt) von RetroClinic hängen hatte. Damit kann man alle damals erhältlichen Zweitprozessoren emulieren, vom Z80 über den 80286 bis zum original ARM-Entwicklungssystem. Und als Sonderbonus der direkte Zugriff auf den native ARM des Raspberry Pi. Was man damit anfangen kann? Keine Ahnung, aber cool, dass es geht! Die gängige Demo-Software dafür ist die Executive-Version von Elite, die den Turbo-6502-Coprozessor nutzt. Ansonsten ist die Softwareunterstützung dieser Wunderwerke eher sparsam. Die für Archimedes-Archäologen hochinteressanten verschiedenen Zwischenstände der Arthur- und ARX-Entwicklung aus der ARM-Frühzeit sind meines Wissens für immer verloren.

Und sonst? Das zentrale Event war die Versteigerung diverser Gerätschaften und anderen Retro-Dingen für den guten Zweck, einem Kinder-Hospiz. Großartige Gegenstände, inspirierend angepriesen von Hellcat. Den höchsten Einzelpreis erzielte nach meiner Erinnerung die handsignierte Debüt-CD von Chris Hülsbeck. Sehr cool fand ich ein Space-Invader-Mosaik aus 3,5″-Disketten. Großen Zuspruch fand auch ein holzfurniertes C64-Gehäuse, das ein Vereinsmitglied gebastelt hatte. Und zwischendurch beispielsweise der limitierte, goldene USB-Competition-Pro-Joystick oder auch das Spiel Top Gun auf Kassette für den C64. Das blieb im Gedächtnis. Zwei optische Highlights unter den Ausstellungsstücken will ich auch noch erwähnen: eine handgestrickte Abdeckung für den C64 (hier neben anderen Fotos auf Seite 3 zu finden) und ein beleuchteter Sinclair Spectrum in Transparenz-Optik, wobei die Beleuchtung das Spectrum-Regenbogenlogo simulierte (vermutlich dieses Gehäuse). Sehr cool. Die Kreativität im Retro-Bereich ist unverändert hoch.

Die gesamte Atmosphäre der Veranstaltung fand ich sehr angenehm, auch wenn in meinem fortgeschrittenen Alter die ständige Hintergrundbedröhnung durch Musik und den Versteigerungsevent etwas verstärkten Einsatz der Stimmbänder und höchste Konzentration beim Zuhören erforderte. Allerdings muss ich sagen, dass die Playlist wirklich exzellent zusammengestellt war, so dass nicht die Musik selbst störend war, sondern nur ab und an die Lautstärke. Mein Kompliment. Auch hinsichtlich der Organisation der Veranstaltung gibt es nichts zu mosern.

Außerdem stelle ich fest, dass ich es sehr genieße, mal in einer Zusammenkunft vieler Menschen NICHT der exotische Nerd zu sein. Sondern einer unter vielen. Wo findet man schon 100 oder mehr Leute auf einem Haufen, die bei der Ankündigung der Versteigerung einer Chris-Hülsbeck-CD nicht erstmal fragen „Häh? Wer soll das denn sein?“ Mir kam die legendäre Szene aus dem Film „Voll normaaal“ mit Tom Gerhardt in den Sinn: „Endlich normale Leute“.

Jedenfalls ist die DoReCo-Party auf der Liste der Events, bei denen man dabei sein sollte. Leider gibt es da reichlich Konkurrenz: das klassische GAG-Treffen, die Classic Computing, das Xzentrix…und es gibt eben viele konkurrierende Hobbys. Mal sehen, was 2020 ansteht.

Neue Testversion von Aemulor verfügbar

2019-09-08 18:27

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

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

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

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

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

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

Aktuelle Retro-Projekte

2019-08-24 17:45

Nachdem ich einige alte Acorn-Rechner aus der RISC OS-Frühzeit mein Eigen nenne – vom A310 über den A3000 bis zum A5000 – interessiere ich mich auch für aktuelle Projekte rund um die Retro-Schätzchen. Vor allem die Verbindung der alten Welt mit aktueller Hardware interessiert mich immer – ich bin weniger der Typ für „100% Retro“, sondern will einfach rund laufende Hardware betreiben – ob es Ende der 80er schon Flash-Speicher oder optische Mäuse gab, ist mir eigentlich wurscht, zumal die Originalhardware inzwischen empfindlich teuer ist. Zentrale Informationsstelle ist für solche Projekte das Stardot-Forum Abteilung 32bit. Ich will einige davon kurz vorstellen.

Wie bekannt sein dürfte, ist das Thema „Massenspeicher“ ein ständiges Ärgernis. Frühe Rechner wie der A310 oder der A3000 und auch der weit verbreitete A3010 hatten weder das damals noch verbreitete MFM/ST506 an Bord (das gab’s nur in der A4xx-Familie) noch das brandneue IDE und auch nicht die damals gängige Profi-Variante SCSI. Und die späteren Rechner mit IDE on board bis inklusive RiscPC und A7000(+) scheitern häufig an mangelhafter Kompatibilität mit heute wünschenswerten Lösungen wie SD-Cards im IDE-Adapter. Also braucht man ein IDE- oder SCSI-(Mini-)Podule. Nun sind die aber gebraucht eher rar und teuer, und im Falle von SCSI wird es durch das dann sinnvollerweise benötigte SCSI2SD noch teurer.

IanS aus dem Stardot-Forum hat deshalb ein einfaches IDE-Interface gebaut (nach dem Vorbild der alten ICS-ideA-Podules von Ian Copestake) und bietet regelmäßig sowohl Standard-Podules (alle A-Rechner außer A3010, A3020 und A4000) als auch Mini-Podules (A3000, A3010, A3020, A4000) oft inklusive IDE-Flash-Modul an. Als Software kommt John Kortinks ZIDEFS zum Einsatz, das insgesamt bezüglich Laufwerkskompatibilität und Features einen guten Ruf hat. CJE Micro’s bietet die Dinger auch an, allerdings zu den üblichen Mondpreisen.

In die gleiche Kerbe schlägt das Projekt von Dave Hitchins (daveejhitchins im Stardot-Forum), der die alten IDE-Podules von Baildon Electronics (Dave Prosser und Dave Hitchins, verkauft als Arcin und Blitz von APDL sowie als Awesome von MicroDigital) erneut in Kleinserie bauen (lassen) will. „Baildon Electronics IDE Interfaces – Replication“ heißt der Thread auf Stardot zum 16bit-Podule (Arcin), und hier der Nachfolgethread zum Arcin32/Blitz/Awesome. Beide Projekte scheinen kurz vor der Fertigstellung zu sein.

Ein ambitioniertes Projekt von Stardot-User myelin hört auf den Namen „Arcflash“ – hier der Thread, hier die Hardware und Software auf GitHub. Dahinter verbirgt sich eine Flash-ROM-Lösung für alle Acorn-Rechner vom A310 bis zum Risc PC. Was sich einfacher anhört als es ist, weil die Konfiguration und Position der ROM-Chips eher uneinheitlich sind – zwei oder vier Chips, unterschiedliche Sockelabstände – schwer, da eine universelle Lösung zu finden. Außerdem soll es ja „in situ“ neu flashbar sein, und man will einen eigenen Bootloader haben, um beim Booten auswählen zu können, welche RISC OS-Variante man denn haben will. Bisheriger Stand: das Flashen soll über USB funktionieren, 16 MiB Flash-ROM sollen aufs Board, und der Bootloader ist wohl auch schon recht weit fortgeschritten. Zusätzlich wird experimentiert, welche Acorn-Rechner (außer Risc PC und A7000, die das von Haus aus beherrschen) mit 4 MiB ROM statt den üblichen 2 MiB umgehen können, ggf. mit einem kleinen „Patch“ des Mainboards. Das Projekt scheint kurz vor der Fertigstellung zu sein.

Sowohl für RiscPC/A7000 als auch für die alten Archimedes-Kisten ist Arcflash hochinteressant. Ironischerweise hilft es auch gegen das Massenspeicherproblem, weil damit sehr einfach ein gepatchtes ADFS ins ROM könnte, das die Kompatibilität zu IDE-Geräten drastisch verbessert. Und bei den alten Rechnern kann man problemlos zwischen Arthur, RISC OS 2 und RISC OS 3.1 umschalten, sowie gegebenenfalls ein aktualisiertes RISC OS 3.2 bauen mit Wünsch-Dir-Was-Komponenten wie Nested WIMP, Toolbox-Modulen und TCPIP-Stack nebst Netzwerkkartentreiber – alles das, was beim Softload auf den Rechnern mit typischerweise maximal 4 MiB RAM richtig schmerzt. Allerdings ist es traditionell eher schwierig, ein funktionierendes ROM-Image zu bauen, umso wichtiger wäre eine Hardware, die in den eher empfindlichen Sockeln verbleiben kann während man am Entwickeln ist.

Und noch ein Projekt: eins der üblichen Probleme für alle Rechner vor dem A7000 ist das Mausproblem, vor dem Risc PC auch das Maus- und Tastaturproblem. Denn vor PS/2 gab es Acorn-proprietär (Tastatur) und Busmaus (eher selten im Rest der IT-Welt). Wäre es nicht super, wenn man – ohne absurde Mengen Geld in ein USB-Podule zu stecken oder einen der seltenen und teuren PS/2-Adapter zu ergattern – einfach so eine x-beliebige USB-Maus anschließen könnte? Genau das will Stardot-User cmj6502 per Podule lösen. Scheint aber eher noch in einem frühen Stadium zu stecken – Hardware steht, aber die Software noch nicht.

Zuletzt noch ein interessantes Projekt für die Hardware-Reparier-Front: zu Acorn-Zeiten gab es ein wirklich seltenes Stück Hardware namens „POST box“. Standardmäßig haben die Acorn-Rechner einen Selbsttest, und wenn der fehlschlägt, blinkt die Floppy-Lampe ein Binärmuster um den Zustand dieses Selbsttests zu signalisieren. Es werden aber viel mehr Informationen während des Selbsttests vor dem eigentlichen Bootprozess generiert, und eben diese sind über den POST-Port verfügbar. Es sind Bemühungen im Gange, diese POST Box nun nachzubauen auf Basis eines kleinen preiswerten Microcontroller-Boards. Hier das zugehörige Projekt auf GitHub.

Wie man sieht: die Retro-Szene ist auch im RISC OS-Bereich aktiver denn je. Es bleibt spannend.