Geschichten vom Dateisystem

2015-06-06 01:39

RISC OS macht bekanntlich vieles anders als andere Betriebssysteme. Besonders augenfällig ist das im Bereich Dateisysteme, was regelmäßig für Verwirrung sorgt. Dieser Artikel soll helfen, den Überblick zu bewahren.

Beteiligt am bunten Filesystem-Treiben unter RISC OS sind beispielsweise folgende Kandidaten:

  • Fileswitch
  • Filecore
  • SCSIFS, ADFS, SDFS, IDEFS…
  • CDFS, CDROMFS
  • DOSFS, Fat32FS, Win95FS
  • SparkFS, TBAFS, X-Files…
  • Sunfish, ImageNFS, NFSClient, LanManFS, LanMan98…
  • HostFS
  • PipeFS

Vorabinfo: Image-Filing-Systeme

Eine Besonderheit von RISC OS ist die Unterstützung von Image-Filing-Systemen. Darunter versteht man die Möglichkeit, eine einzelne Datei (oder auch ein ganzes Medium wie eine Festplatte, ein USB-Stick oder eine Diskette) als Verzeichnis zu behandeln. Bekannte Implementierungen sind z.B. DOSFS (Zugriff auf FAT-Medien) oder SparkFS (Zugriff auf Archive wie ARC, ZIP und ARJ). Für viele Operationen sind solche Images nicht von normalen Verzeichnissen zu unterscheiden – von der Kommandozeile aus z.B. kann problemlos in den Innereien einer ZIP-Datei herumgefuhrwerkt werden, wenn SparkFS aktiv ist. Alles funktioniert völlig transparent. Nur auf SWI-Ebene kann man herausfinden, ob ein Objekt ein „File“ ist, ein „Directory“ oder ein „Image“ – wobei das „Image“ auf dieser Ebene dann entweder als File oder als Directory bearbeitet werden kann.

Die Basis: Fileswitch

Basis aller Dateisystem-Dinge ist Fileswitch. Hier registrieren sich alle tatsächlichen Dateisysteme (egal ob „echte“ oder „Image-Filing-Systeme“ mit ihren „Entry points“). Hier sind die SWIs definiert, die in RISC OS die Schnittstelle zum Dateisystem bilden, von OS_Args über OS_File bis OS_GBPB.

Fileswitch definiert die „special characters“ von RISC OS-Dateisystemen wie „$“, „:“, „&“ und „%“ und die Wildcards „*“ und „%“, legt fest dass der Verzeichnistrenner „.“ ist und beschäftigt sich mit den berühmten 8 Bytes, die entweder 5 Byte Datestamp + 12 Bit Filetype repräsentieren oder 4 Byte Load address + 4 Byte Exec address. Dazu gibt es noch ein volles Word Attribute.

Fileswitch ist ansonsten weitestgehend agnostisch gegenüber Implementierungsdetails. Zeichensatz? Physikalische Abbildung der logischen Verzeichnisstruktur auf dem Datenträger? Maximale Länge eines Dateinamens? All das bestimmt die Implementierung des Fileswitch-Clients. Die API ist leider nur 32bittig, d.h. die maximale Dateigröße ist auf 4 GiB begrenzt (lange Zeit (vor RISC OS 5.22) konnte Filecore sogar nur 2 GiB-Dateien verwalten). Wichtig zu wissen: Fileswitch ist inhärent case-insensitiv.

An dieser Stelle sollte aber beachtet werden, dass zwar Fileswitch gegenüber vielen Details agnostisch ist, aber leider nicht jede Software, die Fileswitch verwendet. Denn die meisten Entwickler testen ja mit real existierenden Dateisystemen, und oft nur mit einem – Filecore. Wenn sich dann andere Dateisysteme zwar API-konform, aber nicht gleich wie Filecore verhalten, führt das oft zu Verdruss. Beispiele in der Vergangenheit waren das Enumerationsverhalten von Verzeichnissinhalten bei Fat32FS, HostFS oder Sunfish.

Übrigens ist das Dateigrößenlimit von 4 GiB ein größeres Problem, als es zunächst scheint. Denn es limitiert nicht nur (logischerweise) die Größe einer Datei, sondern auch die Größe des Mediums, das ein Image-Filing-System verwalten kann. Deshalb ist DOSFS nicht in der Lage, mit FAT-formatierten USB-Sticks umzugehen und man benötigt Fat32FS, das als „echtes“ Dateisystem implementiert ist und daher nicht an das 4 GiB-Limit der Image-Filing-Systeme gebunden ist.

Das native Dateisystem: Filecore

Filecore hat eine lange Historie bis zurück in die Zeit der 8-Bitter. Von Anbeginn der RISC OS-Zeit war das „Filecore E“-Format das native Dateisystem auf Disketten und Festplatten. Lange Zeit (bis RISC OS 4) ein Ärgernis, da limitiert auf maximal 10 Zeichen pro Dateiname und 77 Objekte in einem Verzeichnis. Aber ziemlich clever, was die Platzausnutzung des Mediums angeht (über „shared fragments“ erreicht man eine feinere Granularität als die Blockgröße) und die Optimierung mit automatischer Defragmentierung.

Verschiedene RISC OS-Versionen haben unterschiedliche Limitierungen bezüglich Filecore. Alles bis einschließlich RISC OS 3.5 hatte eine maximale Partitionsgröße von 512 MiB (nicht zu verwechseln mit dem alten BIOS-PC-Limit von 504 MiB), alles bis einschließlich RISC OS 3.7x konnte nur 10 Zeichen pro Dateiname und 77 Objekte pro Verzeichnis.

Aktuelle Limits bei RISC OS 5 sind 256 GiB pro Partition bei einer Blockgröße von 512 Bytes. Theoretisch kann Filecore auch andere Blockgrößen (traditionell 1024 Bytes, inzwischen auch 2048 und 4096 Bytes), aber das wird meines Wissens derzeit von keinem Filecore-Client unterstützt.

Jede Filecore-Instanz kann maximal 8 Geräte verwalten, 4 Festplatten und 4 Wechselmedienlaufwerke. In der Theorie wurde das RISC OS 5-Filecore durch einen neuen Aufruf erweitert, um theoretisch bis zu 256 Geräte mit jeweils bis zu 16 EiB (also 16 Milliarden GiB) zu verwalten. Meines Wissens ist das aber nicht ausimplementiert. Insbesondere größere Medien wären schlecht zu handhaben, weil die Größe der Filecore-Map linear mit der Größe des Mediums wächst und vollständig im Hauptspeicher liegen muss.

Geht bei Filecore etwas schief, sind die Bordmittel um etwas zu retten sehr begrenzt. Der *CheckMap-Befehl kann zwar die Map auf Konsistenz prüfen, aber wenn sie inkonsistent ist, gibt es keine Lösungsmöglichkeit. *Verify prüft im Prinzip nur, ob die einzelnen Sektoren bzw. Blocks lesbar sind. Man muss kaputte Sektoren dann von Hand per *Defect als kaputt markieren.

Deshalb sollte jeder RISC OS-Benutzer auf jeden Fall DiscKnight von David J. Ruck in seiner Werkzeugkiste haben. Und zwar auf jedem Medium – besonders auf Netzwerkmedien, auf die man auch im Falle des Falles zugreifen kann, wenn die Platte oder der USB-Stick nicht mehr wollen. Schmale 10 UKP sollte das jedem wert sein.

Besondere Vorsicht ist auch beim Löschen geboten. Es gibt hier keinen (sicheren) Weg zurück, schon der nächste Schreibvorgang kann die soeben gelöschten Daten unwiederbringlich überschreiben. DiscKnight hat deshalb ein Feature, den freien Speicherplatz einer Filecore-Partition in eine Datei zu verwandeln, so kann man ggf. gelöschte Daten wiederherstellen.

Die Brücke zur Hardware: ADFS, SCSIFS, SDFS, IDEFS

Jeder RISC OS-Nutzer kennt ADFS. Ursprünglich (RISC OS 2, Archimedes, als Festplatten noch unsäglich teuer waren) als ADFS::0 der Zugang zum einzigen Diskettenlaufwerk, wird es später um ST506-basierte Festplatten (MFM) und noch später um IDE-basierte Festplatten erweitert. Eines blieb immer gleich: ADFS unterstützt nur eine Partition. Von Drittherstellern gibt es BDFS und EADFS mit Multi-Partition-Support.

ADFS ist, genau wie SCSIFS, SDFS und IDEFS, ein Filecore-Client. In anderen Worten: ADFS kümmert sich darum, Zugriffsroutinen bereitzustellen, um Blöcke von Geräten zu lesen und auf sie zu schreiben. Das logische Dateisystemformat steuert also Filecore, den Zugriff auf die physischen Geräte ADFS.

Selbiges gilt für SCSIFS, das aber nicht nur für die weitestgehend ausgestorbenen SCSI-Geräte zuständig ist, sondern auch für USB-Geräte vom Typ „Mass Storage“ – dazu wird über SCSISoftUSB ein Low-Level-Treiber in den SCSIDriver integriert, der USB-Geräte als SCSI-Devices bereitstellt, damit SCSIFS darauf zugreifen kann.

SDFS und IDEFS schlagen in dieselbe Kerbe, nur eben für Zugriff auf SD-Karten und IDE-Geräte, wobei IDEFS von Drittherstellern von IDE-Podules bereitgestellt wurde und meistens mehrere Partitionen unterstützt.

Durch die Konstruktion „xxFS ist das Dateisystem das ein Filecore-Client ist, Filecore ist ein Fileswitch-Client, aber der eigentliche Hardware-Treiber sitzt wieder in xxFS“ wurde der Filesystem-Stack von RISC OS oft als „upside-down“  charakterisiert.

Scheibenversteher: CDFS, CDROMFS

Mit CDFS und CDROMFS verlassen wir die Welt der Filecore-Clients und nehmen die ersten Dateisysteme, die direkt an Fileswitch andocken, unter die Lupe.

CDFS war anfangs eine „SCSI-only“-Veranstaltung und konzentrierte sich ganz auf das ISO9660-Format, dem Standard für Daten-CDs. Mitte der 90er, als CDROM-Laufwerke langsam gebräuchlich wurden, führte CDFS die Technik des „softloadable drivers“ ein – man konnte nun Module bauen (typische Namen: CDFSSoftSCSI2, CDFSSoftATAPI), die die Verbindung zur Hardware übernahmen. Praktisch jeder Anbieter von SCSI- und IDE-Podules hatte seinen eigenen Treiber, dazu kamen generische Treiber von EESOX und IOC (später Pulse Computer) für SCSI sowie Power-tec und EESOX für ATAPI.

CDROMFS von Warm Silence Software (geschrieben von Ian Fry) ist ein Ersatz für CDFS. Und zwar nur für das CDFS-Modul, CDROMFS benutzt die Treiberinfrastruktur von CDFS einfach weiter. CDROMFS versteht mehr Varianten von ISO9660, versteht Joliet und Teile von RockRidge sowie ein Subset von UDF. Außerdem ist CDROMFS ein Image-Filing-System, kann also ISO-Images direkt öffnen – CDFS kann das nur in Verbindung mit CDFaker.

CDFS wurde inzwischen auch weiterentwickelt und versteht seit RISC OS Select und RISC OS 5.20 ebenfalls Joliet.

Ausblick

Im nächsten Teil geht es um die „FAT-Versteher“ DOSFS, Fat32FS und Win95FS. Um ein paar interessante Image-Filing-Systeme wie DOSFS, Win95FS, SparkFS, TBAFS und X-Files. Um Netzwerk-Clients wie Sunfish, ImageNFS, NFSClient, LanManFS und LanMan98. Dazu ein kurzer Blick auf HostFS, dem Dateisystem der Emulatoren. Und eventuell PipeFS, das u.a. für den Zugriff auf USB genutzt werden kann.

Ein weiterer zukünftiger Artikel soll skizzieren, was im Bereich Dateisysteme in RISC OS geändert werden sollte. Bei RISC OS Open Ltd. gibt es ein offenes „Filesystem bounty“, das sich mit der Problematik der Partitionierung beschäftigt. Ein erster Schritt ist bereits getan. Die gesamte Roadmap ist hier und hier skizziert.

Nein, liebe c’t, RISC iX war nie im ROM

2015-05-24 01:04

Über merkwürdige Wege bin ich neulich auf einen Artikel über die ARM-Historie in der c’t gestoßen – schon sehr alt, von 2002 um es genauer zu sagen. Aber Fehler veralten ja nie, und so ist es mir ein Bedürfnis, der Welt mitzuteilen, dass die Idee, dass der R140 mit RISC iX im ROM ausgeliefert wurde, natürlich komplett absurd ist. RISC iX war schon immer nur auf der Platte, es wurde schon immer über RISC OS gestartet, welches das OS im ROM war.

Die Unschärfe beim Thema Lander und Zarch ist man inzwischen fast schon gewohnt, genauso wie kreative Schreibweisen wie RISC-PC oder RISC-OS. Und nein, es war nicht der „Cambridge Ring“, der von Acorn primär als Netzwerk bei den 6502-basierten Modellen verwendet wurde, sondern das gute alte Econet. Auch wenn es mal eine Broschüre von Acorn zum Cambridge Ring gab.

Bei dieser Gelegenheit habe ich auch den bisher einzigen Kommentar (von 2014) zum Artikel gelesen und mit einigen korrigierenden Hinweisen  versehen. Leute kommen ja auf Ideen…und die Amiga-Fraktion war bezüglich ihrer Brillen-Rosafärbung schon immer ganz vorne dabei.

RISC OS 5.22 im Schnelldurchlauf

2015-04-26 04:00

Rechtzeitig zur Wakefield Show wurde RISC OS 5.22 veröffentlicht. Bekanntlich folgt RISC OS 5 dem „ungerade-gerade“-Versionsnummernschema, wo die geraden Nummern die stabilen Releases repräsentieren und die ungeraden die Entwicklungsversionen.

Aus meiner Sicht relevante Verbesserungen:

  • Filecore kann jetzt nativ mit 2k- und 4k-Sektoren umgehen. Vor 20 Jahren wäre das obercool gewesen, weil man dann direkt PhaseChange- und MO-Laufwerke mit Filecore verwenden hätte können. Ist aber immer noch cool, weil es uns etwas Luft im Kampf mit den großen Festplatten verschafft – bisher gingen 256 GiB einigermaßen problemlos, mit 4k-Sektoren verschiebt sich das Limit damit auf 2 TiB
  • CDFS kann jetzt Joliet
  • LanManFS ist jetzt schneller (die Änderungen von Colin Granville, um die neueren Passwort-Varianten ab Windows Vista zu unterstützen, haben es leider nicht ins 5.22-Release geschafft)
  • wenn die Grafikhardware es kann, werden jetzt auch 4k- und 64k-Farben-Modi unterstützt
  • Verbesserung der DHCP-Unterstützung (Timeout, Hostname)
  • Sort-by-number im Filter (RISC OS Select/Adjust lässt grüßen)
  • Unterstützung für Alpha-Channel-Sprites, Drags werden jetzt mit Transparenz angezeigt
  • GraphicsV vorbereitet für zukünftige Erweiterungen (z.B. Multihead-Unterstützung)
  • EtherUSB-Verbesserungen von Colin Granville

Das stabile Release gibt es in den Geschmacksrichtungen IOMD (Risc PC, A7000(+), RPCEmu), Tungsten (IYONIX pc), OMAP3 (BeagleBoard(-xM), BIK, ARMini, Pandora, Touchbook, IGEPv2) und OMAP4 (PandaBoard (ES), ARMiniX, PandaRO).

ARMX6 und OMAP5 (IGEPv5) sind naturgemäß noch zu frisch, um schon im „normalen“ Release-Zyklus mitzumischen.

Weitere Infos bei RISC OS Open Ltd.

WebKit-Portierung rückt näher

2015-04-26 03:11

Aktuell ist mal wieder viel Bewegung im GCCSDK-Repository, Abteilung Autobuilder. Qt 5.4.1, Qt5Webkit, QtTestBrowser, Arora. Lee Noar committed wie der Wilde. Auch Chris Gransden, Meister der hundert Portierungen, mischt mit, wie man hier nachlesen kann.

Erfahrungsgemäß ist es ab hier noch ein gutes Stück Arbeit, bevor ein schnieker schneller stabiler Browser zur Verfügung steht. Aber der Anfang ist gemacht. Danke John, Lee, Chris, Alan, Theo und alle die sich rund um GCCSDK und das Tooling drumrum verdient gemacht haben.

RISC OS-Projekte: Qt portieren

2015-04-06 22:37

Der zweite Teil der Reihe „RISC OS-Projekte“ sollte ursprünglich von Oberflächenbibliotheken und deren Portierung handeln. Qt, GTK+, FLTK und wxWidgets sind da die interessantesten Kandidaten. Zur Portierung interessanter Software vornehmlich aus der Linux-Ecke wäre das eine wichtige Voraussetzung. Auch eine Portierung von WebKit wäre dadurch deutlich erleichtert.

Aus aktuellen Gründen will ich das Projekt etwas kleiner schneidern und nur eine Portierung von Qt kurz anreißen. Qt hat eine lange und bewegte Geschichte, die mit Trolltech begann und durch die Verwendung als Basis für den KDE-Desktop der breiten Masse bekannt wurde. Später wurde Trolltech von Nokia übernommen und Qt 2009 unter der LGPL veröffentlicht, nachdem jahrelang die Lizenzierungsfrage breitgetreten wurde. Qt ist in C++ geschrieben und gilt als einer der wenigen kompetenten Cross-Plattform-GUI-Toolkits. Qt zeichnet sich durch eine verhältnismäßig saubere API aus und wurde auf viele auch eher esoterische Systeme portiert, von Symbian bis Windows CE, von SailfishOS bis BlackBerry OS (QNX-basiert).

Qt ist inzwischen mehr als ein reines GUI-Toolkit, es gibt Module rund um Netzwerkzugriff (Qt Network) oder auch Datenbankanbindung (Qt Sql).

Viele Programmiersprachen wurden mit Anbindungen versehen, darunter z.B. Ada, Perl, Python und Haskell – auch hier also durchaus exotenfreundlich.

Und jetzt kommt der Gag: seit heute ist im GCCSDK-Repository im Autobuilder die Portierung von Qt 5.3.0 durch Lee Noar verfügbar.

Vielleicht hätte ich deshalb den Blogbeitragstitel in „Wunder geschehn“ umbenennen sollen.

Ich hatte noch keine Gelegenheit, ein paar einfache Tests damit durchzuführen, um herauszufinden, welchen Stand die Portierung hat und welche der vielen Qt-Module bereits portiert sind. Vielleicht ist es also verfrühter Optimismus, denn Qt ist groß und es ist kaum anzunehmen, dass ein initialer Port direkt alle Module mitportiert. Die Inhalte im Autobuilder legen aber nahe, dass Qt Core und Qt Gui die ersten beiden Module sind.

Bisher in der Reihe „RISC OS-Projekte“ veröffentlicht:

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.

RPCEmu unter Linux – ein Kochbuch

2015-03-28 00:28

Bekanntlich ist RPCEmu der beste frei verfügbare Emulator für IOMD-basierte Hardware (vulgo Risc PC und A7000), den es für die Geschmacksrichtung „Linux“ gibt. Während es für die Windows-User ein „ready-to-install“-Paket gibt und auch ein ZIP-Paket, das man einfach irgendwo auf die Platte extrahiert, heißt es bei Linux traditionell „compile from source“.

Ich will hier für eine aktuelle Ubuntu-Installation kurz die Schritte skizzieren, die einen zu einem funktionsfähigen RPCEmu mit Netzwerkunterstützung führen – auf der RPCEmu-Seite sind die Hinweise doch etwas verstreut, und einiges muss man sich zusammenreimen.

Das verwendete RISC OS ist natürlich RISC OS 5 von RISC OS Open Ltd.

RPCEmu Quellcode beschaffen

Hier gibt es zwei Möglichkeiten: Sourcecodearchiv von der RPCEmu-Seite  herunterladen, oder per Mercurial direkt das Source-Repository anzapfen. Ersteres ist etwas komfortabler, weil im Archiv bereits viele Dinge unabhängig vom Quellcode an der richtigen Stelle liegen. Will man letzteres tun, muss man Mercurial („hg“) auf die Kiste bekommen – der Paketmanager hält hier alles notwendige bereit (einfach „sudo apt-get install mercurial“ ausführen geht am schnellsten). Auschecken des tip-Standes (anderswo „Head“, „Trunk“ oder „Master“ genannt) ist simpel:

hg clone http://www.home.marutan.net/hg/rpcemu rpcemu

Egal für welchen Weg man sich entscheidet, man sollte am Ende ein „rpcemu“-Verzeichnis auf der Platte liegen haben, in dem sich der Quellcode im Verzeichnis src befindet.

RPCEmu compilieren

Zunächst sollte man sein Linux mit den notwendigen Libraries ausstatten. Gott sei Dank sind die Abhängigkeiten hier überschaubar: es braucht nur Allegro (mindestens Version 4.2, aber nicht Version 5; derzeit aktuell ist 4.4) und pthread (aka libpthread). Letzteres war bei mir schon installiert, ersteres kam über „sudo apt-get install liballegro4-dev“.

Über das config-Skript parametriert man alle notwendigen Dinge, vor allem aktiviert man den dynamischen Recompiler (vulgo „JIT“), weil sonst die Emulation doch eher gemächlich läuft: ./configure –enable-dynarec

Danach kommt dann der eigentliche compile-Vorgang, den man wie üblich per „make“ startet. Resultat ist ein Binary namens „rpcemu“, das theoretisch ausführbar wäre – aber es fehlt ja noch ein bisserl was.

RPCEmu vorbereiten

Hat man sich bei der Quellcode-Beschaffung vom Mercurial-Repository bedient, muss man etwas mehr tun. Dort, wo das rpcemu-Binary nun liegt, erzeugt man zwei Verzeichnisse: hostfs (dort liegt später das RISC OS-Dateisystem) und poduleroms (dort kommen RISC OS-Module rein, die RPCEmu dann automatisch ins ROM integriert, und zwar über den Podule-ROM-Mechanismus – genau so, wie z.B. bei physischer RISC OS-Hardware die Podules (Netzwerk, SCSI, IDE, USB…) ihre Treiber ins RISC OS einbinden). Ins poduleroms-Verzeichnis kopiert man jetzt die drei Dateien hostfs,ffa hostfsfiler,ffa SyncClock,ffa aus riscos-progs/HostFS und riscos-progs/SyncClock. Damit steht nun HostFS zum Booten zur Verfügung, und die RISC OS-Uhr wird regelmäßig mit der Uhr des Hostsystems abgeglichen.

Jetzt gilt es, die Konfiguration anzupassen. Das passiert in der Datei rpc.cfg. Damit unfallfrei gebootet werden kann, muss unbedingt
model = RPCSA
in dieser Datei stehen, da der „Dynamic Recompiler“ zwingend die StrongARM-Emulation voraussetzt, ansonsten kommt es zu bösen Instabilitäten. Um für die spätere Netzwerkkonfiguration schon gerüstet zu sein, kann man hier schon die Zeile
username = <your standard username>
eintragen – den Platzhalter mit dem Benutzer ersetzen, der den Emulator später ausführen wird.

Alle anderen Konfigurationen – Sound aktiv oder nicht, wieviel RAM und VRAM etc. – kann man später bequem über das RPCEmu-Menü setzen (Strg+Ende blendet das Menü ein).

RISC OS installieren

Letzter Schritt ist die Installation von RISC OS. Seit RISC OS 3.5 ist RISC OS ja quasi zweigeteilt: einmal das ROM, und einmal die „disc based components“, auch gerne mal vereinfacht „!Boot“ oder „Bootstruktur“ genannt.

Das ROM bekommt man natürlich von RISC OS Open Ltd. https://www.riscosopen.org/content/downloads/riscpc – abenteuerlustige Naturen verwenden einen 5.21-Nightly Build, eher konservative Nutzer begnügen sich mit der als stabil gekennzeichneten Version 5.20. Beiden gemeinsam ist, dass man in den Tiefen des jeweiligen ZIP-Archivs fündig wird: soft/!Boot/Choices/Boot/PreDesk/!!SoftLoad/riscos ist die Datei der Wahl, die ins Verzeichnis roms des RPCEmu kopiert werden muss.

Passend zur ROM-Version braucht man jetzt noch das „HardDisc4“-Disk-Image. Hier https://www.riscosopen.org/content/downloads/common kann man das runterladen unter „Disc based components“. Um es nochmal zu wiederholen, weil Fehler hier oft sehr merkwürdige Auswirkungen haben – wichtig: passend zur ROM-Version! Ich empfehle die „self-extracting archives“, dann braucht man nicht extra noch einen Entpacker. Die Datei kopiert man nach „hostfs“, damit sie von innerhalb RISC OS zur Verfügung steht.

Jetzt ist es endlich soweit, und RPCEmu kann gestartet werden: einfach rpcemu ausführen. Standardmäßig ist im mitgelieferten cmos.ram ADFS als Bootdateisystem konfiguriert, deshalb kommt man nicht mal in den Desktop. Also schnell von der Kommandozeile in RISC OS konfigurieren:
*co. filesystem HostFS
Dann einfach
*desktop
tippen und man kommt in die graphische Oberfläche. Hier auf das HostFS-Laufwerksitem clicken, das vorher dort platzierte HardDisc4-File mit dem Filetype „Utility“ ausstatten, doppelclicken und warten bis sich alles entpackt hat. Es entsteht ein Verzeichnis „HardDisc4“ – den Inhalt dieses Verzeichnisses ins Root verschieben.

Netzwerk einrichten

Die Kür ist die Netzwerkinstallation. Die soll hier gar nicht im Detail behandelt werden, denn die RPCEmu-Doku ist hier sehr gut und erlaubt ein schrittweises Einrichten.

In Kurzform:

  • rpcemu künftig per sudo starten
  • per iptables und sysctl das Tunnelling konfigurieren
  • im RPCEmu-Menü das Netzwerk aktivieren (Strg+Ende, Settings -> Networking -> IP-Tunneling)
  • RISC OS-Netzwerktreiber installieren
  • RISC OS-TCP/IP-Konfiguration durchführen

Quellen

RPCEmu-Homepage http://www.marutan.net/rpcemu/
Linux compile from source http://www.marutan.net/rpcemu/linuxcompile.html
RPCEmu networking http://www.marutan.net/rpcemu/manual/network.html
Linux networking: binary config http://www.marutan.net/rpcemu/manual/net-lin.html
Linux networking: IP tunnelling http://www.marutan.net/rpcemu/manual/net-lin-tun.html
Networking: RISC OS network driver install http://www.marutan.net/rpcemu/manual/net-ro.html
Networking: RISC OS configuration for IP tunnelling http://www.marutan.net/rpcemu/manual/net-ro-tun.html

Der Expertentipp zum Abschluss

Wer wie ich mal probeweise die Linux-Maschine virtuell eingerichtet hat (z.B. via VirtualBox), sollte darauf achten, im BIOS die Virtualisierungsoptionen einzuschalten (VT-x, Intel VT, AMD-V oder ähnlich). Sonst ist die Performance eher unterirdisch, und man kann auch auf 64bit-Systemen nur 32bit-Gastsysteme betreiben.

 

Aemulor-Innereien

2015-03-22 20:48

Adrian Lees, Autor von Aemulor (Pro) und Geminus, hat zwei Artikel ins Netz gestellt, die der eine oder andere vielleicht schon aus der Foundation RISC User kennt. Darin werden einige interessante Details zur Implementierung von Aemulor und Aemulor Pro beschrieben.

Wer die letzten zwölf Jahre unter einem Stein gelebt hat: Aemulor ist ein High-Performance-Emulator für 26bit-Software auf 32bit-only-Plattformen wie IYONIX pc, A9home, Raspberry Pi, BeagleBoard, PandaBoard und ARMX6. Aemulor Pro setzt noch einen drauf und bietet nicht nur eine Plattform für gewöhnliche WIMP-Anwendungen, sondern emuliert auch alles notwendige für Dateisysteme aller Art (Win95FS, LanMan98, CDROMFS) und bietet eine Emulation für sogenannte „low colour depth screen modes“ – neuere Systeme fangen meist erst bei 8bpp an, während bis zum Risc PC noch alles bis runter zu 1bpp unterstützt wurde – und tatsächlich wurde das auch von Anwendungen wie Sibelius 7 verwendet.

Besonders zur Anfangszeit des IYONIX pcs war Aemulor beinahe unverzichtbar, weil die Konvertierung der Anwendungen von 26bit nach 32bit doch recht zäh war, und außerdem absehbar war, dass einige wichtige Anwendungen wohl noch eine lange Zeit nicht konvertiert werden würden (Impression-Familie, Artworks, Photodesk) – dass heute eigentlich bis auf Impression und Sibelius keine der „großen“ Anwendungen mehr auf Aemulor angewiesen ist, sollte als positives Zeichen für die Plattform aufgefasst werden.

An dieser Stelle ein persönlicher Dank an Adrian Lees, der dieses Stück Software, das beinahe an Magie grenzt, über all die Jahre gehegt und gepflegt hat und den Nutzern der neuen Cortex-A8/A9-Plattformen kostenlos zur Verfügung stellt.

RISC OS-Projekte: ein kompetenter Browser

2015-03-11 13:45

In der Reihe „RISC OS-Projekte“ soll es um Anregungen gehen für Menschen mit zu viel Freizeit. Es sollen Projekte beschrieben werden, die sowohl interessant sind, technisch anspruchsvoll und mit hohem Mehrwert für die RISC OS-Community. Den Anfang macht quasi eines der größten denkbaren Projekte überhaupt.

Die Geschichte der Browser für RISC OS ist lang. Es begann mit ArcWeb und Webster im Bereich Freeware. Dann kam die lange Reihe an Versuchen, Browser zu verkaufen: Fresco (immer nur erhältlich im Gesamtpaket der ANT Internet Suite), Webite (als Teil von Termite Internet), WebsterXL, Acorn Browse, Oregano, Oregano 2. Ein kurzes Zwischenspiel gab es mit einer Portierung von Firefox 2, die aber recht langsam und instabil war und nicht wirklich in RISC OS integriert war. Aktuell ist nur einer übrig geblieben: NetSurf, der unter der GPL steht und ständig weiterentwickelt wird.

Das Problem: das Internet entwickelt sich weiterhin rasant weiter. HTML5 und CSS3 sind aktuell die Standards, dazu tiefe JavaScript-Integration zur DOM-Manipulation. Die ständig zunehmende Verwendung von komplexem JavaScript erfordert außerdem ausgefeilte Optimierungsmechanismen bei der JavaScript-Interpretation. NetSurf hinkt schon heute dem Stand der Technik weit hinterher und hat bis heute keine anständige JavaScript-Unterstützung. Die Ziele der NetSurf-Entwickler sind sicher weitgehend passend für RISC OS-Zwecke (speicherplatzsparend, schnell, kompakt, gutes schlankes UI), aber was hilft das, wenn moderne Webseiten schlicht nicht zugänglich sind? Das sollte nicht als Kritik an NetSurf missverstanden werden – die Entwicklerkapazitäten sind dort begrenzt, und der Wettlauf gegen die Aktualisierung der Standards ist kaum zu gewinnen ohne ein großes Vollzeit-Entwicklerteam.

Im RISCOSOpen-Forum gibt es dazu einen Thread mit einer recht interessanten Diskussion dazu.

Unterm Strich bleibt meines Erachtens nur eine sinnvolle Option: die Portierung von Firefox/Gecko oder WebKit/Blinks. Nur damit ist garantiert, dass der Browser anständig kompatibel ist und bleibt mit den aktuellen Inhalten des Webs. WebKit scheint rein vom Portierungsaufwand her die bessere Wahl zu sein – es ist die deutlich jüngere Codebasis, wurde schon auf viele auch spärlich ausgestattete Plattformen portiert, und scheint generell besser modularisiert zu sein als Firefox bzw. Gecko.

Also, frisch ans Werk. Es braucht jemand, der sowohl unter RISC OS als auch unter Linux zuhause ist. Jemand, der die UI-Toolkits unter Linux kennt und natürlich WIMP-Experte ist. Jemand, der C und C++ im Schlaf beherrscht. Jemand, der die notwendige Entwicklungsinfrastruktur aufsetzen kann und dann natürlich auch betreibt. Und jemand, der reichlich Freizeit hat, um das Projekt voranzutreiben. Mit anderen Worten: einer allein wird das wohl kaum schaffen.

Grobe Vorgehensweise: einen ausreichend leistungsfähigen Linux-Server anmieten. Die heutzutage notwendige Infrastruktur aufsetzen (Gerrit/Git, Jenkins, GCCSDK). Das WebKit-Git-Repo clonen. Die WebKit-Portierung finden, die RISC OS technisch am nächsten ist. Code branchen und anfangen, den technischen Minimaldurchstich zu implementieren (hier gibt es Hinweise dazu). Nach und nach die Lücken füllen – vermutlich wird es sinnvoll sein, einige der Mainstream-Libs zu portieren wie Cairo und Freetype. Die notwendigen Anpassungen für die RISC OS-Portierung als Patches upstream zur Verfügung stellen. Eine anständige RISC OS-GUI drumrumstricken. Herausfinden, dass WebKit inzwischen von Blink abgelöst wurde. Gehe zurück auf Los. Froh sein, dass man die Basislibs schon portiert hat.

Ein ironisch-sarkastischer Beitrag zum Browser-Thema findet sich hier. „Because there are four of you“ könnte zum geflügelten RISC OS-Ausspruch werden. Das Original von Peter Naulls ist auch immer noch von gewisser Aktualität und zeigt, wie alt das „Browser-Problem“ schon ist.

Bewegung im GCCSDK-Repository

2015-02-22 02:01

Um halbwegs auf dem Laufenden bezüglich der GCC-Entwicklung der Geschmacksrichtung RISC OS zu bleiben, schaue ich ab und zu mal rein, was im SVN-Trunk von GCCSDK so läuft.

Seit ein paar Tagen gibt es interessante Commits von Lee Noar, der schon der Hauptverantwortliche für den RISC OS ELF-Support war. Die Schlüsselworte lauten Clang und LLVM.

Clang ist – compilertechnisch gesprochen – ein Frontend für C, C++ und Objective-C, das an die Compiler-Infrastruktur von LLVM angeflanscht werden kann. LLVM arbeitet dann als Backend, um den von Clang gelieferten Input in was Maschinentaugliches zu verwandeln.

Warum Clang/LLVM anstatt GCC? Die Clang- und LLVM-Codebasis ist deutlich jünger und übersichtlicher, die Weiterentwicklung ist sehr dynamisch, der Compilevorgang viel schneller und speichersparender. LLVM kann Bytecode erzeugen, der dann in einer VM ausgeführt werden kann – daher hat LLVM auch seinen Namen.

Wo sind die Haken? Der ARM-Codegenerator von LLVM ist wohl hauptsächlich auf ARMv6/ARMv7 optimiert. Die Portierung auf non-Unix-Plattformen gilt als eher schwierig. Die Details bezüglich EABI/APCS-32 usw. sind bisher eher unklar. Also zumindest mir 🙂

Übrigens kann GCC per DragonEgg so umgedingst werden, dass LLVM als Backend verwendet werden kann.