C64 Crossdevelopment unter Linux mit gedit/Gnome

Mit GEdit (Kommando gedit), dem Standardtexteditor der Gnome-Desktopumgebung, ist es ohne weiteres möglich per Tastendruck oder Menüeintrag vom Benutzer geschriebene Shell-Skripte auszuführen, denen die derzeit geöffnete Datei übergeben wird. Diese Funktion kann selbstverständlich auch dazu genutzt werden, diverse Prozesse, die für C64 Crossdevelopment nötig sind zu automatisieren; wie z.B. Kompilieren eines Quelltextes, Linken einzelner Programmteile und schlussendlich das Packen und Ausführen eines Programms in einem Emulator oder auf dem echten C64 per Codenet.

Grundlegende Konfiguration von GEdit

das Plugin "Externe Werkzeuge" aktivieren

Um diese Funktion nutzen zu können, muss man das Plugin "Externe Werkzeuge", das in einer GEdit-Standardinstallation bereits verfügbar ist, aktivieren unter:

Bearbeiten > Einstellungen > Plugins

Nach erfolgreicher Aktivierung lassen sich nun Shell-Skripte unter "Werkzeuge > Manage External Tools" verwalten.

Einstellungen

Mit dem Hinzufügen-Button unten links lässt sich ein neues "Werkzeug" erstellen. Oben rechts kann nun das Skript eingegeben und unterhalb können diverse Einstellungen vorgenommen werden:

Tastenkürzel

wird nicht zwingend benötigt, kann man aber im Grunde beliebig wählen und erleichtert natürlich den Aufruf. Man sollte nur aufpassen, keine systemweiten Tastaturkürzel zu benutzen. Ich persönlich habe mir die drei meistgebrauchten Skripte für C64 Crossdevelopment auf F12 , Shift +F12  und Strg +F12  gelegt.

Speichern

Hier ist "Nichts" zu wählen, da die Quelltexte ja nicht verändert werden.

Eingabe

Hier muss man "momentan geöffnetes Dokument" auswählen, um es im Skript nutzen zu können.

Ausgabe

bestimmt den Umgang mit dem Konsolen-Output des aufgerufenen Skripts. Hier sind vor allem die Optionen "In Fußleiste anzeigen" oder "Neues Dokument anlegen" interessant. Letzteres insbesondere dann, wenn man ein Errorlog haben möchte.

Anwendbarkeit

Hier würde ich der Einfachheit halber "Alle Dokumente" und "All Languages" auswählen, um das Skript immer zur Verfügung zu haben, egal wie die Dateiendung aussieht und unabhängig davon, ob die Programmiersprache korrekt erkannt wurde.

Schreiben geeigneter Shell-Skripte

Je nach dem, wie groß oder komplex die Toolchain ist, die man verwalten möchte, ist es hilfreich sich möglichst gut mit Shell-Programmierung unter Linux auszukennen. Ein paar simple Skripts werde ich exemplarisch im Folgenden erklären.

Zunächst ist es wichtig, die erste Zeile mit

#!/bin/sh

zu beginnen. Je nach GEdit-Version wird das bereits automatisch in eingefügt.

Wenn man, wie oben erwähnt das momentan geöffnete Dokument als Eingabe ausgewählt hat, stehen einem bereits einige Umgebungsvariablen von GEdit zur Verfügung. Die wichtigsten davon sind:

GEDIT_CURRENT_DOCUMENT_PATH
GEDIT_CURRENT_DOCUMENT_NAME

Eine vollständige Auflistung aller Umgebungsvariablen findet man in der GEdit-Dokumentation.

Achtung! Damit diese Variablen die korrekten Werte enthalten, muss das Dokument vor der Verwendung eines externen Werkzeugs gespeichert werden.

Um den Quelltext komfortabel weiter zu verarbeiten, empfiehlt es sich, zunächst eine neue Variable anzulegen, die den Dateinamen inklusive kompletter Pfadangabe enthält, z.B.:

QUELLE = $GEDIT_CURRENT_DOCUMENT_PATH/$GEDIT_CURRENT_DOCUMENT_NAME;

So kann unser momentan geöffnetes Dokument im Skript stets durch $QUELLE angesprochen werden. Will man z.B. einen Quelltext mit Namen test.asm per Acme kompilieren lassen, kann dies nun durch die Zeile

acme $QUELLE;

erfolgen, wobei die Variable QUELLE durch die o.g. Zuweisung den String "test.asm" enthält.

Natürlich kann acme aus diesem Beispiel mit jedem beliebigen Compiler/Assembler ersetzt werden. Meist steht man allerdings vor dem Problem, dass man nicht nur Kompilieren, sondern das Kompilat auch direkt im Emulator Vice oder auf dem C64 ausführen möchte. Je nach Compiler hat das Kompilat eine andere Dateiendung (meist .prg) oder auch einen völlig beliebigen Dateinamen (z.B. bei Acme, den durch die Anweisung "!to" angegebenen).

Um diesen Dateinamen herauszufinden helfen einem die Befehle grep und sed. Möchte man z.B. einfach nur die Dateiendung abschneiden und eine gleichnamige Datei mit Endung .prg im Vice öffnen, so ist das unter anderem wie folgt möglich:

ZIEL=`echo $QUELLE | sed 's/\.[^.]*$//'`;
x64 $ZIEL.prg;

Will man das Kompilat vor der Ausführung noch mit dem Exomizer packen, so lässt sich auch das bewerkstelligen:

ZIEL=`echo $QUELLE | sed 's/\.[^.]*$//'`;
exomizer sfx sys -o $ZIEL-exo.prg $ZIEL.prg;
x64 $ZIEL-exo.prg;

Im Grunde kann man sagen, dass jedes denkbare Szenario mit einem geeigneten Shell-Skript umsetzbar ist. So zum Beispiel auch das "Extrahieren" des Output Dateinamens aus dem Quelltext heraus (hier einmal exemplarisch für die !to Anweisung des Acme):

ZIEL=`grep '!to' $QUELLE | sed 's:.*"\(.*\)".*:\1:'`;

Achtung! Im Gegensatz zum Beispiel oben enthält die Variable ZIEL hier jetzt den Dateinamen inklusive Dateiendung, also alles, was im Quelltext nach dem !to in Anführungszeichen steht.

Syntax-Highlighting

Syntax-Highlighting

Ein weiteres, praktisches Hilfsmittel ist die Möglichkeit in GEdit eigene XML-Dateien einzubinden, die Syntax-Highlighting-Informationen für alle möglichen Programmiersprachen enthalten können. Diese haben üblicherweise die Dateiendung ".lang" und müssen, je nachdem, ob sie für alle oder nur einen Benutzer des Computers zur Verfügung stehen sollen, in einen der folgenden Ordner kopiert werden:

~/.local/share/gtksourceview-3.0/language-specs                   (ein Benutzer)
/usr/share/gtksourceview-3.0/language-specs                       (alle Benutzer)

Diese .lang-Dateien können problemlos mit Aufruf von gedit selbst an die eigenen Bedürfnisse angepasst werden. Eine gute Vorlage, die bereits rudimentär an die Acme-Syntax angepasst ist, findet man auf den Internet-Seiten von cbmhardware. Eine überarbeitete Version ist im Forum64 publiziert worden.

Aktiviert wird das Syntax-Highlighting in GEdit über Ansicht -> Hervorhebungsmodus. Wenn das jeweilige .lang-File wie oben beschrieben erfolgreich im Ordner language-specs befindet, sollte man den Modus, z.B. "6510", nun finden.

Beispielskripte

Beispiel a)

Kompilieren mit Acme, Ausführen mit Vice und Codenet:

#!/bin/sh 
QUELLE=$GEDIT_CURRENT_DOCUMENT_DIR/$GEDIT_CURRENT_DOCUMENT_NAME; 
ZIEL=`grep '!to' $QUELLE | sed 's:.*"\(.*\)".*:\1:'`; 
acme $QUELLE; 
x64sc --autostart $ZIEL & codenet -n 192.168.1.164 -x $ZIEL; 

Beispiel b)

Kompilieren und Linken mit cl65 (cc65), Ausführen mit Codenet und Löschen der .o Datei:

#!/bin/sh 
QUELLE=$GEDIT_CURRENT_DOCUMENT_DIR/$GEDIT_CURRENT_DOCUMENT_NAME; 
ZIEL=`echo $QUELLE | sed 's/\.[^.]*$//'`; 
cl65 -O -t c64 -o $NAME.prg $QUELLE; 
codenet -n 192.168.1.164 -x $ZIEL.prg; 
rm $ZIEL.o; 

Ergänzende Bemerkungen

In allen Beispielen wird davon ausgegangen, dass die Programmverzeichnisse der entsprechenden Crossdevelopment-Programme in der PATH-Variable eingetragen sind oder dass sich diese Programme in

/usr/bin

oder

/usr/local/bin

befinden.

Selbstverständlich kann man alternativ in den Skripten auch absolute Pfadangaben benutzen, z.B. falls die Acme-Programmdatei im Heimverzeichnis des Users in dem Unterordner ~/c64tools/acme/ liegt:

/home/<username>/c64tools/acme/acme $QUELLE;

Neben den "External Tools" gibt es für gedit jede Menge weitere, nützliche Plugins, die die Programmierarbeit stark erleichtern können. Mit geringem Aufwand lässt sich der Editor in eine leistungsstarke Entwicklungsumgebung verwandeln, die vollständig an die persönlichen Bedürfnisse angepasst werden kann. Wer z.B. bei größeren Projekten die Übersicht über Labels, Funktionen und Variablen nicht verlieren will, dem empfehle ich, sich einmal den Source-Code-Browser anzusehen. Leider gibt es aktuelle Versionen davon lediglich für GEdit 3.x.

Außerdem lässt sich GEdit unter Linux auch mit jeder anderen Desktopumgebung ganz genauso, wie in diesem Dokument beschrieben verwenden. Des weiteren gibt es auch Portierungen für Windowsund MacOS X. Insofern das "External Tools" Plugin unter diesen Systemen ähnlich funktioniert, müssten die Skripte allerdings in Batch/AppleScript übersetzt werden.