Sound Bits. Computerarchäologische(s) Spiele(n) mit historischen Sound-Prozessoren

Computer produzieren immer schon Klänge.¹ Angefangen beim Geräusch, das die bewegten Perlen eines Abacus verursachen oder bei den Rhythmen früher elektromechanischer Analogrechner bis zu klickenden Relais und audifizierten Bit-Streams der Mainframe-Ära und den Minicomputer-Sound-Hacks an US-amerikanischen Universitäten der 1950er-Jahre. Der „algorhythmische“ Grundton² der Rechentechnik, mal vernehmbar wie in den genannten Beispielen, oft aber unhörbar im Mega- und Gigahertz-Bereich, ist Gegenstand der folgenden Überlegungen. Ein besonderer Akzent liegt dabei auf Technologien, die das Sonische hörbar machen sollten, um es für musikalische Zwecke nutzen zu können. Hierbei wäre sowohl die historiografische Frage nach den Soundhardware-Epochen als auch die computerarchäologische Frage zur ‚Urzeit von Computersounds‘ zu stellen. Für beides eignet sich eine Eingrenzung auf die 1970er- und 1980er-Jahre, in denen zum einen Computersound-Technologien vorheriger Jahrzehnte in Soundhardware kondensieren und zum anderen die zuvor vor allem als ‚Hack‘ komponierte Computermusik in professionelle Anwendungen kulminierte: Computerspiele.

Eine besondere Rolle nehmen Computerspiele in diesem Zeitraums deshalb ein, weil es ist nicht nur eine Computerspiel-Hardware ist, aus der der erste Soundchip (Ataris TIA³ erscheint 1977) hervorgeht, sondern weil die spezifischen Anforderungen an die Programmierung solcher scheinbar nebenläufigen Soundausgaben von besonderer computerarchäologischer Brisanz sind: Sie zwingen die Programmierer dazu, nun stets die technischen Abläufe detailliert mitzudenken und vorzuvollziehen.

1. Computersoundarchäologie

Untersuchungen zu Computersoundhardware favorisieren nicht selten⁴ den Modus der Historiografie, nach der eine stetige Weiterentwicklung von Technik und Technologien vom Einfachen zum Komplexen führt. Als Gradmesser werden hierfür nicht selten quantifizierbare Argumente wie Jahreszahlen, Verkaufszahlen oder technische Elemente (etwa Bandbreiten der generierbaren Frequenzen, Anzahl unterschiedlicher Wellenformen, Soundkanäle, Filter usw.) verwendet. Das führt in einigen Fällen aber dazu, dass Systeme, die ökonomisch nicht erfolgreich waren, marginalisiert werden (wie bei Dittbrenner⁵). Ein weiteres Problem solcher Historiografien ist medialer Natur: Die Bündelung von Erkenntnissen in Forschungsdiskursen friert den eigentlich sehr volatilen Charakter von Sound auf Papier ein. An dieser Stelle könnte eine computerarchäologische Betrachtung des Phänomens einsetzen, die nicht nur versucht, beide Probleme zu erkennen und zu umgehen, sondern zugleich auch die technologische Spezifität des betrachteten Gegenstandes zu berücksichtigen und Erkenntnisse daraus zu gewinnen.

Im vorliegendem Fall von Computersoundhardware und der damit erzeugten Geräusche könnte sich ein Perspektivwechsel als besonders lohnenswert erweisen, denn insbesondere vor dem hier betrachteten zeithistorischen Hintergrund emergieren etliche Technologien, die sich der Gruppe der dedizierten Programmable Sound Generators (PSG) gar nicht eindeutig zuordnen lassen – Geräte, mit deren Hilfe der Computer Geräusche produziert, die dann sogar als Kompositionswerkzeuge verwendet wurden (und werden), obwohl sie für diesen Zweck gar nicht vorgesehen waren. Daneben zeigt sich, dass sich beispielsweise genauso wenig von ‚dem SID-Chip‘ (im Kollektivsingular) sprechen lässt, wie überhaupt von ‚dem Computer‘. Der so genannte SID-Chip (etwa in seiner Ausprägung MOS 6581) existiert nämlich allein auf dem Papier. Und nur als solcher beschreibt er die Rahmen möglicher Funktionen. Für den realen Baustein gelten diese nur als ‚Sollwerte‘. Zu viele (Chip-)externe Parameter bestimmen, wie sich die Tonausgaben eines spezifischen SID-Chips anhören,⁶ und längst ist nicht alles von den Erfindern dokumentiert worden, weil diese selbst oft gar nicht alles über ihre Erfindung wussten. Das wirft die Frage auf, wie sich überhaupt theoretisch über reale Medienfunktionen verhandeln lässt. Die Computerarchäologie nutzt hierfür das ‚Aufschreibesystem‘ der Archäographie⁷ 378, das sie um eine Methode ergänzt, die angesichts der hier verhandelten Thematik einen Zusatznutzen flankierend oder ergänzend zu diskursiven Ausführungen erbringt: die Demonstration.

Das Notationssystem der Notenschrift ermöglicht bereits ein Aufschreiben ephemerer musikalischer Prozesse zum Zwecke des späteren Nachvollzugs (gleichermaßen verstanden als „Re-Enactment“⁸ und „Vergegenwärtigung“⁹ mit Instrumenten. Dass sich dabei klangliche Unterschiede nicht nur in Abhängigkeit von der Raumakustik des Aufführungsorts,¹⁰ sondern vor allem bedingt durch die Materialität des Instruments selbst ergeben, führt zur erfreulichen Vielfalt von Aufführungen in der Geschichte der Live-Musik. Jedes einzelne Instrument besitzt (s)eine spezifische „Klangfarbe“¹¹, was zusammen mit den räumlichen und zeitlichen Einflüssen auf Instrument und Klang die Unikalität und Ephemerität einer Aufführung doppelt unterstreicht. Dieser Umstand gilt ebenso für PSGs, die ihren ‚Sound‘ auf Basis ihrer Umgebung färben – hier sind es jedoch keine akustischen, sondern vor allem mehr oder weniger kontrollierbare elektronische Einflüsse, die sich mit zu Gehör bringen. Diskursive Notationen solcher Prozesse können also bestenfalls einen Idealzustand ‚beschreiben‘, das Notationssystem, das hierfür (Abschnitt 5) zum Einsatz kommt, ist die (hardwarenahe) Programmiersprache. Der programmiererische Nachvollzug von Computersounds kann damit als empirischer Beleg einer These ebenso nützen wie als archäologischer Widerspruch zu einer wie auch immer gearteten ‚Historizität‘ von Ausgaben historischer Soundhardware. Zudem vergegenwärtigt er die Tatsache, dass Computersounds dieser Zeit in Echtzeit generiertes (und nicht bloß nachträglich ‚wiedergegebenes‘) Medientheater¹²  sind.

Abb. 1: Programmable Video Interfaces (PVI) Signetics 2636¹³, der auch für die Soundausgabe des Systems (hier die Spielkonsole Interton VC-4000) zuständig ist. Ein historiografisch gern ignorierter Chip, der allerdings auch auf diesem Foto nichts von seinen Funktionen preisgibt.

2. Computer als sonische Maschinen

Wie eingangs erwähnt, haben Computer nie im Stillen gerechnet. Das hat sich auch nicht geändert, als sie selbst unhörbar wurden. Da waren und wären zum einen ihre Peripherien, die Geräusche emittieren – mit ihren Motoren (Laufwerke, Drucker, Scanner), Rotoren (Lüfter), beweglichen Köpfen (Festplatten, Diskettenlaufwerke), Relais (in Datenrecordern und Netzteil-Choppern) und Spulen (in Netzteilen).¹⁴ Zum anderen war Computertechnik, bevor sie elektronisch wurde, pneumatisch,¹⁵ mechanisch (Zuse Z1) oder elektromechanisch (Relais-Computer wie Zuse Z3, Mailüfterl oder OPREMA¹⁶) und wo Reibung auftritt, da entsteht auch Sound.

Das inhärent sonische Moment der Computer basiert aber nicht auf diesen ‚Ton-Abfällen‘, sondern auf ihrer mathematischen Grundlage: Für die Automatisierung diskreter Rechenprozesse wird ein Arbeitstakt benötigt. Der lag bei frühesten Digitalcomputern, wie Zuses Z1, noch bei 1 Hertz, wurde jedoch mit dem Einzug der Elektronik und später der Mikroelektronik sukzessive beschleunigt, so dass heutige Mikroprozessoren mit 4 Gigahertz und mehr getaktet werden. Dieser Takt konnte zu Gehör gebracht werden, indem er an eine Membran umgeleitet wurde, die ‚im Takt‘ zu Schwingen begann. Bei frühen Großrechnern wie Zuses Z23 oder dem TX-0 am MIT¹⁷ waren Lautsprecher integriert, die mit einer Datenleitung des Prozessors verbunden waren. Weil an solch einer Datenleitung nur zwei Signale anliegen können (die die Stromspannungen von 0 und 1 repräsentieren), wurde der Lautsprecher in eine Schwingung stets gleich großer Amplitude gebracht. Die Frequenz, mit der sich die Signalflanken auf der Leitung abwechselten, bestimmte dann die Tonhöhe. Zweck dieser Installation war es, dem Programmierer zu Gehör zu bringen, wenn sein Programm ‚hing‘ (also abgestürzt war). Dann nämlich brachte der Lautsprecher statt einer ungeordneten Kakophonie ein regelmäßiges Muster, einen Rhythmus, zu Gehör.¹⁸ Gelangweilte Ingenieure¹⁹ und Hacker²⁰ haben sich diese Technologie recht bald zunutze gemacht, um den Lautsprecher gestaltförmige Klänge ausgeben zu lassen. Hierzu mussten lediglich Programme geschrieben werden, deren einziger ‚Sinn‘ die Veränderung diese Audiomonitor-Bits war.

Mit dieser Technologie kam schließlich der Computersound auf die Welt.

Bis in die 1980er-Jahre wurden solche Beeper- oder Piezo-Lautsprecher in verschiedensten Computersystemen²¹ für die Ausgabe von so genannter 1-Bit-Musik verwendet. Aufgrund der für menschliche Verhältnisse immens hohen Taktraten der Prozessoren konnten mittels Pulsfrequenzmodulation nicht bloß beliebige akustische Frequenzen erzeugt, sondern auch der Anschein von Polyphonie erweckt werden:

„Die Anzahl der möglichen Software-Channels ist bei der Puls-Frequenz- Modulation nahezu unbegrenzt. Allerdings ist zu beachten, dass mit jedem zusätzlichen Kanal die Klangqualität nachlässt. Insbesondere niedrige Frequenzen gehen mit zunehmender Polyphonie verloren. […] In seiner einfachsten, das heißt monophonischen Variante, ist die Puls-Frequenz-Modulation die älteste bekannte Form der Computermusik.“²²

Die Rechteckwellen der 1-Bit-Sounds ließen aber nicht bloß die Generierung von Musik zu, sondern erlaubten es sogar, Sprache (und Gesang²³) nach eben jenem Modulationsprinzip zu erzeugen oder wiederzugeben. So erschreckten frühe Heimcomputerspiele ihre Spieler zwar mit klanglich unangenehmer Musik, beeindruckten jedoch im selben Atemzug durch Sprachausgaben (vgl. Barbie‘s Adventure für Apple II oder Robot Attack für den TRS-80).

3. Programmable Sound Generators

Zur selben Zeit, als Apples und Tandys 8-Bit-Computer ihre Nutzer mit solchen Sounds beeindruckten, erschien von der Firma Atari die Spielkonsole VCS, die den ersten dedizierten Soundprozessor mitbrachte. Der TIA (Television Interface Adapter) erfüllte gleich mehrere Aufgaben, um den aus Kostengründen technisch reduzierten Mikroprozessor MOS 6507 zu entlasten. Neben der Generierung der Grafik und der Verwaltung der Controller-Eingaben war er auch für die Sounds zuständig. TIA konnte zwei Mono-Soundkanäle in 32 Tonstufen (verteilt auf das Frequenzbereich 10480-31440 Hertz) erklingen lassen. Weder der Frequenzumfang noch die daraus abrufbaren Töne lassen TIA als besonders ‚musikalisch‘ erscheinen. Deshalb hat dieser Sound medienwissenschaftliche Aufmerksamkeit erregt.²⁴ Vor unserem Hintergrund sind vor allem die Technologien interessant, die TIA zur Soundprogrammierung mitbrachte und die sich in späteren Soundchips fortsetzten.

Sound musste für den TIA in enger Abstimmung mit der Bildgenerierung programmiert werden. Die Abhängigkeit von Grafik und Sound ist allerdings – und anders als etwa bei „Pong“²⁵ – nur eine indirekte: Da die Grafikeinheit des Chips über keinen Bildspeicher verfügt, müssen die Pixel in Echtzeit auf dem Bildschirm generiert werden. Jedes mal, wenn TIA eine Bildschirmzeile (Horizontal Blank) oder den ganzen Bildschirm (Vertical Blank) fertig generiert hat und der Kathodenstrahl kurzfristig abgeschaltet wird,²⁶ können sich die CPU und der TIA um andere Dinge wie Code-Ausführung oder Sound- Generierung kümmern. Weil diese Bildprozesse aber abhängig von der Netzspannungsfrequenz (50 Hertz/60 Hertz) und der Fernsehfarbnorm (PAL/NTSC) sind, unterscheiden sich nicht nur die Grafik-, sondern auch die Klangausgaben von US-amerikanischen und europäischen Atari VCS voneinander. Man könnte sagen, dass der Sichtbarkeit eine höhere Priorität gegenüber der Hörbarkeit des Systems eingeräumt wurde – oder, dass der Sound eine visuelle und das Bild eine akustische Spur enthält.

Wie bereits erwähnt, stellt die Art, wie die Soundchips arbeiten, besondere Anforderungen an den Programmierer. Er muss regelrecht ‚im Takt‘ coden, wenn er rhythmisch exakte Soundausgaben erzeugen möchte. Bei der Programmierung der TIA (aber auch einiger anderer nachfolgender PSGs) bedeutet dies, dass der Taktverbrauch des Programms²⁷ genau kalkuliert werden muss, damit nur so viel Code bearbeitet wird, dass die CPU ‚rechtzeitig‘ Daten an TIA zur Grafikgenerierung schicken kann. Im Ergebnis finden sich nur wenige Spiele für die VCS, die über komplexe Sounds oder gar Hintergrundmusik verfügen. Pitfall II bringt hierfür einen weiteren Chip im Modul mit, der Grafik und Sound der VCS unterstützt und ergänzt.²⁸

3.1 Discreet Music

Spätere Systeme ab Anfang der 1980er-Jahre sind großzügiger mit Haupt- und Bildschirmspeicher ausgestattet, so dass Programmierung der Grafik keinen Einfluss mehr auf die Soundprogrammierung hat. Und dennoch muss notiert werden, dass eine scheinbar ‚im Hintergrund‘ ablaufende Musik oder ein ‚gleichzeitig‘ zu einem Bildschirmereignis auszugebender Sound von Prozessoren der 8- und 16-Bit-Generation eben nicht simultan ausgegeben wird. Vielmehr muss die Codeausführung regelmäßig unterbrochen werden, damit die Soundroutinen angesprungen werden können, um (im musikalischen Sinne) ‚taktgenau‘ den nächsten Ton ausgeben zu können. Dieser Vorgang lässt sich auch aus der umgekehrten Perspektive beschreiben: Die Signal-Diskretheit computativer Prozesse (zu denen die Soundgenerierung ja auch gehört) wird hier um eine Daten- und Code-Diskretheit der Sound-Routinen erweitert. Ein im Spielhintergrund ablaufendes ‚Musikstück‘ wird auf diese Weise regelrecht ‚zerstückelt‘, weil seine Wiedergabe ständig unterbrochen wird, damit die CPU anderen Code ausführen kann.

Weil selbst die (nach heutigen Maßstäben) langsamen CPUs dieser Zeit aber immer noch millionenfach schneller getaktet sind als die Sounds, die mit ihrer Hilfe zu Gehör gebracht werden sollen, bleiben diese Unterbrechungen im mikrozeitlichen Bereich und für Menschen unhörbar. Der Programmierer muss sich aus diesem Grund allerdings wieder ans Timing halten und wissen, wie viel CPU-Zeit verstreichen muss, um einen Ton zur rechten Zeit oder lange genug ausgeben zu lassen. Hierbei helfen entweder Programmiertricks²⁹ oder Service-Signale (Interrupts³⁰) der Soundprozessoren, die der CPU mitteilen, wenn ein Sound nach den vorgegebenen Daten zu Ende ausgegeben wurde. Die zeitkritische Programmierung kann aufgrund der hohen Taktraten der CPUs aber nicht bloß die Länge von Sounds oder das Tempo eines musikalischen Stücks steuerbar machen, sondern sogar akustische Frequenzen generieren (siehe oben zu 1-Bit-Sounds).³¹

Wie die Tabelle der frühen PSGs zeigt, bieten diese Bausteine jedoch mehr Möglichkeiten, Sounds zu generieren: Die Anzahl an Kanälen wächst (zugunsten der Polyphonie), die Menge und Lautstärkestufen spielbarer Töne und der Frequenzumfang werden ebenfalls mehr. Schließlich werden PSGs zu veritablen Synthesizer-Chips, die neben den erwartbaren Rechteck-Signalen auch andere Wellenformen (Dreieck, Sägezähne), Filtereffekte und programmierbare Hüllkurven anbieten. Alle diese Bausteine generieren ihre Sounds dabei über die subtraktive Klangsynthese³²: Sie erhalten durch den Frequenzteiler³³ auf der Platine eine Grundfrequenz, aus der heraus sie dann die für die Sounds benötigten Frequenzen durch weitere Teilung herstellen. Diese Frequenzen werden schließlich mittels Hüllkurven (Anstieg, Abfallen, Halten, Freigeben der Lautstärke) modelliert, gefiltert und gemischt. (Abb. 2)

Abb. 2: Seite aus dem Manual des AY-3-8910 [GI 1978:26-31], auf der u.a. die Hüllkurvenfunktionen zu sehen sind (oben links).

3.2 Sonic Sound Technologies

Die intensive Verquickung von hörbaren und unhörbaren Schwingungen zeigt sich also auf vielfältige Weise in den PSGs. Einige von ihnen besitzen zudem Features, die das Sonische von Computeroperationen jenseits des Akustischen noch unterstreichen. TIA, Pokey³⁴ und SID³⁵ verwalten beispielsweise mehr als nur die Soundausgaben des Systems. In der Auflösung ihrer Akronyme („Television Interface Adapter“, „Po[tentiometer] Keyboard Integrated Circuit“ oder „Sound Interface Device“) entbirgt sich ihre technische Vielfalt. Alle drei Bausteine verarbeiten beispielsweise auch Steuerungseingaben des Joystick-Ports. Das hat seinen Grund darin, dass sie in ihrer Eigenschaft als Soundgeneratoren über einen Digital-Analog-Wandler verfügen müssen, um mehr als bloß Rechteck-Signale an die Lautsprecher ausgeben zu können. In ihnen sind zudem Analog-Digital-Wandler eingebaut, die die kontinuierlichen Signale von Paddle-Steuerungen³⁶ diskretisieren und als binäre Daten an die CPU weiterleiten.

Die Technologie, die sich hinter der Analog-Digital-Wandlung verbirgt, lässt sich als Sampling verstehen: Einkommende kontinuierliche Signale werden zeitdiskret abgetastet. Die daraus entstehenden diskreten Signale müssen dann nur noch einem Zahlenwert zwischen 0 und 255 zugeordnet werden.³⁷ Wie sich aus dem Akronym des Pokey ablesen lässt, verwaltet dieser Chip darüber hinaus auch die Keyboard-Eingaben – der AY-3-8910 (und kompatible) verfügt ebenfalls über Eingänge für Joysticks und Keyboard. Hieran zeigt sich, dass die Soundprozessoren mit der Verarbeitung derartiger Input-Signale nicht bloß eine ‚Zusatzfunktion‘ realisieren, sondern als veritable Sampler Signalverarbeitung auf Ultra- und Hyperschall-Ebene betreiben. Die 8-Bit-Heimcomputer von Atari, Commodore, Amstrad und vielen anderen zeigen sich damit auch abseits der Klangeigenschaften ihrer PSGs als Musikinstrumente: auf ihnen zu spielen oder zu tippen ist eine implizit pseudoakustische Tätigkeit. PSGs wie der LR35902³⁸ (im Gameboy) und der SID besitzen darüber hinaus auch Eingänge für Soundsignale, die sie ‚durchschleifen‘ und – im Falle des SID – sogar filtern können.³⁹

Alle PSGs verfügen neben den Soundkanälen auch über mindestens einen Rauschkanal (im Fall der TIA und des TED⁴⁰ kann ein Soundkanal vom Programmierer als Rauschkanal definiert werden). Das damit erzeugte ‚weiße Rauschen‘ dient sowohl der Gestaltung von Soundeffekten (Zisch- und Knallgeräusche) und Schlaginstrumenten (zumeist für Rhythmus-/Drum-Sounds) als auch als Beimengung für andere Sounds, um deren Klangfarbe zu beeinflussen (um Obertöne zu erzeugen).

Die Generierung des Rauschsignals führt ein exotisches Element in die Computerelektronik ein, geht es dabei doch um ein Geräusch, das möglichst gleichverteilt und zufällig alle verfügbaren Töne des Frequenzumfangs erzeugt. Warum erzeugen aber einiger der PSGs ein Rauschen, das mit 125 (76489AN⁴¹ und Dave⁴²) bzw. 131 (LR35902) Kilohertz Höchstfrequenzen weit jenseits der menschlichen Hörschwelle liegt? Diese Frequenzen werden als Grundlage für die Erzeugung von Zufallszahlen verwendet. Je nach verwendeter Rauscherzeugungsmethode lassen sich damit Zahlen generieren, die leicht (Pseudozufallszahlen), schwer oder gar nicht (basierend auf thermischem Rauschen) zurückrechenbar sind.⁴³ Genutzt wird dieser Zufall unter anderem in Computerspielen – etwa im VCS-Spiel „Pitfall II“, das diesen Zufallsgenerator nutzt, um damit das zufällige Leveldesign zu verwirklichen.

Der Rauschkanal des SID lässt sich mit einem kleinen BASIC-Programm aktivieren, abfragen und ausgeben:

10 POKE 54286,255: REM HIGHBYTE STIMME 3 FREQ AUF MAXIMUM
20 POKE 54287,255: REM LOWBYTE STIMME 3 FREQ AUF MAXIMUM
30 POKE 54290,128: REM KONTROLLREGISTER STIMME 3 AUF NOISE
40 PRINT PEEK(54299);: REM AUSGABE OSZILLATOR-REGISTERWERT STIMME 3
50 GOTO 40

4. Retro/soundchip/computing

Die Funktionalitäten der hier betrachteten PSGs sind in Datenblättern und der zeitgenössischen Sekundärliteratur gut dokumentiert (auf diese wird im Folgenden verwiesen). Retrocomputing-Szenen haben über die Jahrzehnte umfangreiche Archive mit solchem historischem Material angelegt, so dass es auch heute noch möglich ist, diese Geräte zu programmieren. Insbesondere Musiker haben davon gezehrt, nutzen sie PSGs doch für Chiptune-Kompositionen oder um in ihre Musik historisch klingende Elemente zu integrieren. Darüber hinaus bringt die fortgesetzte Beschäftigung mit diesen Geräten jedoch auch ständig neue Erkenntnisse hervor.  So wurden beispielsweise zwei weitere Soundkanäle des VIC-Chips im VC-20 erkundet⁴⁴ oder die Möglichkeit, mit Atari-Homecomputern Soundsamples mit 8-Bit-Auflösung wiederzugeben (anstelle der 2- oder 4-Bit-Auflösungen, die in der Pokey-Referenz beschrieben werden).⁴⁵ Aber nicht nur die Beschäftigung mit der Software (der Programmierung) hat verborgenene PSG-Funktionalitäten freigelegt, auch die Hardware der Soundchips wird kreativ erweitert und genutzt. Der immer rarer werdende SID ist vollständig reverse engineert worden⁴⁶, so dass für ihn inzwischen FPGA-Surrogate⁴⁷ angeboten werden können oder Erweiterungen möglich sind, die zwei SIDs in einen C64 einbaubar machen⁴⁸, um beispielsweise 6-Kanal-Mono- oder 3-Kanal Stereo-Sound zu erzeugen.

Nicht wenige solcher Projekte explorieren die Soundfähigkeiten anderer Hardware-Elemente von 8-Bit-Homecomputern. Insbesondere für den heute noch viel genutzten C64 existieren etliche Hacks und Erweiterungen, die die Soundfähigkeiten des Systems – auch jenseits seines SID-Chips – kreativ einsetzen. Die Tatsache beispielsweise, dass die 6510-CPU beim Speichern auf Kassette die Daten unvermittelt an den Tape-Port weitergibt, hat ein Verfahren hervorgebracht, bei dem der Prozessor 1-Bit-Musik als Audiosignal auf Audiokassetten im Datenrecorder schreibt.⁴⁹ Damit realisiert der C64 eine Funktion, die – aus der Not eines fehlenden Soundchips heraus – bereits beim TRS-80 für Spiele eingesetzt wurde: die Audioausgaben über den (ohnehin ‚audiokompatiblen‘) Kassettenport des Computers auszugeben.⁵⁰

Die Hybridität der Audiokassette als Tonband und Datenspeicher hatte frühe ‚Raubkopierer‘ bereits das Kopieren von Programm-Kassetten mit zwei heimischen Kassettenrecordern praktizieren lassen; sind es doch hörbare Frequenzen (1200 Hertz für 0, 2400 Hertz für 1), die die Bits repräsentieren. Atari nutzt für die Datenkassetten seiner 8-Bit-Computer lediglich den linken Kanal; auf dem rechten wurden bereits früher Audiospuren ausgenommen, die während des Ladens von Programmen Musik über den Fernsehlautsprecher wiedergaben oder in Spielen als ‚Hintergrundsound‘ eingesetzt wurden.⁵¹ Bei der Kassettenversion des Spiels Warhawk wurde nach Ende des Ladevorgangs der Motor des Datenrecorders nicht deaktiviert, so dass es möglich war, während des Spielens darin Musikkassetten darin abzuspielen, deren Inhalt dann gemischt mit dem Pokey-Sound aus dem Fernsehlautsprecher ertönte.

Die Steuerung des Datenrecorder-Motors kann sowohl beim C64 als auch bei Ataris 8-Bit-Computern durch Software erfolgen, weil diese Peripherie-Geräte ihre Stromversorgung über den Computer beziehen.⁵² Systeme, die, wie Amstrads CPC-464-Computer, einen eingebauten Datenrecorder besitzen, steuern die Stromversorgung für diesen häufig über ein Relais. Sobald die Tape-Funktionen aktiviert werden, hört man ein deutlich vernehmbares Klick-Geräusch. Die CPC-Spiele S7 (Sigma Seven) und Death Wish III nutzten diese Klickgeräusche als Effekte in ihren Spielsounds. Vor dem allzu häufigen Spieles des ersten wurde jedoch gewarnt.⁵³Grund hierfür ist die mangelnde Eignung von Relais als Soundgeneratoren: Die Langsamkeit solcher elektromechanischen Schalter war schon bei historischen Relais-Computern ein geschwindigkeitslimitierender Faktor. Bei allzu schnellem Schalten kann nicht nur der Schaltkontakt aufgrund der unvollständigen Bewegung der Relaiszunge nicht mehr stattfinden, auch wird das Relais durch anhaltende mechanische Beanspruchung schnell beschädigt. Insofern verbieten sich Experimente mit so genannten „Killerpokes“⁵⁴, bei denen Datenrecorder-Relais zur Musikerzeugung eingesetzt werden in der realen Hardware – auch, wenn sie möglich wären/sind. Für den CPC existiert jedoch ein Emulator, der das Relais-Geräusch ebenfalls ausgibt.⁵⁵ Der virtuelle Baustein kann selbstverständlich nicht beschädigt werden, weshalb hierfür Musik programmiert werden konnte. Folgendes Programm ist im BASIC des CPC dafür einzugeben:

10 OUT &F600,&10:REM Tape-Relais ein
20 OUT &F600,&0:REM Tape-Relais aus
30 GOTO 10

Hier zeigt sich augenscheinlich ein Vorteil von Emulatoren: Mit ihnen können Features historischer Hardware jenseits ihrer realen Nutzbarkeit exploriert werden. Im genannten Beispiel ist aber gar kein wirkliches Relais zu hören, sondern bloß das Soundsample eines solchen. Das maßgebliche Problem von Emulatoren ist, dass sie zwar die symbolische Maschine „Computer“ simulieren können, vor der physikalischen Grenze des realen Computers kapitulieren müssen.⁵⁶ Das zeigt sich nicht zuletzt bei der Soundhardware: Auch wenn die VICE-Emulation etliche Konfigurationen des Zyklus-genau emulierten SID-Chips anbietet⁵⁷, bleibt es doch unmöglich, deren analogen Filter in Software nachzubilden. (Abb. 3) Ein letzter, bemerkenswerter Sound-Hack für den C64 belegt dies einmal mehr, weil er auf spektakuläre Weise Hardware-Defizite des Rechners ausnutzt: Aus Kostenersparnisgründen sind die Datenleitungen des VIC-II-Grafikchips im C64 nicht ausreichend abgeschirmt, so dass die darin erzeugten Felder (insbesondere beim Horizontal Sync⁵⁸) die Leitungen des SID-Chips beeinflussen. Besaß der Vorgänger VIC im VC-20-Computer noch explizite Sound-Features, so sind diese beim VIC II nur noch implizit vorhanden. Hochfrequentes Übersprechen(!) der Grafikprozessor-Signale in die Soundprozessor-Leitungen verändern nicht nur den Sound, sie lassen sich sogar kreativ nutzen, wie die 2008 veröffentlichte Demo Vicious Sid⁵⁹ vorführt.

Abb. 3: C64 (VICE-Emulation) mit ihrer Auswahl an SID-Typen

5. Hands on – open ears!

Sound ist ephemer; sobald die Tonquelle deaktiviert wird, verklingt er. Er lässt sich weder speichern noch aufschreiben noch beschreiben, ohne dass der Dokumentations- und Archivierungsprozess etwas herausfiltert oder ergänzt. Über Instrumentenklänge lässt sich zudem nicht jenseits ihrer prototypischen Eigenschaften diskursiv verhandeln. Betrachten wir die PSGs und die sie notwendigerweise rahmenden technischen Umwelten als Instrumente, die einen spezifischen, gerätetypischen Klang produzieren, so kann ihre Emulation allenfalls als Annäherung und Mittelwert betrachtet werden. Adäquat können sie allein von und über sich selbst ‚sprechen‘. Es ist also das Anliegen dieses Beitrags, am Schluss eine demonstrative Auseinandersetzung mit ihnen anzuregen. Aufgrund der genannten Idiosynkrasien einzelner PSG-Bausteine kann daraus zwar keine theoretische Verallgemeinerung erfolgen, jedoch wäre ein solches nachvollziehendes Invollzugsetzen geeignet, genau diese Problematik vorzuführen.

Es folgt also ein kleines Programm, mit dem ein AY-3-8900-PSG⁶⁰ in einem Amstrad CPC programmiert werden kann. Die Auswahl ist allein durch dem Umstand begründet, dass das im CPC verbaute Locomotive-BASIC sehr komfortable Sound-Programmiermöglicheiten besitzt. (Bei anderen Systemen müsste hier ein im doppelten Sinne „schwer nachvollziehbares“ Assemblerprogramm ein-/angegeben werden.) Generiert werden soll ein Sound, moduliert über zuvor definierte Hüllkurven und ergänzt um ein ebenfalls definiertes Rauschen. Die Syntax des SOUND-Befehls lautet wie folgt⁶¹:

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

Die Ton-Hüllkurve wird mit dem Befehl ENT⁶² definiert:

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

Jeder der 15 möglichen Ton-Hüllkurven kann um fünf mögliche Hüllkurvenabschnitte mit zwei oder drei Parametern ergänzt werden: <Schrittanzahl>,<Schrittweite>,<Schrittzeit> oder <Tonperiode>,<Schrittzeit>

Zur Gestaltung der Lautstärken-Hüllkurve kann der ENV-Befehl verwendet und nach folgender Syntax programmiert werden:

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

Jeder dieser fünf Hüllkurvenabschnitte kann drei Parameter (für <Schrittanzahl>,<Schrittweite> und <Schrittzeit>) oder zwei Parameter (<Registerwert> und <Hüllkurvenperiode>) enthalten.⁶³

Hier nun das Programm:

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

Starten Sie das Programm mit RUN. Experimentieren Sie mit den Parametern. Vergleichen Sie den Sound eines realen CPC mit einem Emulator!

6. Schluss

Seit Pong werden von Computerspielen dedizierte Sounds generiert. Auf welche Weise sie sich zum Gameplay, zum Genre oder zum Spielabschnitt verhalten, liegt in der Hand der Programmierer und Komponisten. Die technischen Möglichkeiten von Spielsounds sind seit Einführung von Sampling-Funktionen (etwa der Paula-Chip im Amiga), CD-ROM-Laufwerken und FM-Synthese in Soundchips und auf Soundkarten scheinbar unbegrenzt. Der Einsatz neuer Technologien hat jedoch nicht zu charakteristischeren Sounds geführt, sondern umgekehrt dazu, dass sich für Nutzer und Spieler alle aktuellen Systeme gleich anhören.⁶⁴ Nur, wenn die gerätespezifischen Färbung eines Klangs in den Hintergrund gerät oder verschwindet, kann der Sound ‚unhörbar‘ mit den visuellen Ausgaben zu einem audiovisuellen Ereignis verschmelzen. Insofern rufen historische PSGs nicht bloß die Anfangszeit dieser Technologien ins Bewusstsein, sondern künden auf akustische Weise von sich selbst. Der ‚Retro-Sound‘ ist nichts anderes als ein Nicht-Überhören-Können computersoundhistorischer Patina.

Abb. 4: Offener C64 mit Wave-Detektor „Elektroslush“ über dem SID.

Die Geschichtsschreibung historischer Mikrocomputer kann mit den Objekten, von denen sie im Sprachtempus der Vergangenheit schreibt, glücklicherweise immer noch konfrontiert werden. Operative PSGs sind dann nicht mehr historisch, sondern laden zu aktuellen Experimenten ein und offenbaren insbesondere über ihre Programmierung, dass ihnen nichts ferner liegt als als Kenndatenliste in einer Chronologie fort zu existieren. Sie schwingen vielmehr im unhörbaren Mikrotempus und „zeitigen“⁶⁵ auf diese Weise Sounds. Im Hintergrund ihrer hörbaren Outputs werden unhörbare Signalereignisse im Prozessortakt verarbeitet, übertragen und prozessiert, welche wiederum die Bedingung der Möglichkeit von Computersounds darstellen. Der programmierbare Sound-Prozessor bildet lediglich die hörbare Oberfläche dieser unerhörten sonischen Kakophonie namens Computer. Wie können wir dieser gewahr werden?

Wie der stumme TRS-80 mit Gadgets und der 1-Bit-Sound-Technologie zum Klingen gebracht werden konnte, wurde oben dokumentiert. Es gibt jedoch noch eine weitere Möglichkeit, mit ihm Musik zu generieren. Mit dem BASIC-Programm Jukebox⁶⁶ werden die vom operativen Computer erzeugten elektromagnetischen Felder mit einem HF-Empfangsgerät messbar – zum Beispiel mit einem Radio. Stellt man ein solches neben den Computer, so wandelt es diese Felder in akustische Signale um. Der Code von Jukebox versetzt den TRS-80 nun in Zustände, die diese HF-Frequenzen von einem nahestehenden Radio als Musik erklingen lassen. Die Elektronik des Computers erzeugt beim Abarbeiten des BASIC-Programms elektromagnetische Felder. Diese ändern sich, abhängig von den im Programm definierten Schleifen, in ultrakurzzeitigen Abständen, was als 1-Bit-Musik hörbar wird. Diese Art der Computermusik blickt ebenfalls auf eine lange Tradition zurück.⁶⁷

Aus dem multifrequenten Konzert der Computer-Operationen soll abschließend der Soundprozessor zu Gehör gebracht werden. Dazu kann ein Detektor genutzt werden, den Miyazaki vorgestellt hat.⁶⁸ Mit einem Sensor habe ich dem SID eines Commodore 64 dabei zugehört, wie er Musikdaten eines Computerspiels verarbeitet.⁶⁹ Die akustische Oberfläche des Spiels Ghosts‘n Goblins wird nach dem oben beschriebenen Verfahren durch wechselseitige Unterbrechungsvorgänge von Codeausführung und Soundgenerierung erzeugt. Die in diesem Experiment zu hörenden Sounds der „Unterfläche“⁷⁰ sind werden durch die ununterbrochenen (wenngleich auch diskreten) Prozesse im SID erzeugt. Sie stellen die eigentliche Musik des Computerspiels dar, die unhörbar unter den Spielsound residiert. Frieder Nakes epistemologischer Zugriff auf Computerprozesse bezieht sich auf das „doppelte Bild“ der Computergrafik. Dass es nicht nur ein doppeltes Bild gibt, sondern einen doppelten Ton, habe ich (und die Computer) hier versucht zu Gehör zu bringen.

Bibliografie

Botz, Daniel: Kunst, Code und Maschine. Die Ästhetik der Computer-Demoszene. Bielefeld: Transcript 2011.

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

Bülow, Ralf: Luftnummern. Das Patent einer Druckluft-Denkmaschine von Emil Schilling. In: Retro Magazin, H. 34, 2015, S. 30f.

Collingwood, Robert G.: Philosophy of History. In: Ders.: The Principles of History And Other Writings in Philosophy of History. Oxford: Oxford University Press 1999, S. 219–234.

DEC: DECUS. Program Library PDP-8 Catalog. Digital Equipment Corporation Users Society, August 1978. Maynard: DEC 1978. http://txt3.de/sndchp1 [05.12.2018]

Dittbrenner, Nils: Soundchip-Musik. Computer- und Videospielmusik von 1977-1994. Osnabrück: epOS 2005.

Ernst, Wolfgang: Sonic Time Machines. Explicit Sounds, Siren Voices, Implicit Sonicity. Amsterdam: Amsterdam University Press 1999.

Ernst, Wolfgang: Gleichursprünglichkeit. Zeitwesen und Zeitgegebenheit technischer Medien. Berlin: Kadmos 2012.

Ernst, Wolfgang: Signale aus der Vergangenheit. Eine kleine Geschichtskritik. Berlin: Kadmos 2013.

Fritsch, Melanie: Musik. In: Beil, Benjamin/Hensel, Thomas/Rauscher, Andreas (Hg.): Game Studies. Wiesbaden: Springer VS 2018, S. 87-108.

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

Höltgen, Stefan: Digitale Analogien. Der Körper des Spielers am Gameport des Computers. In: Inderst, Rudolf Thomas/Just, Peter (Hg.): Build ’em Up – Shoot ’em Down. Körperlichkeit in digitalen Spielen. Glückstadt: vwh 2015, S. 254–273.

Höltgen, Stefan/Othmer, Thorsten: Sounds like a Melody. Computer & Sound: Periphere Musikemissionen. 2013. http://txt3.de/sndchp3 [05.12.2018]

Hugg, Stefan: Making Games For The Atari 2600. Wroclaw: Amazon 2016.

Levy, Steven: Hackers. Heroes of the Computer Revolution. Garden City/New York: Anchor Press/Double Day 1984.

Loebel, Jens-Martin: Lost in Translation. Leistungsfähigkeit, Einsatz und Grenzen von Emulatoren bei der Langzeitarchivierung digitaler multimedialer Objekte am Beispiel von Computerspielen. Glückstadt: vwh 2014.

Maria, Pater: Chipmusik ohne Soundchip. Geschichte, Theorie und kulturelles Erbe der analogen Klangerzeugung mit Digitalcomputern. In: Höltgen, Stefan (Hg.): SHIFT – RESTORE – ESCAPE. Retrocomputing und Computerarchäologie. Winnenden: CSW 2013, S. 81-96.

Miyazaki, Shintaro: Algorythmisiert. Eine Medienarchäologie digitaler Signale und (un)erhörter Zeiteffekte. Berlin: Kadmos 2013.

Montfort, Nicht/Bogost, Ian: Racing the Beam. The Atari Video Computer System. Reihe: Platform Studies, 1. Cambridge/London: MIT Press 2009.

Nake, Frieder: Das doppelte Bild. In: Digitale Form, Bildwelten des Wissens. Kunsthistorisches Jahrbuch für Bildkritik, Bd. 3, Nr. 3, Berlin 2005, S. 40–50.

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

Stübbs, M.: Programmieren mit dem TRS-80. Düsseldorf: Tandy 1979.

van der Meer, John Henry: Artikel: Instrumentenkunde. In: Lütteken, Laurenz (Hg.): MGG Online, Kassel, Stuttgart, New York: 2016ff., zuerst veröffentlicht 1996, online veröffentlicht 2016, http://txt3.de/sndchp2 [07.09.2018]

Völz, Horst: Das Mensch-Technik-System. Physiologische, physikalische und technische Grundlagen – Software und Hardware. Renningen-Malmsheim: expert 1999.

Spiele:

Epyx: Barbie (Apple II) 1984.

Bit Five Software: Robot Attack (TRS-80) 1981.

Activision: Pitfall II – Lost Caverns (Atari VCS) 1984.

Firebird: Warhawk (Atari 8 Bit) 1986.

Durell Software: S7 (Sigma Seven) (Amstrad CPC 464) 1987.

Gremlin Graphics Software Ltd.: Death Wish III (Amstrad CPC 464) 1987.

Elite: Ghosts’n Goblins (Commodore 64) 1986.

Atari: Pong (Arcade) 1972.

1. Für musikwissenschaftliche Hinweise danke ich Dr. Nikita Braguinski, für technische Hinweise Malte Schulz, Markus Hohmann und den Mitgliedern der TRS-80-Model-1-Facebook-Gruppe.[↩]
2. Miyazaki: Algorythmisiert. 2013.[↩]
3. http://txt3.de/sndchp30 [05.12.2018].[↩]
4. vgl. Dittbrenner: Soundchip-Musik. 2005.[↩]
5. Dittbrenner: Soundchip-Musik. 2005, S. 5.[↩]
6. vgl. Dittbrenner: Soundchip-Musik. 2005.[↩]
7. Ernst: Gleichursprünglichkeit. 2012, S. 378[↩]
8. Collingwood: Philosophy of History. 1999, S. 223.[↩]
9. Ernst: Signale aus der Vergangenheit. 2013, S. 169f. sowie Ernst: Sonic Time Machines. 1999, S. 99.[↩]
10. Völz: Das Mensch-Technik-System. 1999, S. 57-59.[↩]
11. van der Meer: Instrumentenkunde. 2016.[↩]
12. Botz: Kunst Code Maschine. 2011, S. 18, 289f.[↩]
13. http://txt3.de/sndchp31 [05.12.2018].[↩]
14. Dass auch solche Geräusche zur Musikproduktion eingesetzt wurden und werden, ist nicht Gegenstand dieses Beitrags. (Vgl. Höltgen/Othmer: Sounds like a Melody. 2013).[↩]
15. Bülow: Luftnummern. 2015.[↩]
16. vgl. Miyazaki: Algorythmisiert. 2013, S. 44ff.[↩]
17. Levy: Hackers. 1984, S.15.[↩]
18. vgl. Miyazaki: Algorythmisiert. 2013, S. 78ff.[↩]
19. http://txt3.de/sndchp5  [05.12.2018].[↩]
20. vgl. Levy: Hackers. 1984, S. 20f.[↩]
21. Die populärsten Beispiele hierfür sind die frühen PCs von IBM, der Apple II, Sinclairs Spectrum und – über den Umweg seines Kassettenports (http://txt3.de/sndchp6 [05.12.2018]) – auch der TRS-80.[↩]
22. Maria: Chipmusik ohne Soundchip. 2013, S. 90.[↩]
23. 1961 sang der IBM 7094 als erster Computer auf Basis dieser Technologie ein Lied (http://txt3.de/sndchp7 [05.12.2018]).[↩]
24. Braguinski: RANDOM. 2018, S. 183-221 sowie Montfort/Bogost: Racing the Beam. 2009, S. 130-133.[↩]
25. Beim Arcade-Automaten „Pong“ (1972) wurden die drei verschiedenen Sounds mithilfe von Zählerbausteinen, die eigentlich für die Synchronisierung von Bildelementen genutzt werden, erzeugt. (Vgl. http://txt3.de/sndchp8 [05.12.2018]).[↩]
26. vgl. Hugg: Making Games for the Atari 2600. 2016, S. 33f.[↩]
27. Jeder Maschinensprache-Befehl wird in einer definierten Anzahl von Takten von der CPU abgearbeitet. Diese ist von verschiedenen Faktoren, wie Adressierungsart oder zu verarbeitender Datengröße abhängig [Hugg: Making Games for the Atari 2600. 2016, S. 213f., 227-233].[↩]
28. http://txt3.de/sndchp9 [05.12.2018].[↩]
29. Durch programminterne Zähler, die beim Erreichen eines bestimmten Grenzwertes eine Funktion aufrufen.[↩]
30. http://txt3.de/sndchp10 [05.12.2018].[↩]
31. Hugg: Making Games for the Atari 2600. 2016, S. 203–206.[↩]
32. Dittbrenner: Soundchip-Musik. 2005, S. 21.[↩]
33. Dieser Baustein teilt die vom Schwingquarz generierten Takt auf die verschiedenen zeitabhängigen Elemente des Systems (CPU, Treiberbausteine, I/O-Bausteine etc.) auf.[↩]
34. http://txt3.de/sndchp32 [05.12.2018].[↩]
35. http://txt3.de/sndchp33 [05.12.2018].[↩]
36. Hierbei handelt es sich um regelbare Widerstände, die die Eingangsspannung von 5 Volt stufenlos („analog“) verringern, was von der Spielsoftware als Steuerungsinformation ausgewertet wird (vgl. Höltgen: Digitale Analogien. 2013, S. 258-262).[↩]
37. Erst diese Umwandlung nicht nur von kontinuierlich zu diskret, sondern auch von einer Spannungsgröße zu beziffertem Puls heißt Digitalisierung. [↩]
38. http://txt3.de/sndchp34 [05.12.2018].[↩]
39. Der Pin 26 („Ext in“) des SID wurde angelegt, um mehrere SIDs – etwa in Synthesizern – kaskadieren zu können. Sein Erfinder Robert Yannes gründete später die auf elektronische Instrumente spezialisierte Firma Ensonic (vgl. Dittbrenner: Soundchip-Musik. 2005, S. 21) – einen SID-Synthesizer hat er dort nicht entwickelt. Der SID-Pin 26 kann jedoch als das ‚verbindende Element‘ zwischen diesen beiden Tätigkeiten gesehen werden.[↩]
40. http://txt3.de/sndchp35 [05.12.2018].[↩]
41. http://txt3.de/sndchp37 [05.12.2018].[↩]
42. http://txt3.de/sndchp36 [05.12.2018].[↩]
43. Braguinski: RANDOM. 2018, S. 163ff.[↩]
44. http://txt3.de/sndchp11 [05.12.2018].[↩]
45. http://txt3.de/sndchp12 [05.12.2018].[↩]
46. http://txt3.de/sndchp13 [05.12.2018].[↩]
47. http://txt3.de/sndchp14 [05.12.2018].[↩]
48. http://txt3.de/sndchp15 [05.12.2018].[↩]
49. http://txt3.de/sndchp16 [05.12.2018].[↩]
50. Stübbs: Programmieren mit dem TRS-80. 1979, S. 77.[↩]
51. Um auf einem historischen 8-Bit-Atari heutige Musik wiedergeben zu können, genügt es bereits z.B. eine Kassette mit aktueller Musik einzulegen, auf Play zu drücken und POKE 54018,52 einzugeben. Mit POKE 54018,60 stoppt man die Wiedergabe.[↩]
52. Frühere Systeme, wie der Sol-20, nutzten handelsübliche Kassettenrecorder, um Daten darauf zu laden und zu speichern. Um solch einen Kassettenrecorder zu steuern, besitzt der Sol-20 eine 2,8-mm-Klinkenbuchse für ein Motor-on-off-Signal. Einige Kassettenrecorder verfügten ebenfalls über eine solche Buchse, um von extern gesteuert werden zu können.[↩]
53. http://txt3.de/sndchp17 [05.12.2018].[↩]
54. http://txt3.de/sndchp18 [05.12.2018].[↩]
55. http://txt3.de/sndchp28 [05.12.2018].[↩]
56. Vgl. Loebel: Lost in Translation. 2014, S. 108–126.[↩]
57. http://txt3.de/sndchp27 [05.12.2018].[↩]
58. http://txt3.de/sndchp19 – Abschnitt „Software Methods“ [05.12.2018].[↩]
59. http://txt3.de/sndchp20 [05.12.2018] Um zu beweisen, dass die Sounds nicht aus dem SID-Chip stammen, kann man diesen aus der Platine abziehen/auslöten. Der VIC II ‚sendet‘ seine Soundsignale nicht durch den SID, sondern direkt auf die Leitungen, die zum Audio-In des Chips (Pin 26, vgl. Fußnote 14) führen. Um ein unerwünschtes Übersprechen zu verhindern, werden Hardware-Lösung angeboten (http://txt3.de/sndchp21 [05.12.2018]).[↩]
60. http://txt3.de/sndchp29 [05.12.2018].[↩]
61. Spital u.a.: Amstrad CPC 6128 User Instruction. 1985, S. 1-73.[↩]
62. Spital u.a.: Amstrad CPC 6128 User Instruction. 1985, S. 3-22–24.[↩]
63. vgl. Spital u.a.: Amstrad CPC 6128 User Instruction. 1985, S. 3–34f.[↩]
64. vgl. Fritsch: Musik. 2018, S. 94.[↩]
65. Ernst: Gleichursprünglichkeit. 2012, S. 38.[↩]
66. http://txt3.de/sndchp23 [05.12.2018].[↩]
67. DEC: DECUS. 1978, S. 29 sowie Levy: Hackers. 1984, S. 198-200.[↩]
68. Miyazaki: Algorithmisiert. 2013, S. 229-233. Hier werden der Aufbau und Experimente mit dem Detektor beschrieben: http://txt3.de/sndchp22 [05.12.2018].[↩]
69. Das Ergebnis habe ich in einem Video festgehalten (http://txt3.de/sndchp24 [05.12.2018]). Es sollte, den oben aufgeführten Überlegungen zur Demonstration als Argumentationsverfahren, jedoch an einem eigenen Gerät nachvollzogen werden.[↩]
70. Nake: Das doppelte Bild. 2005, S. 47.[↩]