iMX6-HAL erreicht das ROOL-Repository

2017-03-10 19:50

Ich hatte es früher schon erwähnt: es lohnt sich immer, die Bewegungen im ROOL-Repository im Auge zu behalten. Seit einiger Zeit hat nun endlich der iMX6-HAL seinen Weg dorthin gefunden. Nebenbei: man hofft, dass der Code fehlerärmer ist als die Commit-Kommentare.

Der iMX6, der im Herzen des ARMX6 von R-Comp (und ja, ich würde gerne auf eine ARMX6-Seite verlinken, aber R-Comp ist eben R-Comp) in Form des Wandboard Quad schlägt, erhielt seine RISC OS-Weihen in proprietärer Form von R-Comp. Klar, wer entwickelt, will damit auch Geld verdienen. Die kommerzielle RISC OS-Lizenz von Castle hat für diesen Fall eine Spezialklausel: gegen ein paar Euro (maximal 10 UKP pro verkaufter Lizenz) müssen geänderte OS-Quellen zunächst nicht an ROOL zurückfließen, sondern man kann sich bis zu 2 Jahre Zeit erkaufen. Die waren im Falle des iMX6 jetzt rum.

Nächste Aufgabe: iMX6-ROM bauen aus den aktuellen Quellen.

Ada, RISC OS und ARMv8

2017-03-10 19:17

CDVDBurn ist in Ada geschrieben. Und wird mit dem einzigen Ada-Compiler compiliert, der je unter RISC OS existiert hat: GNAT 3.03, basierend auf GCC 2.7.2.1. Also Technik von 1996. Natürlich nicht 32bit-kompatibel, ich compiliere also entweder auf dem dicken PC im Emulator, oder per Aemulor auf dem ARMX6. Durch glückliche Fügung erzeugt der Compiler 32bit-kompatiblen Code (zumindest meistens – es gibt einige Ada-Features die man besser nicht nutzen sollte wie z.B. Representation Clauses) – das ARM-Backend des GCC konnte das eh schon länger, die GCC-Runtime habe ich damals 2002 als der IYONIX pc erschien aus einem GCC 2.95 extrahiert, und die GNAT-Runtime hat mir Martin Würthner persönlich auf Binärebene angepasst.

Nun hat sich allerdings in den letzten Tagen herausgestellt, dass der erzeugte Code doch nicht so ganz hasenrein war, was die 32bit-Kompatibilität angeht. Ein Sack voll deprecated LDM-Instruktionen haben sich in der GCC-Runtime gefunden, die zwar auf bisherigen 32bit-Maschinen – vom IYONIX über den Pi 1 bis zum ARMX6 – trotzdem funktioniert haben, aber beim Pi 3 mit einem gnadenlosen „Undefined Instruction“ abgebügelt werden. Konsultation mit Experten und nähere Analyse mit ARMalyser zeigten den Schuldigen: die GCC-Runtime enthält im main-Entrycode non-32bit-Code. Die Suche nach Sourcecode, auf dem die Runtime basiert, war leider nicht erfolgreich, und so versuchte ich mein Glück mit händischem Binär-Patch.

Scheint mein Glückstag gewesen zu sein: CDVDBurn läuft nun einwandfrei auf dem Raspberry Pi 3. Ich hoffe inständig, dass das auch so bleibt falls RISC OS auf weiteren ARMv8-Plattformen stattfinden wird. Ich bin zu alt für diesen Scheiß.

RISC OS auf Linux portiert

2017-02-13 23:09

Zugegeben, die Überschrift klingt irgendwas zwischen merkwürdig und erklärungsbedürftig.

Timothy Baldwin hat im ROOL-Forum genau das angekündigt: ein RISC OS, das unter Linux läuft. Und zwar nicht in einem Emulator, sondern nativ (falls es sich um ARM Linux handelt, sonst wird QEMU genutzt).

Ich habe es noch nicht selbst ausprobiert, aber was dort zu lesen ist, klingt schon sehr interessant (wenn auch noch nicht ganz produktionsreif). Im Prinzip wird das RISC OS-ROM-Image quasi als Linux-Anwendung ausgeführt. Im User-Space wohlgemerkt. Als Standard-Linux-Prozess. Ein spezielles Dateisystem, genannt IXFS, sorgt für die Verbindung zum Linux-Dateisystem und kümmert sich auch um die Speicherung der RISC OS-Spezialitäten (Load/Exec bzw. Filetype) in den Metadaten. Video-, Maus- und Tastaturtreiber verbinden sich via Unix Domain Socket (Interprozesskommunikation nach POSIX-Art – auch IPC genannt) mit einem Prozess, der dann z.B. für die Darstellung des „Bildschirms“ SDL2 verwendet.

Das Posting nennt auch ein paar Bereiche, wo es noch Schwächen gibt. Aber immerhin ein erster Schritt, und einige Anwendungen laufen bereits.

Hier ist das GitHub-Projekt zu finden.

Wie immer bei neuen Entwicklungen gibt es jede Menge Unwägbarkeiten, und es ist sicher ein typisches 80-20-Softwareprojekt – obwohl schon zu 80% fertig, wird die Perfektionierung noch sehr lange dauern. Aber sollte die Perfektionierung gelingen, ist das Projekt fast schon eine Revolution im RISC OS-Bereich. Es vereinigt die Vorzüge einer Emulationslösung mit den Vorzügen einer nativen Lösung. Gerade im Bereich der ARM-Boards gibt es ja eine Vielzahl von Geräten, auf denen Linux läuft, aber auf denen RISC OS niemals laufen wird, weil die Manpower für die Portierung fehlt und/oder gar nicht ausreichend Informationen über das verwendete SoC zur Verfügung stehen, um überhaupt eine Portierung zu ermöglichen (typische Beispiele sind SoCs von Rockchip, MediaTek und Allwinner, aber auch die Tegras von NVIDIA oder das Qualcomm-Zeugs oder die Samsung Exynos).

Optimistisch gesprochen ist ab sofort Linux der Hardware Abstraction Layer für RISC OS. Eine Revolution.

CDVDBurn für Titanium

2017-02-12 00:55

Die letzten Tage habe ich ein paar Stunden investiert, um CDVDBurn so anzupassen, dass S-ATA-Geräte am Titanium-Board unterstützt werden.

Die Anpassung an „yet another transport system“ ist eine regelmäßig wiederkehrende und zuweilen nervige Arbeit. Historisch hat CDVDBurn, als es noch CDBurn hieß und man das Jahr 1997 schrieb, nur SCSI-Laufwerke unterstützt. Die gute alte Zeit. Egal welche SCSI-Karte, alle unterstützten die von Acorn vorgegebene API, und es gab nur wenige böse Überraschungen (der Connect32 war mit frühen Firmwareversionen bei größeren Blockgrößen etwas instabil, und das EESOX-SCSI-Podule hatte etwas abweichende Vorstellungen, wie der SCSI_Op genau bestückt wird).

Dann kam IDE. Risc PC und A7000 verwenden ADFS zum Zugriff, bei Simtec- und APDL-IDE-Podules wurde jeweils eine ganz eigene API rund um das dort verwendete IDEFS verwendet. Das RapIDE-Podule hatte wieder eine andere Idee, immerhin war dort die ATAPI-API sehr ähnlich der bewährten SCSI-API. Also: 4 unterschiedliche Transporter für den Eintritt ins IDE-Zeitalter.

Dann kam neue Hardware, aber zum Glück verwendeten die RiscStation-Maschinen die Simtec-API und die MicroDigital-Maschinen die APDL-API. Erst der IYONIX pc machte das Fass wieder auf – aber die Anpassung war initial einfach: CD_SCSIUserOp wurde ins CDFS reingedengelt, mit einer SCSI-ähnlichen API, aber man musste CDFS-Control-Blocks verwenden statt der SCSI-ID. Erst nach und nach kamen Einschränkungen ans Licht, vor allem bezüglich der Auswertung von Fehlern per Sense-Request. Auch unschön: CDFS musste das Laufwerk auch tatsächlich erkennen, was nicht immer der Fall war. Der IYONIX hatte aber eine Alternative zu bieten: dort hat ADFS in der Version 3 das IDE-Zepter geschwungen, und hatte endlich eine ATAPI-API anzubieten (beim ADFS von Risc PC und A7000 musste man noch Magic betreiben, um ATAPI-Kommandos abzusetzen).

Dann fing wieder die Glückssträhne an: die RISC OS 5-API für USB setzte sich durch, und dort wurden die Geräte schlicht als SCSI-Geräte behandelt. RISC OS 5 hatte nämlich den klassischen Acorn-SCSIDriver so erweitert, dass nun – ähnlich der softloadable drivers bei CDFS – per SCSISwitcher unterschiedliche Hardwaretreiber eingebunden werden konnten. So hätte das von Anfang an laufen sollen, IDE-Geräte wären nur spezielle SCSI-Devices gewesen und alle wären glücklich und zufrieden. Also: alles klar bei BeagleBoard, PandaBoard, Raspberry Pi und Konsorten. Auch beim ARMX6 gab es kein neues Problem – der bindet S-ATA-Geräte (oder besser: DAS S-ATA-Gerät, denn er hat nur einen S-ATA-Anschluss und S-ATA-Multiplexer werden derzeit nicht unterstützt) per softloadable SCSI driver ein. Aber da niemand seine schnelle S-ATA-Platte gegen ein S-ATA-DVD-Laufwerk tauschen will, ist das nur ein theoretischer Glücksfall.

Wer nun aber dachte, dass die softloadable SCSI drivers der Weg der Zukunft sein würde, sah sich mit dem Erscheinen des Titanium-Boards eines Besseren belehrt. ADFS 4 wurde aus der Taufe gehoben. Mehr oder weniger kompatibel zum alten ADFS, aber nicht kompatibel genug: CDVDBurn fand beim Drive-Scan keine Laufwerke.

Gott sei Dank gab es aber eine einfache Möglichkeit, den IYONIX-ADFS-Transport so aufzubohren, dass nun sowohl der IYONIX als auch das Titanium-Board mit einem Transport-System unterstützt werden können. Angenehmer Nebeneffekt: statt jedes Laufwerk einer ATAPI-Erkennungsprozedur zu unterziehen, wird jetzt auf die Ergebnisse, die ADFS beim Device-Scan erzielt, direkt zugegriffen (per ADFS_IDEDeviceInfo). Die Testergebnisse meiner Titanium-Tester sind noch durchwachsen, aber das könnte andere Gründe haben.

Wer zufällig ein Titanium-Board sein eigen nennt und beim Testen helfen will – E-Mail genügt.

Erste Schritte mit MAME und der Archimedes-Emulation

2017-01-20 21:15

Zwei Tage ist es her, dass ich über die Archimedes-Emulation in MAME zuerst gestolpert und dann berichtet habe. Nun gibt es einen ersten Erfahrungsbericht über den langen, schmerzhaften Weg bis zum vertrauten Anblick des RISC OS-Desktops.

Zunächst: das MAME-Team scheint nicht viel von Dokumentation zu halten, zumindest die Dinge, die von der MESS-Seite eingebracht wurden sind sehr sparsam dokumentiert. Und irgendwie wird man das Gefühl nicht los, dass die MAME-Philosophie zwar sehr gut auf Spielautomaten-Emulation passt, bei Computern aber eher holprig ist. Aber aller Anfang ist ja bekanntlich schwer, und vermutlich liegt das nur an meinem einsetzenden Altersstarrsinn, dass sich doch gefälligst alle Emulatoren dieser Welt auch ähnlich verhalten sollten.

Aber ins Detail. Die Archimedes-Emulation (aa310 in der MAME-Abkürzung) hat zum Beispiel eine ganz genaue Vorstellung davon, welche Dateien unbedingt vorhanden sein müssen, bevor ein Start möglich ist. Dazu gehören ROM-Images und CMOS-Dateien. Die Dokumentation schweigt sich darüber aus, welche Dateien mit welchem Namen erwartet werden, aber man kann per

mame -listxml aa310

sich alles anzeigen lassen. Man erfährt dann, dass Arthur 0.30 und 1.20 sowie RISC OS 2.00, 2.01, 3.00, 3.10, 3.11 und 3.19 möglich sind. Benannt nach keinem einheitlichen Muster oder einheitlich in 4-ROMs-sind-4-Dateien-Form. Schade, schließlich gibt es ja die RISC OS Classic ROMs Collection, die hätte man ja durchaus als die kanonische Form verwenden können.

Merkwürdig: es wird auch eine CMOS-Datei erwartet (getrennt nach RISC OS 2 und RISC OS 3, aber keine speziell für Arthur), die ebenfalls – wie bei MAME üblich für ROMs – eine CRC und SHA1-Summe hinterlegt hat, also einen ganz bestimmten, vorbestimmten Inhalt haben muss. Seltsam für eine im Kern variable Datei – wöllte man fix gewisse Inhalte vorgeben, warum sie dann nicht gleich in MAME fest hinterlegen?

Wenn man dann sich entweder die benötigten Ressourcen selbst zusammengefrickelt hat (z.B. funktioniert es, wenn man die von anderen Emulatoren bekannten ic24.rom bis ic27.rom nebst cmos_riscos3.bin (z.B. von Arculator) ins Verzeichnis aa310 ins ROM-Verzeichnis kopiert) oder in den Weiten des Internets ein entsprechendes aa310.zip gefunden hat (nicht zu verwechseln mit dem alten, für MESS tauglichen a310.zip), kopiert man das in das ROM-Verzeichnis von MAME (egal ob noch im ZIP verpackt oder extrahiert in das Verzeichnis aa310).

So gerüstet, kann man nun das erste Mal die Emulation starten – entweder direkt MAME starten und sich durch die vielen emulierten Systeme hangeln, oder direkt per Kommandozeile

mame aa310 -bios 311

ein RISC OS 3.11 ordern. Nicht vom fehlschlagenden Selbsttest (roter Bildschirm) irritieren lassen, einfach kurz warten und das vertraute RISC OS-Startup-Banner begrüßt uns.

So weit, so gut. Und wie kriegt man jetzt die Software ins System? Wie immer bei Emulatoren: über Disketten-Images. MAME wird im Moment erweitert, um neben den üblichen ADF-Images auch APD und JFD zu unterstützen. Also ein paar ADFs nach mame\software kopiert, und man steht vor dem nächsten Rätsel: wie mounted man nun das Image? Des Rätsels Lösung: MAME bietet ein On-Screen-Menü, das man per Tastendruck auch „Scroll Lock“ aufrufen kann. Kleines Problem in meinem Falle: die Laptop-Tastatur hat keine „Scroll Lock“-Taste anzubieten. Aber es gibt Abhilfe: man kann über eine Kommandozeilenoption eine andere Taste definieren – exemplarisch für die Tab-Taste:

mame aa310 -uimodekey TAB -bios 311

Und schon kann man über den Menüpunkt „File Manager“ ein Floppy-Image auswählen, mit verschiedenen Mount-Optionen wie Read-Only oder Read-Write.

Ich wünsche fröhliches Experimentieren. Wer ein gescheites Frontend für MAME findet, bitte Meldung machen.

Multicore-RISC OS für Experimentierfreudige

2017-01-18 15:30

Zwei Wochen nach der ersten Ankündigung hat Jeffrey Lee Nägel mit Köpfen gemacht: hier ist Schritt zwei auf der langen Reise zu einem Multicore-RISC OS. Das dort verlinkte Archiv enthält die entsprechenden Sourcen und ein fertiges Raspberry Pi RISC OS-ROM-Image mit dem SMP-Modul, um auf RPi 2 und RPi 3 auf den drei bisher brachliegenden Cores Code zur Ausführung zu bringen.

Meine Zeiten als Low-Level-Frickler sind lange vorbei (mit der sporadischen Ausnahme, ATAPI/SCSI-Commands über den Bus zu schicken), und so überlasse ich gerne der Assembler-Fraktion das Feld für erste Experimente. Sagt mir Bescheid, sobald die Unterstützung für Ada-Tasking verfügbar ist 🙂

Archimedes-Emulation im MAME

2017-01-18 15:17

Heißt es „im MAME“ oder „in MAME“? Ich kann mich nicht entscheiden. Egal.

Durch einen Thread auf stardot.org.uk bin ich darauf aufmerksam geworden, dass im MAME (Multi Arcade Machine Emulator) inzwischen auch ein Archimedes-Emulator („Driver“ nennt sich das in der MAME-Sprache) seine Heimat gefunden hat.

MAME entstand ursprünglich als Emulator-Framework zur Emulation von klassischen Spielautomaten. Später gab es ein Schwesterprojekt namens MESS, das sich mit der Emulation von Computersystemen und Spielekonsolen befasste. Inzwischen sind beide unter dem Dach von MAME vereinigt, der damit eher zum „MME“ wurde.

Das erste Mal mit MAME in Kontakt kam ich durch den RISC OS-Port von Gareth S. Long, der auch Mitinitiator des MESS-Projekts ist. Ich denke es war 1998, die MAME-Version war 0.30 und im spieleunterversorgten RISC OS-Reich war es einer der wenigen Lichtblicke. Klar, ein StrongARM war vonnöten, und die emulierten Arcade-Automaten waren älteren Datums (Pac-Man, Frogger, Donkey Kong, Zaxxon, Bomb Jack, 1942, Xevious…), aber es machte trotzdem eine Menge Spaß.

Nun gibt es also für Windows, Linux und Mac eine weitere Möglichkeit neben Arculator und ArcEm um die goldene Archimedes-Zeit per Emulator neu zu erleben.

Ein erster Erfahrungsbericht folgt demnächst.

Multicore ante portas

2017-01-04 21:19

Jeffrey Lee war nicht faul über die Feiertage und macht uns aktuell das Maul wässrig.

Klar, es ist immer noch ein riesiges Stück entfernt vom eigentlichen Ziel, einem multi-threading multi-core all-singing all-dancing RISC OS. Aber ein Schritt nach dem anderen.

RISC OS-Wünsche zum neuen Jahr 2017

2017-01-03 00:49

Zu Weihnachten 2015 hatte ich neben den Weihnachtsgrüßen einen kleinen Wunschzettel verfasst. Diese Tradition will ich hier fortsetzen. Nebenbei: meinen Lesern alles Gute fürs Jahr 2017. Here we go again.

Unglücklicherweise sind die 5 Punkte von letztem Jahr noch offen, deshalb wiederhole ich sie hier:

  • neues CDVDBurn-Release
  • Basis-Multicoreunterstützung in RISC OS
  • die Vervollständigung der 32bit-ung von Impression-X
  • Runderneuerung der Filesystem-Architektur in RISC OS
  • BeagleBoard-X15 mit RISC OS-Port

Ersteres ist besonders ärgerlich, aber es gibt zwei „must haves“, die noch nicht fertig sind: Unterstützung für S-ATA auf dem Titanium-Board, und verbesserte Medienkompatibilität auf zumindest einem noch aktuell erhältlichen Laufwerk (BD-R, BD-RE, DVD-RAM, DVD+RW und DVD+R und/oder DVD-R).

Neue (zusätzliche) Wünsche habe ich auch noch:

  • Lösung des RISC OS-Browser-Problems (entweder durch Weiterentwicklung von Netsurf oder Verbesserung der WebKit-basierten Otter und QupZilla)
  • Verfügbarkeit einer Ready-to-run-VM für GCCSDK und Portierungen
  • WLAN-Unterstützung und IP-Stack-Update
  • Portierung aktueller VCS wie Git und Mercurial

Aus meiner Sicht ist die mangelnde Verfügbarkeit von WLAN-Unterstützung und gescheitem Browser genau das, was RISC OS von einer „allgemein nützlichen Lösung“ jenseits der Legacy-User trennt. Gerade mit Verfügbarkeit des On-Board-WLANs beim RPi 3 wird dieser Mangel noch ärgerlicher.

ADFFS 2.60 verfügbar

2016-12-22 23:35

Jon Abbott hat die Verfügbarkeit von ADFFS 2.60 verkündet. Wichtigste Neuerung ist die neue Implementierung der 50Hz-Synchronisation, um die originale Spielgeschwindigkeit in Verbindung mit tearing-freier Grafikdarstellung zu ermöglichen. Dazu kommen reichlich Bugfixes und die Vervollständigung der Kompatibilität auf den Pis zu solch großartigen Spielen wie Mig 29M Fulcrum oder Interdictor.

Leider zickt mein A3000 gerade etwas, so dass ich meine Testaktivitäten wohl hin zum RPi verlagern werde. Erste Maßnahme: Grafikausgabe auf echte 50Hz einstellen, ich hoffe mein Monitor spielt da mit.