Develop

Entwickeln für RISC OS

CDVDBurn für Titanium

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.

Multicore-RISC OS für Experimentierfreudige

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 :-)

RISC OS-Projekte: Qt portieren

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:

Bewegung im GCCSDK-Repository

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.