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?

Classic Computing 2016 (3) – Das MIST-Board

2016-09-14 16:53

Der zweite Kandidat unter der Hardware, die ich bei der Classic Computing 2016 zeigen will, ist das MIST-Board, manchmal auch “MIST FPGA computer” genannt oder einfach schlicht MIST (was im Deutschen natürlich kontextabhängiges Verstehen erfordert). Ich hatte schon früher darüber berichtet.

In aller Kürze: das MIST ist ein FPGA-basierter Computer. Ein FPGA ist ein reprogrammierbarer Chip. Für das MIST gibt es eine ganze Menge sogenannter Cores, die den FPGA so programmieren, dass er sich (mehr oder weniger) genau wie diverse Retro-Hardware verhält. Computer-Beispiele: Acorn Archimedes, Commodore Amiga, Atari ST, Commodore 64, Schneider CPC, Sinclair ZX Spectrum, Apple II+, Commodore 16, Acorn BBC Model B, Apple Macintosh, MSX, Sam Coupe, Sinclair QL. Spielkonsolenbeispiele: Atari VCS 2600, Sega Master System, Nintendo Entertainment System, NEC PC Engine, CBS ColecoVision. Hardwareseitig wird das unterstützt durch zwei Joystickports für die guten alten digitalen Joysticks mit 9-poligem Anschluss (früher auch als “Atari-kompatibel” bekannt), zudem kann man Maus und Tastatur (und auch Joysticks oder Joypads) per USB anschließen. Unterm Strich: Es steckt viel Spaß im MIST.

Für die CC2016 steht natürlich der Archimedes-Core im Mittelpunkt – wir sind schließlich die GAG, die German Archimedes Group, da ist der Name Programm. Ich habe eine SD-Karte mit RISC OS 3.11 vorbereitet mit ein paar echten Spieleklassikern. Dazu gibt es natürlich die beiden unvermeidlichen Competition Pro-Joysticks, auch wenn die Auswahl an Spielen, die sowohl auf dem MIST funktionieren als auch das vom MIST emulierte Acorn-Joystickinterface unterstützen sehr begrenzt ist. Als Bildschirm habe ich einen alten 20″-LCD dabei im klassischen 4:3-Format, der bis 50 Hz problemlos synchronisieren kann – ein Muss für den MIST-Betrieb.

Der Archimedes-Core ist insofern eine Besonderheit, dass er der einzige 32bit-Vertreter auf dem MIST ist. Der Core funktioniert für viele Dinge zwar schon prächtig, ist offiziell aber noch im Beta-Status. Am meisten vermisse ich die Harddisc-Emulation, so dass man ausschließlich mit Diskettenimages arbeiten muss – und hier wird leider nur das ADF-Format unterstützt, und es werden nur Images akzeptiert die genau 800KiB groß sind. Sehr pingelig. Es war eine Herausforderung, die problemlos lauffähigen Spiele herauszufiltern. Leider ist es mir nicht gelungen, im Verbund mit ADFFS kopiergeschützte Original-Images zum Laufen zu kriegen – irgendwie vertragen sich ADFFS und der Archimedes-Core nicht so recht.

Im Moment bin ich bei folgender Spieleauswahl angelangt, die nach kurzem Testspielen einwandfrei zu funktionieren scheinen:

Aldebaran
Chocks Away
Conqueror
E-Type
Elite
Oh No! More Lemmings
Pac-Mania
Populous
Zarch

Wer sich ein MIST kaufen will: der Dragonbox-Shop (bekannt durch Pandora, Pyra etc.) ist eine deutsche Bezugsquelle. Wer Doku und Sourcen inspizieren will, hat auf Github die Chance, denn das Projekt ist komplett Open Source – sowohl die Software als auch die Hardware. Ein deutschsprachiges Forum gibt es auch. Sogar mit eigenem Unterforum für den Archimedes-Core.

MiST-Board Archimedes-Core Schnelltest

2016-01-21 03:36

Seit einiger Zeit bin ich stolzer Besitzer des MiST-Boards (im alten Blog-Post kann man auch nachlesen, was es mit diesen FPGAs so auf sich hat). Vorrangiger Zweck ist die Befriedigung nostalgischer Sehnsüchte – Bomb Jack, Commando, Ikari Warriors und Barbarian auf dem Schneider CPC, IO und Armalyte auf dem Commodore 64. Dazu auch Ausflüge auf die 16bitter, die ich nie selbst besaß (Atari ST, Commodore Amiga). Da werden die Competition Pros angestöpselt und los geht’s.

Und weil auf dem MiST-Board eine Menge Exoten vertreten sind, gibt es auch einen Core für den Exoten schlechthin: den Acorn Archimedes, Urvater aller ARM- und RISC OS-Rechner. Ich hatte schon kurz darüber berichtet. Passend zum Exoten-Status ist es auch gar nicht so einfach, den Core erfolgreich ans Fliegen zu bekommen. Unter all den Cores, die ich ausprobiert habe (und das waren fast alle), ist es sogar am Schwierigsten, obwohl ich RISC OS-technisch auch was die alten Kisten angeht schon einen reichhaltigen Erfahrungsschatz habe.

Ein Problem: bootet man das MiST mit einem anderen Core und wechselt dann zum Archimedes-Core, funktioniert nach meiner Erfahrung gar nix. Es startet nicht. Man benötigt definitiv eine eigene SD-Karte mit dem Archimedes-Core als Default, und man muss manchmal das MiST-Board resetten damit der Archimedes-Core startet. Der Thread zum Archimedes-Core im Atari-Forum ist leider eingeschlafen, was nichts gutes heißt für die Weiterentwicklung. Ab und zu scheint das Video-Setup auch nicht korrekt zu sein und der Bildschirm flimmert unerträglich. Ein Shift+Ctrl+Break-Reset (warum der nur mit Shift geht? Keine Ahnung…) bringt das normalerweise wieder ins Lot. Also versuchen wir mal mit dem zu leben, was wir heute haben.

Was könnten die Gründe sein, überhaupt den Archimedes-Core betreiben zu wollen? Na klar, die klassischen Games wieder zu zocken. Anwendungssoftware ist etwas schwerer vorstellbar, da die Emulation einer Festplatte leider noch fehlt, und mit zwei Floppies wird es doch eher mühsam. Nicht unmöglich (ich habe einige Zeit mit einem A3000 mit nur einer Floppy gearbeitet – man muss halt gut organisiert sein, was die Disketten angeht, und bootet am besten so, dass die üblichen Module direkt im RAM landen, sonst wird die Diskette mit !System und !Fonts der beste Freund des Disc-Jockeys), aber mühsam. Wobei diese Erinnerung hauptsächlich durch RISC OS 2 geprägt ist, wo quasi jede Anwendung zusätzlich die SharedCLibrary laden musste nebst ColourTrans und FPEmulator. Und die Fonts waren natürlich auch disc-based. Das wurde mit RISC OS 3 Gott sei Dank anders, wo man allein mit den ROM-Inhalten schon relativ weit kam.

Also: Schwerpunkt Spiele. Aber auch bei Spielen braucht man natürlich das Betriebssystem, und das ist die erste Hürde. Ähnlich wie beim Amiga ist auch RISC OS – selbst in den ältesten Versionen – nicht für Emulationszwecke lizenzfrei nutzbar. Zwar gibt es Downloadquellen, aber wir wollen uns ja nicht außerhalb der Legalität bewegen. Gott sei Dank muss man nicht einen der alten, seltenen Acorn-Rechner kaufen und das ROM rippen, sondern kann direkt online shoppen bei RISCOS Ltd.. “Classic ROM Collection” heißt das gute Stück und beinhaltet nahezu alles der prä-RISC OS 4-Ära: neben den Urgesteinen Arthur 0.30 und 1.20 (da diskutiert man noch, ob das schon den Namen “Betriebssystem” verdient) und dem Exoten RISC OS 2.01 (die spezielle A540-Version) sind auch die Mainstream-Versionen RISC OS 2, RISC OS 3.10/3.11 und RISC OS 3.70/3.71 am Start. Für diese nahezu vollständige Sammlung – aus deutscher Sicht fehlt leider RISC OS 3.19, die deutsche Version von RISC OS 3.11 – sind die 10 UKP doch gut angelegt.

Und welche OS-Version hätten wir gerne? Die weitestgehende Kompatibilität bietet definitiv RISC OS 3.11. Nur ein paar ganz alte Schätzchen laufen nur unter RISC OS 2, und da fällt mir spontan doch überhaupt kein spielenswerter Kandidat ein. Also RISC OS 3.11.

Fehlt also noch die Software. Wer sich für die damals mitgelieferte Software interessiert, findet im Apps-Ordner die sich im ROM befindlichen Anwendungen wie Draw, Paint, Edit und Alarm. Dazu kann man in die Disketten Apps1, Apps2 und Support reinschnuppern, die als ZIP-Archiv bei der Classic ROM Collection mitgeliefert werden. ZIPs entpacken geht natürlich mit SparkPlug von David Pilling – aber wie auf die MiST-SD-Karte bringen? Zwei Möglichkeiten: entweder per Computer und Emulator auf ein Floppy-Image kopieren, oder ein fertiges Floppy-Image von Wockis Acorn-Site runterladen. Wer sich ernsthaft mit der klassischen RISC OS-Software beschäftigen will, wird nicht drumrumkommen, einen Weg zu etablieren, Downloads aus dem Internet auf Floppy-Images zu transferieren. Wenn ein gewöhnlicher Windows-PC am Start ist, bieten sich RPCEmu, RedSquirrel oder Arculator an. Linux-Freunde nehmen RPCEmu oder ArcEm. Wer in der glücklichen Lage ist, unter RISC OS zu arbeiten, dem ist A310Emu oder ArchiEmu zu empfehlen.

Lange Vorrede, aber wie sieht jetzt das Setup der SD-Karte aus? Simpel: aktuelle MiST-Firmware, Archimedes-Core r1028 als core.rbf und das RISC OS 3.11-ROM als riscos.rom ins Hauptverzeichnis, dazu die gewünschte Auswahl von Disc-Images im Format ADF – es empfiehlt sich hier, die Dateinamen kurz und knackig zu wählen, sonst werden sie im MiST-OSD schnell schwer zu lesen.

Empfehlenswerte Spiele – hier sind nur die “Originale” aufgelistet, keine Umsetzungen von anderen Systemen, es sei denn die RISC OS-Version ist signifikant besser:

Zarch
Conqueror
E-Type
Chocks Away
Elite

Eigentlich empfehlenswert, aber der Core ist derzeit zu langsam:

Star Fighter 3000

Eigentlich empfehlenswert, ich hab’s aber nicht zum Laufen gebracht:

Spheres of Chaos
Cataclysm
Stunt Racer 2000

Gute Online-Quellen für Software – bitte Copyright beachten!

Wocki’s Acorn Emulation Site (direkter Link auf die Download-Seite, die Hauptseite ist gerade indisponiert)
4corn
Qube RiscOS Server
Chris’ Acorn
FTP-Server der Uni Stuttgart
Nitroroms.com – Archimedes-Bereich

MiST-Board mit frühem Archimedes-Core

2015-04-06 00:23

In der Retro-Szene zeichnet sich seit ein paar Jahren ein neuer Trend ab: statt sich mit der uralten Hardware rumzuärgern, die langsam ihrem finalen Verfall entgegenstrebt, oder auf Emulatoren setzt, die es leider oft nicht schaffen das “originale” Gefühl herzustellen sondern irgendwie synthetisch wirken, setzt man auf “echte” Hardware auf FPGA-Basis und baut damit die alten Schätzchen nach.

Meines Wissens die erste breit eingesetzte Variante dieser neuen Spielart war der C-One, der eigentlich einen C64 nachbauen sollte, amüsanterweise aber als erste funktionierende “Personality” einen Amstrad/Schneider CPC-Core bekam. Nicht zuletzt deshalb, weil Original-Entwicklerin Jeri Ellsworth das kommerzielle Projekt C64 DTV (ein Joystick im Competition-Pro-Design, der einen kompletten FPGA-basierten C64-Nachbau enthielt nebst 30 klassischen Spielen und per FBAS direkt an einen gewöhnlichen Fernseher angeschlossen werden konnte) dazwischenschob.

Seit einiger Zeit gibt es nun das MiST-Board mit Zielrichtung eines Nachbaus von Commodore Amiga und Atari ST. Entscheidend: zwei Joystickports der Geschmacksrichtung “9polig Atari-kompatibel” – also die gute alte Microschalter-Digital-Generation, mit der sich die Kinder der 80er die Handgelenke bei Daley Thompson’s Decathlon oder Combat School ruiniert hat – sind mit an Bord. Software wird über eine SD-Karte bereit gestellt.

Und warum nun ein Artikel über das MiST-Board auf einem RISC OS-Blog? Seit kurzer Zeit steht eine früher Version eines Acorn Archimedes-Cores zur Verfügung, der einen 4MB-A3000 simuliert. Noch nicht wirklich ausgereift (keine Floppy-Emulation), aber ein guter Anfang. Hier kann man sich genau informieren.

Für schmale 200€ kann man das MiST-Board in einem recht schmucklosen Stahlblechgehäuse bei Lotharek (bekannt durch den SD-Card-Floppy-Emulator HxC) kaufen. Wenn man sich überlegt, was gebrauchte gut erhaltene Atari STs, Commodore Amigas oder Acorn A3000 kosten, ein echtes Schnäppchen.

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.

Cloverleaf Kickstarter gestartet

2020-11-24 00:22

Viele haben vermutlich schon auf anderen Kanälen vom Cloverleaf Project gehört, initiiert von einem alten Bekannten in der RISC OS-Szene – zumindest für die, die schon zu Archimedes-Zeiten dabei waren: Stefan Fröhling, früher bekannt für die Entwicklung und den Verkauf des ersten IDE-(Mini-)Podules für Archimedes-Rechner vom A3xx/A4xx bis zum A3000 unter dem Namen “Evolution Computer GmbH” aus dem schönen Olpe im Sauerland.

Nun wurde der Cloverleaf Kickstarter gestartet, eine klassische “crowdfunding campaign”, die in der RISC OS-Szene für einige Fragezeichen gesorgt hat. Vermutlich auch deshalb, weil die Kampagne sehr viele Dinge auf einmal versucht zu tun – ich will versuchen, hier ein wenig Kontext zu liefern zur Herangehensweise von Cloverleaf, den Chancen, den Risiken und den Unklarheiten.

Stefan Fröhling war lange Zeit in der Szene nicht aktiv, grob hat er rund 20 Jahre ausgesetzt, zwischen 1998 und 2018, also “Ende Acorn” bis “RISC OS unter Apache-Lizenz freigegeben”. So eine lange Abwesenheit hat Vor- und Nachteile. Auf jeden Fall den Vorteil, nicht allzu viel historischen Ballast mitzubringen und zudem als aktiver Nutzer anderer Computersysteme und Betriebssysteme eine Idee davon zu haben, was heutzutage ein RISC OS-Neueinsteiger von einem Betriebssystem erwartet. Auf jeden Fall ist es aber auch von Nachteil, die diversen Befindlichkeiten innerhalb der RISC OS-Szene nicht so genau zu kennen. RISC OS ist ja tendenziell eher ein Einzelkämpfer-Biotop denn eine Community, die an einem Strang zieht, und die Nutzerschar ist klein, meinungsstark und sehr divers. Divers bezogen auf die Ansprüche – den einen kann die Modernisierung des OS nicht schnell genug gehen, die anderen beschwören die Wichtigkeit der heiligen Rückwärtskompatibilität und des “Anderssein” gegenüber anderen Betriebssystemen. Wer bei Erscheinen des “Style Guide” zu RISC OS 3 damals mitverfolgt hat, wie der Wechsel von Select-Copy-Move zu Cut-Copy-Paste als Paradigma der Blockoperationen heiß diskutiert wurde, wird wissen was ich meine. Oder hat vielleicht jemand noch Lust auf eine wochenlange Diskussion über Vor- und Nachteile von kooperativem Multitasking gegenüber präemptivem Multitasking? Ich bin sicher, auf Google Groups finden sich noch die Threads aus dem Usenet, comp.sys.acorn.* war damals viel frequentiert, lange bevor diese neumodischen “Webforen” auftauchten.

Und da sind wir schon bei einem wichtigen Punkt der Cloverleaf-Idee: Stefan geht aus von den Bedürfnissen eines RISC OS-Neueinsteigers und hat sich überlegt, was denn in und um RISC OS fehlt, um zumindest vom Prinzip her ein OS bereitzustellen, das nicht schon kurz nach dem Erstkontakt als “nice try” wieder in der Schublade verschwindet. Und dass das ein tatsächliches Problem darstellt, sieht man ja am Ausbleiben des dramatischen Nutzeranstiegs nach Verfügbarkeit der Raspberry-Pi-Version von RISC OS. Kostenlos verfügbar für Millionen von RPi-Besitzern und -Nutzern, aber kaum jemand nimmt von RISC OS Notiz.

Und so gibt es (mindestens) vier Zielrichtungen des Cloverleaf-Projektes, die m.E. unglücklicherweise alle in derselben Crowdfunding-Kampagne gelandet sind: 1. Die Weiterentwicklung von RISC OS an den diversen neuralgischen Punkten. Diese sind leider zahlreich: WLAN, IPv6, USB3, Bluetooth, UTF-8, Internationalisierung, Cacheing, Dateisystem (Partitionierung, Fremddateisysteme wie exFat und ext2/3), Multi-Core-Unterstützung und natives Multithreading, Security-Features, Prozessisolation, moderne Fontformate, Unterstützung solch schnöder Hardware wie aktuelle Drucker…die Liste ist endlos. 2. Die Bereitstellung neuer Hardware, auf der RISC OS läuft. Das “Kitten”-System ist noch einfach in Reichweite, ist es doch schlicht ein Raspberry Pi 4 in einem schicken Gehäuse. Bei Puma, Laptop und All-in-one-System sieht es aber schon anders aus: auf Basis eines Rockchip-SoCs, dazu noch mit Mali-GPU, das ist um zwei bis drei Größenordnungen anspruchsvoller. 3. Die Bereitstellung von Software, damit zumindest für den “normalen” Benutzer keine allzu großen Lücken bestehen in dem, was man so täglich nutzt. Und das beginnt beim modernen Browser und hört bei der Office-Suite und einer Bildverarbeitungssoftware noch lange nicht auf. Selbst in Bereichen, wo RISC OS Mitte bis Ende der 90er noch recht gut aufgestellt war – Musik, E-Mail, DTP – gibt es heute entsetzliche Lücken. 4. Die Bereitstellung einer “Cloverleaf RISC OS-Distribution” für alle RISC OS-Systeme vom Emulator (RPCEmu) bis zum Raspberry Pi.

Die ganze Kickstarter-Beschreibung liest sich wie ein Wunschzettel, der herauskommt, wenn man 100 RISC OS-Benutzer fragt, was ihres Erachtens das größte Problem der Plattform ist. Die Kickstarter-Kampagne läuft damit Gefahr, es allen recht machen zu wollen. Kein Fokus. All things for all people. Keine klare Message, keine klaren Ziele.

Es soll das niemand falsch verstehen. Alle diese Ziele sind valide. Sie werden gebraucht. Sie müssen umgesetzt werden. RISC OS hat eine Menge aufzuholen gegenüber anderen Betriebssystemen, und die genannten Dinge sind nur ein Anfang. Aber die Frage ist: kann man eine solche Diversität an Zielen sinnvoll und klar kommunizieren? Das Feedback sagt m.E. eher: nein, es ist zu komplex, es ist zu erklärungsbedürftig, es ist zu unübersichtlich. Schon das Feedback in Richtung “warum werden dort Sachen verkauft, die doch eigentlich kostenlos sind” zeigt das Problem. Oder die Frage, ob es dann ein “Cloverleaf RISC OS” gibt als Fork des altbekannten “RISC OS 5”. Oder die Frage, ob die angedachte Multi-Core-Unterstützung in Konkurrenz zu den bisherigen Bemühungen von Jeffrey Lee stehen (Antwort: nein, es SIND die Bemühungen von Jeffrey Lee, die im Rahmen der Cloverleaf-Ziele direkt verwendet werden sollen!). Oder die Frage, warum man 300€ für einen RPi 4 im schicken Gehäuse zahlen soll (Antwort: es ist Crowdfunding um RISC OS weiterzuentwickeln, nicht ein schnöder Hardware-Verkauf!).

Aus meiner Sicht war es höchste Zeit, dass jemand die RISC OS-Szene mit neuen Ideen aufmischt. Stefan verwendet hier einen eher managementorientierten Ansatz, was ihn deutlich vom “üblichen”, eher ingenieurs-bis-bedenkenträgerischen RISC OS-Ansatz abhebt, und vermutlich eckt er deshalb auch öfter mal an oder kann sein Anliegen nicht so klar und trotzdem diplomatisch formulieren, dass es breit verstanden wird. Stefan hat erkannt: um in endlicher Zeit Nägel mit Köpfen machen zu können, braucht es neue Leute. Neue Entwickler und neue User. Am einfachsten findet man neue User, wenn man ihnen interessante Produkte anbietet oder mindestens in Aussicht stellt. Am einfachsten findet man z.B. Entwickler, wenn man ihnen Geld bezahlt. Heraus kam mit ChatCube eine RISC OS-Anwendung, die von Entwicklern geschrieben wurden, die völlig ohne RISC OS-Vorkenntnisse an die Sache herangegangen sind. Es ist der Beweis, dass die Herangehensweise funktioniert. Ob sie auch für das OS selbst funktioniert, bleibt abzuwarten. Und ob am Ende die Bemühungen in einen signifikanten Anstieg an RISC OS-Nutzern münden – schön wäre es. Aber wetten würde ich nicht drauf. Seit Acorn-Zeiten wird versucht, diverse RISC OS-Merkmale zur Besetzung von Nischen gewinnbringend einzusetzen. Besonders erfolgreich war man damit zu keiner Zeit.

Erfrischend finde ich, wie Cloverleaf die “neuen Medien” für sich nutzt. Ob Facebook-Gruppe oder Kickstarter, oder auch ChatCube als Telegram-Client – da weht gar ein Hauch von Modernität durch die angestaubten RISC OS-Hallen.

Weil ich ein prinzipiell detailversessener Mensch bin, stören mich allerdings auch diverse Kleinigkeiten am Cloverleaf-Auftritt, die aus meiner Sicht unsauber und damit unnötig angreifbar sind. Und für nicht-RISC OS-Experten auch irreführend sein könnten. Zum Beispiel die Screenshot-Seite – wäre hier nicht ein Hinweis vonnöten, dass die dort gezeigte Software teilweise kommerziell und nicht ganz billig ist? “Excellent for Retro Gaming” – in welcher Hinsicht, außer klassische RISC OS-Spiele, wäre das denn tatsächlich der Fall? Wäre es nicht gut, präzise auszuführen, was denn nun Cloverleaf anschieben und machen will, und was eh schon anderweitig auf dem Weg ist? Wäre es nicht hilfreich, die genaue Position im RISC OS-Universum zwischen beispielsweise RISC OS Open Ltd., RISC OS Developments, R-Comp, Elesar und RISC OS Direct zu definieren? Oder die Liste der “available software” auf der Kickstarter-Seite – Impression Style als 26bit-Software aufzuführen, die bekanntlich nur unter Aemulor dreht, ist schon etwas verwegen. Dazu der hohe “Rauschanteil” auf der Kickstarter-Seite – warum die vielen Dinge nennen, die einen Menschen aus der Zielgruppe “neuer potenzieller Benutzer” überhaupt nicht interessieren oder zumindest gar nichts sagen – PlingStore, Packman, …. Oder warum wird eine mögliche klare Message verwässert durch Nichtigkeiten wie “ein freies Exemplar des Archive-Magazins” oder “ein Cloverleaf-T-Shirt” oder “ein RISC OS-Einsteiger-Buch”? Und auch das Loblied auf die RISC OS-Fonttechnologie wirkt doch seltsam aus der Zeit gefallen, haben hier doch alle anderen Plattformen RISC OS schon lange überholt. Seit ungefähr 20 Jahren.

Am Ende überwiegt aber mein Optimismus, dass diese neue Herangehensweise durchaus von Erfolg gekrönt sein kann. Und das Schöne am Crowdfunding ist ja, dass das persönliche Risiko eng begrenzt ist, und trotzdem im Erfolgsfall eine schöne Summe zustande kommen kann, mit der einiges bewegt werden kann. Wie gesagt, die Ziele an sich sind absolut valide. Und deshalb werde auch ich eine der Kickstarter-Optionen von Cloverleaf unterstützen. Ich weiß nur noch nicht welche. Die Timeline halte ich für sehr optimistisch, das ist kaum zu schaffen, egal wieviel Geld man in die Sache investiert – Softwareentwicklung ist nicht beliebig parallelisierbar, und im RISC OS-Universum müssen teilweise erst mal mühsam die Basics geschaffen werden (z.B. Entwicklerwerkzeuge) von einer sehr begrenzt verfügbaren Anzahl von kompetenten Entwicklern, bevor man an andere Aufgaben gehen kann. Und dennoch: ich bleibe optimistisch. Wer es versucht, kann scheitern. Wer es nicht versucht, ist schon gescheitert.

Übrigens ist auch dieser Blogbeitrag ein schönes Beispiel dafür, wie schwierig es ist, komplexe Sachverhalte klar und verständlich zu beschreiben. Beim nochmaligen Durchlesen bleiben dann doch Zweifel…

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.

Classic-RISC OS für Neueinsteiger

Update 2019-03-11

Korrektur VIDC/Monitorsituation beim A540

Update 2018-07-28

Kleinere Erweiterungen bei der Historie
Desktop-Kapitel leicht erweitert bei Iconbar und Pinboard und Maus
Task Manager beschrieben
Grundkonzepte hoffentlich besser erklärt
kurzen einleitenden Abschnitt eingefügt mit einem Schnelldurchlauf “Fenster öffnen, Anwendung starten, neues leeres Dokument öffnen, Anwendung beenden”
ein paar weiterführende Links eingefügt bei den Stub-Bereichen für die Ungeduldigen

ACHTUNG

Hier folgt nun eine Ansammlung von Text, noch recht unstrukturiert, aber mit durchaus interessantem Inhalt, der schon ewig auf meiner Platte vergammelt weil ich das Dingens nicht fertig bekomme. Vielleicht hilft es im jetzigen Zustand auch schon jemand, deshalb als DRAFT hier und jetzt veröffentlicht. WORK IN PROGRESS!

ENDE ACHTUNG

So ist die geplante Gesamtstruktur:

Teil 1: Einführung
- Historie
- RISC OS
- Welche RISC OS-Version?
- Emulieren, simulieren oder in echt?
- Andere Einführungen
Teil 2: Installation und Konfiguration
- MIST und MISTer
  - was muss auf die SD-Karte
  - was funktioniert, was nicht
- reale Hardware
  - Archimedes vs. A3000 vs. A5000/A3010/A3020/A4000/A4
  - Geräte anschließen
  - v.a. Bildschirmauswahl, der richtige Bildschirmmodus
  - Power-On-Resets/Configs
  - sinnvolle Hardware-Erweiterungen
- Emulatoren
  - Arculator
  - ArcEm
  - Red Squirrel
  - ArchiEmu
Teil 3: Der Desktop
- Maus
- Iconbar und Pinboard
- Filer
Teil 4: Die Kommandozeile
Teil 5: Die mitgelieferten Anwendungen
Teil 6: Wie kommt die Software auf das RISC OS-Gerät?
- Grundsätzliches (Filetype-Problematik, wo muss extrahiert werden)
- MIST/MISTer
  - Weg über Arculator
  - Weg über RISC OS/Raspberry Pi
- reale Hardware
  - Floppy
  - serielle Übertragung
  - Festplatte, Wechselplatte
  - moderne Peripherie
- Emulator
  - Floppy-Images
  - Festplatten-Images
  - Host-Dateisystem
Teil 6: Empfohlene Anwendungen und Tools
Teil 7: BBC BASIC
Teil 8: Troubleshooting

Vorbemerkung

RISC OS und die Acorn-Maschinen waren vornehmlich im englischen Sprachraum verbreitet. Das bedeutet, dass auch die englischen Begrifflichkeiten weit vorherrschend sind, auch unter deutschsprachigen RISC OS-Nutzern. Es gab zwar verschiedentlich Versuche von Acorn, auch im deutschsprachigen Raum Fuß zu fassen und es gab auch die eine oder andere eingedeutsche Fassung von RISC OS und diversen Programmen, aber es blieb die Ausnahme.

Demzufolge versuche ich im Artikel, das “übliche” englische Wording zu verwenden und bei erster Verwendung in Klammern den mir dafür bekannten deutschen Begriff zu nennen. Mit den englischen Begriffen kommt man in der Suchmaschine seiner Wahl normalerweise deutlich einfacher zu weiterführenden Informationen.

Eine Ausnahme bilden hier gängige IT-Begriffe wie Fenster oder Maus, die ich nicht zwanghaft englisch verwenden werde.

Kapitel 1 – Einführung

Wer konnte sich Ende der 80er schon einen Acorn Archimedes leisten? Nur wenige waren in der glücklichen Lage – ich gehörte dazu dank des preiswert(er)en A3000, sogar mit 200 DM Schüler-Rabatt (was dann immer noch auf knapp 2000 DM rauslief), und einem großzügigen Zuschuss meiner Oma. Angefixt wurde ich durch Berichte in den damals üblichen Zeitschriften wie Happy Computer, c’t, Chip und sogar Schneider Aktiv und Compute Mit! (wobei man bei letzteren beiden “üblich” wirklich sehr weit auslegen muss), wo dem Archimedes geradezu sagenhafte Fähigkeiten zugeschrieben wurden. Eins der Killerargumente: der verfügbare PC-Emulator, der es schaffte, auf dem Archimedes einen üblichen IBM PC-XT in Originalgeschwindigkeit zu emulieren. Man kaufte sozusagen zwei Rechner in einem. Dazu der wahnsinnig schnelle ARM-Prozessor mit dieser neuartigen RISC-Technologie. Dazu hervorragende grafische und musische Fähigkeiten, die die Heimcomputer-Konkurrenz wie Commodore Amiga oder Atari ST schlicht deklassierten (allerdings auch preislich weit übertroffen wurden). Der Archimedes war die Zukunft, man kaufte in Erwartung der phantastischen Software die da kommen würde aber hatte als Fallback für die unvermeidlichen Lücken ja den PC-Emulator.

Wahrscheinlich genießt der Acorn Archimedes auch deshalb Legendenstatus, weil er schlicht so selten war. Heute kann man diese Legende für kleines Geld wiederauferstehen lassen und selbst erleben – entweder durch Erwerb eines klassischen Gerätes (wobei hier die Preise inzwischen unangenehme Höhen erreicht haben), oder durch eine der verfügbaren Emulationslösungen – vom MIST(er)-Archimedes-Core über Red Squirrel, ArcEm, Arculator und VirtualA5000 auf x86-PCs bis zu Emulationslösungen wie ArcEm, A310Emu, ArchiEmu und ADFFS auf modernen RISC OS-Maschinen wie dem Raspberry Pi (egal ob Zero, 1, 2 oder 3). Zu den diversen RISC OS-Emulatoren mit Schwerpunkt Windows als Host-System gibt es eine eigene Seite.

Der Fokus dieses Artikels soll “Classic-RISC OS” sein, also das, was auf den Ur-Archimedes-Geräten A3xx und A4xx lief (manche zählen den A3000 auch noch dazu), sowie auf den danach, aber vor dem Risc PC erschienenen Maschinen A540, A5000, A3010, A3020, A4000 und A4. Mit anderen Worten: alles von RISC OS 2 bis RISC OS 3.1x, Also grob die Jahre 1988 bis 1994. Wer sich für die geschichtliche Einordnung interessiert, kann hier ein paar Details nachlesen. Ich empfehle dringend, auf die originale Archimedes-Erfahrung mit dem ursprünglichen Betriebssystem “Arthur” zu verzichten. Die erste Version war bestenfalls rudimentär zu nennen (0.30), die zweite Version zwar ansatzweise solide, aber immer noch verstörend bunt und immer noch nicht multitaskingfähig (1.20). Auch RISCiX, Acorns BSD-basierter Versuch mit der Archimedes-Hardware im Markt der Unix-basierten Workstations zu landen, werde ich beharrlich ignorieren.

1.1 RISC OS

Als klassische RISC OS-Versionen stehen 2.00 (Auslieferungsversion der nach-Arthur-Zeit von A3xX, A4XX und A3000), 2.01 (A540 – im Prinzip 2.00 plus Unterstützung für ARM3 und 16 MiB RAM), 3.00 (initiale Version für A5000), 3.10 (Upgrade-Version für alle Modelle, initiale Version für A3010/3020/4000/4), 3.11 (minimales Update von 3.10) und 3.19 (Deutsche Version von 3.11) zur Auswahl.

Wenn man nicht unbedingt auf deutsche Texte (be)steht, würde ich zur Version 3.10 oder 3.11 raten. Die allermeiste Software ist zu diesen Versionen kompatibel, man kann sie sogar aufrüsten auf etwas beinahe Äquivalentes zur letzten Risc PC-Version 3.71 (Stichworte: “UniBoot”, “Toolbox” und “Nested WIMP”), weil Acorn traditionell sehr weitreichende Rückwärtskompatibilität anstrebte und auch Ende der 90er, als Acorn einen eigenen Web-Browser und Java entwickelte, die alten Maschinen im Schulmarkt noch weit verbreitet waren.

RISC OS 3.1x ist auch deshalb die pflegeleichtere Option, weil schon einige nützliche Anwendungen und Ressourcen im ROM (!Edit, !Draw, !Paint, die Standard-Fonts) integriert sind und man sich deshalb nicht damit rumschlagen muss, der Software diverse fast immer benötigte Module auf einer Floppy zum Nachladen bereitzustellen (SharedCLibrary, FPEmulator, ColourTrans, FontManager…).

In Einzelfällen mag auch RISC OS 2 noch eine Option sein, wenn man historisches Interesse mitbringt oder Software testen will, die unter 3.1x nicht funktioniert. Aber nichts für meine Zielgruppe hier.

RISC OS ist unter den Retro-Betriebssystemen dahingehend ein Sonderfall, als hier Copyright-Verstöße tatsächlich teilweise noch verfolgt werden. Es gibt noch aktive Händler, die an der alten Software Geld verdienen und ihr Recht entsprechend gewillt sind zu verteidigen. Immerhin wird es einem einfach gemacht, eine legale RISC OS-Version zu erwerben: hier gibt es die “Classic ROM collection” zu kaufen, die alles von Arthur bis RISC OS 3.71 mitbringt, mit der überraschenden Ausnahme von RISC OS 3.19 (vermutlich aufgrund unklarer Rechtslage bezüglich der Rechte an der Übersetzung). Natürlich gibt es aber auch Download-Quellen wie die 4corn-Seiten oder den Qube FTP-Server.

Bleibt die Frage zu klären: warum heißt die erste RISC OS-Version eigentlich “2”? Weil Arthur posthum zu “RISC OS 1” erklärt wurde.

1.2 Emulieren, simulieren oder in echt?

Gibt man sich mit einer x86-Emulationslösung zufrieden, geht es – Windows-PC vorausgesetzt – recht einfach: VirtualA5000 kaufen. Eine “out of the box”-Lösung für 15 UKP, ganz ohne notwendiges Gebastel, aber natürlich damit auch ohne den Bastelspaß. Und von der Kompatibilität her für die älteren Spiele nicht uneingeschränkt tauglich. Aber eine Art Maximallösung – 16 MiB RAM und Bildschirmauflösungen wie 1024×768 bei 16 Farben und 800×600 bei 256 Farben, die früher aufgrund der knappen RAM-Bandbreite langsam bis unmöglich waren. Und auf heutigen CPUs wird die Originalgeschwindigkeit des A5000 mit seinem 25 MHz ARM3 mal locker auf das Zehnfache gesteigert.

Wer es preiswerter (also umsonst) haben will: Arculator ist der Emulator der Wahl für Windows was die Präzision des Timings der Emulation angeht, ArchiEmu ist für moderne RISC OS-Systeme vorne, ArcEm unter Linux. Bezüglich Benutzerfreundlichkeit ist weiterhin Red Squirrel unter Windows eine Option – die Red-Squirrel-Webseite scheint derzeit tot zu sein, deshalb stattdessen der Link zu Wocki’s Acorn Revivalteam-Seite. ADFFS nimmt als RISC OS-Lösung einen Sonderstatus ein, weil es sich ganz auf Spiele konzentriert und durch eine Kombination aus Emulation, nativer Ausführung und Patching kein Emulator im eigentlichen Sinne ist.

Alle Emulatoren sind recht pflegeleicht und ausreichend kompatibel – im Gegensatz zu anderen Retro-Plattformen kommt es bei RISC OS nicht so sehr auf “cycle exact emulation” und Emulation von Hardwaretricks jenseits der Datenblätter an – die allermeiste Software ist so gebaut, dass sie auf der unterschiedlichen Hardware vom 8 MHz ARM2 mit 8 MHz Bustakt bis zum 36 MHz ARM3 mit 16 MHz Bustakt, FPU und Grafikkarte einwandfrei läuft – die Diversität der Hardware hat erfolgreich verhindert, dass jenseits einiger weniger Demos zu hardwarenah programmiert wurde.

Ebenfalls bequem ist, dass die Emulatoren meistens ein “HostFS” anbieten – ein Dateisystem, das Zugriff auf die Festplatte des Host-Computers anbietet und so sowohl den Datenaustausch erleichtert als auch eine höhere Performance und mehr Platz als auf den Originalsystemen bietet. Allerdings gibt es hier häufig Kompatibilitätsprobleme weil sich das Dateisystem doch nicht so ganz wie ein “natives” RISC OS-Dateisystem verhält – wenn man sich der Beschränkungen nicht bewusst ist, besser das HostFS nur zum Austausch von Dateien und nicht zum Arbeiten verwenden.

Emulatoren fühlen sich allerdings oft synthetisch an. Das Retro-Gefühl stellt sich nicht so recht ein. Als einen Schritt näher am Original bieten sich FPGA-basierte Systeme wie MIST oder neuerdings MISTer an, auf denen jeweils der Archimedes-Core von Stephen Leary verfügbar ist. Hier wird ein A3000 simuliert, angereichert um die A3010-Joystick-Ports.

Der Haken: die Inbetriebnahme ist nicht so ganz simpel (hier gibt es einige Hinweise für MIST), und die Stabilität ist eher durchwachsen. Man ist wieder auf Diskettenimages (einziges unterstütztes Format: ADF in der Acorn-Variante, nicht zu verwechseln mit dem Amiga-ADF) eingeschränkt, eine Festplattenunterstützung oder gar direkten Zugriff auf die SD-Karte gibt es nicht. Die Simulation erreicht nicht ganz die Original-ARM2-8 MHz-Geschwindigkeit. Die Kompatibilität ist durchwachsen, bei den diversen Spielen funktionieren nur etwa 50%. Es werden maximal 4 MiB RAM unterstützt. Die PAL-Bildschirmmodi scheinen unter ungenauem Timing zu leiden (ich analysiere noch). Änderungen an der CMOS-Konfiguration werden nicht gespeichert, und es gibt keine Möglichkeit die CMOS-Inhalte vorzugeben. ADFFS läuft nicht, d.h. man ist auf ungeschützte ADF-Images angewiesen und kann weder JFD noch APD als Image-Formate nutzen.

Das Schöne an MIST und MISTer ist natürlich deren Vielseitigkeit – C64, Amiga, CPC, dazu diverse Konsolen. Den Archimedes-Core würde ich aber im jetzigen Zustand eher als nette Beigabe denn als Kernfunktionalität oder empfehlenswerte Lösung sehen.

Letztlich schlägt nichts die Originalhardware bezüglich der Authentizität. Aber die ist pflegeintensiv: die CMOS-Stützbatterie muss routinemäßig ersetzt werden bevor sie durch Auslaufen die Platine ruiniert. Der Datenaustausch muss, sofern man nicht zufällig eines der seltenen Ethernet-Podules hat, häufig über Disketten erfolgen, bei A3xx/A4xx/A540/A3000 gar per DD-Disketten. Nullmodem per seriellem Port wäre eine Option, ist aber sehr mühsam – und bei der alten Garde auf 19200 Baud begrenzt, der A3000 hatte gar serienmäßig gar keinen seriellen Port. SCSI2SD ist die Luxusvariante für die Glücklichen mit einem SCSI-Podule (damals Serie beim A540), Glückspilze haben ein Gerät mit IDE-Schnittstelle eingebaut (A3020, A4000, A5000) und finden eine der seltenen CF-Karten, die hier funktionieren. Die Netzteile sind auch oft ein Problem und waren schon in jungen Jahren bekannt für ihre Unzuverlässigkeit.

Dazu kommt das Problem der Peripheriegeräte – sowohl Tastatur als auch Maus sind eher unüblich, die Tastatur Acorn-spezifisch und die Maus eine vom seltenen Busmaus-Typ. Es gibt PS/2-Adapter, aber die sind rar und teuer. Auch bezüglich des Monitors steht man vor potenziellen Problemen. Zwar unterstützt RISC OS 3.1x Super-VGA-Monitore, also auch heutige LCDs sofern sie noch einen analogen VGA-Eingang haben. Aber die dafür notwendigen präzisen Frequenzen kann nur Hardware ab dem A540 bzw. A5000 erzeugen, die älteren Archimedes-Modelle haben noch einen klassischen 9pin-RGB-Ausgang und können nur so ein ungefähres VGA-Signal erzeugen und sind zudem nicht fähig, die zum Arbeiten wichtige Auflösung von 800×600 zu erzeugen – dafür braucht es ein Hardware-Teil namens VIDC-Enhancer. Und die VGA-kompatiblen Letterbox-Varianten der PAL-Bildschirmmodi sind auch eher unelegant – vor allem Spiele laufen typischerweise in den PAL-Modi. Für die echte Retro-Experience braucht man also einen Monitor, der 15kHz-PAL-Signale verarbeiten kann. Nicht einfach zu beschaffen. Hier und hier habe ich darüber gebloggt.

Der Retro-Traum wäre ein Fertiggerät auf MISTer-Basis, der auf HDMI-Bildschirmen alle Videomodi erfolgreich emuliert, so schnell wie ein 33 MHz A5000 ist, nativ SD-Karten unterstützt und den Ethernet-Port als Ethernet-Podule ins System integriert. Natürlich mit Unterstützung für bis zu 16 MiB RAM und Festplatten-Images sowie den APD- und JFD-Disketten-Images. Ob wir das noch erleben werden? Entwickler, die sowohl die Acorn-Hardware gut kennen als auch in FPGA-Programmierung firm sind wachsen nicht gerade auf den Bäumen.

1.3 Andere Einführungen

Völlig überraschend bin ich nicht der erste, der auf die Idee kommt eine RISC OS-Einführung zu schreiben. Eine alternative Einführung auf Deutsch findet sich hier bei der ArcSite. Auch empfehlenswert, und zudem schön druckbar als A5-Broschüre: die RISC OS 3-Einführung von Detlef Thielsch/a4com. Hier wird mit der deutschen RISC OS-Version gearbeitet.

Wer die “original learning experience” nachvollziehen will, kann mit den Originalhandbüchern arbeiten, z.B. dem “Welcome Guide” für den A3010, um sich mit den RISC OS-Grundlagen vertraut zu machen.

Viele Einführungen und Tutorials basieren auf moderneren RISC OS-Versionen wie z.B. dieses von Steve Potts. RISC OS hat sich aber seit Anfang der 90er nicht so dramatisch verändert, als das man aus solchen Tutorials überhaupt keinen Nutzen mehr ziehen könnte – man darf sich nur durch leicht abweichend aussehende Screenshots nicht beirren lassen.

Kapitel 2 – Installation und Konfiguration

2.1 MIST und MISTer

Hier gibt es eine ausführlichere Fassung als Blog-Post, allerdings schon leicht veraltet.

Die Kurzform: Man nehme eine verwaiste SD-Karte im FAT-Format. Archimedes-Core als core.rbf draufkopieren. Gewünschtes RISC OS-ROM als riscos.rom draufkopieren (muss in einer einzigen Datei vorliegen – 512 KiB für Arthur und RISC OS 2, 2 MiB für RISC OS 3). Die gewünschten Disk-Images (nur das Format ADF wird unterstützt, das Image muss exakt 819200 Bytes haben) draufkopieren. Optional gleich mal zwei der Disk-Images als floppy0.adf und floppy1.adf benennen (müssen im Root liegen!), die werden automatisch gemounted.

Wenn man von einem anderen Core übers MIST-Menü auf den Archimedes-Core wechselt, funktioniert das nach meiner Erfahrung fast nie. Auch der initiale Boot-Vorgang wenn der Archimedes-Core als core.rbf vorliegt klappt fast nie, einfach kurz warten und den MIST-Reset-Knopf drücken, dann klappt es in den allermeisten Fällen. Manchmal flackert der Bildschirm komisch, dann einfach nochmal Reset drücken.

Es hat sich gezeigt, dass aktuellere Hardware-Versionen des MIST (z.B. die Revision 1.3 mit den serienmäßigen MIDI-Ports) offenbar aufgrund leichter Abweichungen bei den verwendeten RAM-Chips eine speziell angepasste Version des Cores benötigen. Den gibt es hier, die Berichte über dessen Stabilität sind eher wechselhaft. Wie es sich mit dem MIST-Nachbau MISTICA verhält konnte ich noch nicht herausfinden.

Und wie ist es auf dem MISTer? Da habe ich noch wenig Erfahrung, aber zumindest der Start aus dem Menü-Core funktioniert hier problemlos. Hier gibt es den Core. Der HDMI-Anschluss macht zumindest die Monitor-Suche erheblich einfacher.

Was macht man, wenn die gewünschte RISC OS-Version nicht in einer einzigen Datei vorliegt, sondern wie häufig zu sehen in vier Dateien (das kommt daher, weil die Original-Maschinen 4 ROM-Chips namens IC24 bis IC27 intus hatten und die ersten Emulatoren genau auf vier Dateien bestanden)? Hier wird Abhilfe für verschiedenste Host-Betriebssysteme beschrieben.

2.2 Reale Hardware

…to be written…old-style Archimedes (A3xx/A4xx/A540/A3000) vs. new-style (A4/A5000/A3010/A3020/A4000)

A3xx/A4xx: ARM2 8 MHz, MEMC1, 8 MHz RAM, 24 MHz VIDC-Takt, WD1772-Floppy-Controller (DD), 9pin RGB, CSync only, unidirektionaler Parallelport, serieller Port über 6551
A4xx/1: ARM2 8 MHz, MEMC1a, 8 MHz RAM, 24 MHz VIDC-Takt, WD1772-Floppy-Controller (DD), 9pin RGB, CSync only, unidirektionaler Parallelport, serieller Port über 6551
A3000: ARM2 8 MHz, MEMC1a, 8 MHz RAM, 24 MHz VIDC-Takt, WD1772-Floppy-Controller (DD), 9pin RGB, CSync oder HSync/VSync über Jumper, unidirektionaler Parallelport, serieller Port über 6551
A540: ARM3 25 MHz 4 KiB cache, MEMC1a, 8 MHz RAM, 24/25,175/36 MHz VIDC-Takt, WD1772-Floppy-Controller (DD), 9pin RGB, CSync oder HSync/VSync über Jumper, unidirektionaler Parallelport, serieller Port über 6551
A5000: ARM3 25 MHz 4 KiB cache, MEMC1a, 12 MHz RAM, 24/25,175/36 MHz VIDC-Takt, C&T 82C710 PC-Style I/O (HD-Floppy, IDE), 15pin VGA, CSync oder HSync/VSync über Software, bidirektionaler Parallelport, serieller Port über 8250-kompatiblen Teil des 82C710
A3010/A3020/A4000: ARM250 12 MHz, 12 MHz RAM, 24/25,175/36 MHz VIDC-Takt, C&T 82C711 PC-Style I/O (HD-Floppy, IDE (kein IDE-Steckplatz im A3010 verfügbar!)), 15pin VGA, CSync oder HSync/VSync über Software, bidirektionaler Parallelport, serieller Port über 8250-kompatiblen Teil des 82C711
A4: ARM3 24 MHz, 4 KiB cache, MEMC1a, 12 MHz RAM, 24/25,175/36 MHz VIDC-Takt, C&T 82C711 PC-Style I/O (HD-Floppy, IDE), 15pin VGA, 640×480-16-Graustufen-LCD, CSync oder HSync/VSync über Software, bidirektionaler Parallelport, serieller Port über 8250-kompatiblen Teil des 82C711

2.3 Emulatoren

…to be written…Arculator, ArcEm, Red Squirrel auf x86, ArchiEmu, ArcEm und ADFFS auf RISC OS 4/5

RISC OS auf dem Emulator unter Windows

Kapitel 3 – RISC OS – Der Desktop

Läuft alles normal und nach Standard, begrüßt uns RISC OS mit einer grafischen Oberfläche, dem Desktop (wird auch mit dem Oberbegriff “WIMP” bezeichnet – Windows, Icons, Mouse, Pointer). Der RISC OS-Desktop arbeitet sehr mauszentriert und verwendet sehr häufig Drag&Drop für Operationen wie Speichern oder Laden, wo andere Betriebssysteme Dateiauswahldialoge verwenden. Auch Datenaustausch zwischen Anwendungen funktioniert häufig mittels Drag&Drop.

Um RISC OS bedienen zu können, bedarf es eines gewissen Grundwissens über die Maus, Fenster, Icons, den Filer und die Iconbar, die sich gegenseitig bedingen und nur im Zusammenhang klar werden. Bitte am besten die folgenden Unterkapitel erst mal durchlesen und dann durch Ausprobieren sich mit den Konzepten anfreunden.

Für die ungeduldigen Leser der Kurzdurchlauf: mit der linken Maustaste auf das “Apps”-Icon im unteren Bildschirmbereich (die Iconbar) clicken. Es öffnet sich ein Fenster mit dem Titel “Resources:$.Apps” mit einigen Icons, die – erkennbar am führenden “!” – Anwendungen repräsentieren. Doppelclick z.B. auf !Edit startet den im ROM mitgelieferten einfachen Texteditor. Ist er gestartet, erscheint sein Icon im rechten Bereich der Iconbar. Click darauf mit der linken Maustaste öffnet ein leeres Textdokument, repräsentiert durch ein Fenster mit dem Titel “<untitled>”. Click mit der mittleren Maustaste innerhalb dieses Fensters zeigt das Menü der Anwendung. Click mit der mittleren Maustaste auf das !Edit-Icon auf der Iconbar erlaubt das Beenden der Anwendung durch Auswahl von “Quit”.

Auf Englisch hier ein paar Infos (RISC OS 4, aber das meiste passt auch auf RISC OS 3).

3.1 Die Maus

Ohne Maus läuft hier gar nix, Tastaturbedienbarkeit der grafischen Oberfläche war von Acorn nicht wirklich vorgesehen. Wichtig: es sollte eine Drei-Tasten-Maus sein, RISC OS nutzt tatsächlich alle drei Tasten sinnvoll. Hat man – wie leider bei Laptops oft üblich – nur zwei Tasten zur Verfügung, bieten die Emulatoren oft Hilfe in Form einer speziellen Taste auf der Tastatur als Maustastenersatz an, häufig in Form der unter RISC OS nutzlosen Windows- oder Kontextmenütaste.

Die linke Maustaste nennt sich “Select” (Deutsch: “Auswahltaste”) und funktioniert so, wie man es von anderen Betriebssystemen kennt. Man kann mit einem Click Buttons drücken oder Dinge selektieren, mit einem Doppelclick Dateien und Programme starten und mit einem Drag (Drücken-und-Festhalten der Maustaste und dann bewegen, Loslassen der Maustaste ist dann der “Drop” passend zum Drag&Drop-Paradigma) Fenster oder Scrollbars hin- und herschieben oder auch einen Drag-Bereich aufspannen. Die rechte Maustaste nennt sich “Adjust” (Deutsch: “Spezialtaste”) und tut stets so was ähnliches wie “Select”, aber leicht anders, und manchmal sogar das Gegenteil. Klingt komisch, ist aber so. Beispiele (die muss man sich nicht alle auf Anhieb merken – man kann RISC OS auch problemlos nur mit der linken und der mittleren Maustaste bedienen, aber es entgehen einem sehr schöne Feinheiten):

Drag eines Fensters per “Select” mittels der Titlebar holt dieses gleichzeitig in den Vordergrund. Nimmt man “Adjust”, bleibt das Fenster auf seiner ursprünglichen Position im Window-Stack
Drag eines Scrollbars per “Adjust” erlaubt das gleichzeitige scrollen sowohl horizontal als auch vertikal
wählt man eine Menüaktion mit “Adjust” aus, so bleibt die komplette Menühierarchie offen
clickt man einen Button eines Dialogs (z.B. OK), so bleibt der Dialog offen
Click per “Adjust” auf einen Pfeilbutton (z.B. eines Scrollbars) löst die Gegenaktion aus (also beim Scrollbar: Scroll nach unten statt nach oben)
Click per “Adjust” auf den leeren Bereich eines Scrollbars scrollt zur umgekehrten Richtung als per “Select”
Schließt man ein Filer-Fenster mit “Adjust”, so wird nicht nur das Fenster geschlossen, sondern an derselben Fensterposition geht das Parent-Verzeichnis auf
Click per “Select” auf ein Icon z.B. im Filer oder auf dem Pinboard löscht die bisherige Selektion und selektiert das geclickte Icon – “Adjust” behält die bisherige Selektion bei und selektiert das geclickte Icon zusätzlich (bzw. deselektiert es wenn es selektiert war)

Schließlich die mittlere Maustaste – betrachtet man Screenshots von RISC OS mit laufenden Programmen, so fällt sofort auf, dass kein Fenster eins der üblichen Pull-Down-Menüs hat. Das liegt daran, dass RISC OS alles mit Pop-Up-Menüs handhabt, und die mittlere Maustaste ist die “Menu”-Taste (Deutsch: “Menütaste”) . Wo immer der Mauszeiger ist, die mittlere Maustaste öffnet kontextsensitiv das Menü der jeweiligen Anwendung. Diese Menülösung ist so genial, dass man sich schon wundern muss, dass keine andere (mir bekannte) grafische Oberfläche so arbeitet. Die Mauswege werden minimiert (man muss nicht bis zur Menüleiste hochfahren, sondern clickt einfach da wo man ist), man kann je nach Fensterbereich andere Menüinhalte bereitstellen ohne allein über Disabling von Menüpunkten gehen zu müssen, man kann das Menü überall auf den Bildschirm hinschieben, um alle Bereiche der Arbeitsfläche sichtbar zu halten…wie gesagt, genial.

3.2 Pinboard und Iconbar

Der Desktop besteht aus zwei Teilen – der größere obere Teil ist das Pinboard und sowas wie die Arbeitsfläche. Der untere kleinere Teil ist die sogenannte Iconbar.

Die Iconbar ist ein zentrales Element unter RISC OS. Alles darauf wird – nomen est omen – von einem Icon repräsentiert. Dort findet man Dinge wie die verfügbaren Geräte (Laufwerke, Drucker – auf der linken Seite) oder laufende Anwendungen (auf der rechten Seite).

Startet man eine Anwendung, so legt sich diese typischerweise als Icon auf die Iconbar, öffnet aber kein Fenster. Erst ein Click per “Select” auf das Iconbar-Icon öffnet das Hauptfenster oder ein leeres Dokument. Click per “Menu” auf das Iconbar-Icon öffnet das Iconbar-Menü der jeweiligen Anwendung, wo nach Style-Guide mindestens ein Info-Fenster über die Anwendung aufklärt (Name, Version, Autor…) sowie das Beenden der Anwendung ermöglicht wird (stets der unterste Eintrag im Menü, “Quit” oder “Beenden”) – eine Ausnahme bilden hier nur die Systemanwendungen auf der äußersten rechten Seite.

3.3 Der Filer

Zentrales Element der RISC OS-Benutzung ist der sogenannte Filer. Das ist ein Fenster, in dem Inhalte eines Dateisystems angezeigt werden – Dateien, Verzeichnisse und Applications (Deutsch: Anwendungen). Ein Mausclick auf eines der Laufwerksicons auf der linken Seite der Iconbar öffnet das Hauptverzeichnis des jeweils repräsentierten Mediums – das kann z.B. eine CD sein, eine Festplatte oder eine Festplattenpartition, eine Diskette oder ein Netzwerk-Mount. Oder im Falle des “Apps”-Icons die Anwendungen, die im RISC OS-ROM fest installiert sind. Unterhalb des Laufwerksicons steht manchmal der Name des Mediums oder die Laufwerksnummer. Mit der Menu-Maustaste (das ist die mittlere – siehe vorhergehender Abschnitt) kann man oft mehr erfahren, z.B. welches Dateisystem hier repräsentiert wird (ADFS, IDEFS, AppFS, CDFS…) und wieviel Platz schon belegt oder noch frei ist (typischerweise heißt dieser Menüeintrag “Free”).

Ein kurzer Exkurs zu RISC OS-Dateisystemen: Der “.” ist der Verzeichnistrenner (juhu, nach Windows/DOS-Backslash und Unix-Slash die dritte Variante! Übrigens eine Gemeinsamkeit mit VMS). “$” bezeichnet das Wurzelverzeichnis. Pro Dateisystem gibt es bis zu 8 Laufwerke, die von 0 bis 7 durchnummeriert werden. Jedes Laufwerk (bzw. das dort derzeit eingelegte Medium) hat einen Namen. Eine Datei “File” im Verzeichnis “Directory” im Dateisystem “ADFS” auf einem Medium namens “HardDisc4” hat dann z.B. folgenden voll qualifizierten Pfadnamen: ADFS::HardDisc4.$.Directory.File. Zusätzlich gilt per Konvention: der “/” trennt die Dateiextension ab – RISC OS verwendet “File Types” um den Dateien ihren Typ zu verleihen, aber beim Datenaustausch mit anderen Systemen kann automatisch basierend auf der Extension ein File Type vergeben werden.

Ausführliches zum Filer auf Englisch (RISC OS 4, aber das meiste passt auch auf RISC OS 3) hier.

3.3.1 Dateien

Dateien werden durch typischerweise quadratische Icons repräsentiert, die dem Typ der Datei entsprechen. RISC OS arbeitet mit sogenannten “File Types” (deutsch: Dateitypen) anstatt mit Datei-Extensions wie DOS oder Windows. Diese “File Types” sind dreistellige Hex-Codes, die – falls das System sie kennt – einem Namen zugeordnet sind. Hier kann man nachlesen, welche File Types in der weiten RISC OS-Welt bekannt sind. Die wichtigsten zum Merken: &FFF sind Texte, &FEB sind Obey-Files (im Prinzip ausführbare Kommandoscripts), &FFD sind “Data-Files” die typischerweise Verwendung finden wenn kein anderer Typ gepasst hat. &FF8 für Programm-Binaries (im Prinzip sowas wie .exe-Dateien), &FFB für BASIC-Dateien, &FF9 für Sprite-Dateien und &FFA für Module (im Prinzip Betriebssystemerweiterungen) laufen einem auch recht häufig über den Weg.

3.3.2 Verzeichnisse

Verzeichnisse werden durch das Folder-Icon (ein stilisierter Aktenordner) repräsentiert. Ein Doppelclick öffnet dieses Verzeichnis in einem neuen Filer-Fenster (zumindest wenn man mit der Select-Taste (zur Erinnerung: das war die linke Maustaste!) doppelclickt – tut man das mit der Adjust-Taste, schließt sich hingegen automatisch das bisherige Filer-Fenster und das neue tritt an seine Stelle).

3.3.3 Anwendungen

Anwendungen (RISC OS-Sprech: “Applications”), also die startbaren Programme, sind auf dem Dateisystem nichts anderes als speziell benannte Verzeichnisse – sie beginnen per Konvention mit einem “!” (englisch: “Pling”). Acorn hat irgendwann einmal festgelegt, dass man in Texten die Anwendungen beim Namen ohne das vorangestellte “!” referenzieren soll, aber m.E. ist das eine eher verwirrende Konvention – ich rebelliere bewusst dagegen und werde !Draw einfach !Draw nennen, alleine damit man es einfacher im Text herauslesen und unterscheiden und im Filer unter gleichem Namen wiederfinden kann.

Gestartet wird eine Anwendung mittels Doppelclick. Wenn nun Anwendungen aber im Prinzip Verzeichnisse sind, wäre es ja schön, diese auch öffnen zu können, um zu sehen, was in so einer Anwendung wirklich steckt. Da der Doppelclick schon für die übliche “Ausführen”-Funktion belegt ist, tut man dies per Shift-Doppelclick.

Wird ein Filer-Fenster geöffnet, so werden automatisch alle Anwendungen in diesem Verzeichnis “gebootet” – soll heißen, ihre !Boot-Obey-Datei wird ausgeführt. In diesem !Boot-Script werden üblicherweise alle notwendigen Grafiken für Dateitypen und die Anwendung selbst initialisiert und notwendige Systemvariablen belegt, z.B. damit automatisch diese Anwendung bei einem Doppelclick auf eine von ihr verarbeitbare Datei gestartet und die Datei automatisch geladen wird. Der Doppelclick auf die Anwendung selbst führt hingegen die !Run-Obey-Datei aus, in der typischerweise die eventuell notwendigen Erweiterungsmodule ggf. geladen werden und schließlich die Anwendung selbst gestartet wird – der Hauptprogrammcode befindet sich normalerweise in einer Datei namens !RunImage.

Man kann diesen automatischen Boot-Vorgang aller Anwendungen in einem Verzeichnis dadurch verhindern, dass man beim Öffnen des Verzeichnisses die Strg-/Ctrl-Taste gedrückt hält. Das kann nützlich sein, um beispielsweise temporär zu verhindern, dass eine Anwendung sich einen File Type krallt oder um den Öffnen-Vorgang zu beschleunigen – vor allem bei Disketten, wo das Ausführen der !Boot-Dateien schon mal etwas dauern kann. Normalerweise sind die !Boot-Dateien aber so gestrickt, dass die zeitraubenden Aktionen nur einmal ausgeführt werden, so dass das erneue Öffnen eines Verzeichnisses sehr schnell geht.

Durch die Kapselung einer Anwendung in einem Verzeichnis, das die Anwendung selbst ist, ergibt sich ein großartiger Vorteil von RISC OS: die Installation einer solchen Anwendung entspricht einfach einer Kopieraktion dieser Anwendung . Will man sie auf seinem Dateisystem woanders haben, verschiebt man sie einfach woanders hin. Will man sie deinstallieren, löscht man sie. Einfacher geht es nicht.

3.3.4 Arbeiten mit dem Filer

Die üblichen Aktionen auf Dateien, Verzeichnisse und Anwendungen (nachfolgend mit dem Überbegriff “Objekte” bezeichnet) wie kopieren und verschieben funktionieren per Maus und Drag&Drop. Man kann entweder einzelne Objekte bearbeiten oder eine Selektion von Objekten. Eine Mehrfachselektion kann entweder durch Click auf einzelne Objekte mit der Adjust-Taste hergestellt werden oder durch Aufziehen eines Bereichs per Drag mit der Select- oder Adjust-Taste startend in einem freien Bereich des Filer-Fensters. Über das Filerfenster-Menü kann man per Aktion einfach alle Objekte selektieren oder eine existierende Auswahl aufheben. Das Löschen aller Objekte einer Auswahl geht ebenfalls über das Filerfenster-Menü.

Eine Selektion von Objekten kopiert man, indem man sie von einem Fenster per linke-Maustaste-Drag in ein zweites Fenster zieht. Hält man dabei Shift gedrückt, werden die Objekte verschoben anstatt kopiert. Solche Dateioperationen werden, sofern der “Verbose”-Modus angeschaltet ist (in einem Filer-Fenster die mittlere Maustaste drücken, im “Options”-Untermenü “Verbose” anhaken), in einem sogenannten FilerAction-Fenster angezeigt, in dem man jederzeit die Operation unterbrechen, fortsetzen oder abbrechen kann.

…to be continued…

3.3 Der Task Manager

Ein Links-Click auf die Acorn-Eichel unten rechts auf der Iconbar (das sogenannte Switcher-Icon) öffnet das Task Manager-Fenster (“Task display”). Hier erfährt man detailliert, was im System gerade wieviel Speicher verbraucht und was denn gerade so am Laufen ist.

Die roten Speicherbalken signalisieren, dass der Benutzer sie durch Mausdrag hin- und herziehen kann, grüne Speicherbalken hingegen signalisieren dass die Anwendung den Speicher selbst managed oder der Balken nur der Information dient.

Im Task Manager finden wir wieder ein schönes Beispiel für die kontextsensitiven Menüs – geht man mit dem Mauszeiger auf einen der Namen im Bereich “Application tasks” und clickt mit der mittleren Maustaste, so kann man über “Task ‘xxx’ -> Quit” die Anwendung beenden – äquivalent zur Auswahl des “Quit”-Menüpunktes des Iconbar-Menüs der Anwendung.

Eine schöne Funktionalität verbirgt sich im Bereich “System memory allocation” hinter “RAM disc” – hier kann man per Drag einfach eine gewünschte Speichermenge als RAM-Disk allokieren. Sobald man den Drag beendet, installiert sich auf der Iconbar ein “RAM”-Icon und man hat einen sehr schnellen Zwischenspeicher zur Verfügung, natürlich auf Kosten der Hauptspeichermenge – nichts ist umsonst.

Interessant ist ab und an auch der “Next”-Slot bei den “Application tasks”: dort kann man für Anwendungen, die nicht selbst ihren Speicherbedarf festlegen, die zu verwendende Speichermenge festlegen. Beispielsweise nutzt eine ausgelöste Dateikopieraktion genau den Speicher, der in “Next” eingestellt ist. Oder das nächste geöffnete Task Window (siehe folgendes Kapitel 4).

Kapitel 4 – RISC OS – Die Kommandozeile

Obwohl RISC OS “normalerweise” uns mit dem Desktop beglückt, hat es auch eine Kommandozeile (oft kurz CLI genannt), die man ab und an bemühen muss, wenn was nicht so funktioniert wie es soll. Man erreicht die Kommandozeile aus dem Desktop jederzeit per F12. Der Prompt beginnt immer mit einem Stern, die Kommandos die man dort eingeben kann werden deshalb auch als “star commands” bezeichnet. Um wieder zum Desktop zurückzukehren, einfach beim Prompt ohne weitere Eingabe Enter drücken. Alternativ kann man auch ein sogenanntes “Task Window” verwenden, im weitesten Sinne mit der Windows-Eingabeaufforderung oder einem Unix-XTerm zu vergleichen. Ctrl+F12 öffnet ein solches “Task Window”.

RISC OS speichert einige Einstellungen im CMOS-RAM. Das ist ein kleiner, 240 Bytes umfassender Speicherbereich, der typischerweise batterie- oder akkugepuffert ist, also “non-volatile”, wie der Engländer sagt. Wichtige Einstellungen, die hier gespeichert werden:

Monitorkonfiguration
von welchem Dateisystem und welchem Laufwerk wird gebooted
wird initial in die Kommandozeile, in den Desktop oder ins BASIC gesprungen?

Zur Anzeige der derzeit aktiven Einstellungen geht man in die Kommandozeile und gibt ein:

status

Das listet alle verfügbaren Einstellungen auf. Man kann das Scrolling verlangsamen wenn man Strg/Ctrl drückt, oder anhalten wenn man Umschalt/Shift drückt. Einzelne Optionen ändert man mit

configure <name der option> <wert für die option>

Man kann jedes Kommando auch abkürzen durch den Punkt, sofern der Name dann noch eindeutig ist (bzw. es wird das erste genommen, das matcht) – statt immer configure zu tippen kann man auch co. verwenden.

Wichtige Kommandos im Alltag:

help
help <Kommandoname>
ex – listet den Inhalt des derzeitigen Verzeichnises auf
dir <Verzeichnis> – wechselt in das angegebene Verzeichnis
show – zeigt alle gesetzten Systemvariablen an
adfs – wechselt zu ADFS als derzeit ausgewähltem Dateisystem (andere gängige Dateisysteme: IDEFS, SCSIFS, HostFS bei Emulatoren)
drive 0 – wechselt zum Laufwerk 0 des derzeit ausgewählten Dateisystems
basic – wechselt zum eingebauten BASIC-Interpreter
modules – zeigt alle momentan aktiven Module
rommodules – zeigt den Zustand aller ROM-Module an – “unplugged” oder “dormant” sagt: derzeit nicht aktiv!
rmreinit <Modulname> – zum Reaktivieren eines Moduls im Zustand “unplugged”

Wer mehr wissen will, liest hier das Originalhandbuch, ab Seite 127 (PDF-Seite 146) wird es interessant.

…to be finished…Systemvariablen, Obey-Skripte, typische Obey-Kommandos…

Kapitel 5 – RISC OS – Die mitgelieferten Anwendungen

Kapitel 6 – Datentransfer von und zu RISC OS

Wichtig: Archive (ZIP o.ä.) immer unter RISC OS entpacken, damit die File-Type-Informationen der Dateien intakt bleibt! SparkPlug als Entpacker ist empfohlen…MimeMap erklären…HostFS-Extension-FileType-Mapping…

…to be written…

Kapitel 7 – Interessante Software

…to be written… !Zap, !StrongEd, !StrongHelp, !SparkFS, !SparkPlug, !ZipEE, !ArcFS, !Memphis, !Thump, !PrivateEye, !Browse, !FTPc, !GhostScript, !DiscSpace, !XChars, !AppDock2, GhostScript/GView

Kapitel 8 – Troubleshooting

…to be written… wann wird von welchem Laufwerk gebootet oder auch nicht? Warum startet RISC OS nicht in den Desktop? Warum werden Schriften so langsam gezeichnet? Warum ist das Tastaturlayout englisch? Wo kommt die falsche Zeitzone her?

Draft-Textstücke, die irgendwann in die Gesamtstruktur eingepasst werden

Lokalisierung, Tastatur, Datum, Uhrzeit, Zeitzone, Sommerzeit

Manchmal empfängt einen das Bild einer übergroßen Diskette beim Bootvorgang, die manchen an den Amiga erinnert. Unter RISC OS ist das aber das Zeichen, dass ein “Territory” konfiguriert ist, das im ROM nicht vorhanden ist und auf dem Bootlaufwerk nicht gefunden wurde. Die dringende Empfehlung: das UK-Territory verwenden, das macht man per

co. territory 0

Trotz UK-Territory kann man andere Einstellungen unabhängig auf “Deutsch” stellen. Z.B. eine deutsche Tastatur konfiguriert man dauerhaft per

co. country germany

Wenn man nur temporär das Tastaturlayout wechseln will, geht das per

keyboard germany

Die richtige Zeitzone setzt man per

co. timezone +1

und dann noch für die Sommerzeit

co. dst

oder für die Normalzeit

co. nodst

Über Dateisysteme

RISC OS unterstützt eine beliebige Anzahl Dateisysteme. Jedes Dateisystem kann 8 Laufwerke verwalten, per Konvention gilt: 0-3 sind die Laufwerke mit wechselbaren Medien (z.B. Disketten), 4-7 sind die festen Laufwerke (Festplatten). Das ADFS-Dateisystem ist standardmäßig eingebaut und verwaltet sowohl Floppies als auch IDE-Festplatten (nur neuere Hardware). Viele Emulatoren bieten zusätzlich noch HostFS an, wo man je nachdem ein oder mehrere Verzeichnisse des Rechners, auf dem der Emulator läuft, einbinden kann.

Der Verzeichnistrenner unter RISC OS ist der Punkt, Dateinamenextensions im DOS-Sinne gibt es nicht, die Typisierung von Dateien erfolgt über den sogenannten FileType, eine Zahl zwischen 0 und &FFF. Es kann keine Dateien mit gleichem Namen und unterschiedlichem FileType geben. Der absolute Pfad einer Datei sieht z.B. so aus: ADFS::0.$.Hello.World

Also die Datei “World” im Verzeichnis “Hello” welches seinerseits im Hauptverzeichnis liegt (symbolisiert durch “$”) auf Laufwerk 0 des Dateisystems ADFS. Wichtig: RISC OS-Dateisysteme sind stets case-insensitiv.

Das native Dateisystem unter RISC OS nennt sich “Filecore” – ADFS ist quasi nur der Hardware-Treiber für Filecore. Das Filecore von RISC OS 2 und 3 hat unschöne Beschränkungen: in einem Verzeichnis dürfen maximal 77 Dateien oder Verzeichnisse liegen, und die maximale Länge eines Dateinamens ist 10 Zeichen. Die gesamte Pfadlänge darf 240 Zeichen nicht überschreiten.

Schnellkurs: RISC OS auf dem MIST(er)-Board

s.o.

Schnellkurs: RISC OS auf x86 mit Arculator

…to be written…

Schnellkurs: RISC OS auf dem Raspberry Pi

…to be written…

Schnellkurs: RISC OS auf echter Hardware

Hier hat man den Vorteil, dass man nicht lange nach dem ROM-Image suchen muss, denn das ROM ist schon eingebaut 🙂

Gleich ein Hinweis zum häufigsten Defekt: alle Modelle ab dem A3000 haben einen Akku zum Stützen des CMOS und der RTC auf dem Board. Oftmals suppt hier der Akku auf das Board und zerstört entscheidende Teile wie z.B. den CMOS-Chip und Leitungen auf der Platine. Hier http://www.retro-kit.co.uk/page.cfm/content/Restoring-an-A5000/ gibt es eine komplette Reparaturanleitung für den A5000, hier für den A3000 http://www.retro-kit.co.uk/page.cfm/content/Acorn-BBC-A3000-Battery-Maintenance/.

Ein typisches Problem (oft aufgrund eines kaputten, mindestens aber entladenen Stützakkus): der angeschlossene Bildschirm zeigt kein Bild. Das kann an einem schrägen CMOS liegen oder an einzelnen komischen Einstellungen für eine andere Bildschirm-Konstellation. Setzt man ganz neu auf, empfiehlt sich zuerst ein CMOS-Reset. Dazu drückt man entweder die Taste “R” (Bildschirm braucht Composite Sync) oder die Taste “T” (Bildschirm braucht HSync/VSync getrennt – Achtung, nur verfügbar ab A3000 und A540, und bei jenen beiden zusätzlich über Jumper zu konfigurieren!) und schaltet den Rechner ein. Bekommt man so schon ein Bild, kann man über die Kommandozeile nun bequem den MonitorType konfigurieren: Für einen 15kHz-tauglichen Bildschirm wie z.B. einen Fernseher mit Scart-RGB-Anschluss oder einen alten TV-Type-Monitor (C64, Amiga):

con. monitortype 0

Für einen “echten” Multiscan-Monitor (typischerweise mindestens 15-38kHz Zeilenfrequenz):

con. monitortype 1

Für einen heute typischen VGA-Monitor (typischerweise mindestens 31kHz Zeilenfrequenz):

con. monitortype 4

Bildschirmmodi sind nummeriert. Eine Auswahl an interessanten Modi:

Mode 12 – 640×256, 16 Farben, 50 HZ (PAL-kompatibel)
Mode 15 – 640×256, 256 Farben, 50 Hz (PAL-kompatibel)
Mode 27 – 640×480, 16 Farben, 60 Hz (VGA-kompatibel)
Mode 28 – 640×480, 256 Farben, 60 Hz (VGA-kompatibel)
Mode 31 – 800×600, 16 Farben, 60 Hz (SVGA-kompatibel)

Mode 31 ist nur auf der neueren Hardware (A540, A3010, A3020, A4000, A5000, A4) verfügbar, auf der Archimedes-Hardware nur dann, wenn ein VIDC-Enhancer nachgerüstet wurde. Die VGA-Modi 27 und 28 produzieren auch nur auf der neueren Hardware ein exaktes VGA-Timing (Zeilenfrequenz 25,175 MHz), was allerdings nach meiner Erfahrung kein Problem bei Nutzung der Archimedes-Hardware ist, es sei denn man setzt einen Festfrequenz-VGA-Monitor ein – das dürfte eher selten sein – oder einen Fernseher mit VGA-Eingang, der sehr genau auf VESA-Modes getrimmt ist.

Außerhalb des Desktops kann man per Kommandozeile den Bildschirmmodus mit

mode <Modenummer>

umschalten, wenn der Desktop aktiv ist geht selbiges mit

wimpmode <Modenummer>

Die Sync-Einstellung kann auch per Kommandozeile erledigt werden, dem T-Reset (HSync/VSync getrennt) entspricht

con. sync 0

und dem R-Reset (Composite Sync) entspricht

con. sync 1

…to be continued…

Wichtige Ressourcen im Internet:

http://chrisacorns.computinghistory.org.uk/
http://www.4corn.co.uk/
http://acorn.revivalteam.de/
viele Scans der alten Handbücher http://chrisacorns.computinghistory.org.uk/docs/Acorn/Manuals/Manuals.html
noch mehr Handbücher http://www.4corn.co.uk/articles/docs/
Original-Systemdisketten http://www.lewisgilbert.co.uk/archiology/osdiscs.html

Eine Menge Software vor allem aus früherer Zeit (RISC OS 3.1)

Referenzmaterial:

RISC OS 3 Einführung von Detlef Thielsch/a4com auf Deutsch http://riscos.openpandora.org/ROS_ein-col_A5.pdf
http://www.risc-os.de/artikel/desktop/index.html
http://www.raspberry-pi-geek.de/Magazin/2014/02/Alternatives-RasPi-Betriebssystem-RISC-OS
http://www.steve-potts.me.uk/rot/index1.html
Allerlei, auch historisches, RO-Versionsunterschiede… http://www.2a1p.de/start/index.shtml
schöner Einstieg (RPi RISC OS) von Theo Markettos: https://www.raspberrypi.org/forums/viewtopic.php?f=55&t=22093
http://www.2a1p.de/
First Steps with RISC OS 4

Neuer UserGuide von ROOL (WIP, Draft)

https://www.riscosopen.org/zipfiles/platform/common/UserGuide.pdf

Im weitesten Sinne:

Die guten alten Demos

Frohes Fest, guten Rutsch, auf ein Neues in 2018

2017-12-26 16:22

Zunächst: allen treuen Lesern dieses Blogs wünsche ich ein Frohes Fest und einen guten Start in 2018 – ich bedanke mich für die entgegengebrachte Aufmerksamkeit und das viele Lob.

2017 empfand ich RISC OS-technisch als eher durchwachsen. An der Hardwarefront wurden ARMX6 und Titanium durch verbesserte OS-Versionen verfeinert, der RPi 3 und damit ARMv8 etablierte sich und zog den üblichen Versionswahnsinn nach sich, weil ARM ja mal wieder etwas sparsam bei der Rückwärtskompatibilität war.

RISC OS selbst war auch eher sanften Verbesserungen unterworfen. Hauptpunkt vermutlich die EDID-Unterstützung, die aber immer noch teils überraschende Effekte zeitigt. RC15 für die Pis war sicher ein Meilenstein, für Newcomer und Zurückkommer ist es nun wieder deutlich unkomplizierter, einen RPi unter RISC OS ans Fliegen zu kriegen. Nachdem Filecore nun mit 4KiB-Sektoren umgehen kann, ist nun auch der Betrieb von 2 TiB-Platten möglich – wir warten aber weiterhin auf eine Version von HForm, die das auch formatieren kann, und natürlich auf die Möglichkeit vernünftig Partitionen unter ADFS und SCSIFS zu verwalten. Fortschritt gab es an der Dokumentationsfront, das “User Manual” hat große Fortschritte zu verzeichnen, und das BBC BASIC-Referenzhandbuch gibt es in einer überarbeiteten Neuauflage. Auf echtem Papier. So richtig gedruckt.

Es gab ein neues DDE-Release, Nummer 28. Auch hier eher Evolution als Revolution. Bei einem Toolset, dass das Betriebssystem baut, keine schlechte Strategie.

Ansonsten war es softwaretechnisch m.E. eher verhalten. Die Webkit-basierten Browser erfuhren einige Verbesserungen, und es gab mit dem OBrowser den Versuch, die RISC OS-Integration dieser Browser mit einfachen Mitteln zu verbessern.

Adrian Lees hat Aemulor kostenlos freigegeben in der Version 2.40, die nun auch ARMv8-Unterstützung hat und auf aktuellen RISC OS-Builds in High-Vector-Konfiguration läuft – meine diversen Versuche auf Pi3 und Ti zeigten aber noch einige Ecken und Kanten. Demnächst mehr dazu auf diesem Blog.

Eines der wenigen Tools, die seit Jahren stetig weiterentwickelt werden, ist ADFFS – Jon Abbott ist hier unermüdlich dabei. Was anfangs ein simpler ADFS-Emulator war um auf den alten Archies mit Floppy-Disc-Images arbeiten zu können, ist inzwischen ein kompletter High-Performance-Emulator, um die Spiele der 80er auf allen RISC OS-Maschinen bis zum neuesten ARMv8-Pi 3 wiederaufleben zu lassen. Nebenbei hat Jon auch gleich das Geheimnis des IDE-ADFS-Problems gelöst, warum die alten Kisten z.B. mit CF-IDE-Adaptern oft nicht richtig zusammenarbeiten können.

Auch Fred Graute mit StrongEd ist emsig an der Weiterentwicklung und reagiert sehr schnell auf etwaige Bugs. Kompliment von mir.

Aus deutschsprachigen Landen sind Thomas Milius mit seiner SmartHome-Steuersoftware zu nennen und Anton Reiser, dessen neueste Schöpfung ein Utility zur Behandlung von Photoshop-Dateien ist. Auch Martin Würthner hat nach fünfjähriger Kunstpause mit Artworks 2.X3 endlich wieder ein neues Upgrade am Start.

Was kommt 2018? Endlich das neue Release von CDVDBurn. Versprochen. Und ich hoffe auf Fortschritte bei der Emulator-Front – RPCEmu auf Qt-Basis und damit eventuell auch eine RISC OS-Version davon, die Archimedes-Emulation in MAME, Fortschritte bei ArchiEmu, Aemulor-Verbesserungen, und die vage Hoffnung auf eine Fortentwicklung des Archimedes-Core in MIST und MISTer.

1 2 Weiter »

Mist

ACHTUNG

ENDE ACHTUNG

Vorbemerkung

Kapitel 1 – Einführung

1.1 RISC OS

1.2 Emulieren, simulieren oder in echt?

1.3 Andere Einführungen

Kapitel 2 – Installation und Konfiguration

2.1 MIST und MISTer

2.2 Reale Hardware

2.3 Emulatoren

Kapitel 3 – RISC OS – Der Desktop

3.1 Die Maus

3.2 Pinboard und Iconbar

3.3 Der Filer

3.3.1 Dateien

3.3.2 Verzeichnisse

3.3.3 Anwendungen

3.3.4 Arbeiten mit dem Filer

3.3 Der Task Manager

Kapitel 4 – RISC OS – Die Kommandozeile

Kapitel 5 – RISC OS – Die mitgelieferten Anwendungen

5.1 Der Texteditor !Edit

5.2 Das Zeichenprogramm !Draw

5.3 Das Malprogramm !Paint

Kapitel 6 – Datentransfer von und zu RISC OS

Kapitel 7 – Interessante Software

Kapitel 8 – Troubleshooting

Draft-Textstücke, die irgendwann in die Gesamtstruktur eingepasst werden

Post Navigation

Statisches

Such’ Dir was

Gegenwart

Vergangenheit

Kategorien

Links

hubersn Blogs

Kommentare

Abonnieren