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, A4xx und A540 lief und auf den danach, aber vor dem Risc PC erschienenen Maschinen A3000, 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, 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 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)

2.3 Emulatoren

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

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

5.1 Der Texteditor !Edit

…to be written…hier das Tutorial aus dem RISC OS 3.7 User Guide

5.2 Das Zeichenprogramm !Draw

…to be written…hier das Tutorial aus dem RISC OS 3.7 User Guide

5.3 Das Malprogramm !Paint

…to be written…hier das Tutorial aus dem RISC OS 3.7 User Guide

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) 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 (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, 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.

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

  • mode <Modenummer>

umschalten, wenn der Desktop aktiv ist geht selbiges mit

  • wimpmode <Modenummer>

…to be continued…

Wichtige Ressourcen im Internet:

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

Referenzmaterial:

Neuer UserGuide von ROOL (WIP, Draft)

Im weitesten Sinne:

Die guten alten Demos