Ab und an muss man mit einem etablierten Muster brechen. In dieser Reihe habe ich schon Spiele dezidiert NICHT vermisst, auch mal eine Ausgabe einem ganzen Studio gewidmet – aber sonst geht es hier schon in über 150 Einträgen um Spiele, die mich so beeindruckt haben, dass ich mich zum Teil über 30 Jahre später noch immer an sie erinnere. Heute bekommt ihr es mal wieder mit einem Experiment zu tun: Kann man eine ganze Programmiersprache vermissen? Ich behaupte „Ja“ – und bringe gleich den Beweis mit: Der C64 mini hat in mir natürlich nostalgische Erinnerungen an frühere Spielerlebnisse erweckt, aber was selbst mich überrascht hat: Kein vorinstalliertes Programm hat mich so sehr an früher erinnert wie eines, mit dem man eigentlich gar nicht so einfach ohne persönliche Vorarbeit spielen kann: Commodore Basic.
Beginnen wir zunächst mit der Sprache an sich: Basic steht für Beginner‘s All-purpose Symbolic Instruction Code und wurde in den 60ern von John George Kemeny und Thomas Eugene Kurtz entwickelt. Das Ziel war, eine Programmiersprache zu entwickeln, die auch Leute ohne großen technischen Background bewältigen konnten (eine größere Maschinennähe mag zwar effizienter sein, aber sie erfordert auch einiges an Wissen über die Abläufe in einem Rechner) – und das gelang auch: In den 70ern schaffte die Sprache den Sprung von den Mainframes der Unis auf die Homecomputer. Zwar wurde damals schon von einigen Informatikern (darunter Dijkstra, dessen Algorithmen bis heute gelehrt werden) auf die „primitive“ Sprache Basic herabgesehen, doch es war einerseits High-Level genug, dass man als Entwickler nicht wissen musste, wie der Computer intern tickt, andererseits aber klein genug, um in die damaligen Speicher zu passen, deren Größe damals oft noch in Kilobyte angegeben wurde. Und noch einen Vorteil gab es für die gerade aufkommenden Heimcomputer: Basic konnte auch als Betriebssystem fungieren. Anders als bei den großen Mainframes (die mit ihrer Server/Terminal-Struktur und Timesharing-Konzepten ganz andere Lösungen brauchten) und den ersten PCs war für die Homecomputer kein komplexes Betriebssystem vonnöten. Dafür war es für Hobbyisten durchaus interessant, eigene Programme mit einfachen Mitteln entwickeln zu können. Also wozu ein Betriebssystem und eine separate Programmiersprache liefern, wenn man in Basic alles einbauen kann, was man für die Bedienung des Geräts benötigt? Dieses Konzept sah man unter anderem auf dem Apple II oder auch den 8-Bit Ataris – und auch auf den frühen Commodore-Rechnern.
Interessanterweise ist Basic untrennbar mit dem Aufstieg einer Firma verbunden, die heute kaum aus der PC-Welt wegzudenken ist: Microsoft. Bill Gates und Paul Allen veröffentlichten 1975 als allererstes Produkt ihrer neuen Firma Altair Basic für den Altair 8800 – eine Geschichte für sich, denn sie entwickelten mit Hilfe eines Emulators für das PDP-System ihrer Uni, da sie keinen Zugriff auf das eigentliche Zielsystem hatten, und wussten bis zur Demonstration bei ihren Kunden nicht, ob das Programm funktionieren würde. Geliefert wurde das Programm auf Lochstreifen zu einem stolzen Preis – kein Wunder, dass schon hier fleißig kopiert wurde. Trotzdem: Der Erfolg dieser Veröffentlichung sorgte dafür, dass Microsoft „ihr“ Basic auch auf andere Plattformen brachte – auch deshalb, weil sich Microsoft Basic bald als de facto Standard etablierte, der sich aber dennoch ständig weiterentwickelte (und zwar technisch gesehen bis heute – immerhin steht Visual Basic in der Tradition von Microsoft Basic). Schon bald kam es nicht mehr auf Lochstreifen, sondern wurde schon in dieser frühen Phase auf Magnetband oder Disketten geliefert – und, und damit schließen wir den Bogen wieder zum vorherigen Absatz, zum Teil auch einfach direkt auf ROM-Bausteinen, womit es auf damit ausgestatteten Maschinen direkt verfügbar wurde, ohne geladen werden zu müssen.
Schon 1977 lizenzierte Commodore Microsoft Basic in eben dieser 6502-Variante (die wegen des verwendeten ROM-Bausteins so heißt) für ihre ersten Computer. Jack Tramiel von Commodore hatte dabei durchaus Glück, denn er kaufte den Code von Microsoft für 25.000 US-Dollar, anstatt den ursprünglich angestrebten Deal von drei Dollar pro verkaufter Maschine anzunehmen. Das wäre wohl im Endeffekt teurer gewesen. Tatsächlich hätte er damit Microsoft mit diesem Deal aber fast den Todesstoß gegeben, den der Vertrag besagte, dass das Geld erst fließen würde, wenn die ersten Computer verkauft werden. Das dauerte aber knapp ein halbes Jahr, in dem Microsoft laufende Kosten und einen teuren Rechtsstreit wegen AltairBasic am Laufen hatte. Gerettet wurde Bill Gates Firma damals ausgerechnet von Apple, die MS Basic für den Apple II lizenzierten.
Das Besondere an Microsoft Basic 6502 war, dass es zwar alle wichtigen Programmierkommandos beherrschte, aber gewisse maschinenspezifische Kommandos den Hardwarebauern überließ. Sprich: Basic beherrschte von sich aus keinen Druck, kein Laden oder Schreiben von Daten und nicht mal das Löschen des Bildschirms, da diese Aufgaben des Betriebssytem-Teils von Basic waren. Diese Kommandos wurden daher erst von Commodore implementiert. Im Ausgleich dazu zeigte Commodore Basic erst auf dem C128 (und damit einer weiterentwickelten Version der Sprache) an, dass es von Microsoft stammte. Allerdings gab es schon zuvor ein Easter Egg mit dem Wait-Befehl, das „Microsoft!“ ausgab.
So kam es, dass eigentlich jeder, der mit einem Commodore-Rechner zu tun hatte, auch Kontakt mit Basic hatte. Um hier gleich zum berühmten C64-Startscreen zu springen (es gab natürlich schon vorher Versionen für andere Commodore-Computer, wie die PET-Reihe und den VC-20): Sobald der blinkende Cursor auf dem blauen Bildschirm mit hellblauer Schrift auftauchte, befand man sich eigentlich mitten im Basic-Modus. Dieser konnte auf drei Arten benutzt werden: Man ignorierte im Grunde genommen, dass es sich hierbei um eine Programmiersprache handelt, gab einfach seinen Load-Befehl ein und startete das gewünschte Programm. Ja, das war technisch gesehen schon eine Anwendung von Basic (genauer gesagt von den schon erwähnten Erweiterungen durch Commodore), aber dass es sich dabei um Programmieren handelte, fiel wohl kaum jemandem auf. Oder man gab eine Zeile Basic ein, die (so der Syntax korrekt war) einfach ausgeführt wurde. Oder man schrieb zuerst eine Zeilennummer und erst dann das Kommando (also z.B. “100 PRINT “HALLO SHOCK2“). In letzterem Fall begann man wirklich Programme zu schreiben, denn diese Zeile wurde vom C64 in ihre Einzelteile zerlegt - die sogenannte Tokenisierung – und danach im Speicher abgelegt.
Wurde das Programm daraufhin mit „run“ gestartet, wurden die gespeicherten Kommandos in Reihenfolge ihrer Nummerierung abgearbeitet. Aus diesem Grund etablierten sich auch einige Defacto-Standards, z.B., dass die Nummerierung oft in 10er-Schritten erfolgte. So konnte man im Notfall auch noch Zeilen einschieben, indem man die freien Zeilennummern verwendete. Auch die Aufteilung in Programmteile, die an bestimmten Zeilen-Meilensteinen begannen, war oft zu sehen. Für längere Programme war das zwar nicht optimal (es gab eine maximale Zeilennummer) und es stellte eigentlich keine gute Programmierpraxis dar, aber da ein Umnummerieren noch nicht vorgesehen war (das kam erst in späteren Versionen bzw. mit zusätzlichen Tools), musste man sich auf alle Eventualitäten vorbereiten.
Natürlich hatte Basic so seine Limitationen, die oft an den Beschränkungen der Hardware lagen. So konnten Variablen beliebig lange Namen haben – relevant waren aber nur die ersten beiden Zeichen, sodass ADD2 denselben Wert wie AD1 besaß. Allerdings gab es eine etwas verwirrende Ausnahme: AA war nicht gleich AA$ und nicht gleich AA% - das lag am unterschiedlichen Datentyp, der durch das Zeichen hinter dem Variablennamen ersichtlich war. AA war eine Fließkommazahl (der Default-Wert für eine neue Variable), AA$ ein String (also eine Zeichenkette) und AA% eine vorzeichenbehaftete Ganzzahl. Dazu kam, dass es Variablen nur in einer globalen Variante gab - man konnte also von jedem Teil des Programms diese lesen oder verändern. In der heutigen Zeit, in der man globale Variablen soweit wie möglich vermeidet, ein ziemliches No-Go. Auch der Programmfluss war noch nicht so, wie man sich das von einer modernen Sprache erwartet –mit GOTO wurde verzweigt oder mit GOSUB in eine Unterroutine gesprungen, aber von klar benannten Funktionen mit bestimmten Parametern und Rückgabewerten war man damals weit entfernt. Dazu kommen dann noch Limits in der Zeilenlänge und einige technische Limitationen, denn es gab keine Kommandos für Sound oder Grafik. Dies ließ sich allerdings umgehen, indem man Daten mit dem Poke-Befehl direkt in entsprechende Speicherbereiche schrieb. Hier musste man aber schon genauer wissen, was man tat, und näherte sich eigentlich systemnaher Programmierung.
Bei aller Einfachheit von Commodore Basic gab es einen ganz gravierenden Nachteil (zusätzlich zu den oben genannten): Es handelte sich um eine interpretierte Sprache. Hier muss ich vielleicht einen kurzen Exkurs für all jene ohne Programmierkenntnisse einschieben – keine Angst, das was jetzt kommt, tut nicht weh, ich werde es eher verallgemeinert halten und ein paar Sonderfälle weglassen. Eine Hochsprache kann nicht einfach so vom Computer ausgeführt werden, sondern muss zuerst in Maschinencode übersetzt werden, denn was wie eine simple Anweisung aussieht, z.B. zwei Zahlen zu addieren, erfordert oft mehrere Schritte für den Prozessor. Das Übersetzen kann ganz grundsätzlich auf zwei Arten passieren: Ein Compiler übersetzt den fertigen Code in Maschinensprache und speichert das Resultat ab – der Enduser benötigt den Code nicht, sondern nur das Ergebnis dieses Prozesses, die Übersetzung muss nur einmal erfolgen und der Compiler kann zahlreiche Optimierungen vornehmen. Außerdem ist der Sourcecode für den Enduser nicht sichtbar.
Die andere Variante ist der sogenannte Interpreter: Hier wird der Code zur Laufzeit übersetzt, ein eigener Compiler ist nicht notwendig und es ist sogar möglich, das Programm während der Ausführung zu ändern. Dieses Modell finden wir unter anderem heute noch in den Script-Sprachen, mit denen z.B. Spiele um Funktionen erweitert werden. Die Nachteile? Eventuelle Syntax-Fehler werden oft erst bei der Ausführung gefunden, eine Optimierung findet normalerweise nicht statt und generell hat der Computer natürlich hier mehr zu tun, wodurch solche Programme oft langsamer ablaufen. Dafür ist hier grundsätzlich eine gewisse Portierbarkeit auf andere Plattformen gegeben: Während ein Compiler schon wissen muss, für welche Plattform er übersetzen soll, wird beim Interpreter eben erst zur Laufzeit übersetzt. Das sorgt für eine theoretische Portierbarkeit, die allerdings stark davon abhängt, wie systemspezifisch hier programmiert wurde.
Vieler Worte kurzer Sinn: Commodore Basic war standardmäßig interpretiert und dementsprechend langsam (es gab allerdings Compiler von Third-Party-Herstellern, die oft ihre eigenen Probleme mit sich brachten). Wenn man berücksichtigt, wie (vor allem im Vergleich zu heutigen Maschinen) schwachbrüstig der C64 an sich war, konnte man mit Basic nette eigene Projekte bauen. Ein Textadventure ließ sich ebenso realisieren wie ein Quiz, aber wenn es wirklich um Action ging stand man schnell an einer Speed-Grenze. Hier musste man dann doch dazu übergehen, Maschinencode zu schreiben, und sei es nur für jene Routinen, wo Geschwindigkeit gefragt war. Dazu kam, dass ein Basic-Programm immer lesbar war, während reiner Maschinencode zumindest Anfänger vor schwierigere Probleme stellte. Insofern ist es kein Wunder, dass Commodore Basic eher für Hobbyisten interessant blieb, während diejenigen, die aus dem Brotkasten alles herausholen wollten, eher auf andere Hilfsmittel zurückgriffen und/oder maschinennahe programmierten.
Mich hat allerdings der Maschinencode damals noch nicht interessiert – und mit „mich“ meine ich in diesem Fall mein siebenjähriges Ich, das damals unter dem Weihnachtsbaum seinen eigenen C64 fand. Klar war Schritt eins damals, die zahlreichen Spiele auszuprobieren. Und doch hatten meine Eltern etwas im Nachhinein sehr Gescheites getan und mir neben dem Rechner und zahlreichen Disketten ein kleines Buch gekauft – leider kann ich mich nicht mehr genau an den Titel erinnern –, das Basic kindgerecht aufbereitete. Alle wichtigen Befehle wurden behutsam erklärt, dazu gab es ein kurzes Programm, das natürlich auch noch ausführlich erläutert wurde. Und da ich zu dem Zeitpunkt auch schon ziemlich gut lesen konnte (danke, lustige Taschenbücher), verschlang ich dieses Programmierbuch zu einem Zeitpunkt, als meine Schulkollegen noch nicht mal alle Buchstaben konnten.
Das Problem? Die Programme darin funktionierten oft nicht. Ich habe bereits erwähnt, dass es Dialekte gab bzw. gewisse Routinen von den Computerherstellern implementiert wurden und sich damit nicht an Standards hielten. Genau dieses Problem gab es auch mit meinem Basic-Buch, das nicht spezifisch für den C64 geschrieben worden war. Zum Beispiel: Das oft gebrauchte Kommando „CLS“, mit dem man den Bildschirm löschte, gab es in Basic für den C64 nicht. Mangels Internet hieß es daher die Dokumentation lesen – das C64-Handbuch widmet sich nämlich ziemlich ausführlich Basic -, wodurch ich schließlich herausfand, dass das richtige Kommando PRINT CHR$(147) war. Letzteres Zeichen konnte auch als eine Art invertiertes Herz durch eine Tastenkombination dargestellt werden. Damit konnte es wirklich losgehen.
Über kurz oder lang hatte ich also die Programme aus dem Buch umgesetzt, natürlich auch alle abgespeichert und zum Teil sogar leicht adaptiert. Der nächste Schritt war das erste eigene Programm, an dessen Idee ich mich sogar noch erinnern kann: Ich wollte ein Programm schreiben, das Übungen zum Lesen-lernen generiert. Leider war ich damit völlig überfordert – weiter als den Schwierigkeitsgrad festzulegen und zu fragen, welche Wörter vorkommen sollen, kam ich mangels Planung nicht. Und vermutlich wäre ich auch mit Planung völlig an der Komplexität gescheitert. Ich war schon damals einfach gut darin, mir zu große Projekte auszusuchen.
Stattdessen wagte ich den nächsten Schritt, komplexere Programme zumindest abzuschreiben – und zwar aus dem schon erwähnten C64-Handbuch. Dort waren die Codes meist länger und wagten sich durchaus in Territorien, die das erste Buch nicht ansprach – auch deshalb, weil hier natürlich spezifische Anwendungen für den C64 zu finden waren. Hier lernte ich, mit dem Computer Musik zu machen – also Klangerzeugung im Stil eines Analog-Synthesizers und Musikdaten im Stil von MIDI, bei dem Tonhöhe und Dauer wichtige Parameter darstellten. Die Theorie hinter Wellenformen, Hüllkurven und Co. verstehe ich erst jetzt, aber für die Praxis reichte es damals schon: Für die Melodien saß ich oft auf dem Boden meines Kinderzimmers und rechnete Melodien in Daten um. Generell spielte der Boden meines Zimmers oft eine große Rolle beim Programmieren, denn auch beim Entwickeln von Sprites (grafische, bewegbare Objekte – das klassische Beispiel ist zum Beispiel die Spielfigur) saß ich mit kariertem Papier dort und rechnete mit der Hand die Datenwerte aus. Die Zeichnung wurden nämlich in Blocks zu je acht Pixeln aufgeteilt, und je nachdem, ob in einer Zeile gewisse Pixel „an“ oder „aus“ waren (mehrfarbige Sprites gab es ohne Trickserei nicht), ergab sich für jeden Block in jeder Zeile ein bestimmter Zahlenwert. Ja, das war durchaus komplex für mich in dem Alter, machte aber auch Spaß.
Ein wichtiger Grundsatz beim Programmieren ist es auch, möglichst viel Code von anderen zu lesen. Nachdem die Codes meiner beiden Bücher ausprobiert waren, versuchte ich also den nächsten Schritt – und gelangte dabei an eine gewisse Grenze. Ja, ich hätte gerne die diversen Spiele ausführlicher studiert, aber wie schon erwähnt waren die meist in Maschinensprache geschrieben und gaben deshalb auf ein „List“ einfach nur irgendeinen Sys-Befehl aus, der das Programm via einer Maschinenroutine startete. Einige willkommene Ausnahmen gab es allerdings doch, wie z.B. ein Quizspiel, an dessen Namen ich mich nicht mehr erinnere, und Diktator. Zum leichteren Studium druckte ich diese Programme oft aus – noch heute finden sich in meiner C64-Kiste ganze Stapel an Endlospapier, die mein treuer Nadeldrucker mühselig (und lautstark) gefüllt hatte. 100%ig nachvollziehen konnte ich diese Spiele aber oft nie, und sei es nur, weil mir die Geduld ausging oder die Sprünge über mehrere Seiten gingen, was das Hin- und Herblättern erschwerte.
Stattdessen gab es dann doch ein paar eigene Experimente, die meistens einfache Frage/Antwortspiele waren, die je nach Eingaben irgendwohin verzweigten. Oder die schon erwähnten Adaptionen von Code, die aber genau das blieben – einfache Modifikationen mit anderen Grafiken oder Musik. Für mehr reichte mein Wissen damals noch nicht. Aber es reichte, um meine Lust am Programmieren zu wecken. Und es war ja auch so einfach – es war einfach Teil des Systems. Man brauchte keine eigene Software. Und so entstanden regelmäßig neue Programme. Einfach so.
Wie sehr diese Verzahnung von Betriebssystem und Programmiersprache für mich selbstverständlich war, zeigte sich, als ich den C64 schließlich verließ und zunächst Richtung Amiga 500 zog. Und dabei hatte ich noch Glück, dort überhaupt ein Basic vorzufinden, mit dem ich mich zurechtfand. Amiga OS 1.0 bot einen Basic-Dialekt eines anderen Herstellers namens ABasiC, mit Version 1.1 tauschte man diese Implementation gegen eine auf Microsoft Basic basierende namens AmigaBasic aus und behielt diese für die gesamte folgende 1.x-Serie bei. Die Philosophie war hier allerdings bereits eine andere – Basic war ein separates Programm, das man aus der Workbench (der grafischen Benutzeroberfläche) heraus startete, und nicht mehr einfach Teil der Shell. Auch Basic selbst war ähnlich, aber nicht gleich. Zeilennummern waren nun nicht mehr nötig, dafür gab es gab einen relativ angenehmen Editor, der das Programmieren deutlich erleichterte. Eigentlich ein klarer Fortschritt. Aber eben nicht mehr Teil der allgemeinen Benutzeroberfläche.
AmigaBasic war übrigens das einzige Programm, das Microsoft jemals für den Amiga entwickelte, und das merkte man auch, denn AmigaBasic hatte einige technische Probleme. Es war unglaublich langsam (dasselbe Programm lief auf einem C64 nur minimal langsamer) und besaß gerade bei der Unterstützung der Amiga-Features (zum Beispiel Libraries, um die grafischen Möglichkeiten der Plattform auszunutzen) einige Bugs. Auch das Ausführen von Routinen in Maschinensprache war fehleranfällig bis unbenutzbar. Hier dürfte sich Microsoft über die Programmier-Guidelines von Commodore hinweggesetzt haben und schuf damit Probleme, die auch zum Ende von AmigaBasic führten: Mit AmigaOS 2.0 (und damit rund um den Amiga 3000) wurde AmigaBasic durch eine Script-Sprache ersetzt, da die aktuelle Version mit dem neuen Betriebssystem und der neuen CPU nicht mehr kompatibel war. Außerdem war man bei Commodore der Ansicht, dass sich die Ansprüche der Benutzer geändert haben und eine Script-Sprache mehr dem Geist der Zeit entsprach.
Für mich war AmigaBasic zwar irgendwie vertraut, aber dann auch wieder nicht, da es sich in etlichen Details vom klassischen C64-Basic unterschied. Gleichzeitig war Basic im Amiga-Mikrokosmos – im Vergleich zum C64 – einfach viel weniger Platz eingeräumt. Ja, es gab sogar ein eigenes Handbuch für Basic am Amiga, aber es war völlig anders strukturiert und bot vor allem eine Befehlsreferenz und Hintergrundwissen darüber, wie manche Befehle funktionierten (z.B. die Bit-Operatoren). Aber bei den Beispielen hielt man sich stark zurück. Vielleicht war es das – oder war mein eigener Anspruch an meine Projekte bereits zu sehr gestiegen? -, dass ich AmigaBasic schon viel weniger verwendete. Das einzige Projekt, an das ich mich hier definitiv noch erinnere, war eine Textadventure-ähnliche Umsetzung von X-Wing, die auf der Komplettlösung eines Videospiels basierte.
Noch schlimmer erging es Basic dann nach meinem Wechsel auf den PC: Dort fand sich unter DOS 6.2 zwar ebenfalls ein mitgeliefertes Basic (natürlich wieder ein eigenes Programm) namens Qbasic, und auch dieses war eine Microsoft-Basic-Umsetzung. In Erinnerung blieb mir Qbasic allerdings eher wegen seiner Demo-Programme – eine Snake-Version namens Nibbles und ein Artillery-Game namens Gorillas. Bei mir war die Zeit von Basic einfach abgelaufen. Abgesehen von einigen Word-Makros, für die ich etwas mühselig Jahre später meine Basic-Kenntnisse wieder auffrischte, strebte ich nach Sprachen, mit denen man mehr anfangen könnte – ein Weg, der mich über C/C++ und Pascal/Delphi schlussendlich dazu bringen sollte, Informatik zu studieren und von eigenen Spielen zu träumen. Wie das ausgegangen ist, wissen fleißige Leser bereits.
Und das ist wohl der Grund, warum ich Commodore Basic noch immer vermisse. Hier wird ein wichtiger Grundstein für meine Liebe zum Programmieren gelegt, die immerhin bis zu einem Studium geführt hat. Gut, es war ein Studium, das ich im Nachhinein nie ausleben wollte, aber Programmieren wurde (vor allem in Hinblick auf das eigene Entwickeln von Spielen) eine große Liebe. Noch heute entwickle ich gerne mal ein kleines Hobby-Projekt und konnte diese Erfahrungen auch im Redaktionsalltag ausleben (erinnert ihr euch noch an die Specials in diversen consol- und Gamers-Ausgaben zur Spieleprogrammierung, wie über XNA, eigene Kinect-Spiele oder wie man für die Ouya entwickelt? Ja, die waren alle (auch) von mir). Auch bei meinem Folgejob bei Cliffhanger Productions war die Programmiererfahrung nützlich. All das hätte es wohl nie gegeben, wenn ich nicht mit dem C64, Basic und einem kleinen Buch Blut geleckt hätte. Basic damals hat mich auf die großen Programmiersprachen vorbereitet und mit seiner einfachen Verfügbarkeit meinen Experimentierdrang unterstützt. Und es hat mir für viele Stunden Spaß bereitet. Und allein dafür verdient es all meine nostalgischen Gedanken.
