August 2019

You are browsing the site archives by month.

Aktuelle Retro-Projekte

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.

Der RISC OS-Quellcode lebt jetzt in Git

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

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

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

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

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