Software-Klassiker zum Nachlesen: Ovation

2015-09-20 19:29

David Pilling hat heute verkündet, dass er den Source-Code eines seiner Frühwerke – dem DTP-Programm „Ovation“ – veröffentlicht hat.

Hier geht es zur entsprechenden Seite mit Download-Möglichkeit. Nur für den Source-Code wohlgemerkt, denn die Rechte für die Software liegen derzeit bei APDL. Nach dem Tod von David Holden soll die dort vertriebene Software irgendwann zum freien Download bereitgestellt werden – ich vermute, dass deshalb David die Zeit gekommen sah, den Source-Code freizugeben.

Ich finde vor allem den Text, den David zu Ovation geschrieben hat, sehr interessant. Denn er enthält ein paar ewig gültige Weisheiten der Softwareentwicklung, die ich folgendermaßen zusammenfassen würde:

  • Software, die gut aussieht, verkauft sich besser
  • Nur Wahnsinnige schreiben einigermaßen komplexe Software in Assembler
  • Wofür man in Assembler ein ganzes Team benötigt, kann selbst in einer assemblerartigen Hochsprache wie C ein einziger Entwickler leisten
  • Auf lange Sicht ist Assembler-Code praktisch unwartbar (siehe auch: Impression-X)
  • Nur weil etwas auf lange bis sehr lange Sicht die richtige Entscheidung war, heißt das nicht, dass man langfristig auch den Erfolg dafür erntet
  • die Software-Entwicklung früher – langsame Maschinen, noch langsamere Massenspeicher, wenig Speicher, kein vernünftiges Tooling – war eine echte Qual (meine Programmierkarriere begann auf einem Schneider CPC 464 – zeilenbasierter Editor, BASIC mit Zeilennummer und GOSUB als einzigem Merkmal strukturierter Programmierung, Speichermedium Datasette)

Manchmal hat man das Gefühl, dass die Software-Entwicklung unter RISC OS immer noch auf dem Stand Ende der 80er Jahre verharrt. Dazu muss man nur mal Diskussionen in diversen Foren verfolgen, wo immer noch das Hohelied auf den Norcroft C-Compiler oder Acorn BBC BASIC gesungen wird. Wirklich professionelle Software-Entwicklung mit den heute gängigen Tools – moderne Versionsverwaltung mit Git oder Mercurial, Continuous Integration, Cross-Compilation auf leistungsfähigen Rechnern, echte Hochsprachen – findet unter RISC OS kaum statt. Stattdessen typische 1-Mann-Projekte in BASIC und C. Was natürlich trotzdem gute Software hervorbringen kann. Aber unter deutlich erhöhtem Aufwand und nicht nachhaltig. Und erhöhter Aufwand ist der Tod für eine Plattform, deren aktive Programmierer man an zwei Händen abzählen kann.

Aber das wäre ein Thema für einen anderen Blog-Beitrag. Oder auch hunderte.

Der Otter ist gelandet

2015-09-12 16:57

Seit einiger Zeit zirkulieren in kleinem Kreis verschiedene Versionen des WebKit-basierten Browsers namens Otter, wie schon früher berichtet. Jetzt hat Chris Gransden, Meister der hundert Portierungen, den Otter in den Autobuilder gesteckt, was einem offiziellen Release gleichkommt. Siehe auch der entsprechende Thread im ROOL-Forum.

Der Otter-Browser nutzt als UI-Tookit Qt5, das vor einiger Zeit von Lee Noar auf RISC OS portiert wurde. Das führt leider dazu, dass Performance und Desktop-Integration sich leicht suboptimal gestalten. Aber lieber ein langsamer Browser als gar kein Browser. Schwierigkeiten gibt es vor allem noch auf der Javascript-Seite – hier ist nur der Interpreter und nicht der JIT aktiv, weil letzterer noch extrem absturzfreudig ist. Dadurch ist komplexes Javascript eher langsam. Aber um den heimischen Router zu konfigurieren, sollte es reichen.

Um nicht einzuschlafen, ist ein PandaBoard, ARMX6 oder IGEPv5 anzuraten. Ein Raspberry Pi 2 ist grenzwertig.

Jetzt, wo nachgewiesen ist, dass ein WebKit-basierter Browser durchaus brauchbar unter RISC OS auf existierender Hardware funktionieren kann, braucht es nur noch ein motiviertes Individuum, um eine etwas nativere RISC OS-Portierung von WebKit auf den Weg zu bringen.

Kleines Update für OpenVector, OpenGridPro und DrawPlus

2015-08-06 23:18

Das Triumvirat der ex-4Mation-Anwendungen hat ein Update auf Version 3.46 erhalten, hauptsächlich Bugfixes. Vor allem OpenVector ist ein echtes Kleinod, eine Art Super-Draw.

Runterladen kostet nix, und ARMv7-kompatibel sind die Dinger auch noch. Sourcecode ist verfügbar unter der GPL.

Ein Haufen Software (im Quellcode!) von David Pilling

2015-08-05 20:10

David Pilling, einer der bekanntesten Programmierer im RISC OS-Universum, hat sein Schatzkästchen geöffnet und ein wenig Quellcode zum Download bereitgestellt.

Besonders interessant: die Bibliothek namens XL. Langjährige RISC OS-Entwickler haben ja alle ihre eigene WIMP-Bibliothek von mehr oder weniger großem Umfang am Start, und David Pilling macht da keine Ausnahme. Kein Wunder, waren die Acorn-Angebote von RISCOS_Lib bis zur Toolbox doch mit großen Problemen behaftet. Ich schaue mir gerne Fremdbibliotheken an – API-Design ist hochinteressant und ein schwieriges Geschäft, da kann man von anderen viel lernen. Und sei es nur, wie man es nicht macht.

Ansonsten für mich interessant sind die Sourcen zu den TWAIN-Scannertreibern, zu SPrinter (für alle, die schon immer unter RISC OS einen Druckertreiber entwickeln wollten) und zu Snapper. Exoten-Bonus gibt es für CSFS, einer Auftragsentwicklung aus den NC-Zeiten.

Danke, David.

Neuigkeiten zum BeagleBoard-X15

2015-07-29 20:12

Es gibt Neuigkeiten zum BeagleBoard-X15 – und zwar zur Verfügbarkeit und zum Preis.

Auf der offiziellen Support-Seite kann man nun lesen, dass die „Unverbindliche Preisempfehlung“ bei 199 US$ liegt. Der erste Probefertigungslauf mit zunächst 50 Exemplaren läuft im Moment, die Testboards sollen dann Ende August soweit sein. Für die große Masse soll das Board dann über Distributoren wie Digi-Key und Mouser ab November verfügbar sein. Den Preis in Euro kann man auf den Seiten schon begutachten: 194,82€ genau.

Wer meine früheren Artikel zum Thema nicht gelesen hat, das Wichtigste zum BeagleBoard-X15 in aller Kürze:

  • TI OMAP5 Sitara AM5728 1,5 GHz (Dual-Core Cortex-A15)
  • 2 GB DDR3-RAM
  • USB 3.0 Host
  • Gigabit Ethernet
  • eSATA
  • 4 GB Flash on board

Gegenüber der einzigen echten Konkurrenz (ISEE IGEPv5) dürfte vor allem der niedrige Preis interessant sein.

GAG-Treffen 2015

2015-07-22 00:08

Vergangenes Wochenende war mal wieder GAG-Treffen in Siek, und traditionell war ich wieder mit dabei. Inzwischen ist das GAG-Treffen beinahe die einzige Möglichkeit in Deutschland, Gleichgesinnte in Sachen RISC OS persönlich zu treffen – dies auch ein Hinweis auf die Jungs von der Arche e.V., mal wieder ein Treffen im Unperfekthaus zu organisieren. Und vielleicht sogar einen Hinweis an mich selbst, ein allerletztes Treffen im wilden Süden zu veranstalten?

Jedenfalls ist das GAG-Treffen für mich immer eine Chance, lange aufgeschobene Dinge in Angriff zu nehmen. Diesmal auf der Tagesordnung stand z.B. der Otter-Browser (eine Qt-WebKit-Portierung), den ich einer intensiven Prüfung unterzog. Performance ist hier das große Thema, denn für RISC OS-Verhältnisse ist die Software riesig – der Startup dauert ewig (Raspberry Pi 2 mit schneller SD-Karte: knapp 30s), was nicht zuletzt an der neuen Welt der Shared Libraries liegt – viele kleine Dateien dauern eben länger als eine große Datei. Hier kann der Einsatz der RAM-Disc Wunder bewirken, was wieder mal zeigt, dass das ganze File-IO-Thema unter RISC OS dringend einer grundlegenden Überarbeitung bedarf – anständiges Buffering und Cacheing wären ein guter Anfang. Etwas frustrierend war die Tatsache, dass wir den Otter nur auf dem RPi 2 zum Laufen bekommen haben, nicht jedoch auf PandaBoard und IGEPv5. Grund weiterhin unklar.

Prinzipiell halte ich den Otter-Browser für einen großen Schritt in die richtige Richtung, auch wenn die derzeitige Lösung noch stark holpert. Die Frage ist, ob man auf der Qt-Basis eine performante und anständig in RISC OS integrierte Lösung ans Laufen bringt, oder ob man das große Rad drehen und WebKit direkt an RISC OS anflanschen muss.

Genug von der Browser-Geschichte. Ein Highlight war die Kurzdemo der neuen Khronos-Library, die von Lee Noar entwickelt wurde und die praktisch ein Wrapper-Modul um Linux-Code ist, der diverse Hardware-Features des Raspberry Pi (alle Varianten) zur Verfügung stellt, darunter Video-Overlays und Open GL. Die verfügbaren Beispiele sind noch sehr rudimentär und durchaus absturzwillig (wobei dann das Overlay erhalten bleibt und nur ein Reset hilft), aber die Software ist noch jung, gerade mal seit etwa einer Woche in der mehr oder weniger freien Wildbahn.

Ich widmete mich auch noch intensiv einer anderen Front: Emulation. ADFFS, ArchiEmu und ArcEm standen auf dem Programm. ADFFS war ein kompletter Fehlschlag – ich konnte keines der angeblich auf dem Pi unterstützten Spiele zum Laufen bringen, und finde das Handling zum Starten der Spiele sehr unergonomisch. Ich werde mich dieser Tage mal ins JASPP-Forum begeben, um die Probleme aufzuarbeiten. ArchiEmu habe ich nur kurz angetestet, hier erntete ich nur direkte Abstürze. ArcEm war etwas vielversprechender, aber die Ergonomie ist stark suboptimal – so muss man z.B. zu verwendende Floppies und Harddiscs nach einer bestimmten Konvention benennen, um sie verwenden zu können. Und es ist mir nicht gelungen, den selbstextrahierenden SparkPlug unfallfrei auf die emulierte MFM-Platte zu bekommen. Immerhin hat der Boot sowohl nach RISC OS 2 als auch RISC OS 3.10 geklappt. Ich denke, darüber gibt es mal einen eigenen Blog-Artikel.

Den ARMX6 (i.MX6-Basis) gab es ebenfalls zu sehen. Sauschnell (vor allem in Sachen Platte – S-ATA statt USB zahlt sich aus), aber eben leider mit dem üblichen üblen R-Comp-Preisaufschlag. Und wie sich rausgestellt hat gibt es doch an der einen oder anderen Stelle noch Kompatibilitätsprobleme zu beheben, aktuell macht Photodesk Probleme.

Neues vom JASPP – ADFFS 2.50beta und neue Spiele

2015-07-02 13:44

Jon Abbott hat wieder zugeschlagen. ADFFS 2.50beta heißt die neu freigegebene öffentliche Beta-Version der ursprünglich-mal-Floppy-Emulator-jetzt-universeller-Spiele-Emulator-Software, die in diesem Blog schon öfter Thema war. Der jetzt erreichte Meilenstein ist ein weitestgehend vollständiger Support der im Rahmen des Projekts bisher freigegebenen Spiele für die Plattform „Raspberry Pi“. Und hier kommt es auf die Feinheiten an, denn tatsächlich wird nur der Ur-Pi (also Model A, Model B und Model B+) unterstützt, nicht der neue Pi 2. Das liegt einfach daran, dass der Ur-Pi noch ARMv5-kompatibel ist, während der Pi 2 ARMv7 ist und das leider bei der Emulation der alten Welt einen riesigen Unterschied macht. Ich sage nur unaligned memory access.

Weitere gute Nachricht vom JASPP: es gibt nun eine Vereinbarung mit Artex Software, Eterna, Minerva und VOTI dahingehend, dass die alten Archimedes-Software-Schätzchen im Rahmen des Projekts veröffentlicht werden können. Wir dürfen uns also auf Klassiker wie Exodus, Rockfall, Ballarena oder Sunburst freuen.

Und Jon macht unermüdlich weiter: sein nächstes Projekt ist die Unterstützung von 26bit-Modulen in ADFFS. Bisher wurden zentrale Module immer als 32bit-Varianten bereitgestellt, meist waren das einfache Dinge wie Voice-Module oder Tracker-Player. Jetzt kommt also die generische Lösung, die einen ganzen Schwung von Spielen auf dem Raspberry Pi dann spielbar machen wird. Darunter alte Favoriten wie Sensible Soccer oder PipeMania.

Nut Pi für Raspberry Pi 2 verfügbar

2015-06-06 17:29

Bekanntlich basiert der Raspberry Pi 2 auf einer neueren ARM-Microarchitektur – ARMv7 statt ARMv6 mit v5-Kompatibilitätsmodus, Cortex-A7 statt ARM11. Das führte unter anderem dazu, dass das „Nut Pi“-Bundle von RISC OS Open Ltd nur auf dem Original-Pi lief.

Das hat sich nun geändert – ab sofort ist eine Neuauflage der Nut Pi SD-Karte am Start, bei der alle Programme sowohl auf dem RPi(+) als auch dem RPi 2 lauffähig sind.

Am Umfang hat sich nichts geändert – viele Programme sind im Bundle dabei, von einer Spezialversion von Messenger Pro über SparkFS bis PhotoDesk, Luafox und Writer+. Eine schöne Erstausstattung, aber dank des niedrigen Preises von 35 UKP zuzüglich MwSt und Versand auch für die alten Hasen interessant. Das ebenfalls enthaltene DDE – unverzichtbar, wenn man an RISC OS mitentwickeln will – kostet schließlich einzeln schon mehr.

Also meine Kaufempfehlung hat es.

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.