»Und wenn ich diese Taste drück’...« Sounds und ihre Programmierung in BASIC-Spielen

Mit dem Erscheinen der Homecomputer Ende der 1970er-, Anfang der 1980er-Jahre beginnt nicht nur die professionelle Computerspiele-Industrie aufzublühen; es entsteht auch ein neuartiges Hobby, ein regelrechter ‚Breitensport‘: das Programmieren. Die kleinen Computer von Atari, Commodore, Amstrad, Sinclair und Dutzenden anderer Anbieter bringen zumeist einen Dialekt der leicht erlernbaren Programmiersprache BASIC mit. Wollte man ein solches Gerät nutzen, musste man sich zumindest in die Grundlagen dieser Sprache einarbeiten. Dabei halfen neben den mitgelieferten Handbüchern vor allem Sekundärliteratur, Zeitschriften, Clubs und Gleichgesinnte. In einem Zeitraum von zwanzig Jahren (zwischen 1975 und 1995) wuchs auf diese Weise eine neuartige Subkultur heran: die der Hobbyprogrammierer:innen. Deren Leistungen sind in ein Archiv von Paperware- und Software-Publikationen, (privater) grauer Literatur und Datenträgern mit nie veröffentlichten selbstgeschriebenen Programmen eingegangen. Ein Archiv, das noch auf systematische Erforschung wartet.

Der nachfolgende Beitrag birgt einige Programmcodes aus diesem Archiv, die sich mit BASIC-Computerspielen beschäftigen. An solchen Programmen lassen sich die zumeist autodidaktisch erworbenen Programmier- und Technikkenntnisse der Entwickler:innen am deutlichsten ablesen und der Schritt von einer rein privaten Amateur- zur semiprofessionellen und professionellen Spieleentwicklung zeigen. Nach der Vorstellung der hierfür verwendeten Systeme und der Programmiersprache BASIC sowie spezifischer Dialekte in Hinblick auf die Soundprogrammierung, wird eine theoretische Einordnung der Type-in-Listings anhand konkreter Beispiele vorgenommen.¹ Hieraus soll sich eine Typologie der Sound- und Musikprogrammierung für BASIC-Spiele ergeben, die bisherige theoretische Überlegungen zur Klassifizierung von Tonausgaben in Computerspielen ergänzt.

1. Am Heimcomputer sitz’ ich hier…

Aus zahlreichen Historiografien zu Computern ist bekannt, dass das Phänomen der Computerspiele viel älter ist, als aus der Geschichte der daraus entstandenen Industrie abzulesen wäre. Tatsächlich geht die Erfindung der Computer oft sogar mit der Entwicklung von Spielen einher, sei es, weil der Spielbegriff im Sinne Claus Pias’ mit dem Computing-Begriff zur Deckung gebracht werden kann,² oder aber, weil Computerspiele nicht selten zur Entwicklung³ und zum Testen neuer Hardware genutzt werden. Als mit den Minicomputern der 1960er-Jahre erstmals Systeme für kleinere Betriebe, Universitäten und Schulen erschwinglich wurden, ließ auch die Entwicklung von Computerspielen nicht lange auf sich warten. Diese wurde von Beginn an von der Sekundärliteratur begleitet: 1969 veröffentlichte David Ahl den ersten Band von 101 BASIC Computer Games, in welchem Hobbyist:innen ihre Spielideen in PDP-BASIC-Dialekten publiziert hatten.

Steven Levy beschreibt die Phase dieses Übergangs von sporadischem Game-Hacking der frühen 1970er-Jahre zur explosionsartigen Vergrößerung der Bewegung zu Beginn der Homecomputer-Ära ab 1977⁴ als eine Fortsetzung jener Autonomiebewegung, die in zwanzig Jahre früher mit dem Credo „You can create art and beauty on a computer“⁵ einsetzte. Das „can“ darf hierbei als Folge des grundsätzlichen „Access to computers“⁶ und Aufruf zum „Hands-on“⁷ verstanden werden. Die von Apple, Radio Shack, Commodore und kurz darauf auch von Sharp, Atari und Texas Instruments gegen Ende des Jahrzehnts veröffentlichten Mikrocomputer wurden quasi zur Manifestation dieser Ideen. Denn aufgrund ihrer geringen RAM-Speicher, langsamen Datenträger, oft nur schwer möglichen Erweiterbarkeit und fehlenden oder teuren professionellen Software⁸ war das Selber-Handanlegen (Home Brewing) oft die einzige Möglichkeit, kreativen Zugang zu den Systemen zu bekommen.

Wo die frühesten Homecomputer noch eher spärlich mit Sound- und Grafikmöglichkeiten sowie Schnittstellen für Game-Controller ausgestattet waren, brachte bereits die zweite Generation, zu der die Geräte von Atari, Amstrad, Commodore und die MSX-Computer gehörten, schon alles mit, um aus Homecomputern veritable Spielcomputer zu machen. Allem voran war die ‚Auslagerung‘ der Grafik- und Tonerzeugung aus der CPU (die damit mehr Ressourcen für das Abarbeiten des übrigen Programmcodes bekam) der entscheidende technologische Schritt in Richtung audiovisueller Versatilität der Homecomputer. Atari hatte das Prinzip mit der Entwicklung des TIA-Chips in der Spielkonsole VCS bereits 1976 eingeführt und zwei Jahre später auf seine Homecomputer übertragen; andere Anbieter zogen mit Eigenentwicklungen (wie Commodore) oder lizenzierten Standardbausteinen (wie MSX oder Amstrad) für ihre Systeme nach.

2. Computer für das Eigenheim

Anders als heute waren Mikrocomputersysteme der Vergangenheit zumeist inkompatibel zueinander. Dass Software vom einem Commodore-Computer nicht auf einem Gerät von Atari geladen werden konnte, lag nicht allein an den unterschiedlichen Datenträger-, Signalformaten und Schnittstellen; trotz oftmals gleicher CPUs ‚verstanden‘ sich die Systeme untereinander nicht, weil sie über unterschiedliche Spezialbausteine verfügten, welche die Eingabe, Ausgabe und Verarbeitung von Daten auf unterschiedliche Weise und in unterschiedlichen Speicherarchitekturen vollzogen – dies betraf zentral die Grafik- und Soundoperationen. Manche Computer verfügten über eingebaute Lautsprecher, andere gaben Ton über eine Standard-Audioschnittstelle aus, wieder andere mischten das Tonsignal dem TV-Signal bei oder stellten dafür separate Pins in der Monitorbuchse zur Verfügung. Der Tonerzeugungsmöglichkeiten der Systeme variierten in Abhängigkeit von den Soundbausteinen⁹ und deren Spezifikationen (Frequenzumfang, Anzahl der Kanäle, Klangformung und -filterung, Rauschgeneratoren etc.)

Aufgrund dieser Hardwarevielfalt und der Mitte der 1980er-Jahre nahezu unüberschaubar groß gewordenen Anzahl verschiedenartiger Homecomputersysteme entwickelten sich auf die jeweiligen Plattformen spezialisierte Nutzergruppen – teilweise überregional vernetzt, teilweise in kleinen, lokal begrenzten Clubs oder bloß locker organisierten Nutzer:innengruppen, um Ideen, Erfahrungen und Programme zu tauschen. Systematische Vernetzung dieser Communities fand auf Basis der erhältlichen Literatur für die jeweiligen Systeme statt. Der Homecomputer und die Literatur zum Homecomputing waren in der ersten Hälfte der 1970er-Jahre wechselseitig auseinander hervorgegangen: Die ersten Homecomputer wurden als Bausätze in Bastlerzeitschriften angeboten und diese Zeitschriften kümmerten sich hernach auch um den Nachschub an Peripherie und Software. Solche Beiträge berichteten entweder von professionellen Lösungen oder dokumentierten die Entwicklungen von Leser:innen und Anwender:innen: Lötkurse, Umbau- und Erweiterungsanleitungen und nicht zuletzt Programmierkurse und Programmcode zum Abtippen nahmen eine zentrale Stelle und großen Raum in solchen Publikationen ein (Abb. 1).

Abb. 1: Auswahl von Computerzeitschriften mit BASIC-Listings

Zusammen mit den Computertypen wuchs auch die Menge an spezialisierten Zeitschriften und Buchpublikationen. Die Autor:innen dieser Werke waren ebenso nicht immer Fachleute, die Informatik oder Technikjournalismus gelernt oder studiert hatten, sondern viel öfter selbst Hobbyist:innen, die Fanzines, größere Magazine oder Computerbücher publizierten. Verlage entdeckten das Potenzial dahinter und öffneten sich neuen Reihen und Themengebieten. Mithilfe dieser Publikationen eskalierte auch die Selbstausbildung der zumeist jungen Computernutzer:innen und ging in den Publikationskreislauf ein. Dies geschah zumeist in Form eingesandter Programmlistings. Abtipp-Programme in BASIC, Maschinensprache oder seltener anderen Hochsprachen (Pascal, Forth oder Logo) sind ein spezifisches Merkmal dieser Zeitschriften, das sich weder zuvor noch danach in IT-Zeitschriften gefunden hat. Die Mischung aus redaktionellen Beiträgen (Tests, Berichte, Interviews) mit Leserbeiträgen (Kleinanzeigen und Programmlistings) bildete ein attraktives Medium der Informationsgewinnung und Vernetzung der Computernutzer:innen.

Neben solchen Zeitschriften existierte ein immenser Vorrat an ‚Ratgeberliteratur‘, in der Computerbesitzer:innen auf jedem Niveau Informationen über ihr System erhalten konnten, die in den (obwohl sehr umfangreichen und didaktisch gut aufgebauten¹⁰) Handbüchern nicht verfügbar waren. Die Palette solcher Bücher reichte von Bedienungshilfen für kommerzielle Software über Sammlungen von Abtipp-Programmen, technischen Ratgebern (wie Erweiterungen selbst gebaut oder Defekte repariert werden können), Dokumentation der Betriebssysteme, Lehrbücher für Programmiersprachen bis hin zu thematisch sortierten Anleitungen, um Programme bestimmter Gattungen selbst schreiben zu können. Überproportional viele Titel beschäftigten sich mit Computerspielen – entweder, indem sie Programme zum Abtippen oder einzelne Routinen (etwa für Game-Sounds) versammelten oder die Leser:innen darin anleiteten, selbst Spielprogramme zu entwickeln. (Abb. 2)

Abb. 2: Auswahl an Homecomputer-Buchpublikationen mit Spielprogrammen

3. Starr auf den Fernsehschirm

Die Textsorte Programmlisting nimmt eine eigentümliche Stellung zwischen dem Programmcode im Computer und dem gedruckten Diskursbeitrag in der Zeitschrift ein. Gelesen werden muss ein solches Listing nämlich vom Menschen, der es zeichengenau in seinen Computer einzutippen hat, damit dieser es im nächsten Schritt ebenfalls lesen und schließlich ausführen kann. Die Abtipper:innen finden sich dabei in die Rolle mittelalterlicher Kopisten zurückversetzt,¹¹ wenn sie den vor ihnen liegenden Ausdruck weniger – wie einen herkömmlichen Text – hermeneutisch erfassen, als ihn – wie ein Medienkanal – von einem Speichermedium (der Zeitschrift mit ihrem Papier) in ein anderes Speichermedium (das Computer-RAM und dann den magnetischen Massenspeicher) kopieren. Damit gleichen sie augenscheinlich Searles Übersetzer im „chinese room“¹²; allerdings stellen sich beim Übertragen durchaus erste rudimentäre Verständnisse des Codes und seiner Struktur ein.¹³ Überdies ereignen sich beim Abtippen nicht selten ‚Kopierfehler‘, die später zum Abbruch/Absturz oder einem nicht-erwartetem Verhalten des Programms führen und ein abermaliges, akribisches Vergleichen von Textvorlage und eingegebenem Code verlangen.

Abtipp-Programme wurden, wie geschrieben, zumeist in der Programmiersprache BASIC veröffentlicht. Das didaktische Paradigma, das dieser Sprache zugrunde liegt, erlaubt es selbst bei solchen Dialekten, die sich schon weit von den Originalideen ihrer Erfinder entfernt hatten,¹⁴ durchaus den Code lesend zu verstehen. Dies hilft sowohl dabei, die Struktur und Syntax des Programms zu erfassen und Fehler zu vermeiden oder zu finden, als auch Algorithmen mental ‚vorzuvollziehen‘ – in Antizipation der später erwarteten Ausführung durch den Computer. Gekonnte Routinen und nützliche Algorithmen können auf diese Weise auch für eigene Programmierprojekte gelernt oder umgenutzt bzw. kopiert werden. Insbesondere dieses ‚interpretierende‘ Verstehen des Programmcodes versetzt die Programmierer:innen damals wie heute in jenen Maschinenzustand, von dem bereits Alan Turing schrieb, als er den (menschlichen) Computer als „Papiermaschine“ bezeichnete.¹⁵

Die mentale In-Operation-Setzung des Programms muss für die Nutzer:innen jedoch zwangsläufig vor allem an jenen Punkten versagen, wo die Hardware vom Code direkt adressiert wird, um spezifische zeitkritische Maschinenfunktionen aufzurufen. Wie weiter unten gezeigt wird, ist dies insbesondere beim Aufruf von Sound-Routinen der Fall. Darüber hinaus können auch heute nur wenige Hobbyprogrammierer:innen die ‚Black Box‘ der Hochsprache BASIC so weit durchschauen, dass wie wissen, was genau ihr Computer tut, wenn ein BASIC-Befehl ausgeführt wird.¹⁶ Hinter jedem Kommando, jeder Funktion und Operation verbirgt sich eine ganze ‚Bibliothek‘ von miteinander verknüpften Maschinensprache-Routinen, die als Betriebssystem und Übersetzerprogramm die Hochsprache BASIC in für den Computer ausführbaren Maschinenode übertragen. Diese Übertragung gleicht einer zweiten, nunmehr maschinellen Transkription, bei der in Echtzeit das BASIC-Programm durchlaufen wird, Strukturen wie Schleifen und bedingte Sprünge erkannt, Tabellen für Variablen und Adressen angelegt und ausgelesen und natürlich die Befehle ausgeführt werden. Dies alles vollzieht sich in so hoher Geschwindigkeit, dass für die Programmierer:innen der Eindruck einer Echtzeitausführung des Programmcodes entsteht.

4. Ich kontrolliere und komponiere

Die Programmiersprache BASIC besitzt aufgrund der zuvor geschilderten Nutzung in Homecomputern und den damit zusammenhängenden Publikationen und Kulturen die umfangreichste Kulturgeschichte aller Programmiersprachen. Keine andere Sprache wurde von so vielen Menschen gelernt und programmiert. Dass dies möglich war, ist Ergebnis einer Kombination aus didaktisch orientiertem Sprachdesign und der (ökonomischen) Entscheidung, die Sprache nicht zu patentieren oder zu lizenzieren. Aus diesen Gründen fand BASIC Verwendung durch viele kleine Computerhersteller, die damit kostengünstig und einfach Sprache in ihre Systeme integrieren konnten.

BASIC wurde 1964 am Dartmouth College (Hanover, New Hampshire, USA) von Thomas E. Kurtz und John G. Kemeny entwickelt. Ziel war es, eine Programmiersprache für Lehrzwecke zu konzipieren, die vor allem von Student:innen nicht-technischer Fächer verstanden und schnell gelernt werden konnte. Aus diesem Grund verzichtete BASIC auf viele Eigenschaften anderer höherer Programmiersprachen (vor allem in Hinblick auf unterschiedliche Datentypen) und setzte von Beginn an auf interaktives Programmieren. Hierfür entwickelten Kurtz und Kemeny zeitgleich ein Time-Sharing-Betriebssystem (Dartmouth-Time-Sharing-System¹⁷), das es ermöglichte, viele Terminals an einem einzigen Computer anzuschließen. So konnte Programmieren nicht nur in größeren Lerngruppen gleichzeitig hands-on unterrichtet werden, sondern durch das Time-Sharing-Konzept konnten alle Kursteilnehmer:innen (scheinbar) zeitgleich auf den Computer zugreifen, um ihre BASIC-Programme laufen lassen. Dies führte zwar zu einer Verlangsamung des Computers, diese blieb jedoch unmerklich, weil frühe BASIC-Dialekte noch keine zeitkritischen Programmfunktionen ermöglichten.

BASIC wurde kurz nach der Veröffentlichung auch an Schulen (die via Telefon auf das Time-Sharing-System des Dartmouth-College zugreifen konnten¹⁸) genutzt und von anderen Colleges auf eigenen Computern für die Programmierlehre übernommen. Da hier auch andere Systeme als am Dartmouth College eingesetzt wurden, musste das BASIC-Übersetzerprogramm (der Compiler) umgeschrieben werden. So entstanden nach den Versionen für General-Electric-Computer solche für Hewlett-Packard-, Digital-Equipment-Corporation- und andere Minicomputer-Systeme. Als Mitte der 1970er-Jahre Bill Gates und zwei Kommilitonen am Stanford-College BASIC kennenlernten, entwickelten sie das erste Übersetzerprogramm, das auf den neu erschienen Mikrocomputern BASIC lauffähig machten sollte (einen Interpreter). Dieser unterschied sich dadurch von der Compiler-Version, dass er das BASIC-Programm nicht schon komplett vor der Ausführung, sondern erst zu seiner Laufzeit schrittweise in Maschinencode übersetzt. Damit konnte zwar Speicher gespart werden, die BASIC-Programme liefen jedoch langsamer, weil jeder Befehl und jede Funktion nun ‚on the fly‘ übersetzt werden musste, sobald sie im Programmcode erkannt wurden. Die von Gates und seinen Kollegen gegründete Firma Micro-Soft entwickelte in den Folgejahren zahlreiche solcher BASIC-Interpreter für unterschiedlichste Mikrocomputer-Systeme, so dass Microsoft-BASIC auf zahlreichen Plattformen vorzufinden war.

5. (Hello) Computer World!

Um eine basale Lesekompetenz für BASIC-Programme zu erlangen, die für die Lektüre der Spielprogramm-Beispiele genutzt werden kann, soll im Folgenden auf einige Aspekte des Sprachbaus eingegangen werden.

BASIC war zur Zeit der Homecomputer trotz seiner didaktischen Ausrichtung eine maschinennahe Sprache,¹⁹ denn etliche Sprachkonzepte erinnerten an die Art und Weise, wie Algorithmen und Programme in Assembler- bzw. Maschinensprache formuliert oder abgearbeitet wurden. Hierzu zählte zunächst der rein imperativ orientierte Programmierstil: Programme wurden als Befehlsfolgen formuliert, die durch den Computer nacheinander ausgeführt wurden. Dieses imperative Programmierparadigma teilt BASIC bis heute mit zahlreichen anderen Sprachen; es ist allerdings auch ein Grund für seine syntaktische Struktur. Beim Übersetzen von BASIC-Anweisungen sucht der Interpreter zunächst entweder nach

1. einem Schlüsselwort (ein sofort auszuführender Befehl) oder
2. einer Zeilennummer (eines später auszuführenden Programms) oder
3. einem Variablennamen (einer Zuweisung von Daten).

Wird keine dieser drei Möglichkeiten gefunden,²⁰ gibt der Interpreter eine Fehlermeldung aus. Die Fehlermeldungen in BASIC sind „in English“²¹ und für die Programmierer:innen klar verständlich formuliert. An einem kurzen Beispiel soll gezeigt werden, wie ein BASIC-Programm aufgebaut ist:

10 CLS: REM Bildschirm löschen
20 PRINT A$;
30 GOTO 20

Das Programm löscht nach dem Start den Bildschirm und gibt eine endlose Folge des Variableninhaltes von A$ nebeneinander aus. An diesem Code können einige Besonderheiten der Sprache gezeigt werden:

Die Zeilennummern (10, 20, 30) strukturieren das Programm linear in aufsteigender Abfolge. ‚Zwischen‘ zwei Zeilennummern kann, sofern der numerische Abstand groß genug ist, nachträglich eine weitere Zeile eingefügt werden, etwa das hier noch fehlende:

15 LET A$=“Hallo, Welt!“

Die Zeilennummern dienen aber nicht allein der Strukturierung des Codes, sondern auch als Label, die von überall im Programm aus angesprungen werden können. Die Zeile 30 zeigt dies: Dort wird mit GOTO 20 zurück in die Zeile 20 gesprungen, damit diese noch einmal ausgeführt wird.

Der Befehl CLS in Zeile 10 ist typisch für Microsoft-BASIC-Dialekte, allerdings weder in all diesen zu finden noch in vielen Dialekten anderer Hersteller vertreten. Oft existieren dort anders lautende Befehle mit derselben Funktion (im Commodore-BASIC 3.5/7: SCNCLR) oder Ersatzkonstrukte (beim Commodore 64: PRINT CHR$(147) oder bei Atari GRAPHICS 0). Bei CLS handelt es sich um ein Akronym zu „CLear Screen“ – ein Befehl, um den Bildschirm zu löschen.

Der Befehl REM (REMark) ermöglicht es, einen Kommentar zu hinterlassen, der vom maschinellen BASIC-Interpreter ‚überlesen‘ wird und sich an die menschlichen Leser:innen des Programms richtet. Dass hier zwei Befehle in einer Zeile, durch einen Doppelpunkt getrennt, platziert werden können, spart zwar Platz auf dem Bildschirm, sorgt jedoch für eine gewisse Unübersichtlichkeit des Codes, gerade dann, wenn komplette Algorithmen auf diese Weise in einer Zeile untergebracht werden.²²

Während CLS keine weiteren Argumente verlangt oder ermöglicht, lassen sich beim Befehl PRINT in Zeile 20 Argumente angeben: entweder Daten in Form von Zahlen, Variablennamen (wie hier A$) oder eine Zeichenkette sowie optionale Steuerzeichen, die den Cursor positionieren. Letzteres wird hier durch das Semikolon erreicht, das dafür sorgt, dass die nächste Ausgabe mit PRINT rechts neben der vorherigen (und nicht wie standardisiert unterhalb dieser) ausgegeben wird.

Damit der PRINT-Befehl hier ‚weiß‘, was er mit der Variable A$ ausgeben soll, muss diese Variable zuvor definiert werden. Dies geschieht in Zeile 15 durch die Zuweisung LET A$=…, wobei das LET bei den meisten BASIC-Dialekten zwar optional ist, aber dabei hilft, das Zeichen „=“ nicht als Identitäts-, sondern als Zuweisungsoperator zu verstehen. Zeichenkettenvariablen sind am nachgestellten $-Zeichen von Zahlenvariablen (ohne $) unterscheidbar.

Die zwangsweise Strukturierung mit Zeilennummern, die als Labels. bzw. Sprungziele verwendet werden können, sowie das imperative Paradigma mit seiner Befehl-Argument-Struktur erinnern, wie geschrieben, stark an die maschinennahe Sprache Assembler:

C000 INC $D408
C003 JMP $C000

Die Hexadezimalzahlen C000 und C003 sind die Speicheradressen, an denen die Programmbefehle INC (INCrement, erhöhe den Inhalt des Speichers, hier: an der Adresse D408) und JMP (JuMP, Springe zu einer Adresse, hier: zurück zur Adresse C000) sowie deren Argumente/Adressen hinterlegt sind. Strukturell sind die beiden Programmcodes damit einander schon auf den ersten Blick recht ähnlich. Diese Ähnlichkeit hat nicht nur zur bereits erwähnten breiten didaktischen Kritik an BASIC geführt²³, sondern auch Programmierer:innen den ‚Sprung‘ von BASIC zu Assembler wesentlich erleichtert. Die Kenntnis der Assemblersprache des jeweiligen Systems²⁴ war unabdingbar, wollte man zeitkritische Algorithmen (etwa zur Musikerzeugung) programmieren.

6. Music Non Stop

Mit dem Anwachsen des Homecomputermarktes um weitere Hersteller und immer neue Modelle entstanden stetig neue BASIC-Dialekte. Dem technischen Fortschritt entsprechend, der auf diesem Sektor vor allem in Hinblick auf die audiovisuellen Funktionen und den Anschluss neuer Peripheriegeräte wahrnehmbar war, mussten die Dialekte angepasst werden. Homecomputer-Nutzer:innen sollten komfortabel von BASIC ausgehend möglichst alle Funktionen ihres Computers aufrufen und nutzen können. Hierzu wurde die Sprache um systemspezifische Befehle und Funktionen erweitert. Dort, wo solche Funktionen nicht durch eigene BASIC-Befehle aufrufbar waren, konnten sie entweder mit maschinen-nahen Programmiertricks aktiviert oder durch das Nachladen alternativer Programmiersprachen bzw. BASIC-Dialekte aufgerufen werden.²⁵

Im Folgenden sollen die Soundprogrammier-Möglichkeiten von vier BASIC-Dialekten auf vier Homecomputer-Typen kurz vorgestellt werden. Dies dient einerseits als weitere Grundlage für das Verständnis der im Anschluss besprochenen BASIC-Spielprogramme und ihrer Soundausgaben; andererseits zeigt es bereits die oft zeitkritische Operativität solcher Funktionen.²⁶

6.1 Atari-BASIC

<http://zerstoerung.de/jsa8e/>

Atari stieg nach dem Erfolg der Spielkonsole VCS bereits 1979 in den Homecomputer-Markt ein. Die Modelle Atari 400 und 800 (und die später erschienenen, kompatiblen XL- und XE-Modelle) verfolgten die Hardware-Strategie der Spielkonsole und enthielten Spezialchips für Grafik (GTIA) und Sound (POKEY). Ebenfalls wie bei der Spielkonsole konnte Software über Steckmodule ‚geladen‘ werden. Das Atari-BASIC gehörte zu diesen Titeln; es war auf einem 8 Kilobyte großen Cartridge verfügbar und ist in den beigefügten Anleitungen in seinen Grundfunktionen dokumentiert.

Die POKEY-Chips der Atari-Homecomputer 400, 800, XL- und XE-Serie sind für die Tongenerierung zuständig und verwalten zusätzlich die Eingabeschnittstellen des Computers (POtentiometer & KEYboard Controller). POKEY verfügt über vier monophone Tongeneratoren, die unabhängig voneinander oder im einem Mischmodus aufgerufen und über einen angeschlossenen Monitor bzw. Fernseher ausgegeben werden können. Es können 256 Tonhöhen zwischen 125 Hertz und 32 Kilohertz generiert werden. Neben den Klängen ist damit die Erzeugung von weißem Rauschen möglich. Überdies können 16 verschiedene Lautstärken eingestellt werden. Einige dieser Parameter lassen sich durch den Atari-BASIC-Befehl SOUND²⁷ aufrufen:

SOUND A, B, C, D

Wobei A für den Tonkanal 0-3, B für die Tonhöhe 0-255, C für die Verzerrung (0-14, geradzahlig) und D für die Lautstärke (0-15) steht. Abb. 3 zeigt die Verteilung der Werte für Parameter A auf einer dreioktavigen Klaviatur.

Abb. 3: Beziehung der Klaviertasten zum SOUND-Befehl ²⁸

FOR I=0 TO 255:SOUND 0,I,10,15:NEXT I:END

Diese Befehlskette erzeugt einen Durchlauf durch alle in BASIC verfügbaren Tonhöhen aus Kanal 0 in der Lautstärke 15. Am Ende wird ohne Unterbrechung der Ton 255 ausgegeben. END stoppt die Ausgabe.

FOR I=0 TO 255:SOUND 0,I,10,15:SOUND 1,I,8,10:NEXT I:END

Diese Eingabe aktiviert zwei Soundkanäle (0 und 1) simultan in zwei unterschiedlichen Lautstärken (15 und 10) und mit zwei unterschiedlichen Verzerrungen (10 und 8).

Der Parameter C steht für den Verzerrungswert. Hier können nur die Zahlen 0, 2, 4, 6, 8, 10, 12 und 14 übergeben werden; allein der Wert 10 führt zu ‚reinen‘ Klängen, alle anderen zu Verzerrungseffekten (distortion), wobei den Klängen auf „in der Industrie einzigartige Weise“²⁹ Rauschanteile beigemischt werden:

Die Verzerrung gibt beim ATARI’TM’-Computer nicht die Veränderung von Kurven, sondern die Entfernung der ausgesuchten Schwingungen innerhalb einer Kurve an (es werden vom Gerät immer nur Rechteck-Schwingungen ausgegeben). Diese Technik wird durch das Wort ‚Verzerrung‘ nicht korrekt bezeichnet; ein besserer Begriff wäre ‚Rauschen‘.³⁰

Auf die Kanal-Mischmodi bekommt man nur durch Programmierung des POKEY mittels POKE-Befehl Zugriff. Ebenso lassen sich nur auf diese Weise frequenzgenaue(re) Tonhöhen programmieren. Hierzu dienen die Audio-Kontrollregister (AUDC1 bis AUDC4) und Audio-Frequenzregister (AUDF1 bis AUDF4) des POKEY. Im Register AUDCTL lassen sich über Bit-Masken spezifische Funktionen wie Filter, Kanalverbindungen, Frequenzumfang (bis hin zur Taktung über den CPU-Takt von 1,79 MHz) regulieren.

6.2 Locomotive-BASIC

<https://floooh.github.io/tiny8bit/cpc.html>

Die Colour Personal Computer (CPC) waren aufgrund der Lizenzstrategie der britischen Firma Amstrad in ganz Europa verbreitet. Amstrad nutzte hierfür Kooperationen mit Elektronik-Resellern anderer Länder, welche ihre Homecomputer CPC 464, CPC 664 und CPC 6128 unter eigenem Label vermarkten durften. In Deutschland war dies die Firma Schneider. Der CPC wurde standardmäßig mit eingebautem Kassetten- (464) oder Diskettenlaufwerk (664, 6128) und 64 (464, 664) oder 128 Kilobyte (6128) RAM ausgeliefert. Zum Lieferumfang gehörte zusätzlich entweder ein Grün- oder Farbmonitor. Der Ton wird in allen drei Geräten über einen eingebauten Mono-Lautsprecher ausgegeben. Zusätzlich besitzen die Computer einen Audio-Ausgang, über den die drei vom Soundprozessor generierten Kanäle in Stereo (eine Stimme links, eine Stimme rechts und eine Stimme auf beiden Kanälen) ausgegeben werden.

Als Soundprozessor in den CPCs dient der AY-3-8912 der Firma General Instruments. Dieser bereits 1978 veröffentlichte PSG (programmable sound generator) ist auch in zahlreichen anderen Computern und Spielautomaten verbaut worden. Er verfügt über 3 Stimmen/Kanäle mit jeweils 1024 Tonhöhen, die in 16 Lautstärkestufen wiedergegeben werden können. Alle drei Stimmen können über einen Hüllkurven-Generator modelliert werden. Ein Zufallszahlengenerator im IC ermöglichte auch hier die Beimischung von Rauschanteilen zu jeder Stimme.

Das in den CPCs implementierte Locomotive-BASIC gehört zu den umfangreichsten und am besten dokumentierten Dialekten der Homecomputer-Ära. Für die Erzeugung und Gestaltung von Klängen stehen vier verschiedene Befehle zur Verfügung: SOUND zur Erzeugung eines Klanges mit den angegebenen Parametern, ENT zur Gestaltung einer Ton-Hüllkurve³¹ und ENV zur Gestaltung einer Lautstärken-Hüllkurve³² sowie RELEASE zur Auslösung eines Kanal-‚Rendezvous‘ (s. u.):³³

SOUND <Kanal>,<Tonperiode>,<Dauer>,<Lautstärke>,<Lautstärken-Hüllkurve>,<Ton-Hüllkurve>,<Rauschen>

Der Parameter <Kanal> wählt eine der drei Stimmen aus oder gibt bei Übergabe von 8, 16 oder 32 ein ‚Rendezvous‘ an (das den Kanal erst aktiviert, wenn ein anderer Kanal erklingt). Der <Rauschen>-Parameter mischt zum Klang ein Rauschen mit der Periode 0-32 hinzu. Die beiden Hüllkurven-Parameter werden mittels zwei separater Befehle voreingestellt:

ENT <Hüllkurvennummer>[,<Hüllkurvenabschnitt>][,<Hüllkurvenabschnitt>][,<Hüllkurvenabschnitt>][,<Hüllkurvenabschnitt>][,<Hüllkurvenabschnitt>]

ENV <Hüllkurvennummer>[,<Hüllkurvenabschnitt>][,<Hüllkurvenabschnitt>][,<Hüllkurvenabschnitt>][,<Hüllkurvenabschnitt>][,<Hüllkurvenabschnitt>]

Jede der 15 möglichen Ton-Hüllkurven (ENT) kann um 5 mögliche Hüllkurvenabschnitte mit zwei oder drei Parametern ergänzt werden: <Schrittanzahl>,<Schrittweite>,<Schrittzeit> oder <Tonperiode>,<Schrittzeit>. Jeder der fünf Lautstärken-Hüllkurvenabschnitte (ENV) kann drei Parameter (für <Schrittanzahl>,<Schrittweite> und <Schrittzeit>) oder zwei Parameter (<Registerwert> und <Hüllkurvenperiode>) enthalten.

Das folgende BASIC-Programm zeigt die Verwendung der Befehle:

10 ENV 1,100,1,3:REM Lautstaerkenhuellkurve 1
20 ENT 1,100,5,3:REM Tonhuellkurve 1
30 SOUND 1,142,300,15,1,1,5:REM Soundkanal 1, Tonstufe 142, Dauer 300

Zunächst werden in den Zeilen 10 und 20 die Hüllkurven für den Kanal 1 modelliert. In Zeile 30 wird dann der Kammerton A (440 Hertz) mit der Lautstärke 15 und der Länge 300 Millisekunden gespielt. Dieser wird durch die beiden Hüllkurven (1,1) verändert und mit einem Rauschen mit dem Intervall 5 angereichert.

Mit RELEASE können Sounds, die über die Rendezvous-Funktion in einer Warteschlange auf ihre Aktivierung warten, ausgelöst werden:

RELEASE <Kanäle>

Der <Kanäle>-Parameter liegt zwischen 1 und 7 und gibt wahlweise einen (1,2,4), zwei (3,5,6) oder alle drei Kanäle (7) frei.

Vom Locomotive-BASIC aus ist es möglich Software-interruptgesteuerte³⁴ Sounds abzuspielen, bei denen der übrige Programmablauf regelmäßig unterbrochen wird, um einen neuen Ton wiederzugeben. Hierzu können die Befehle EVERY und AFTER verwendet werden:

10 AFTER 250 GOSUB 100
20 PRINT X;:X=X+1:GOTO 20
100 SOUND 1,142,300,15
110 RETURN

5 Sekunden nach Programmstart wird das Unterprogramm in Zeile 100 angesprungen, um einen Ton abzuspielen und dann zum Hauptprogramm zurückzukehren. Der Parameter nach AFTER gibt also 50stel Sekunden an.³⁵

10 EVERY 100 GOSUB 100
20 PRINT X;:X=X+1:GOTO 20
100 SOUND 1,20
110 RETURN

Hier wird voreingestellt, dass das Programm regelmäßig alle 2 Sekunden (alle 100 50stel Sekunden) die Soundausgabe in Zeile 100 anspringt, um dann in die Endlosschleife in Zeile 20 zurückzukehren.³⁶

Beide Befehle speisen ihre Zeitangaben aus einem vom Interpreter zur Verfügung gestellten Software-Timer. Damit wäre es von Locomotive-BASIC aus möglich, zum Beispiel kontinuierliche, timergesteuerte Hintergrundmusik zu programmieren. Die leichten Ausgabeverzögerungen beim Anspringen der Sound-Unterroutine deuten aber bereits das grundsätzliche Timingproblem von BASIC-Sounds an.

6.3 Commodore-BASIC V2.0

<https://c64emulator.111mb.de/index.php?site=pp_javascript&group=c64>

Der dritte hier vorgestellte BASIC-Dialekt ist vor allem durch seine Verwendung im Commodore 64 (C64) bekannt. Wie oben bereits erwähnt, ist dieses BASIC mit nur 34 Befehlen und 26 Funktionen vergleichsweise³⁷ spartanisch ausgestattet. Der Soundchip des C64, SID (Sound Interface Device), gehört allerdings zu den komplexesten Geräten dieser Art, die sich in Homecomputern finden. Er verfügt über drei Stimmen, einen Rauschgenerator, die Möglichkeit vier Wellenformen (Rechteck, Sägezahn, Dreieck und Rauschen) zu generieren, Ringmodulation, Amplitudenmodulation, analoge Klangfilter und sogar einen Audioeingang, um Signale ‚durchzuschleifen‘ – dem erzeugten Ton beimischen und über den Tonausgang wiedergeben. Diese Features werden allerdings durch keine Befehle oder Funktionen im BASIC des C64 repräsentiert.

Das Handbuch und zahlreiche Sekundärliteratur-Titel versuchen, dieses Defizit auszugleichen, indem sie in die maschinennahe Programmierung des Soundprozessors SID mittels POKE-Befehl und PEEK-Funktion einführen.³⁸ Der SID-Chip kann (ähnlich wie POKEY) über seine Register aktiviert und mit Parametern versorgt werden. Diese Register liegen im C64-RAM-Bereich 54272-54300.³⁹ Um eine Stimme (beispielsweise Kanal 1) zu aktivieren, muss zunächst deren Lautstärke definiert werden:

10 POKE 54296,15: REM LAUTSTAERKE 15

Danach muss ein 16-Bit-Notenwert (unterteilt in einen Highbyte- und einen Lowbyte-Anteil) übergeben werden:

20 POKE 54273,57:POKE 54272,172: REM KAMMERTON A (440 HZ) AUF STIMME 1

Nun können die Hüllkurvenparameter definiert werden:

30 POKE 54277,105: REM ATTACK: 1 SEKUNDE, DECAY: 750 MILLISEKUNDEN
40 POKE 54278,252: REM SUSTAIN: 10, RELEASE: 2,4 SEKUNDEN

Schließlich wird die Wellenform bestimmt, womit die Tonausgabe startet:

50 POKE 54276,33: REM SÄGEZAHN

Damit der Ton eine gewisse Zeitlang zu hören ist, kann eine Warteschleife programmiert werden:

60 FOR I=1 TO 1000:NEXT I

Am Ende wird der Ton wieder abgeschaltet, indem die Wellenform neu gesetzt wird:

70 POKE 54276,34: REM RECHTECKWELLE

Das folgende, von Nick Montfort entwickelte BASIC-Progamm⁴⁰ zeigt, wie sich zufällige Einstellungen dieser Register anhören:

10 POKE 54272+RND(1)*25,RND(1)*256:GOTO 10

6.4 ZX-Spectrum-BASIC

<https://jsspeccy.zxdemo.org/>

Besaß das Commodore-BASIC V2.0 keine Soundbefehle, um die vielfältigen Funktionen des SID-Chips direkt zu nutzen, so ist es beim Sinclair ZX Spectrum genau andersherum: Das BASIC verfügt zwar über einen Befehl, um den im Computer eingebauten Lautsprecher erklingen zu lassen,⁴¹ es existiert jedoch gar kein Soundchip in diesem. Die Soundgenerierung übernimmt an dessen Stelle der Mikroprozessor Z80. Dies hat den Nachteil, dass im Prinzip nur eine Stimme verfügbar ist und diese auch nur Rechteckwellen mit einer fixen Amplitude generieren kann. Sie vermag dies allerdings in beliebig wählbaren Frequenzen zwischen 0 Hertz und 437.5 Kilohertz. Zwar können solch hohe Frequenzen nicht gehört werden, die Geschwindigkeit, mit der die CPU in dieser Taktfrequenz aber zwischen einzelnen Tonausgaben wechseln kann, ist allerdings dazu geeignet, polyphone Höranmutungen zu erzeugen. Der ZX Spectrum generiert damit sogenannte1-Bit-Musik⁴² – jedoch nicht unter BASIC.

Der BEEP-Befehl im Sinclair-BASIC ist sehr einfach aufgebaut. Ihm werden zwei Parameter übergeben: die Dauer in Sekunden und die Tonhöhe als Notenwerte in Halbton-Abständen (siehe Abb. 4):

BEEP 0.5,9

… spielt einen halbsekündigen Kammerton A. Pausen zwischen mehreren nacheinander abgespielten Tönen lassen sich mit dem Befehl PAUSE generieren. Der Parameter hierzu wird in 50stel-Sekunden angegeben (abhängig von der Bildwiederholfrequenz des jeweiligen Fernsehsystems und damit im Prinzip interruptgesteuert):

BEEP 1,6:PAUSE 50:BEEP 2,7:PAUSE 25:BEEP 1,6

Der Umstand, dass der ZX Spectrum seine Tonausgaben mit dem Mikroprozessor erzeugt, führt dazu, dass Sounds unter BASIC lediglich einkanalig, in Mono und zudem in stets gleichlauten Rechteckwellen generiert werden können. Erst durch Maschinenspracheprogramme lässt sich die oben genannte Pseudopolyphonie erzielen.

Abb. 4: Klaviatur mit Notenwerten für Spectrum-BASIC⁴³

Beim Ausführen des BEEP-Befehls wird der Interrupt des Prozessors gesperrt (damit andere Prozesse die Klangwiedergabe nicht unterbrechen und so beeinflussen können). Das führt dazu, dass auch das BASIC-Programm, in dem BEEP aufgerufen wird, für die Zeit, in der ein Ton ausgegeben wird, ‚wartet‘. Damit wird die Einbindung längerer Tonwiedergaben oder gar Musikstücke parallel zu Spielprogramm-Ausführungen in BASIC ebenfalls unmöglich.

7. I’s more Fun to Compute

Nachdem die technischen Möglichkeiten der Soundgenerierung bei vier Homecomputer-Systemen dargestellt und deren Aktivierung über die Programmiersprache BASIC vorgeführt wurden, sollen nun Anwendungen diskutiert werden. Dabei handelt es sich um von Hobbyist:innen programmierte Computerspiele in BASIC, die Soundausgaben besitzen. Wie sich zeigen wird, sind diese Ausgaben unterschiedlich komplex, dienen unterschiedlichen Zwecken und werden auf unterschiedliche Weisen programmiert.

Viele BASIC-Computerspiele besitzen gar keine Soundausgaben. Dies kann unterschiedliche Gründe haben: Entweder verfügen die bezogenen Systeme über keine (reguläre⁴⁴) Soundausgabe; die Spiele sind für unterschiedliche Plattformen konzipiert worden, wobei auf systemspezifische Eigenheiten bewusst verzichtet werden musste;⁴⁵ oder die jeweiligen Spiele oder Spielgenres ‚benötigen‘ keine Soundausgaben, was nicht bedeutet, dass sie nicht prinzipiell durch Soundausgaben angereichert werden könnten.

7.1 Zeitkritische Klangerzeugung: ZX Spectrum

Die deutsche Zeitschrift HC – Mein Home-Computer, erschienen zwischen Ende 1983 und 1986 und richtete sich an Nutzer:innen unterschiedlicher Computersysteme, wie sich an den abgedruckten BASIC-Listings zeigt. Für den ZX Spectrum befindet sich unter anderem in Ausgabe 12 von 1983 das mit nur 33 Zeilen kurze BASIC-Spiel Hinterhalt zum Abtippen.⁴⁶

Hinterhalt ist ein Strategie-Spiel mit Zufallselementen, bei dem Spieler:innen mit der Spielfigur ein Areal abschreiten müssen, während sukzessive Fallen in ihrer Umgebung gestellt werden, in die sie nicht tappen dürfen. Geschieht dies dennoch, so ertönt eine fallende Tonfolge [405-420]⁴⁷, bevor das Spiel zu Ende ist und durch RETURN-Eingabe erneut gestartet werden kann. Ziel des Spiels ist es, so viele Schritte wie möglich zu gehen (ein Schrittzähler informiert über die Anzahl), bevor unausweichlich eine Falle betreten wird. Die Tonausgabe gibt daher einen akustischen Hinweis (ein ‚Fallgeräusch‘) auf das Spielgeschehen und zugleich auf das Spielende (Game Over) und kann damit außerhalb der übrigen Spielalgorithmen aufgerufen werden.

Das in der darauf folgenden HC-Ausgabe 1 von 1984 veröffentlichte BASIC-Listing zum Spiel Vier gewinnt ist etwas länger und führt eine computerbasierte Variante des bekannten Zweipersonenspiels⁴⁸ vor, bei der zwei menschliche Spieler:innen gegeneinander antreten. (Der Computer überwacht lediglich die Einhaltung der Spielregeln und registriert die Gewinn/Verlust-Situation.) Das Spiel gibt dabei Sound in unterschiedlichen Situationen aus: Eine zwanzigstel Sekunde lang ertönt ein Ton, wenn ein Spielstein per Tastendruck zu einem Schacht bewegt wird [198], drei zehntel Sekunden lang ertönt ein Geräusch, wenn ein Spielstein nicht in einen Schacht geworfen werden kann [204]; ein algorithmisch erzeugtes Glissando begleitet hingegen das Herabfallen eines Steins [221] und schließlich wird eine kurze Melodie gespielt (das Leitmotiv aus dem River Kwai March), wenn ein:e Spieler:in das Spiel gewonnen hat [265]:

256 BEEP 0.3,13: BEEP 0.6,10: PAUSE 25: BEEP 0.3,10: BEEP 0.3,11:BEEP 0,3,13: BEEP 0.6,22: BEEP 0.6,22: BEEP 0.6,18

Die Länge der Sounds, die während des Spielverlaufs wiedergegeben werden, liegt weit unterhalb einer Sekunde, damit das Spielgeschehen durch die Ausgaben nicht zu lang unterbrochen wird, aber dennoch ein akustisches Feedback über die Spieler:in-Aktionen gegeben werden kann. Wiederum kann eine komplexere Tonausgabe erst nach Ende des Spiels erfolgen.

Abb. 5: Hinterhalt (Screenshot) und Vier gewinnt (Screenshot)

Der Soundeinsatz in beiden Spielen ist typisch für BASIC-Spiele auf dieser Plattform. Er richtet sich in seiner Länge und Komplexität vor allem danach, ob der Programmablauf für die Tonausgabe pausiert werden kann oder nicht. Aufgrund der Langsamkeit des Interpreters und den geringen Möglichkeiten der Parameter-Übergabe an den BEEP-Befehl lassen sich ohne Zuhilfenahme von Maschinensprache-Routinen keine andersartigen Sounds, geschweige quasi-polyphone 1-Bit-Musik in Sinclair-BASIC-Spielen generieren.

7.2 CPC: Vielfältige Soundprogrammierung

Das Spiel Horror Caves für Amstrad-CPCs ist aufgrund seiner Länge von über 280 BASIC-Zeilen ungleich komplexer als die vorherigen Beispiele. Es handelt sich um ein Actionspiel, bei dem Spieler:innen in den Höhlen der Pyrenäen Eisenerz schürfen müssen. Die Spielfigur wird bei dieser Aktion jedoch permanent von Geistern angegriffen, denen sie beim Lauf durch die labyrinthartigen Höhlen entkommen muss. Der zusätzlich knapper werdende Luftvorrat stellt eine Zeitbegrenzung dar; er kann bei Erreichen einer bestimmten Punktzahl durch Tastendruck erneuert werden.

Das Spiel verfügt bereits über KI-Gegner und eine steigende Schwierigkeitskurve. Das BASIC-Listing ist, anders als die Programme für den ZX Spectrum, gut strukturiert und die einzelnen Programmteile sind so kommentiert, dass sich Manipulationen am Code (zu denen der Einleitungstext explizit aufruft) leicht vornehmen lassen. Unterstützend hierfür gibt die Zeitschrift die verwendeten Variablen in einer Tabelle an.

Soundausgaben begegnen den Spieler:innen an verschiedenen Stellen:

• Während der Titelschriftzug gezeichnet wird, ist eine Art Kratzgeräusch zu hören [2260].

Die erste Stimme mit 1244 Hertz wird kontinuierlich für eine hundertstel Sekunde aktiviert und danach für zwei hundertstel Sekunden pausiert.

• Nachdem der Titelschriftzug fertig gezeichnet ist, ertönt ein zweistimmiges Musikstück (der Refrain aus Itsy Bitsy Teenie Weenie Yellow Polka Dot Bikini), das durch Drücken einer Taste unterbrochen wird, womit das Spiel startet [2380-2590].

Diese komplexe Melodie wird aus Werten für Stimme, Tonperiode und Dauer, welche als Datentabelle im Programm [2500-2590] hinterlegt sind, generiert. Dieses wird innerhalb einer Schleife mit 98 Durchläufen ausgelesen und mit einem SOUND-Befehl wiedergegeben. Ist die Wiedergabe beendet, startet sie von neuem, bis eine Taste gedrückt wird. Außerdem gibt es

• einen Sound (eine zehntel Sekunde), der beim Einsammeln des Erzes gespielt wird [2670],
• einen Sound (eine halbe Sekunde), der beim Berühren eines Geistes gespielt wird [910],
• sowie eine Soundfolge (eine fünfundzwanzgistel Sekunde), die bei zu niedriger Luftmenge wiedergegeben wird [980].

Diese Soundausgaben sind vergleichsweise kurz und immer dann zu hören, wenn das Spielgeschehen kurz verlangsamt werden darf, weil Erz eingesammelt oder ein Geist berührt wurde. Der Warnton ist von noch kürzer Dauer und kann daher sogar zwischen den Bewegungsschritten der Spielfigur wiedergegeben werden. Horror Caves nutzt die Software-Timer des Locomotive-BASIC damit nirgends.

Abb. 6: Horror Caves (Screenshot) und Pak Caverns (Screenshot)

Craig Mitchells 1985 in der britischen Zeitschrift Amstrad Computer User abgedrucktes Spiel Pak Caverns besteht aus zwei Teilen: einem „loader program“ und einem „main program“, das von ersterem nachgeladen wird. Das „loader program“ enthält neben der Spielanleitung die Grafik und einige Maschinenspracheroutinen. Das „main programm“ enthält die Spielalgorithmen, die Gebrauch von den zuvor geladenen Grafik- und Sounddaten machen. Bei diesem Snake-artigen Spiel muss eine Figur durch ein Labyrinth gelenkt werden und dort Äpfel verspeisen. Dabei wird sie sukzessive länger. Weder darf sie die Wände noch den eigenen Körper zu lange berühren, sonst verliert sie ein Leben. Pak Cavern enthält eine Vielzahl unterschiedlicher Soundausgaben; hier werden jene vorgestellt, die sich in Art und Erzeugung von denen aus Horror Caves unterscheiden.

Auch hier gibt es eine in DATA-Zeilen hinterlegte Titelmelodie (Maple Leaf Rag), die im „loader program“ geladen und wiedergegeben wird [2060-2430]. Die Sounddaten werden allerdings zunächst in ein dreidimensionales Array geladen, die Hüllkurven vorbereitet [400-530] und dann abgespielt, während andere Spieldaten im Hintergrund verarbeitet werden; dazu wird der Befehl EVERY 5 GOSUB 500 [170] genutzt. Nach dem Start des „main program“ ertönt eine zweite Melodie (Enola Gay von OMD), die bis zum Spielstart wiederholt wird. Sie ist ebenso in DATA-Zeilen hinterlegt [1250-1540 und 2060-2430] und wird aus einem zuvor geladenen Array wiedergegeben.

Das Programm spielt darüber hinaus zum Beispiel eine kurze Melodie und Tonfolgen ab, sobald ein Level beendet ist [2780], wenn ein Highscore erzielt wurde [5840-6130], wenn ein Leben verloren wurde [2580, 2600] oder das Spiel beendet ist [5290-5330]. Diese Soundausgaben verhalten sich ähnlich wie zuvor diskutierten: Sie sind entweder so kurz, dass sie das Spielgeschehen nicht verlangsamen oder werden während einer Wartezeit gespielt (z.B. beim Level-Wechsel).

Der Einsatz der Maschinensprache-Routinen, die im „loader program“ geladen werden, konzentriert sich auf den schnellen Bildaufbau (Levelgrafiken, Spielfiguren). Der Sound des Spiels wird auf Basis direkter Programmierung oder durch Wiedergabe von Datentabellen erzeugt.

7.3 Atari: Hintergrund(sound)wissen

Das für den Atari-Homecomputer vorzustellende Spiel benutzt eine besondere, hybride Technologie, um Sounds wiederzugeben. Es heißt The Castle und wurde 1985 in der Ausgabe 7 von HC – Mein Home-Computer von Thomas Fischermann veröffentlicht.⁴⁹ Im Spiel steuert man einen Ritter, der Steine von einer Burgmauer werfen muss, um acht auf nebeneinander aufgestellten Leitern heraufkletternde Feinde am Erreichen der Zinnen zu hindern. Die Steine müssen einzeln vom rechten oder linken Ende der Mauer geholt, zur jeweiligen Leiter getragen und abgeworfen werden. Wehren die Spieler:innen alle Feinde ab, beginnt der Prozess im nächsten Level erneut – allerdings schneller.

Abb. 7: The Castle (Screenshot)

The Castle nutzt vielfältige Möglichkeiten der Integration von Sounds. Abermals gibt es einen den Aufbau des Startbildschirms begleitenden Sound [1810]. Das Erscheinen [1390] und die Bewegung der Spielfigur [160] sowie der Gegner [1210, 1250] werden durch sehr kurze Geräusche untermalt, ebenso das Aufnehmen eines Steins [200]. Das Herabwerfen desselben wird von einem fallenden Glissando begleitet [330] und das Erreichen des Level-Endes durch Gewinn [1440-1480] oder Verlust (wenn ein Gegner am oberen Ende der Mauer angelangt ist) [1650] wird ebenfalls akustisch akzentuiert. Diese Sounds sind entweder mit konkreten Werten in den Code programmiert oder werden innerhalb von Schleifen generiert. Die gute Strukturierung des BASIC-Programms (durch invers dargestellt Überschriften im Listing und die Angaben der Programmstruktur und Variablenliste im Begleittext) erleichtern das Auffinden und die Manipulation dieser Soundoperationen.

Das hervorstechendste akustische Merkmal von The Castle ist jedoch die kontinuierlich wiedergegebene Hintergrundmusik.⁵⁰ Diese wird über eine in das BASIC-Programm integrierte Maschinenspracheroutine realisiert [950-1010]. Die dortigen DATA-Zeilen enthalten das Wiedergabeprogramm sowie die Musikdaten (Noten, Timingangaben etc.). Beides wird über einen BASIC-Loader [950] mittels POKE-Befehl in den Speicher ab Adresse 1536 (hexadezimal 0600) geschrieben. Um diese Routine regelmäßig und ‚automatisch‘ aufzurufen, wird ein Interrupt-Register⁵¹ der Timerroutinen des Betriebssystems manipuliert [960]. Hierzu wird den Speicheradressen 550 und 551 der 16-Adresswert-Wert 1536 (0600⁵²) übergeben.

Damit der Sound vergleichsweise dynamisch erklingt (also auf das Spielgeschehen reagiert), müssen bestimmte Parameter nachträglich vom BASIC-Programm aus variiert werden können: Er muss abgeschaltet werden können, sobald ein Level beendet ist. Dies geschieht in [1440] und [1650]: dort werden zunächst der Timer auf den Wert 0 gesetzt und danach mit SOUND-Befehlen die Tonausgaben der Kanäle 2 und 3 ausgeschaltet. Außerdem soll sich nach jedem gewonnenen Level die Spielgeschwindigkeit erhöhen, was auch in der Erhöhung des musikalischen Tempos zum Ausdruck kommen soll, um so subtil den Stress bei den Spieler:innen zu erhöhen.⁵³ Dies wird durch Manipulation des vordefinierten Wertes innerhalb der Musikdaten-Tabelle an Speicheradresse 1577 (hexadezimal 629) erreicht. Dieser dort hinterlegte Wert steht zu Spielbeginn auf 6 [960] und wird mit jedem gewonnenen Level verringert [1530].

Auch wenn es in diesem Spiel so erscheint, als erklänge gleichzeitig zum Spielgeschehen eine Hintergrundmusik, laufen beide Prozesse nicht simultan, sondern abwechselnd ab. Die Ausführung des BASIC-Programms wird durch Maschinensprache-Timer in mikrozeitlichen Abständen unterbrochen, um den Sound weiterzuspielen. Diese Soundwiedergabe wiederum wird ebenfalls stetig unterbrochen, damit das BASIC-Programm weiter ausgeführt werden kann usw. Allein die Tatsache, dass diese Unterbrechungsprozesse innerhalb von Mikrosekunden und unterhalb der Wahrnehmungsgrenze stattfinden, erzeugt bei Spieler:innen den Eindruck von Simultanität. Diese lässt sich allein von BASIC aus nicht mehr erreichen, sondern bedarf der Maschinensprache.

7.4 C64: Allround-Soundroutine

BASIC-Spiele mit interruptgesteuerter Hintergrundmusik existieren auch für andere Homecomputer. Beim C64-Textadventure Spion III⁵⁴ wird Johann Sebastian Bachs Komposition Nun ruhen alle Wälder dreistimmig (instrumental) als Endlosschleife wiedergegeben, was auf einer sehr ähnlichen Programmiertechnik basiert wie der Sound von The Castle.

Das letzte Beispiel stellt kein historisches Abtippspiel dar, sondern gehört in die Retrocomputing-Kategorie der „BASIC Tenliner“⁵⁵. Dabei handelt es sich um maximal zehn BASIC-Zeilen lange Programme, die meistens Demos oder Spiele implementieren. Diese Art der Programmierkunst verlangt sowohl intime Kenntnisse der programmierten Plattform wie auch virtuose Fähigkeiten in der BASIC-Programmierung. Tenliner dürfen in der Regel keinen Maschinencode enthalten, sondern müssen alle Algorithmen in BASIC (wo nötig unter Zuhilfenahme von POKEs zur Adressierung von Spezialbausteinen) realisieren. Insbesondere dann, wenn mit ihnen Grafik- oder Soundausgaben erzeugt werden sollen, sind speicherplatzsparende, algorithmische Verfahren notwendig.⁵⁶

Abb. 8: Remember (Screenshot)

Das BASIC-Spiel Remember aus dem Jahr 2017 von „Drazil“⁵⁷ ist die Umsetzung des bekannten Senso/Simon-Spiels, bei dem sich die Spieler:innen stetig länger werdende Licht- und Tonfolgen merken und diese in der korrekten Reihenfolge wiedergeben müssen. Dem Entwickler Guido Bonerz gelingt die Implementierung des Spiels in nur neun BASIC-Zielen. Dabei greift er auf elaborierte Programmiertricks zurück, die seinen Code nur schwer entzifferbar machen. Aufgrund der Tatsache, dass der C64 spezifische Adressen für die Register seines Soundchips reserviert hat, lassen sich die Soundroutinen beim Durchsehen des Codes jedoch identifizieren und, von dort aus, die zugehörigen Variablen und Werte finden:

• Alle Soundausgaben werden in Zeile [9] erzeugt. Dort werden die Parameter der ersten und zweiten Stimme definiert: Wellenform, Hüllkurven (Attack und Hold) sowie die Frequenzen.
• Diese Soundroutine wird mit „GOSUB 9“ in den Zeilen [5], [6] und [7] aufgerufen. Aus diesen Zeilen werden ihr konkrete Werte für die benötigte Wellenform (F) und die Frequenz (S), sowie ein Wert (P) für die Dauer der Tonwiedergabe übermittelt.
• Die in [9] zu spielenden Frequenzen befinden sich in einem 16-Bit-Array. Dieses wird aus den Einträgen 9-16 der DATA-Liste in [1] gefüllt. Das geschieht in [2] über die READ-Anweisung, die die Werte in die Arrays NL() (Lowbyte der Frequenz) und NH() (Highbyte der Frequenz) überträgt. Diese 4 Lowbytes und 4 Highbytes können im Programm zu 16 verschiedenen Frequenzen kombiniert werden.

9 SI=54272 : POKE 54296,15 : POKE SI+5,20 : POKE SI+12,20 : POKE SI+6,200 : POKE SI+13,255 : POKE SI+0,NL(S) : POKE SI+1,NH(S) : POKE SI+2,200 : POKE SI+3,0 : POKE SI+4,F : FOR T=1 TO P : NEXT : POKE SI+4,0 : RETURN

Je nach benötigtem Sound (Start- oder Schlussmelodie, zu ratendem Ton, Falsch- oder Richtigeingabe) wird nun über die Variable S eine der 16 Frequenzen aus der Tabelle ausgewählt und mit einer bestimmten Wellenform und Hüllkurve modelliert. Alle Töne in Remember werden auf diese Weise algorithmisch und auf Basis der Eingaben der Spieler:innen generiert,⁵⁸ obwohl die Töne in ihren Frequenzbestandteilen feststehen.

Das Beispiel verdeutlicht den virtuosen Umgang mit der Programmiersprache BASIC – hier in Hinblick auf die Soundprogrammierung, wenn eine einzige Routine beinahe all jene Rollen übernehmen kann, die in den anderen Spielen durch unterschiedlichste Programmiertechniken realisiert werden mussten. Die Entwicklung solch kompakter Routinen gleicht selbst einem „Gaming a system“⁵⁹ – einem Spiel mit den Möglichkeiten der Sprachsyntax und des Interpreters – und gerät über Wettbewerbe zu einer Gamification der Programmierung.⁶⁰

Abschließend sollen die in den oben vorgestellten Programmen verwendeten Soundausgaben noch einmal einander gegenübergestellt werden, um einen Überblick über die Verfahren der Soundprogrammierung in BASIC-Spielen zu erhalten. Diese mündet in einen Vorschlag für eine alternative bzw. erweiterte Klassifikation von Computerspiel-Sounds ein.

8. Synthetic Electronic Sounds: Arten von Sounds in BASIC-Spielen

In der Literatur werden Sounds in Computerspielen nach unterschiedlichen Kriterien klassifiziert, die sich im Diskurs der Game Studies gewandelt haben. Nachdem zuerst eine Grobeinteilung von „diegetischen“ (zum Spielgeschehen gehörend, z.B. Schussgeräusche, Explosionsgeräusche) und „non-diegetischen“ (nicht zum Spielgeschehen gehörend, z.B. Titelmelodien, Hintergrundmusik) Sounds vorgeschlagen wurde, hat sich über die Kritik gezeigt, dass eine solche Übertragung filmanalytischer Terminologien/Konzepte auf Computerspiele nicht sinnvoll ist.⁶¹ Daraus folgend wurden andere Klassifikationsschemata vorgeschlagen, die etwa Sounds zu verschiedenen technischen oder virtuellen Interfaces von Spielen zugehörig darstellen.⁶² Diese Überlegungen ließen sich auch auf die Soundausgaben der BASIC-Spiele übertragen.

Der Blick unter die Spieloberflächen auf die Spielprogramme, die Programmiersprachen und Hardwareplattformen mit ihren spezifischen Soundgeneratoren hat jedoch eine zusätzliche Perspektive eröffnet, die eine Erweiterung der Klassifikation zulässt. Hierbei können vor allem die unterschiedlichen Code-Realisierungen von Sounds, die Zeitverhältnisse zwischen Sound-Generierung und Spielausführung und die technischen Möglichkeiten der Plattformen nebst ihrer Repräsentation bzw. Adressierbarkeit von BASIC aus unterschieden werden. Damit ließen sich die ästhetische Eigenarten bestimmter Soundkategorien (diegetisch, schnittstellengebunden etc.) an die technischen Dispositive ihrer Erzeugung rückkoppeln: Gerade in frühen Computerspielen folgen die Ästhetiken nicht selten den technischen Möglichkeiten von Plattform, Programmiersprachen (BASIC-Dialekten) und nicht zuletzt Coding Skills ihrer Autor:innen. Sounds müssen hier eng an das übrigen Spielgeschehen gekoppelt gedacht werden.

Historische Video- und Computerspiele können nicht adäquat analysiert werden, ohne ihre technischen (Un-)Möglichkeiten zu berücksichtigen. Mit neuen Spielplattformen ist es möglich, nahezu jede audiovisuelle Ästhetik umzusetzen; daher muss die Interpretation von Spielsounds jüngerer Spiele die Spezifikationen der jeweiligen Plattform nicht berücksichtigen.⁶³ Als die ersten Video- und Computerspiele erschienen, war dies ganz anders: Die möglichen Ästhetiken der Spiele wurden durch die Plattformspezifikationen bestimmt. Heute definieren diese Ästhetiken nicht allein die ‚Qualität‘ der Sound- und Grafikausgaben, sondern lassen sich als kodifizierter Ausweis ihrer kreativen Nutzung lesen. Programmierer:innen solcher Systeme mussten entweder mit den Grenzen, die ihnen ihre Homecomputer diesbezüglich setzen, umzugehen lernen oder aber versuchen, diese Grenzen mit Programmiertricks und Hardwarehacks zu verschieben, um zu neuen Ästhetiken zu gelangen. Solche Verschiebungen lassen sich in Programmcodes, wie den oben zitierten, nachlesen.⁶⁴ Darüber hinaus gibt die Analyse der Soundprogrammiertechniken von hobbyistisch erstellten Video- und Computerspielen einen Einblick in das algorithmische Denken und den Umgang mit der Computertechnologie durch die Entwickler:innen und die Communities. Eine Kategorisierung von BASIC-Spielsounds ist damit auch eine Kategorisierung unterschiedlicher Arten des Umgangs mit den Systemen– von der Programmierung nach Lehrbuch bis hin zur neuen Warte der Sounderzeugung durch ‚gaming the system‘-Praktiken.

Tabelle 1: Kategorisierung von Sound-Ausgaben in BASIC-Listings

9. Schluss: Industrial rhythms all around

Das Archiv der BASIC-Computerspiele ist immens. In sechs Jahrzehnten haben professionelle und hobbyistische Programmierer:innen für Dutzende Homecomputer-Plattformen unzählige Programme entwickelt – wovon einige in Büchern, Zeitschriften oder Diskmagazinen veröffentlicht wurden, viele jedoch in noch unerschlossenen Papier- und Datenträger-Archiven ihrer Entdeckung harren. Die Akzentuierung der Soundprogrammierung, wie sie hier vorgenommen wurde, konnte zeigen, welche Erkenntnisse solche Programme bergen: Sie geben Auskunft über die Systeme, die Programmiersprache, vor allem aber über Wissen, Kultur und Praxis der Hobbyprogrammierung.

Dass die Programmiersprache BASIC für die Analyse so ‚offen‘ steht, liegt in ihrer einfachen Struktur begründet und in der Tatsache, dass sie wie keine andere Sprache ‚Ausdruck‘ und Eingang in Printerzeugnisse(n) gefunden hat. Listings in Computerzeitschriften und -büchern besitzen damit denselben Stellenwert für die Geschichte der Computerspielmusik wie Notensätze für die Musikgeschichte: Sie stellen eine unzweideutige Formalschrift zum Re-enactment der musikalischen (Ur-)Aufführung dar. Der Einblick in die Programmlistings zeigt die algorithmische Verflechtung der Audiogenerierung mit dem übrigen Spielcode und damit, dass prinzipiell alle Computerspielmusik ‚diegetisch‘ ist, wenn die Computerspiele als Code-Texte vorliegen. Auf dieser Analyseebene werden daher andere Kategorien der Beziehungsbeschreibung zwischen Spielgeschehen und Tonausgaben notwendig.

Anders als bei ‚analoger‘ Musik ist die Wiedergabe der Kompositionen keinen Idiosynkrasien der Aufführenden unterworfen, sondern wird von einer Maschine ‚interpretiert‘ – einem BASIC-Interpreter. Einzig die elektronischen und physikalischen Schwankungen der Wiedergabehardware (der Instrumente) können (wenngleich auch kaum hörbar, sondern oft bloß messbar) Einfluss auf diese Wiedergabe nehmen. Grundbedingung hierfür ist jedoch, dass diese Systeme operativ (erhalten) bleiben. Gerade die Soundhardware lässt sich nicht verlustfrei in Software emulieren; die mikrozeitlichen Interaktionen zwischen System, Programmiersprache und Programm realisieren sich authentisch einzig auf den durch den System-Taktgeber rhythmisch orchestrierten Hardwarebausteinen.

Medienverzeichnis

Spiele

Udo Bremer: Horror Caves (Amstrad CPC 464), Deutschland: Computronic 1985.

br: Vier gewinnt (Sinclair ZX Spectrum 48k), Deutschland: HC 1984

Thomas Fischermann: The Castle (Atari 800XL), Deutschland: HC 1985.

Steffen Goebbels: Spion III (Commodore 64), Deutschland: 64‘er 1986.

Jochen Hartik: Hinterhalt (Sinclair ZX Spectrum 16k), Deutschland: HC 1983

Craig Mitchell: Pak Caverns (Amstrad CPC 464), Groß Britannien: Amstrad Computer User 1986.

Guido Bonerz: Remember (Commodore 64), Deutschland: GitHub 2019 <http://txt3.de/basicsound5> [10.06.2021].

Texte

Allen, James D.: The Complete Book of CONNECT 4: History, Strategy, Puzzles. New York: Puzzle Wright Press 2010.

Atari: ATARI Computersystem. Das 600XL/800XL Handbuch. Hamburg: Atari Corp. 1984.

bez.: Horror Caves. Dieses Spiel bringt Ihnen den absoluten HORROR!!! In: Computronic, Ausg. 3-4/1985, S. 71-75.

br.: Vier gewinnt. In: HC – Mein Home-Computer, Ausg. 1/1984 (Januar), S. 37f.

Braguinski, Nikita: RANDOM. Die Archäologie elektronischer Spielzeugklänge. Reihe: Computerarchäologie, Bd. 3. Bochum: Projekt 2018.

Brückmann/Englisch/Gerits: CPC 464 Intern. Mit kommentiertem ROM-Listing. Düsseldorf: Data Becker 1985.

Busjahn T./Schulte C./Busjahn A.: Analysis of code reading to gain more insight in program comprehension. In: Koli Calling. ACM 2011, S. 1-9. http://txt3.de/basicsound7

Caillois, Roger: Die Spiele und die Menschen. Stuttgart: Curt E. Schwab 1960.

CBM: Commodore 64 MicroComputer User Manual. O. O.: Commodore Business Machines, Inc. & Howard W. Sams & Co., Inc 1982.

Crawford, Chris/Winner, Lane/Cox, Jim/Chen, Amy/Dunion, Jim/Pitta, Kathleen/Fraser, Bob: De Re Atari. Anno Domini MCMLXXXI. O. O.: Atari Program Exchange 1982. http://txt3.de/basicsound13

Fischermann, Thomas: The Castle. In: HC – Mein Home-Computer, Ausg. 7/1985 (Juli), S. 82-85.

GI: AY-3-9810/9812 Programmable Sound Generator Data Manual. O.O.: General Instruments 1979. http://txt3.de/basicsound8 [10.09.2021]

Goebbels, Steffen/dm: Spion III – die Jagd nach der Bombe. In: 64‘er Sonderheft Abenteuerspiele, Ausg. 4/1986, S. 134-141.

Hartig, Jochen: Hinterhalt. In: HC – Mein Home-Computer, Ausg. 12/1983 (Dezember), S. 43.

Höltgen, Stefan: BASIC-Spiele und ihre Geschichte. Das kann ich auch programmieren! Ein Kurzinterview mit Yoda Zhang, dem, Programmierer von Gulp! In: Retro, Sonderheft BASIC, 2014, S. 20-22.

Höltgen, Stefan: Das magische Panoptikum. Technologien der Überwachung zum Zwecke des Spiels – eine computerarchäologische Analyse. In: Henning, Martin/Schellong, Marcel (Hgg.): Überwachung und Kontrolle im Computerspiel. PAIDIA-Sonderausgabe. Glückstadt: vwh 2020, S. 124-155. http://txt3.de/basicsound11 [10.06.2021]

Höltgen, Stefan: GO BACK GOTO. Ein kurzer Überblick über die Entfernung der Schulinformatik von den Computern. In: Grundlagenstudien aus Kybernetik und Geisteswissenschaften, Band 57, Heft 3 (September 2016), S. 141–152, http://txt3.de/basicsound9 [10.06.2021].

Höltgen, Stefan: Little Data. Fraktale Bildkompression: Von einer netzhistorischen Miszelle zum medienstrukturellen Bruch. In: Balke, Friedrich/Siegert, Bernhard/Vogl, Joseph (Hgg.): Jahrbuch Archiv für Mediengeschichte 19: „Kleine Formen“. Berlin: Verlag Vorwerk 8 2021, S. 27-41.

Höltgen, Stefan: OPEN HISTORY. Archäologie der frühen Mikrocomputer und ihrer Programmierung (Dissertation). http://txt3.de/open-history [10.06.2021]

Höltgen, Stefan: Play that Pokey Music: Computer Archaeological Gaming with Vintage Sound Chips. In: The Computer Games Journal. Volume 7, Issue 4, December 2018, Special Edition 2018 – Ludomusicology, S. 213–230, DOI: 10.1007/s40869-018-0068-5, http://txt3.de/basicsound10 [10.06.2021]

Höltgen, Stefan: Time Invaders. Zeit(ge)schichten in Computer(spiele)n. In: Höltgen, Stefan/van Treeck, Jan-Claas (Hgg): Time To Play. Zeit und Computerspiel. Glückstadt: vwh 2016, S. 51-69.

Höltgen, Stefan/Ernst, Wolfgang: Programmieren in BASIC. Zehn Bemerkungen zu einer verfemten Programmiersprache. In: Retro, Nr. 29 (2014), S. 16-23.

Isaaman, Daniel/Tyler, Jenny: Computer Space Games. London: Usborn 1982.

Jørgensen, Kristine: A Comprehensive Study of Sound in Computer Games. How Audio Affects Player Action. Lewiston/Queenstone/Lampeter: The Edwin Mellen Press 2007.

Levy, Stephen: Hackers. Heroes of the Computer Revolution. New York/Garden City: Anchor Press/Doubleday 1984.

Lucaßen, Carsten/Höltgen, Stefan: BASIC-Handbücher von Homecomputern. Die längst fällige, vergleichende Rezension. In: Retro, Sonderheft BASIC 2014, S. 13-15.

Lucaßen, Carsten/Ihrig, Ingolf/Othmer, Torsten/Höltgen, Stefan: Einzeiler. BASIC-Spiele und Demos für verschiedene Systeme. In: Retro, Sonderheft BASIC 2014, S. 13-15.

Mitchell, Craig: Pak Caverns. In: Amstrad Computer User, Ausg. 1/1986 (January), S. 53-54, 56, 79f.

Pias, Claus: Computer Spiel Welten. Berlin/Wien: diaphanes 2002.

Rankin, Joy Lisi: Back to BASIC. In: Dies.: A People’s History of Computing in the United States. Cambridge: Harvard University Press 2018, S. 66-106.

Reinefeld, Alexander: Entwicklung der Spielbaum-Suchverfahren: Von Zuses Schachhirn zum modernen Schachcomputer. In: Reisig, Wolfgang/Freytag, Johann-Christoph (Hgg): Informatik. Aktuelle Themen im historischen Kontext. Berlin/Heidelberg: Springer 2006, S. 241-273.

Saukas, Einar/Digital Prawn: Kreativer Missbrauch. Oneliner-Programmiertechniken in Sinclair-BASIC. In: Retro, Sonderheft BASIC 2014, S. 16f.

Schliesser, Jörg/bn: Duell der Geister. In: Happy Computer, Ausg. 9/1986 (September), S. 60-64.

Schulz, Thomas: To Be (Just) in Time. Die Kunst zeitkritischer Programmierung von Spielen in Maschinensprache. In: Höltgen, Stefan/van Treeck, Jan Claas (Hgg.): Time To Play. Zeit und Computerspiel. Glückstadt: vwh 2016, S. 120-143.

Searle, John R.: Geist, Gehirn, Programm. In: Zimmerli, Walther Ch./Wolf, Stefan (Hgg.): Künstliche Intelligenz. Philosophische Probleme. Stuttgart: Reclam 1994, S. 232–266.

Smith, Michael G.: Simons‘ Basic. 114 Additional Programming Commands. Frankfurt a. M.: Commodore 1983.

Spital, I., Perry, R., Poel, W., Lawson, C.: Amstrad CPC 6128 User Instruction. Brentwood: AMSOFT 1985, http://txt3.de/basicsound12 [10.06.2021]

Troise, Blake: The 1-Bit Instrument: The Fundamentals of 1-Bit Synthesis, Their Implementational Implications, and Instrumental Possibilities. In: Journal of Sound and Music in Games (2020) 1 (1), S. 44–74.

Turing, Alan M.: On Computable Numbers, with an Application to the Entscheidungsproblem. In: Proceedings of the London Mathematical Scociety (Series 2). 42 (1936), S. 230–265.

Vickers, Steven: Sinclair ZX Spectrum. BASIC Programming. Second Edition 1983. O. O.: Sinclair Research 1983.

Zimmerman, Eric: Gaming Literacy. Game Design as a Model for Literacy in the Twenty-First Century. In: Perron, Bernard/Wolf, Mark J. P. (Hgg.): The Video Game Theory Reader 2. New York/London: Routledge 2009, S. 23-32.

Bilder

Alle Abbildungen wurden vom Autor selbst erstellt.

1. Weil die Diskussion eng an den Source Codes und operativen Programmen entlang geführt wird, wurden die betreffenden BASIC-Listings und zugehörigen Image-Files in einer ZIP-Datei hinterlegt: http://txt3.de/basicsound1 [10.06.2021] (Eine Ausnahme hiervon bildet das Spiel Remember, dessen Code nur online verfügbar ist.) [↩]
2. Wenn Claus Pias schreibt, „dass die Welt des Computers selbst immer schon eine Spielwelt ist“ (Pias: Computer Spiel Welten, 2002, S. 4), meint er damit die Tatsache, dass Computer stets simulieren, was sich im Sinne Caillois’ als „Mimikry“ (Caillois: Die Spiele. 1960, S. 19) verstehen ließe.[↩]
3. Der Informatiker Alexander Reinefeld spricht angesichts der historischen Entwicklung von Schachalgorithmen davon, dass sich „die Spieleprogrammierung als Drosophila der Computerentwicklung“ (Reinefeld: Entwicklung. 2006, S. 252) sehen lässt.[↩]
4. Levy: Hackers. 1984, S. 313-331.[↩]
5. Ebd., S. 30.[↩]
6. Ebd., S. 27.[↩]
7. Ebd.[↩]
8. Einzig der Apple II bildet hiervon die Ausnahme, war aber schon aufgrund seines hohen Preises kaum breitenwirksam.[↩]
9. Vgl. Höltgen: Play that POKEY Music. 2018.[↩]
10. Vgl. Lucaßen/Höltgen: BASIC-Handbücher. 2014.[↩]
11. Für diese Assoziation danke ich meinem Studenten Philipp Zumpe.[↩]
12. Searl: Geist Gehirn Programm. 1994.[↩]
13. Busjahn u.a.: Analysis of code reading. 2011.[↩]
14. Vgl. Höltgen/Ernst: Programmieren in BASIC. 2014.[↩]
15. Turing: On Computable Numbers. 1936, S. 249.[↩]
16. So genannte ROM-Listings verschafften Nutzer:innen Einblick in die detaillierten Abläufe des BASIC-Interpreters und Betriebssystem. (Bsp: Brückmann u.a.: CPC 464 Intern. 1985) [↩]
17. Vgl. Rankin: Back to BASIC. 2018, S. 66-105.[↩]
18. Vgl. ebd., S. 68.[↩]
19. Ich beziehe mich hier und im Folgenden auf die nicht-strukturierten Dialekte der Phase zwischen 1975 und 1985. Spätere BASIC-Dialekte rückten von solchen Aspekten, die als zu „problemfern und maschinennah“ (Höltgen: GO BACK GOTO. 2016, S. 145) erschienen, aus didaktischen Gründen ab.[↩]
20. Bei 1. kann dies bedeuten, dass der Befehl falsch geschrieben wurde, bei 2., dass eine Zeilennummer außerhalb des gültigen Bereichs gewählt wurde und bei 3., dass ein falscher Variablenname (etwa für den falschen Datentypen oder ein reservierter Begriff) gewählt wurde.[↩]
21. Höltgen/Ernst: Programmieren in BASIC. 2014, S. 23.[↩]
22. BASIC One-Liner sind eine BASIC-Programmgattung, die dieses Prinzip auf die Spitze treibt, werden in ihnen doch komplette Programme in einer einzigen BASIC-Zeile untergebracht – ein Ausweis hoher Programmierkunst, der in Wettbewerben gekürt wurde und wird. (Vgl. Lucaßen/Ihrig/Othmer/Höltgen: Einzeiler. 2014; Saukas/Digital Prawn: Kreativer Missbrauch. 2014) [↩]
23. Hierzu gehörten zum Beispiel, dass aus jeder Schleifen- oder Kontrollstruktur ohne Konsequenzen mit JMP oder GOTO herausgesprungen werden kann und der Code so nahezu unlesbar für Menschen wird.[↩]
24. Die Assemblersprachen und durch sie aufgerufenen Maschinensprachen verschiedener Computersysteme unterschieden sich nicht nur dadurch voneinander, dass verschiedene Mikroprozessoren (mit unterschiedlichenSteck Befehlsinventaren) verwendet wurden, sondern machten auch die Unterschiede in den System- und Speicherarchitekturen deutlich: Welche Speicherbereiche für Programmcode genutzt werden konnte, wie die Spezialbausteine (Sound, Grafik, I/O) angesprochen werden können, wo der BASIC-Interpreter im Speicher hinterlegt ist etc. unterschied sich von Computerplattform zu Computerplattform. Um Assembler programmieren zu können, ist daher nicht bloß die Kenntnis der Sprache und ihrer Syntax nötig, sondern es erfordert auch eine intime Systemkenntnis des jeweils programmierten Computers. Im genannten Beispiel würde damit deutlich werden, dass dieses Programm in MOS-6502-Assembler für den Commodore 64 die Farben des Bildschirmrahmens (dessen Register im Videochip VIC-II an Adresse 53280, hexadezimal D408, liegt) kontinuierlich wechseln lässt.[↩]
25. Zur Erweiterung des C64-BASIC wurden Erweiterungen und Dialekte angeboten, die solche Funktionen zur Verfügung stellten (etwa Simons’-BASIC [Smith: Simons’ Basic. 1983, Ss. 6.1-6.19, 11.1-11.11]).[↩]
26. Alle Programmbeispiele können in online verfügbaren Emulatoren nachprogrammiert werden: Atari 800: http://rtro.de/atari8-emu / Commodore 64: http://rtro.de/c64-emu / Amstrad CPC 6128: http://rtro.de/cpc-emu / Sinclair ZX Spectrum: http://rtro.de/zxspec-emu[↩]
27. Atari: Handbuch. 1984, S. 56.[↩]
28. Ebd.[↩]
29. Crawford u.a.: De Re Atari. 1982, S. 137.[↩]
30. Ebd., S. 137f.[↩]
31. Die Funktion von Hüllkurven wird beispielsweise hier beschrieben: https://de.wikipedia.org/wiki/ADSR[↩]
32. Vgl. Spital u.a.: Amstrad CPC 6128. 1985, Ss. 3/22-26, 3/75f.[↩]
33. Ebd., S. 3/67.[↩]
34. Vgl. Höltgen: Panoptikum. 2020.[↩]
35. Spital et al. Amstrad CPC6128. 1985, S. 3.4.[↩]
36. Ebd., S. 3.28.[↩]
37. Das Locomotive-BASIC V1.1 des Amstrad CPC 6128 enthält im Vergleich dazu 105 Befehle und 55 Funktionen (http://txt3.de/basicsound2).[↩]
38. Vgl. CBM: Commodore 64. 1982, Ss. 152-154, 160-162. Außerdem findet sich im Anhang ein Programm Piano Keyboard zum Abtippen, das die BASIC-Programmierung von Sounds praktisch vorführt. (Ebd., S. 147.) [↩]
39. Vgl. CBM: Commodore 64. 1982, S. 161f. Die Technik, Peripheriebausteine über RAM-Adressen adressierbar zu machen, heißt „Memory-mapped I/O“ und wurde beim C64 aufgrund des Fehlens von I/O-Ports in der CPU verwendet.[↩]
40. http://txt3.de/basicsound3[↩]
41. Für die Tonausgabe können ebenso die Audioein- und -ausgänge (allerdings ebenfalls nur monoton) des Datenrecorders verwendet werden.[↩]
42. Vgl. Troise, 1-Bit Instrument. 2020.[↩]
43. Vickers: ZX Spectrum. 1983, S. 135.[↩]
44. Hier sei am Rande darauf hingewiesen, dass selbst Systeme ohne dedizierte Audiogenerierung zu Tonausgaben programmiert werden konnten (vgl. Höltgen: Play that POKEY Music. 2018).[↩]
45. Vgl. Isaaman/Tyler: Computer Space Games. 1982.[↩]
46. Ich danke Spyros Konitopoulos und Uwe Geiken, Mitglieder der Facebook-Gruppe „BASIC on the ZX Spectrum“, für ihre Mithilfe bei der Eingabe der Programmcodes und der Erzeugung der .tap-Dateien.[↩]
47. Alle in eckigen Klammern angegebenen Zahlen beziehen sich auf die BASIC-Zeilen(nummerierung) der jeweiligen Programmlistings. (Siehe Fußnote 1) [↩]
48. Vgl. Allen: CONNECT 4. 2010.[↩]
49. Fischermann: The Castle. 1985.[↩]
50. Für die Analyse des Programms und seines Aufrufs danke ich dem Atari-Hacker Thomas Schulz! (Vgl. Schulz: To Be (Just) In Time. 2016).[↩]
51. Vgl. Höltgen: Panoptikum. 2020.[↩]
52. Diese 16-Bit-Zahl errechnet sich aus 256-mal dem Inhalt von Adresse 551 plus dem Inhalt aus Adresse 550 (256*0+6) in umgedrehter Reihenfolge (Little Endian).[↩]
53. Vgl. Höltgen: Time Invaders. 2016.[↩]
54. Goebbels/dm: Spion III. 1986.[↩]
55. Seit 2015 finden jährlich Contests statt, bei denen für unterschiedliche Systeme BASIC-Tenliner eingereicht werden können. Vgl. http://txt3.de/basicsound4[↩]
56. Vgl. Braguinski: RANDOM. 2018, S. 71 sowie Höltgen: Little Data. 2021, S. 37.[↩]
57. Das lauffähige Programm findet sich als Image-Datei hier: http://txt3.de/basicsound5; das zugehörige BASIC-Listing hier: http://txt3.de/basicsound6[↩]
58. Vgl. Braguinski: RADNOM. 2018, S. 39-50.[↩]
59. Zimmerman: Gaming Literacy. 2009, S. 25.[↩]
60. Höltgen: OPEN HISTORY. 2020, S. 251-253.[↩]
61. Jørgensen; Sound in Computer Games. 2010.[↩]
62. Ebd., S. 91-93.[↩]
63. Selbstverständlich formatieren auch moderne Spielsysteme ihren Audio- und Videooutput auf Basis ihrer Hardwarespezifikationen. Weil solche Plattformen allerdings über sehr schnelle CPUs und große Speicherkapazitäten (RAM und Massenspeicher) verfügen, erscheint es, als könnten sie jede beliebige ästhetische Ausgabe generieren. Dies ist allerdings ebenfalls nur der Anpassung an die menschlichen Wahrnehmungsmöglichkeiten geschuldet. Die mikroskopische Pixelrasterung von Bildern und die mikrozeitlichen Unterbrechungen von Tonausgaben unterscheiden sich allein quantitativ, nicht aber qualitativ von den Ausgabemöglichkeiten von Heimcomputern der 1980er Jahre. Die Struktur von Digitalisierung, Algorithmisierung und serieller Signal- und Datenverarbeitung hat sich in Digitalcomputer seit ihrer Erfindung nicht grundsätzlich verändert.[↩]
64. Das Archiv solcher Programmcodes ist deshalb als wichtige Quelle der Computerspielforschung nicht zu unterschätzen. Ich habe zusammen mit Kolleg:innen jüngst eine Digital-Humantieis-Arbeitsgruppe etabliert, die sich unter anderem solchen technischen Unterflächen von Spielen widmet. (www.dhspiele.de) [↩]