Cdvdburn

20 Jahre CD(VD)Burn

Man schrieb den 31.Oktober 1997. In London fand die Acorn World statt, und CDBurn wurde dort im Vertrieb von WSS (Warm Silence Software) zum ersten Mal öffentlich vorgestellt.

Man erinnere sich zurück: es war die letzte Acorn World, der Risc PC war noch „state of the art“ und hatte gerade durch den StrongARM eine Frischzellenkur erhalten. CD-Brenner waren teuer und nur als SCSI-Geräte erhältlich. CD-R-Medien kosteten mindestens 10 DM, oft auch 15 DM. 74min/650MiB waren die maximal erhältliche Kapazität. Fast unendliche Weiten in Zeiten, wo die Festplatten noch im deutlich einstelligen GB-Bereich unterwegs waren, vor allem in der Geschmacksrichtung SCSI waren 2 GB schon fast High-End. Ironischerweise wurde die Software selbst noch auf Floppy Disc verkauft. DD 800 KiB wohlgemerkt.

Der einzige unterstützte Brenner war der Philips CDD2000, die Variante CD2600 folge kurz darauf. Ich hatte damals das Glück, dass ich einen Brenner gekauft hatte, der eine öffentlich zugängliche Doku zum Command Set hatte – die Konkurrenz von Teac, Sony und Yamaha war da wesentlich verschlossener, man musste tatsächlich NDAs nach USA faxen, und die Antwort brauchte teilweise Monate. Von Teac habe ich bis heute nix gehört.

Die erste CDBurn-Version war „gerade so“ fertig geworden (und meine Entscheidung, die Software in Ada zu schreiben, ist im Rückblick auch nur durch eine Mischung aus Optimismus und Wahnsinn zu erklären) – die Audio-CD-Funktionalität war schon recht ausgereift, aber bei den Daten-CDs haperte es noch gewaltig. Es gab noch keine Möglichkeit, ein ISO-Image zu erzeugen, ehrlicherweise war es deshalb auch die Versionsnummer 0.99 – deshalb wurde ein quick’n’dirty port von mkisofs beigelegt, um zumindest nominell dieses Feature abhaken zu können. Auf der Acorn World sprach ich mit vielen potenziellen Käufern und versprach baldige Lieferung des ISO9660-Formatters – ein Versprechen, das viele vom Kauf überzeugte und das ich Gott sei Dank noch im selben Jahr mit dem Release 1.00 (ein kostenloses Update) halten konnte.

Einzige Konkurrenz damals war CDScribe von Eesox – die verkauften aber die Software nur im Bundle mit dem Laufwerk, und dieses auch noch gut doppelt so teuer wie das Laufwerk alleine kostete. Audiotechnisch war die Software auch stark unterbelichtet, und der beigelegte ISO9660-Formatter war auch nicht der Weisheit letzter Schluss. Vermutlich deshalb eroberte CDBurn den Markt im Sturm, obwohl gemessen an der PC-Konkurrenz doch eher featurearm und nicht billig.

Über die Jahre wurde featuretechnisch kräftig aufgerüstet, die Updates blieben kostenlos: Multisession-Unterstützung, Joliet-Unterstützung und konfigurierbares Namemapping für ISO9660, CD-RW-Unterstützung, Unterstützung aller MMC-kompatibler Laufwerke, IDE-Unterstützung für Risc PC/A7000, APDL/Microdigital und Simtec/RiscStation, Upgrader um endlich neue Versionen per Download anbieten zu können, und schließlich 32bit-Kompatibilität und Unterstützung für den IYONIX pc. Abfallprodukt der IYONIX-Kompatibilität war die abgespeckte Version CDBurn Lite, die jedem Castle IYONIX pc beilag.

Besonders die 32bit-Kompatibilität halte ich bis heute für ein Wunder, das nur durch Dummenglück erklärbar ist. Klar, es hilft auch, wenn man einen Martin Würthner kennt, der mal kurzerhand eine GNAT-Runtime patchen kann. Aber dass das ARM-Backend des GCC 2.7.2.1 tatsächlich ARMv8-kompatiblen Code erzeugen kann, ist auch als so ein Wunder zu bewerten.

2004 gründete ich dann hubersn Software, um den Vertrieb in die eigene Hand zu nehmen. Es folgte die Integration der DVD-Unterstützung für die neue Generation DVD-Brenner, was die Umbenennung in CDVDBurn nach sich zog, um schon namentlich klar zu machen, dass nun sowohl CDs als auch DVDs gebrannt werden konnten.

Und damit endet die Geschichte der offiziellen Releases – bis heute sind die Ergebnisse der weiteren Entwicklung nicht in einem neuen Release gemündet, sondern werden nur an Interessierte als Beta-Testversionen verteilt. Dazu gehört die DVD-RAM-Unterstützung, die USB-Unterstützung für RISC OS 5, die Blu-Ray-Unterstützung, der CD/DVD/Blu-Ray-Extraktor, die ARMv7-/ARMv8-Kompatibilität für die neue Hardware-Generation vom BeagleBoard bis zum Raspberry Pi 3, die Unterstützung für das neue S-ATA-taugliche ADFS im Titanium.

Der letzte Plan war, all diese Erweiterungen in einem „20th anniversary release“ zu bündeln, aber es fehlte etwas Zeit, um die Sache abzurunden: BD-R und BD-RE in der Dual-Layer und XL-Variante ist noch nicht unterstützt, DVD-R kann nach wie vor nicht geschrieben werden, und an der Kompatibilität mit den modernen (sprich: noch im Handel verfügbaren) Laufwerken hapert es auch noch. Ziel wäre, ein USB-Laufwerk und ein S-ATA-Laufwerk zu finden, mit dem problemlos CD-R/CD-RW/DVD+R/DVD+RW/DVD-RAM/BD-R/BD-RE geschrieben werden können.

Sollte es doch dieses Jahr noch ein Release geben – Arbeitstitel „CDVDBurn 3“ – Leser dieses Blogs erfahren es als erste.

Ada, RISC OS und ARMv8

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ß.

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.