Nach 22 Jahren habe ich ein Update für eine Software veröffentlicht, die ich Ende der 1990er Jahre für die Amiga-Plattform geschrieben habe. Es handelt sich um einen Treiber für die MacroSystem MaestroPro, eine vollständig digitale Soundkarte. Zusammen mit dem Update habe ich den Quellcode dieser Bibliothek offengelegt.
Der Soundtreiber selbst ist eigentlich gar nicht so interessant. Ich glaube nicht, dass es auf dieser Welt noch viele Leute gibt, die diese Soundkarte benutzen. Interessanter ist, wie ich das Projekt verändert habe, um es Open-Source zu machen und unter Linux sowie anderen modernen Plattformen kompilierbar zu machen. Darum geht es in diesem Artikel.
Versionierung (oder das Fehlen davon)
Das erste Problem, auf das ich stieß, kam ziemlich unerwartet. Damals, in den guten alten Amiga-Zeiten, hatte ich keine Versionskontrollsysteme wie CVS verwendet. Da ich nur ein Hobby-Entwickler war, wusste ich weder von ihrer Existenz noch von ihrem Zweck. Stattdessen machte ich häufig Backups meiner Quellcodes, damit ich sie im Falle eines Festplattenausfalls oder nach einem verpfuschten Code-Redesign nicht verliere. Aber abgesehen davon war Programmieren eine Operation am offenen Herzen des Quellcodes, ohne die Möglichkeit, zu einem früheren Zustand zurückzukehren, von dem man wusste, dass er funktionierte.
Als Ergebnis fand ich mehrere verschiedene Versionen des Projekts auf meiner Amiga-Festplatte, und ich musste herausfinden, welche die neueste war. Bei diesem Projekt hatte ich Glück, weil ich der Hauptdatei des Quellcodes ein Changelog hinzugefügt hatte. Ich musste nur die Kopie mit dem neuesten Changelog finden.
Ohne ein Versionskontrollsystem sind die Quellen aller älteren Versionen verloren, also habe ich gar nicht erst versucht, eine Historie aus den Backups wiederherzustellen. Die letzte Version im Aminet war V41.40, aber ich konnte die Quellen dieser Veröffentlichung nicht mehr finden. Was ich stattdessen fand, war eine V41.50, die nie veröffentlicht wurde. Ich kann mich nicht erinnern, warum ich mich entschied, diese Version nicht zu veröffentlichen. Vielleicht stellten sich die Änderungen als Regression heraus? Vielleicht hatte ich einfach das Interesse am Amiga verloren und mir nicht mehr die Mühe gemacht, sie zu veröffentlichen?
Jedenfalls konnte ich zumindest die neueste Version des Quellcodes finden. Was nun damit tun? Da ich in der Zwischenzeit ein professioneller Softwareentwickler geworden war, war mir klar, dass ich nicht einfach nur die neueste Quellcode-Version (und ein paar zufällige Backups) behalten würde, sondern ich wollte jetzt ein Versionskontrollsystem verwenden.
Heute verwende ich am liebsten git. Es würde gut in meine Entwicklungsumgebung passen und mir erlauben, meine Quellcodes in meinem GitHub-Repository zu veröffentlichen. Aber git wurde nie auf den klassischen Amiga portiert, und das wird es aufgrund seiner Komplexität wahrscheinlich auch nie.
Olaf Barthel hat jedoch eine Portierung von subversion gemacht. Die letzte Veröffentlichung war 2009 und basiert auf einer sehr alten Subversion-Version 1.1.4. Es würde nicht viel Spaß machen, sie zu benutzen, aber es wäre machbar.
Es gibt auch eine CVS-Portierung von Frank Wille, aber ich mochte CVS nie wirklich, also war das keine Option für mich.
Also waren svn und git die einzigen Kandidaten, mit einer starken Präferenz für git, aber svn als einzige Option, die auf AmigaOS funktionieren würde. Die Entscheidung war mit der nächsten Frage verknüpft.
Kompilierung
Auf welcher Plattform möchte ich weiterentwickeln?
Ich könnte weitermachen und das Projekt auf dem Amiga entwickeln, so wie ich es in den 1990er Jahren getan habe. Dort hatte ich alles, was ich brauchte. Ich benutzte GoldEd als Editor, mit angepassten Makros zum Kompilieren meiner Projekte. Ich benutzte PhxAss als Assembler und SAS/C als C-Compiler. Keine dieser Softwares wird noch gewartet, und SAS/C war ein kommerzielles Produkt, das nicht mehr erhältlich ist. Mit diesen strengen Anforderungen wären nur wenige Leute technisch in der Lage, sich an dem Projekt zu beteiligen.
Heute verwenden Amiga-Enthusiasten die vbcc-Toolchain für die Entwicklung. Sie wird immer noch aktiv gepflegt. Und sie läuft auf AmigaOS, aber auch auf allen gängigen Betriebssystemen. Als Editor ist Visual Studio Code eine bevorzugte Wahl, da es ein Amiga Assembly Add-on gibt. Es unterstützt Syntax-Highlighting, Inline-Dokumentation, Debugging und vieles mehr.
Das sind die fehlenden Puzzleteile. Mit vbcc ist es möglich, das Projekt unter Linux und anderen Plattformen zu bauen, sodass fast jeder Amiga-Entwickler in der Lage ist, sich zu beteiligen. Die Entwicklung unter Linux ermöglicht es mir auch, git und all die anderen Tools zu nutzen, an die ich mich gewöhnt habe. Aber mit nur wenigen Änderungen am makefile könnte das Projekt immer noch unter AmigaOS gebaut werden.
Ich entschied mich für den Linux-Weg, aber das ist eine Entscheidung, die jeder Retro-Entwickler für sich selbst treffen muss. Das Cross-Kompilieren eines Amiga-Projekts unter Linux wäre komfortabel (und schnell), ist aber nicht wirklich “retro”. Das Bauen unter AmigaOS entspräche dem wahren Retro-Geist, würde mich aber mit einem veralteten und teilweise ungewarteten Toolset zurücklassen.
Portierung
Es war einfach, die Quelldateien auf mein Linux-Dateisystem zu kopieren und dort ein git-Projekt zu initialisieren. Das nächste Problem, auf das ich stieß, war, dass ich das makefile portieren musste. Es war maßgeschneidert für meine AmigaOS-Umgebung, mit speziellen Assigns für Include-Dateien und Binaries.
Ich erstellte ein neues makefile, das stattdessen Umgebungsvariablen verwendet. AMIGA_NDK zeigt nun auf das entpackte AmigaOS 3.2 NDK, während AMIGA_INCLUDES auf die Include-Dateien externer Abhängigkeiten (wie MUI) verweist. Ich habe vbcc installiert, sodass alle Befehle im $PATH waren.
Danach habe ich alle Quellcodedateien restrukturiert und neu angeordnet. Das Projekt enthält nun nur noch meine eigenen Dateien, die für den Bau des Projekts absolut notwendig sind. Ein Aufruf von make baut dann das Projekt auf meinem Linux-Rechner.
I18n
Es gab ein unerwartetes Problem mit dem Zeichensatz. Während alle modernen Betriebssysteme UTF-8 verwenden, unterstützt AmigaOS dies nicht, sondern verwendet stattdessen ISO-8859-1. Das Ergebnis ist, dass das Repository eine furchtbare Mischung aus beiden Zeichensätzen enthielt. Alle Dateien, die für die Verwendung durch die git-Umgebung gedacht sind (wie die README.md-Datei), sind in UTF-8 gespeichert. Andere Dateien, die AmigaOS-bezogen sind (wie AmigaGuide-Dateien), müssen stattdessen in ISO-8859-1 gespeichert werden.
Ich hatte gehofft, dass ich das richtige Encoding für jeden Dateityp in einer .editorconfig-Datei definieren könnte. Aber leider ignoriert Visual Studio Code die Zeichensatz-Einstellungen und verwendet stattdessen standardmäßig UTF-8. Es war zu einfach, auf diese Weise versehentlich alle Sonderzeichen (wie den Umlaut in meinem Nachnamen) zu zerstören.
Die einzige Lösung, die ich fand, war, UTF-8 oder ISO-8859-1 nur dort zu verwenden, wo es absolut notwendig war, aber für die meisten Dateien benutzte ich ASCII als den kleinsten gemeinsamen Nenner. Ein eigenes Make-Target make check überprüft alle Dateien auf illegale Zeichen und erzwingt so die korrekte Verwendung der Encodings.
Testen
Natürlich möchte ich das Ergebnis auf AmigaOS testen (und ausführen), entweder in UAE oder auf einem echten Amiga.
Unter UAE können die erstellten Dateien einfach direkt in das Amiga-Festplattenverzeichnis kopiert und dann sofort im emulierten Amiga verwendet werden.
Für den echten Amiga ist es jedoch etwas schwieriger. Ein Weg ist, eine ADF-Disketten-Datei mit xdftool zu erstellen und die Dateien darauf zu kopieren. Diese ADF-Datei kann dann auf einen USB-Stick kopiert und im Amiga über einen Gotek-Diskettenlaufwerk-Emulator gelesen werden.
Ein besserer Weg ist die Verwendung eines einfachen NFS-Servers, der sowohl auf dem Linux- als auch auf dem Amiga-Rechner gemountet ist. Dateien können so leicht ausgetauscht werden. Natürlich setzt das voraus, dass der Amiga über eine Netzwerkverbindung verfügt.
Veröffentlichung
Damals in den Amiga-Zeiten war das Erstellen eines Releases ein vollständig manueller Prozess. Zu diesem Zweck hatte ich ein separates Verzeichnis mit einer Release-Vorlage. Ich kopierte alle kompilierten Dateien manuell an die entsprechenden Stellen dieser Vorlage, packte sie dann und lud sie ins Aminet hoch.
Jetzt möchte ich, dass das git-Projekt in sich geschlossen ist, also befinden sich alle Dateien der Release-Vorlage im distribution-Verzeichnis. Das make release-Target baut das gesamte Projekt, erstellt dann ein frisches release-Verzeichnis, kopiert alle Dateien an die richtigen Stellen und erstellt ein lha-Paket.
Auf einem modernen Linux-Rechner dauert der gesamte Prozess (von einem sauberen Checkout bis zum Distributionspaket) weniger als eine Sekunde. 🤩
Und das war’s. Der Quellcode der maestix.library ist nun offen und auf GitHub verfügbar. Die erste Version, die in der neuen Umgebung gebaut wurde, kann aus dem AmiNet heruntergeladen werden.
CI/CD
Du hast jetzt vielleicht gelacht, aber es ist wahr: Es ist möglich, CI/CD mit Amiga-Projekten zu machen!
vamos ist eine virtuelle Amiga-Laufzeitumgebung, die es ermöglicht, einfache Amiga-Befehle unter Linux auszuführen. Es ist nur eine CPU- und API-Emulation, kein vollwertiger Emulator wie UAE, aber es reicht aus, um Unit-Test-Suites auszuführen.
Es gibt Docker-Images wie docker4amigavbcc, die es zum Beispiel ermöglichen, Commits automatisch über GitLab CI zu bauen.
Und da es einfach ist, neue Pakete ins AmiNet hochzuladen, wäre sogar Continuous Deployment möglich. Erstelle einfach einen Version-Tag und lass deine CI/CD-Kette den Rest erledigen. 🙂
Insgesamt ist es möglich, diese Retro-Projekte auf modernste Weise zu entwickeln, mit einer modernen IDE, Quellcode-Versionierung, plattformneutraler Entwicklung, Unit-Tests und sogar CI/CD.