Das magische Panoptikum: Technologien der Überwachung zum Zweck des Spiels — eine computerarchäologische Analyse

„Du glaubst zu schieben, und du wirst geschoben.“
(Goethe, Faust I)

1 Einleitung: Gunable User Interface

Die Szenerie erhellt sich und zeigt uns eine hügelige Prärie-Landschaft in Zentralperspektive. Bis zum Horizont erstreckt sich sandiger Boden, auf dem zahlreiche, hoch aufragende Kakteen wachsen. Am blauen Himmel stehen vereinzelte Wolken. Da bewegt sich etwas am linken Bildrand: Ein weißes Kaninchen springt wild auf und ab und durchquert so unser Blickfeld. Dicht hinter ihm erscheint ein Mann, der ein Schwert trägt. Auch er geht nach rechts. Plötzlich kommen aus allen Richtungen Tiere ins Bild: Skorpione, Schlangen, Vögel. Sie alle bewegen sich auf den Mann mit dem Schwert zu. Als eines der Tiere ihn berührt, geht er in Flammen auf und verbrennt in kurzer Zeit zu einem Haufen Asche. Wir beobachten die Szenerie aus (scheinbar sicherer?) Distanz, ohne daran beteiligt zu sein. Der Mann, der gerade verbrannt ist, war unser „Freund“, wie es im Vorspanntext hieß. Ihm folgen weitere, die die Bildfläche ebenfalls von links nach rechts zu überqueren versuchen. Wir sollen ihren Weg von unserer Position aus sichern – sie vor den angreifenden Tieren beschützen, zu denen sich später noch Räuber, Gespenster, glühendes Gestein aus einem Vulkan, mit Kokosnüssen werfende Affen, herabfallende Eiszapfen und andere potenziell tödliche Objekte gesellen. Dazu müssen wir das Geschehen auf dem Bildschirm genau beobachten. Als Verteidigungsinstrument dient uns eine Armbrust, mit der wir die Gefahren von unseren Freunden abwenden können, indem wir auf die Gefahren schießen.

Nach der Form und dem Eingabeprinzip dieser Armbrust ist auch das Spiel benannt: Crossbow ist ein „Abenteuer-Schieß-Spiel“ des Herstellers Exidy, das 1983 als Arcade-Automat erschien. Wenig später wurden auch Versionen für Spielkonsolen (Atari 2600, Atari 7800) und Homecomputer (Atari 8-Bit, Commodore 64) adaptiert. Bekannt ist die Arcade-Version vor allem wegen ihrer Sound-Ausgaben, denn Crossbow besitzt als eines der ersten Spielhallen-Spiele eine komplexe Sprachausgabe, die nicht vom Band stammt, sondern in Echtzeit von einem integrierten Sound Board erzeugt wird. Dieses Board und das Mainboard wurden unter der Bezeichnung „Exidy 440“¹ für insgesamt zehn Spiele genutzt,² von denen acht ebenso wie Crossbow eine Lightgun als Eingabe-Instrument verwenden.³ Das Steuerungsinstrument ist zuvor bereits für unterschiedliche Pong-Spielkonsolen, die NES und Homecomputerspiele eingesetzt worden. Während die Crossbow-Versionen für den C64⁴ und die Atari 2600⁵ ein Joystick-gesteuertes Fadenkreuz verwenden, lassen sich die Versionen für Ataris 7800-Konsole⁶ und Atari-Heimcomputer⁷ wie das Original, jedoch in Pistolen- statt Armbrust-Form, steuern.

Für den folgenden Beitrag soll Crossbow als Exempel eines Spiels diskutiert werden, in welchem das Thema der Überwachung von der Unterfläche auf die Oberfläche des Systems durchdringt und für den Spieler⁸ auf diese Weise das, was Frieder Nake das „doppelte Bild“ nennt, noch einmal sichtbar verdoppelt:

Das Bild als digitales Bild [...] besitzt nun auch eine unterflächliche Innerlichkeit bzw. ist Oberfläche und Unterfläche zugleich. Beide – das ist entscheidend – sind objektiv vorhanden. Die Oberfläche des digitalen Bildes ist sichtbar, während die Unterfläche bearbeitbar ist. Die Oberfläche besteht für den Benutzer, die Unterfläche für den Prozessor (mit Programm). Zur Unterfläche gehört das und nur das, was als Datenstruktur und Algorithmus vorhanden ist. […] Erst das verdoppelte Bild erlaubt die technische Interaktion. Es wird geradezu zur Schnittstelle seiner selbst: Die sichtbare Oberfläche des Bildes wird zum Interface seiner unsichtbaren Unterfläche.⁹

Was im Folgenden derartig bis zur epistemologischen Kenntlichkeit ‚verdoppelt‘ werden soll, sind aber nicht die Algorithmen der Grafikerzeugung Crossbows, sondern das in der Spiel(er)situation verhandelte Überwachungs­motiv. Überwachung als medientechnischer Vorgang (also Überwachen mithilfe von Medientechnik) ist zumeist an die Subtilität des Vorgangs gebunden: Die Überwachungstechnik soll vom Überwachten nicht bemerkt werden – entweder, weil er verdeckt überwacht oder durch den Überwachungsvorgang nicht in seinem Verhalten beeinflusst werden soll. Die Situation des Spielers von Crossbow ist ähnlich: Jene die Spielfigur angreifenden „Feinde“ sollen ebenfalls nicht wissen, dass sie vom Spieler überwacht werden. Das Überwachungsdispositiv verkehrt sich, wie sich zeigen soll, hier jedoch in sein Gegenteil: Es ist der Spieler, der vom Spiel überwacht wird. In der Analyse dieses Vorgangs und der dazu benötigten technischen Vorrichtungen auf der Unterfläche lässt sich das medientechnische Apriori der Überwachung als Gegenstand einer Computerspielanalyse fassen. Der Spieler und das Spiel bilden darin eine ‚Überwachungs-Feedback-Schleife‘: Der Spieler überwacht das Spielgeschehen auf dessen Oberfläche und – um in dieses spielerisch eingreifen zu können – das Spiel überwacht die Handlungen des Spielers auf der Unterfläche. Die Grenzfläche zwischen Ober- und Unterfläche bildet hierbei die Schnittstelle – das Interface.

Der Interface-Begriff, den Nake oben metaphorisch auf das sichtbare Bild (im Sinne eines ‚Graphical User Interface‘) anwendet, ist bei Crossbow damit wortwörtlich vorhanden: Light Gun und Bildschirm bilden ein reales Input/Output-Device – ein ‚Gunnable User Interface‘, das Fragen nach seiner Funktionsweise, nach der hard- und softwareseitigen Verarbeitung der Eingabe und nicht zuletzt nach dem Status des Spielers im Regelkreislauf des Spiel(en)s aufwirft. Eine These des Medienwissenschaftlers Claus Pias lautet, dass Computerspiele ihre Nutzer in ihre Hardware-Software-Gefüge einbinden. Die Überwachung ist dabei das technische Apriori des Computerspielens, oder wie Pias sagt: „Der Spieler wird zu einer Gestalt der An­schlüsse. Nicht er spielt das Spiel, sondern das Spiel spielt ihn.“¹⁰

Die Argumentation dieser These kann nur nahe entlang der Hard- und Softwareprozesse erfolgen, denn nur auf diesen Ebenen lässt sie sich beobachten. Hier wird sich zeigen, dass sich die ‚Gestalthaftigkeit‘ des Spielers, also seine Verkörperung als ein steuerbares Device am Computer, gänzlich in mikrotemporale Überwachungssituationen auflöst. Um diese Behaup­tung zu stützen, werden nach einer allgemeinen Einführung in die sublimi­nalen Technologien digitaler Überwachung¹¹ die technischen Prinzipien einer Crossbow-Spielplattform vorgestellt und der Spielcode für diese in Auszügen diskutiert. Die Einhegung des Spielers in die formalen Dispositive von Elek­tronik, Schaltalgebra und Maschinensprache zeigen, dass ihn das Spiel mit dem Computer bereits auf der Unterfläche seine Handlungsfreiheit kostet, noch bevor die oberflächlichen Spielregeln sein Handeln auf die Pfade eines Spielbaums begrenzen.

Da die Hardware des Arcade-Originals heute vergleichsweise selten zu finden ist und dessen Programm-Code noch nicht disassembliert wurde, greife ich auf die Version für die Spielkonsole Atari 7800 zurück. Diese wurde von Atari 1983 als Nachfolger der VCS 2600 publiziert und ist zu dieser abwärtskompatibel.¹² Die Atari 7800 beinhaltet auf der Hardware-Ebene zwei Systeme, die sogar unterschiedlich schnell getaktet sind und zwei verschiedene Grafikprozessoren, aber einen gemeinsamen Soundprozessor nutzen. Die CPU der Atari 7800 ist Pin-kompatibel zu derjenigen der VCS, bietet dieser gegenüber jedoch verschiedene Erweiterungen. Zu dieser Plattform existieren nicht nur sehr detaillierte technische Beschreibungen;¹³ auch der Source Code der Crossbow-Version für die Atari 7800, den Scott Marshall Ende Juni 1988 fertiggestellt hat, ist auf GitHub frei verfügbar.¹⁴ Ohne diese, vor allem durch Fans organisierte, akribische Bewahrungspraxis wäre ein tiefer(er) Einblick in die Geschichte der Computerspiele jenseits bloß diskursiver Verhandlungen ihrer ästhetischen Oberflächen und Wirkungen kaum möglich.

2 Handlungsfreiheit durch Überwachung durch Unterbrechung

Eine Lehre aus der Geschichte der Computer¹⁵ ist, dass die Freiheit der User/ Spieler, auf der Oberfläche tun zu können, was und wann sie es wollen, stets mit einer ‚Freiheitsberaubung‘ auf der Unterfläche des Systems erkauft werden muss. Dies erklärt sich aus der Notwendigkeit der Echtzeit-Interaktion zwischen dem Menschen und dem Computer, wofür letzterer von seiner Theorie und Architektur eigentlich überhaupt nicht angelegt war: Die nach der Von-Neumann-Architektur¹⁶ implementierte Turing-Maschine¹⁷ ist ein hochgradig seriell und monoton arbeitender Solipsist. Ihre zu verarbeitenden Daten bezieht sie aus demselben Speicher wie ihr Programm. Dies macht es unumgänglich, dass Speicherinhalte getrennt von- und nacheinander in die CPU eingelesen werden müssen, um erst dort in Instruktionen von Argumenten und Daten separiert zu werden.¹⁸ Die augenscheinliche raumzeitliche Flexibilität eines Programms (wie sie sich zum Beispiel im Nebeneinander der Elemente eines Flussdiagramms zeigt), besteht innerhalb der Maschine nirgends. Hier herrscht räumliche Serialität und zeitlicher Gleichtakt: Genauso wenig, wie ein ‚Sprung‘ innerhalb eines Programms eine räumliche Distanz zwischen zwei Speicher-‚Orten‘ überbrückt,¹⁹ verzögert eine Warteschleife einen Programmablauf. Im ersten Fall wird lediglich eine andere als ‚die nächste‘ Adresse in den Programmzähler geladen, zu der dann ‚gesprungen‘ wird; im zweiten Fall wird die Warteschleife mit derselben Geschwindigkeit abgearbeitet, wie alle anderen Instruktionen des Programms auch – nur, dass während dessen für den User nichts von Wichtigkeit passiert (außer, dass gewartet wird).

Frühe Computer waren Geräte, die zu einem singulären Zweck ‚eingerichtet‘ wurden, indem die Programme und die Eingabewerte als materielle Struktur mit Kabeln auf ihre Panels ‚gepatcht‘ wurden. Für die darauf ablaufenden Berechnungen waren Interaktionen mit dem Programmierer weder nötig noch wären sie überhaupt möglich gewesen; das User-Konzept existierte deshalb schlicht gar nicht. Nachdem ein solcher Computer eingeschaltet war, rechnete er los; sein Programmierer stand daneben und war bis zum Ende der Operation einzig damit beschäftigt, das Funktionieren des Systems zu überwachen. Dieses Arbeitsprinzip hielt sich bis in die frühen 1950er-Jahre, bis mit dem Univac-I erstmals die Überlegung entstand, dem Computer eine Möglichkeit zu geben, sich selbst zu überwachen und bei der Arbeit zu unterbrechen, falls eine Berechnung zu nichts führte (zum Beispiel, weil ein Rechenfehler wie „division by zero“ auftrat)²⁰. Mit dieser als ‚Trap‘ bezeichneten Ausnahmebehandlung zog das Prinzip des Interrupts in die Computertechnik ein. In den folgenden Jahren wurden immer weitere Möglichkeiten der Unterbrechung eingerichtet: Neben ‚Trap‘-Funktionen, deren Interrupts beim IBM 650 bereits „maskiert“ (also per Software ausgeblendet) werden konnten, waren es dann 1954 beim NBS DYSAC bereits durch computerexterne Input/Output-Ereignisse hervorgerufene Interrupts, die das System verarbeiten konnte.²¹

In dieser Zeit entstanden die ersten Hacker-Kulturen an US-amerikani­schen Universitäten, deren Agenda die Demokratisierung (und später die Popularisierung) der Computertechnik war.²² Unwillig, sich länger dem ex­trem hierarchischen Batch Processing zu unterwerfen,²³ drangen Studenten des MIT zunächst illegal in das Rechenzentrum ihrer Universität ein, um ihre „Hands-On Imperative“²⁴ zu verwirklichen, und nutzten später neuere Computersysteme mit Terminals dazu, selbst (nun ganz legal) programmieren zu können. Eine Eskalation in dieser Hinsicht stellte die Implementierung des Betriebssystems ‚Multics‘ 1969 auf dem PDP-6-Minicomputer des MIT dar, erlaubte dieses doch, dass gleichzeitig mehrere Nutzer an einem Computer über unterschiedliche Terminals arbeiten konnten. Erreicht wurde dies dadurch, dass das Betriebssystem jedem angemeldeten User Zeitfenster zur Verfügung stellte, in denen seine Prozesse abgearbeitet wurden, bevor es dem nächsten angemeldeten User die Computerressourcen zur Verfügung stellte. Time Sharing basiert also im Wesentlichen auf der Unterbrechung eines Prozesses durch einen anderen. Das von einem menschlichen Operator organisierte Batch Processing war damit zwar Vergangenheit, wurde jedoch von einer maschinellen Rechte- und Zeitverwaltung und Prozess-Über­wachung abgelöst. Die MIT-Studenten erkannten diese daraus resultierende, viel grundlegendere Unfreiheit und begegneten Multics mit Hacks und Eigen-/Gegenentwicklungen.²⁵

Das Prinzip von Überwachung durch Unterbrechung via Interrupt ermöglichte zwei Prozesse, die auch unsere heutige Computertechnik maßgeblich auszeichnen. Zum Einen konnten auf diese Weise nun mehrere Programme ‚gleichzeitig‘ im Computer abgearbeitet werden: Durch vom Betriebssystem initiierte Software-Interrupts wird hierzu ein laufendes Programm unterbrochen, damit ein anderes Programm weiterlaufen kann, das dann ebenfalls unterbrochen wird, damit ein drittes Programm ausgeführt werden kann usw., bis schließlich wieder das erste Programm fortgesetzt wird. Dadurch, dass diese Unterbrechungen durch die Hochgeschwindigkeit des Systems in ex­trem kurzer Abfolge auftreten können, entsteht für den Benutzer ein Eindruck von ‚operativer Gleichzeitigkeit‘, auch Multitasking genannt. Der zweite Vorteil, den der Einsatz von Interrupts mit sich brachte, war, dass sich der Mikroprozessor weiter ‚öffnen‘ und mit Geräten der Außenwelt kommunizieren konnte. Diese unterbrechen ihn in seinem Tun durch Hardware-Interrupts und ermöglichen so nicht nur die Kommunikation des schnellen Computers mit vergleichsweise langsamer Peripherie (Massenspeicher, Drucker etc.), die sich meldet, wenn ein Zeichen vollständig übertragen wurde, um das nächste senden/empfangen zu können. Auch interaktive Eingabegeräte konnten nun mittels Interrupt in Echtzeit abgefragt werden: Schalter, Tastaturen, Joysticks, Light Guns und so weiter erzeugen direkt oder indirekt Signale, die den Computer auf sie aufmerksam machen.

Der Informatiker Edsger W. Dykstra bemerkt, dass dieser Vorteil durch einen gewichtigen Nachteil erkauft wurde:

It was a great invention, but also a Box of Pandora. Because the exact moments of the interrupts were unpredictable and outside our control, the interrupt mechanism turned the computer into a nondeterministic machine with a nonreproducible behavior, and could we control such a beast?²⁶

Die Turingmaschine war mit Einbau der Interrupts in die Von-Neumann-Architektur aus ihrem Solipsismus befreit worden, hatte damit aber gleichzeitig ihre Determinierbarkeit eingebüßt. Die „Priester-Kaste“²⁷ der Operatoren, die Dijkstra hier wohl mit „us“ meint, sollte von nun an aber im Gegenzug mithilfe ihrer Maschinen und Betriebssysteme die User determinieren, indem sie deren Verhalten beobachtete und festschrieb, was sich insbesondere bei Computerspielen zeigt:

Die Diskurselemente des Computerspiels heißen nicht ‚Menschen töten‘ oder ‚Goldtaler fangen‘, sondern Pünktlichkeit, Rhythmus oder Kontrolle. Und diese werden ununterbrochen an einer symbolischen Identität des Spielers abgefragt.²⁸

Bevor am Spiel Crossbow im Detail gezeigt wird, wie diese Einhegung des Spielers per Software und Hardware nicht ‚symbolisch‘, sondern real, und nicht ‚ununterbrochen‘, sondern gerade durch subliminale Unterbrechungen realisiert wird, soll ein Einblick in die wesentlichen Technologien der mikrozeitlichen Kontrolle/Überwachung (welche die Kehrseiten der Interaktivität sind) gegeben werden. Auf ihnen basierten und basieren Computerspiele, die sozusagen die Extremfälle der Interaktion darstellen; ist die permanente Einmischung des Nutzers in den Ablauf ihrer Programme und Prozesse doch kein Ausnahme- oder Sonderfall, sondern eben der Zweck der Spiele.

3 Watch Dogs und andere Software-Technologien mikrozeitlicher Kontrolle

Der wesentliche Grund und Vorteil der oben geschilderten solipsistischen Gleichmütigkeit von Computerprozessen liegt in der Geschwindigkeit, mit der diese ausgeführt werden. Obwohl Rechenoperationen auf der Ebene der Digitallogik in die kleinstmöglichen Schritte zerlegt werden, bevor sie ausgeführt werden können, liegen deren Ergebnisse in kürzester Zeit vor. Ein Prozessor wie jener der PDP-1 (1959/60) führte immerhin bereits “100000 operations per second”²⁹ aus, was den Studierenden des MIT die Imple­men­tie­rung des Spiels Spacewar! mit bewegten Grafiken und Interrupt-ge­steuerter Interaktion ermöglichte.³⁰ Die mit 1,19 Megahertz getaktete CPU 6502C (Codename ‚Sally‘³¹) in der Atari 7800 von 1982 arbeitet bereits circa zwölf mal schneller.³²

Die konsequente Serialität von Computerprozessen führt zusammen mit diesen Ausführungsgeschwindigkeiten dazu, dass Prozesse unmerklich ständig (in ‚Schleifen‘) wiederholt werden können. Dazu zählen Programmteile, die Ereignisse überwachen, welche Einfluss auf den Programmablauf nehmen können, oder Prozesse, die über einen längeren Zeitraum ausgeführt werden müssen, um für Menschen und andere Peripheriegeräte kommensurabel zu sein. Die vier folgenden Technologien zur Zeit-Kontrolle und Signalüberwachung sollen am Beispiel der CPU ‚Sally‘ in der Atari-7800-Spiel­konsole erläutert werden, um die nachfolgende materialnahe Diskussion der Software-Prozesse in Crossbow zu ermöglichen.

Abb. 3 Die Platine der Atari 7800³³

3.1 Timer

Eine Warteschleife, die eine Ausgabe auf dem Bildschirm hält, bevor sie gelöscht und durch eine weitere Ausgabe ersetzt wird, muss sich in ihrer Anzeigedauer nach der Wahrnehmungsgeschwindigkeit des Users richten. Hierfür sind oft Zeiträume von mindestens 0,1 bis 1 Sekunde³⁴ zu überbrücken³⁵, in denen die CPU Millionen und Milliarden Takte lang ausharren muss, um Zeit zu verschwenden.³⁶ Um eine Schleife eine festgelegte Dauer laufen zu lassen, bedient sich der Programmierer eines Timers. Dieser kann entweder in das System integriert sein³⁷ oder er muss, wie bei vielen frühen Mikrocomputern nicht unüblich, die Wartezeit selbst aus der Taktgeschwindigkeit des Prozessors und dem Zeitverbrauch der für die Schleife verwendeten Operationen berechnen.³⁸

Zu den für Spiele wichtigsten Timer-Prozessen gehören die direkt von der CPU gesteuerten Ausgaben, wie zum Beispiel die Tonausgabe. Um eine Melodie parallel zu anderen Prozessen ablaufen zu lassen, können eine oder mehrere Adressen im Computerspeicher als Zählerstand für jeden abzuspielenden Ton hinterlegt werden. Während die Hauptschleife des Computerspiels abläuft und alle anderen Spielprozesse ausführt, wird der Inhalt dieser Adresse(n) bei jedem Durchgang verringert und geprüft. Solange er noch nicht bei Null angekommen ist, wird das Unterprogramm zur Tonausgabe immer wieder ‚angesprungen‘ und der Ton weitergespielt. Auf diese Weise kann durch Angabe eines spezifischen Timer-Wertes die Länge der Tonausgabe definiert werden. Dieses Verfahren muss auch bei der Atari-7800-Konsole angewandt werden, da diese noch den Soundchip des Vorgängermodells (TIA) benutzt, der über keinen eigenen Speicher oder DMA-Zu­griff³⁹ verfügt.

Weil die CPU die Hauptschleife allerdings mit sehr hoher Geschwindigkeit durchläuft, fällt es dem Spieler/Hörer nicht auf, dass bei jedem Durchgang der Schleife nur ein Fragment des Tons wiedergegeben wird.⁴⁰ Die Wiedergabe-Zeit ist sogar zu kurz dafür, dass die Membran des Lautsprechers zu schwingen aufhört, bevor der nächste Schleifendurchgang stattfindet. Der physikalische Eindruck eines andauernden Tons kann also allein auf der symbolischen Ebene des Maschinenprogramms als mikrotemporales Stakkato erkannt werden.

Der unten diskutierte Crossbow-Code benutzt einen Timer für die Synchronisation des Kathodenstrahls mit der Schussposition der Light Gun auf den Bildschirm. Zum ‚Zeitvertreib‘ musste der Programmierer dabei zahlreiche NOP-Kommandos in seine Schleife einbauen.

3.2 Watch Dog

Ein Watch Dog (oder auch Watch Dog Timer) ist ein programmierter Prozess, der dazu dient, Systemkomponenten zu überwachen. Reagiert eine Systemkomponente nicht, so kann ein Watch Dog, welcher Time-Outs (Zeitüberschreitungen) überwacht, einen Reset der betreffenden Komponente oder des gesamten System auslösen. Programmiert wird ein solcher Prozess, indem von der zu überwachenden Komponente ein regelmäßiges Signal abgefragt wird. Der Watch-Dog-Timer versucht, dieses Signal innerhalb eines bestimmten Zeitintervalls immer wieder zu lesen. Bleibt es aus, so liegt offensichtlich eine Störung der Komponente vor und es kann zum Beispiel ein Software-Interrupt ausgelöst werden. Solche Überwachungsprozesse werden häufig in Systemen eingesetzt, die mit komplexer (absturzfähiger) Peripherie arbeiten. So kann ein Watch Dog dem Betriebssystem zum Beispiel signalisieren, wenn die Datenübermittlung an einen Drucker (wegen Papierstaus) oder einen Massendatenträger (wegen defekten Datenträgers) ins Stocken gerät und ein Fenster mit einem Fehler-Hinweis öffnen.

3.3 Polling

Als Polling werden kontinuierliche Überwachungsprozesse bezeichnet, bei denen in regelmäßigen Abständen getestet wird, ob von einem Prozess oder einem Gerät neue Daten an die CPU geschickt wurden. Dies ist insbesondere in Systemen sinnvoll, die mit Peripherie arbeiten, welche in unregelmäßigem Abstand Signale an die CPU sendet, dabei aber keine Interrupts auslöst. Würde der Datenkanal dann nicht kontinuierlich abgefragt, so könnten Daten/Informationen verloren gehen. Die Programmierung einer Polling-Über­wa­chung ist vergleichsweise einfach, führt aber dazu, dass Programme langsamer werden, weil sie ständig auch ohne Anlass einen Datenkanal abfragen.

Vor allem einfache Peripheriegeräte wie Joysticks werden über Polling abgefragt. Das hat Tradition in der Computerspielentwicklung, wie Hardy schreibt: “The DEC PDP-1 (1959) had just one interrupt. The interrupt routine had to poll each of the active I/O devices to learn who had pulled the cord.”⁴¹ Die CPU der Atari 7800 kann hingegen nicht direkt auf den Joystick-Port zugreifen, sondern muss das entsprechende Register des zuständigen I/O-Bausteins auslesen. Bei der Atari-7800-Konsole ist hierfür der RIOT-Chip (UM6532) zuständig, der neben RAM (R) und einem Timer (T) eben auch über eine I/O-Verwaltung (IO) verfügt. Da Computerspiele, die mit Joysticks gespielt werden, ihre Input-Daten vor allem über diesen Kanal beziehen, führt das Polling der Joystick-Register selten zu Zeitproblemen. Immerhin ist die Spiel-Software komplett um diesen Steuerungsprozess herum konzipiert worden. In Crossbow ist es der Trigger der Light Gun, der über eine Polling-Routine abgefragt wird. Wurde er gedrückt, so wird die unten vorgestellte ‚GUNXBOW‘-Routine aufgerufen.

4 Low Activation, High Activity: Hardware-Kontrolle via Interrupt

Der bereits mehrfach erwähnte Prozess der Interrupts stellt für Computerspiele eine wichtige Technologie zur Überwachung interner und externer Prozesse zur Verfügung. Er soll für die Atari-7800-Konsole und die in ihr verwendete 6502C-CPU von MOS Technology Inc.⁴² etwas genauer beschrieben werden.

Schaut man sich die Pins des CPU-Bausteins an, entdeckt man dort:

• 16 Adressleitungen (A0–A15),
• acht Datenleitungen (D0–D7),
• zwei Leitungen, die die CPU in den Schreib- oder Lesezustand von/für Speicherinhalte/n versetzen (R/W),
• sechs Leitungen zur zeitlichen Synchronisation von CPU, Prozessen und Bau­steinen (SYNC, RDY, Ø usw.),
• drei Leitungen für die Stromversorgung (zwei VCC⁴³ für +5V und ein V_SS für den Masseanschluss),
• eine HALT-Leitung, mit welcher der Prozessor gestoppt werden kann, wenn der Grafikchip auf den RAM-Speicher zugreift⁴⁴
• und schließlich drei Interrupt-Leitungen (NMI, IRQ und RST).

Abb. 4 MOS 6502C-‚Sally‘-Pinout-Diagramm⁴⁵

Allen Interrupt-Leitungen (und einigen anderen, wie HALT) gemein ist, dass sie Active Low sind, was an den Querstrichen oberhalb der Pin-Bezeich­nun­gen ablesbar ist. Das bedeutet, dass diese Leitungen im Normalzustand (wenn also kein Interrupt-Signal anliegt) die Systemspannung von 5 Volt führen. Kommt es zu einem Interrupt, dann werden sie auf 0 Volt gezogen – Active Low heißt also, dass der Abfall der Spannung ein Ereignis signalisiert. Dieses auf den ersten Blick ungewöhnlich anmutende Verfahren erklärt sich daraus, dass auf diese Weise versehentliche Interrupts durch Spannungsfluktuationen (etwa durch elektromagnetische Felder oder eine statische Ent­ladung) vermieden werden können, denn liegt eine Spannung auf der Leitung, bedeutet das ja, dass keine Unterbrechung erfolgt.

4.1 Nicht maskierbare Interrupts (NMI)

Es gibt Prozesse, die Interrupts auslösen, welche besonders wichtig für die Funktion des Systems sind, sodass die CPU sie nicht ignorieren darf. Diese Interrupts können nicht ‚maskiert‘ werden und laufen über die NMI-Leitung (Pin 6) in die CPU. Abhängig vom spezifischen System sind unterschiedliche Systemkomponenten mit der NMI-Leitung verbunden. Beim Homecomputer Atari 800 XL, der ebenfalls auf der CPU ‚Sally‘ basiert, wird ein nicht-maskierbarer Interrupt durch den Grafik-Chip ANTIC ausgelöst, a) bei einem Display List Interrupt und b) bei einem Vertical Blank Interrupt. Ersterer tritt auf, wenn der Kathodenstrahl des Monitors eine Bildzeile gezeichnet hat und danach abgeschaltet wird, um zum linken Bildrand zurückzukehren, damit die nächste Zeile gezeichnet werden kann. Der zweite tritt auf, wenn der Kathodenstrahl des Monitors ein Bild vollständig aufgebaut hat und ab­geschaltet wird, damit der Strahl zurück zur oberen linken Bildecke geleitet wird, um das nächste Bild zu zeichnen. Der Computer registriert diese Ereignisse nur indirekt, weil er mit dem Videosignal zusammen ein Synchronisationssignal an den Monitor abgibt, das dieser dazu verwendet, den Kathodenstrahl zu positionieren. Diese beiden Interrupt-Signale erreichen die CPU mit hoher Geschwindigkeit.⁴⁶ In beiden Fällen hat das System einige Mikro­sekunden lang Zeit, Programmroutinen auszuführen. Diese Zeiten werden von Programmierern genutzt, um spezifische Grafikeffekte zu generieren (zum Beispiel sehr feines vertikales Scrolling), die so ‚zwischen den Zeilen‘ stattfinden können. Zusätzlich inkrementiert der Vertical Blank Interrupt auch die interne Systemuhr, da er genau 50-mal pro Sekunde auftritt. Die interne Zeit des Systems basiert also auf dem Videobild.

4.2 Interrupt Request (IRQ)

Die IRQ-Leitung (Pin 4) leitet Hardware-Interrupts, die vom Programmierer maskiert werden können, in die CPU. Solche Signale stellen zumeist ‚Service-Informationen‘ der Peripherie-Bausteine dar. Hierzu gehört bei 8-Bit-Atari-Computern zum Beispiel die Tastatur, die ein IRQ an die CPU schickt, sobald eine Taste gedrückt wurde, oder der serielle I/O-Port, der auf diese Weise meldet, wenn Daten empfangen werden.

4.3 Reset (RST)

Dieses Interrupt-Signal besitzt die höchste Priorität, denn, wenn es (an Pin 40) anliegt, wird die CPU ‚Sally‘ in den Einschaltzustand zurückgesetzt (resettet). Manuell kann dieser Prozess ausgelöst werden, wenn ein Programm abgestürzt ist (dann setzt beispielsweise eine Reset-Taste am Computer die RESET-Leitung auf 0 Volt). In der Regel ist der Reset-Interrupt aber für den korrekten Systemstart verantwortlich: Wird der Computer eingeschaltet, wird diese Interrupt-Leitung erst kurze Zeit später auf high geschaltet. Das führt dazu, dass eine spezifische Startup-Service-Routine aufgerufen wird (um etwa das BIOS zu laden).

4.4 Software-Interrupts

Nicht nur mittels Hardware-Komponenten, auch mittels Software lassen sich Interrupts auslösen. Diese laufen dann natürlich nicht über eine Hardwareschnittstelle in die CPU. Die CPU ‚Sally‘ verfügt über einen Software-Inter­rupt, der die niedrigste Priorität besitzt. Dieser kann durch den Programmierer mittels eines spezifischen Befehls (BRK) in sein Programm eingebaut werden. Die CPU verhält sich beim Erreichen eines BRK-Befehls dann so wie bei einem Hardware-Interrupt. Das heißt, verschiedene Sicherungsprozeduren werden ausgeführt und eine besondere Adresse wird automatisch angesprungen.

Software-Interrupts helfen dem Spielprogrammier bei der Entwicklung der Software. Um den korrekten Ablauf oder Probleme in einer Routine erkennen zu können, ist es sinnvoll, diese im Testlauf (Debugging) mit BRK zu unterbrechen und in ein Test-Unterprogramm zu springen, das bestimmte Werte anzeigt. Pseudo-Software-Interrupts sind auch häufig in höheren Programmiersprachen von 8-Bit-Systemen implementiert.⁴⁷ Sie ermöglichen dem Programmierer, automatische Abläufe (etwa zeitlich exakt wiederkehrende Ereignisse) in seine Programme zu integrieren.

4.5 Interrupt-Service-Routinen (ISR)

Sobald ein Interrupt-Signal an einem der CPU-Pins anliegt oder ein Software-Interrupt ausgeführt wird, finden automatische Prozesse statt:

1. Maskierbare Interrupts werden maskiert, um die Abarbeitung wichtiger(er) Interrupts nicht zu stören.
2. Der von der CPU gerade bearbeitete Befehl wird zu Ende ausgeführt.
3. Die Adresse, die sich gerade im Programmzähler-Register befindet (welche auf die Stelle hinweist, wo das aktuelle Programm fortgesetzt werden soll), die Register-Inhalte sowie der Inhalt des Statusregisters werden auf einem Stapel-Speicher gesichert.
4. Je nach Interrupt-Art und -Herkunft wird nun eine Prozessor-spezifische Adresse in den Programmzähler geschrieben (siehe unten).
5. Die CPU arbeitet die Befehle, die an dieser Adresse liegen (zumeist sind das Sprünge in eine Interrupt-Serviceroutine, ISR), ab.
6. Nach Ausführung der ISR werden die Register-Inhalte vom Stapelspeicher zurück in die jeweiligen Register geschrieben.
7. Interrupts werden wieder aktiviert.
8. Das ursprüngliche Programm wird fortgesetzt.

Zu jeder Interrupt-Art gehören Sprungvektoren. Das sind Adressen, die von der CPU angesteuert werden, wenn ein Interrupt auftritt. Tritt beispielsweise ein NMI-Interrupt auf, so wird die Speicheradresse FFFA_HEX in den Programmzähler gelegt und die CPU führt als nächstes den Befehl aus, der in dieser Speicherstelle abgelegt wurde. Welcher Befehl das ist, bestimmt (außer beim Reset-Vektor) immer der Programmierer. Weil jeweils nur zwei Adressen pro Interrupt zur Verfügung stehen (NMI: FFFA_HEX und FFFB_HEX), befinden sich in diesen Adressen meistens eine weitere Sprunganweisung (Adresse 1) und die Adresse, zu der gesprungen werden soll (Adresse 2). Dieser zweite Sprung führt in die eigentliche ISR, die komplexere Programmanweisungen enthalten kann. Hier kann dann zum Beispiel geprüft werden, was genau den Interrupt ausgelöst hat.

Ob ein maskierbarer Interrupt ausgeführt werden muss oder ignoriert werden kann und welche Vorkehrungen vor der Ausführung von ISRs zu treffen sind, kann der Programmierer durch Setzen spezifischer Bits im Statusregister einstellen. In diesem Prozessor-internen Speicher werden wichtige Ereignisse von Maschinensprache-Operationen registriert. Das Status­register enthält zwei Bits, die für das Interrupt Handling wichtig sind: Zum einen Bit 2 („Interrupt Disable“); wird dieses Bit mit dem Befehl SEI ausgeführt, kann man IRQ-Interrupts maskieren, mit CLI lässt sich diese Maskierung wieder aufheben. Zum anderen das Bit 4 („Break Flag“), das anzeigt, ob ein Interrupt durch BRK ausgelöst wurde, denn (wie auch die 6502) ‚Sally‘ springt für Software- und IRQ-Interrupts dieselben Sprungvektoren (FFFE_HEX/ FFFF_HEX) an.

Der in der o. g. Auflistung genannte Punkt 6, das Ende der ISR, ist dann erreicht, wenn am Ende der ISR der Befehl RTI („Return from Interrupt“) auftritt. Dieser sorgt dafür, dass alle auf dem Stapelspeicher gesicherten Prozessor-Inhalte wieder in diesen zurückgeschrieben werden und das eigent­liche Programm an der letzten Stelle vor dem Interrupt fortgesetzt wird.

5 Shooting-Accessoire

Wie aus den vorangegangenen Darstellungen von Hardware- und Software-Kontrollverfahren ersichtlich ist, muss ein Computerspiel wie Crossbow, das über komplexe Funktionen wie Grafikgenerierung, Sprite-Verwaltung, Soundwiedergabe im Hintergrund, Überwachung der Spielregeln, Verwaltung der „extra-diegetischen Interfaces“⁴⁸ (Punktestand) und nicht zuletzt die Abfrage der Spielsteuerung (Funktionstasten an der Konsole, Controller-Ereignisse) verfügt, zahlreiche Mechanismen der Überwachung, Kontrolle und Zeitsteuerung enthalten. Es kann angesichts des mehrere zehntausend Zeilen langen Spielcodes an dieser Stelle nicht die Aufgabe sein, all diese vorzustellen. Herausgegriffen werden soll anstelle dessen einer von ihnen: die Abfrage der Light Gun.

5.1 Light Guns

Light Guns und mit ihnen verwandte Controller (Light Pens) stellen die älteste Form interaktiver Eingabegeräte dar. Ihren ersten Einsatz fand eine Light Gun im Computer ‚Whirlwind‘ (ab 1951), der in einem Telefon-vermittelten Netzwerk zur Überwachung des gesamten US-amerikanischen Luftraums eingesetzt wurde.

Abb. 5 Light Gun am Whirlwind-Computer⁴⁹

At its heart the light gun contained a photomultiplier tube mounted in a gun-like enclosure which could be pointed with its photosensitive end to an arbitrary point on an oscilloscope’s screen. By pushing a trigger button the computer was informed that the light gun had been pointed to a particularly interesting structure on the display. The output of the photomultiplier tube controlled a particular bit in one of Whirlwind’s flip-flop registers, which was accordingly set when the selected screen area was illuminated by the electron beam of the oscilloscope. So all the software had to do was checking for such a set bit after displaying a point, character or vector.⁵⁰

Die Technologie steht also nicht nur in einem motivischen Zusammenhang mit der Verteidigung, sondern auch in einem engen technikhistorischen Zusammenhang mit der Überwachung – was beides, wie sich zeigen soll, sowohl technologisch als auch epistemologisch begründet ist.

Auch für elektronische Spiele stellen Light Guns die frühesten Zusatz-Controller dar. Die Konsole ‚Odyssey‘, die die Firma Magnavox und ihr Entwickler Ralph Baer 1972 auf den Markt brachten, verfügte neben den eingebauten Drehreglern über einen ‚Accessory‘-Anschluss (ACC), an welchem ab 1973 ein unter dem Titel ‚Shooting Galery‘ erhältliches Light Rifle angeschlossen werden konnte. Damit ließen sich Abschieß-Spiele auf der Odyssey spielen. Dass dieses ‚Accessoir‘ keineswegs nachträglich, sondern sogar zeitgleich mit dem Prototypen (‚Brown Box‘) der Spielkonsole entwickelt wurde,⁵¹ erklärt Ralph Baer damit, dass er die Hardware als Angestellter beim Rüstungskonzern Sanders Associates entwickelte und seinen Vorgesetzten einen militärischen Zweck vorgaukeln musste. Der Einsatz der Light Rifle als Device für Zielübungen klang als Begründung offenbar plausibel.⁵²

Abb. 6 ‚Brown Box‘ mit Rifle⁵³

5.2 Die Technik der Light Gun

Von den späten 1970er- bis Mitte der 1980er-Jahre waren Light Guns häufig anzutreffende Eingabegeräte an Computerspielen, Spielkonsolen und Arca­de-Automaten. Es gab sie von zahlreichen Herstellern in unterschiedlichsten Ausführungen – mal als Pistole, mal als Gewehr oder eben in Armbrust-Form mit mehr oder weniger großer Ähnlichkeit zu richtigen Waffen.⁵⁴

Abb. 7 Geöffnete Light Gun⁵⁵

Unterscheiden sich diese Geräte äußerlich sehr stark voneinander, so ist ihr technischer Aufbau stets derselbe: Das Kernstück der Light Gun ist eine
fotosensitive Diode, die hinter einer kleinen Linse montiert ist. Diese Diode funktioniert wie ein „Licht-Schalter“,⁵⁶ der offen ist, solange kein Licht auf die Diode fällt, und sich schließt, sobald dort Licht auftritt. In diesem Stromkreis befindet sich aber noch ein zweiter Schalter: der Trigger der Pistole. Nur wenn dieser gedrückt ist und gleichzeitig die Diode durch Lichteinfall nicht mehr sperrt, dann wird ein Stromimpuls über das Controller-Kabel an den Port des Systems weitergegeben. Die Gleichzeitigkeit dieser Ereignisse wird durch einen Logik-Baustein überwacht, der beide Signale als Eingang in ein AND-Gatter speist.⁵⁷Die Light Gun ist also ein Licht-Sensor. Sie ist so eingerichtet, dass der Lichtimpuls eine Mindestmenge Photonen enthalten muss, damit sie schaltet. Dieser Lichtimpuls stammt von der Bildröhre des Monitors, auf den gezielt wird. Beim Aufbau eines Bildes in einem Kathodenstrahl-Monitor oder -Fernseher wandert ein Elektronenstrahl die Innenseite des Bildschirms Zeile für Zeile von rechts nach links und von oben nach unten ab. Gelenkt wird er hierbei durch Elektromagneten, die im hinteren Teil des Monitors um die Bildröhre platziert wurden und ihr Magnetfeld so variieren, dass sie den Elektronenstrahl unterschiedlich stark in unterschiedliche Richtungen ablenken können. Trifft der Elektronenstrahl auf die Innenseite der Bildschirm-Mattscheibe, so regt er ein dort befindliches Farbpigment (das zwar nicht aus Phosphor besteht, aber oft so bezeichnet wird) an. Wenn sich dieses Pigment kurze Zeit später wieder ‚abregt‘, gibt es ein Lichtquant ab, dessen Wellenlänge (Farbe) von seiner chemischen Beschaffenheit abhängt. Dieses Photon durchdringt die Mattscheibe und wird für uns als Bildpunkt sichtbar. Die Abregung des Farbpigments findet allerdings nicht instantan statt; vielmehr blitzt es zunächst stark auf und verliert dann langsam an Leuchtkraft. Dieses Nachleuchten ist für unseren Eindruck eines stehenden Bildes wichtig;⁵⁸ der anfängliche Lichtblitz hat jedoch genug Ener­gie und Leuchtdauer, um jene Fotodiode in der Light Gun anzuregen.

Wie oben ausgeführt, findet der Bildaufbau auf einem solchen Monitor in sehr großer Geschwindigkeit statt. Allerdings ist er trotzdem noch um ein Vielfaches langsamer als die Taktung eines Computers. Deshalb kann dieser durch die Synchronisationssignale seines Grafikprozessors stets ‚wissen‘, wo sich der Kathodenstrahl gerade befindet, und diese Position in Bezug zur Koordinate eines Pixels auf dem Bildschirm setzen. Das erklärt, warum der Computer den Ort, auf den mit der Light Gun gezielt und ,geschossen‘ wird, innerhalb seiner Grafik identifizieren und dort grafische Veränderungen (z. B. einen Projektileinschlag) generieren kann.

Abb. 8 Screenshot Crossbow mit ‚Eye in the Sky‘ und Projektileinschlag (‚splat‘ – rot eingekreist) durch Light-Gun-Beschuss.⁵⁹

6 Die Light-Gun-Software von Crossbow

Crossbow kann auf der Version für die Atari 7800 wahlweise mit Joystick oder mit Light Gun gespielt werden. Für letztere Steuerungsoption hat der Programmierer Dave Staugas die „7800 Crossbow Lite Gun Routine“ programmiert, die 512 Byte im Gesamtcode belegt. Sie befindet sich in der vierten Speicherbank ab Adresse 4D00_HEX⁶⁰ und heißt „GUNXBOW“ (Z. 18). Zum Verständnis dieser Routine ist es sinnvoll, sie in ‚Sinneinheiten‘ aufzuteilen, die sich an den Labels⁶¹ orientieren.

.dogun: Die Hauptroutine prüft zunächst, ob die Schussroutine überhaupt durchlaufen werden muss. Dies ist nur dann der Fall, wenn a) nicht bereits eine Schussroutine ausgeführt wird (dann ist das Bit S_STOPPED⁶² in der Adresse movsta+N_CURSOR auf 1 gesetzt, (Z 22–24)), b) die Light Gun überhaupt auf den Bildschirm zielt (was in der Adresse/Variable SCWP registriert ist, (Z. 26–27)) und c) der Trigger an der Light Gun gedrückt wurde (was in der Adresse SWCHA registriert wird, (Z. 29–31)). Falls einer dieser Zustände nicht zutrifft, wird dies durch Einlesen eines FALSE-Wertes in das Akkumulator-Register vermerkt und die Schuss-Routine über den Exit bei .notfire (Z. 33–35) verlassen.

.doshot: Andernfalls wird diese Routine ausgeführt, welche den Schuss auslöst. Hierzu wird die CPU ‚Sally‘ zunächst angehalten (was durch ein Signal auf der HALT-Leitung möglich ist (Z. 39–45)), um den Grafikprozessor ‚Maria‘ mit höherer Taktung (s. Fußn. 48) nutzen zu können. Dies geschieht, während der Kathodenstrahl im Vertical Blank abgeschaltet ist (s. Abschn. 4.1), denn das System sendet dann ein Signal zur vertikalen Synchronisierung und kann danach die Position des Kathodenstrahls und die des Grafik­objektes, auf das mit der Light Gun geschossen wurde, verlässlich mitein­ander korrelieren. Den ‚Startschuss‘ für diese Ermittlung gibt der durch Register WSYNC (wait for synch) des Grafikchips ausgelöste NMI-Interrupt, auf das gewartet wird (Z. 52–55; 273–279). Nach dem Vertical Blank wird der Bildschirminhalt mit der Farbe e_HEX (Weiß) gefüllt (Z. 57–59), um einen kurzfristigen intensiven Lichtimpuls vom Monitor in Richtung Light Gun abzugeben, sodass die darin befindliche Photodiode auslöst, egal welche Farbe das anvisierte Objekt hat(te).

.doklop2: In dieser Routine wird schließlich ermittelt, wohin genau die Light Gun gezielt hat. Hierzu werden im X-Register die Zeilen mitgezählt. Die Zahlen hinter den XX sind die dabei abgelaufenen Taktzyklen vom Grafikprozessor ‚Maria‘. In das 7. Bit der Adresse GUNBIT wird nun der Wert aus der Adresse INPT4 eingelesen (Z. 61), der 0 ist, wenn der Trigger der Light Gun gedrückt wurde (andernfalls 1). Im X-Register befindet sich dann die aktuelle Zeile des Kathodenstrahls / die Y-Position der Light Gun. Die Abfrage der Spalte ist etwas diffiziler, weil sie nicht mehr technisch, sondern nur noch mathematisch ermittelt werden kann, indem der Taktverbrauch während eines Zeilenaufbaus mitgezählt wird (insg. 115 Takte pro Zeile). Bei einem erfolgten Schuss wird die Position des Kathodenstrahls innerhalb dieser Prozedur mit der Adresse des anvisierten Grafik-Elementes verglichen und dies in den Adressen movx und movy gespeichert (Z. 204–233). All dies geschieht noch, während der Bildschirm mit der Farbe Weiß gefüllt ist (siehe .doshot). Erreicht der Kathodenstrahl die Position, auf welche die Light Gun gerichtet ist und ist deren Trigger gedrückt, wird ein Impuls an den Controller-Port gegeben und das System registriert durch den nächsten Display List Interrupt, welche Position auf dem Bildschirm beschossen wurde. Diese Information wird in movx und movy gespeichert und die Light-Gun-Routine verlassen.

In einem anderen Programmteil wird danach getestet, ob sich ein ‚Feind‘, ein ‚Freund‘ oder nichts dergleichen an der anvisierten Stelle befand, und es wird eine Grafik-Routine ausgelöst, die den Projektil-Einschlag animiert. Ich habe hier nicht jedes Detail der Light-Gun-Routine diskutiert, sondern mich auf diejenigen Elemente konzentriert, die für das Überwachungs-Dispositiv des Spiels bedeutsam sind. Interessant wäre es darüber hinaus, die Analyse der zeitkritischen Programmierung der Positionsdetektion in .doklop2 (Z. 77 bis 222) zu untersuchen. Wie sich anhand der zahlreichen Bedingungsprüfungen und NOP-Befehle zeigt, muss der Programmierer die zeitbasierte Hardwarefunktion des Grafikchips genau mit seinem Programm synchronisieren.⁶³

7 Schluss: Überwachen und Strafen

Die Beschreibung der Hardware-Funktionen der Atari 7800 sowie die Code-Analyse des Spiels Crossbow sollte zeigen, welche Mechanismen ein Computersystem benutzt, um seine Peripherien zu überwachen. Die zentralen Einrichtungen hierfür sind die permanente Kontrolle (Watch Dogs, Timer, Polling) und die Unterbrechung (Interrupts). Dass gerade letztere in engem Zusammenhang mit ‚höher gelagerten‘ Formen der Überwachung stehen, diskutiert Simon Yull in seinem Interrupt-Eintrag des Software-Studies-Lexikons: Mit der Benutzung eines Keyboards gerate der User bereits in den „operational space“⁶⁴ des Systems. Dies geschehe aber auch, wenn ein RFID-Device in die Nähe eines Aktivators/Detektors gerate – nur eben, ohne dass der Nutzer es weiß. Bei Annäherung löst er dann ein Interrupt-Signal im System aus. Derartig versteckte Interrupt-Generatoren sieht Yull auch in anderen Überwachungssystemen wirksam:

The CCTV system of a bank, office, or housing estate may be linked up to movement analysis tools, seeking to detect a possible hold-up scenario, or irregular movement patterns among the building’s occupants. The introduction of chip-carrying biometric identity cards, as is currently planned in the United Kingdom, may bring with it the ability to cross-reference these cards and the readings of CCTV facial analysis systems, linking the interruptions of human activity in urban space to singular identities, just as logging onto a computer links the interrupts of keyboard and mouse to a particular username.⁶⁵

Was hat nun ein Spiel wie Crossbow mit der RFID-Technologie und Gesichtserkennung zu tun, außer, dass sie alle Interrupts verwenden, um das System auf den User (der seine Peripherie benutzt) aufmerksam zu machen? RFID beruht darauf, dass das Überwachungssystem den RFID-Transponder durch ein Kopplungselement aktiviert, sobald er in dessen Nähe kommt. So verhält es sich aber auch bei der Light Gun: Durch das Drücken des Triggers löst der User keineswegs einen Schuss aus, vielmehr verifiziert er damit den Start des Überwachungsmechanismus, indem er einen von zwei Schaltern schließt. Der erste Schalter wurde bereits durch das System geschlossen, indem es auf dem Monitor einen Lichtblitz emittierte. Dieser Blitz wurde dazu benutzt, den Lichtsensor in der Light Gun zu affizieren, um die Aktivität des Nutzers zu ‚fotografieren‘. So trivial es klingt: Nicht der User schießt auf den Bildschirm, es ist der Bildschirm, welcher auf den User schießt – und zwar Photonen mit möglichst großer Streuung, damit er ihn (bzw. den Lichtsensor in seiner Hand) auch auf jeden Fall trifft. Auf diese Weise überwacht das Spiel die Positionierung des Spielers vor dem Monitor.

Möglich ist dies nur, weil er als „Man in the Loop“⁶⁶ zu einer „Gestalt der Anschlüsse“ wurde, wie Pias schreibt. Das kann er aber nur deshalb werden, weil sein (in zeitkritischer Hinsicht) ‚grobschlächtiges‘ Verhalten in das mi­krotemporale Gefüge des Systems eingebunden wurde – und zwar dadurch, dass es in winzige Zeitabschnitte ‚zerstückelt‘ (diskretisiert/digitalisiert) wurde. Das Crossbow-Spiel hält hierfür einige Zusatztechnologien bereit, die das dabei entstehende ‚Rauschen‘ (in Form von Zittern des Fingers am Trigger oder des Schwankens der Waffe) minimieren: Der Schalter hinter dem Trigger wird softwareseitig entprellt⁶⁷; ein Schuss-Ereignis muss erst zu Ende ausgeführt werden, bevor das nächste stattfinden kann. Halbautomatisches Schießen ist so weder intendiert noch unintendiert möglich. Zusätzlich überprüft die Software in Hinblick auf die Ziel-Toleranz nicht bloß ein anvisiertes Pixel, sondern auch dessen Umgebung daraufhin, ob sich dort ein ‚Feind‘, ein ‚Freund‘ oder bloß die unparteiische Natur befindet. Das Verhalten des Spielers von Crossbow steht also angefangen bei seinen Muskelzuckungen bis hin zu seinen bewussten Entscheidungen und Handlungen unter mikrozeitlicher Registratur des Systems.

Abb. 9 Don’t shoot your friends!⁶⁸

Das Spiel überwacht den Spieler aber auch auf der Makroebene, indem es prüft, ob er sich systemkonform verhält und die Spielregeln beachtet: Auf ‚Feinde‘ soll man schießen, das Beschießen eines ‚Freundes‘ hingegen löst (in der Arcade-Version) einen Schrei und die Mitteilung „DON’T SHOOT YOUR FRIENDS!“ aus. Beim zweiten Vorfall von friendly fire wird der ‚Freund‘ sofort vom Bildschirm eliminiert. Crossbow verhandelt das Überwachungsmotiv (in seinem allgemeinen kulturellen Verständnis) auf seiner Oberfläche und integriert es gleichzeitig in einem konkret-technologischen Verständnis auf seiner Unterfläche. Es zeigt sich damit als ‚selbstreflexives‘ Spiel, was allerdings voraussetzt, dass man seine Unterflächen – die Schaltungen, Codes und mikrotemporalen Operationen – als Technologien und Episteme in diese Interpretation einbezieht (was ein zentrales Anliegen computer(spiel)archäologischer Forschung ist).

Angesichts all dieser Überwachungsmechanismen kann man schnell zu der Überzeugung gelangen, dass der Mensch dort ganz unfrei ist, wo er spielt. Huzingas „magic circle“⁶⁹ erweist sich computerarchäologisch betrachtet nämlich als ein wahrhaftiges Panoptikum: Eingefügt in das technische Dispositiv des Computer(spiel[en])s, dessen Regelwerk und Anforderungen er für ein gelingendes Spiel erfüllen will und zu erfüllen hat, wird der Spieler selbst zur Peripherie. Er besitzt im Umgang mit dem System nur scheinbar die Freiheit, das zu tun und zu lassen, was er will, und er nimmt in Crossbow auch nur scheinbar die sichere Distanz eines Heckenschützen ein. Die Technologie der Light Gun verschiebt diese Unfreiheit bis zur Kenntlichkeit auf die Spiel-Oberfläche: Der Computer schießt Photonen auf den Spieler, um zu kontrollieren, ob er noch in the loop ist.

Medienverzeichnis

Atari Mania: Crossbow (400/800). o. J. a <http://www.atarimania.com/game-atari-400-800-xl-xe-crossbow_1416.html> [23.10.2019]

Atari Mania: Crossbow (2600). o. J. b <http://www.atarimania.com/game-atari-2600-vcs-crossbow_7269.html> [23.10.2019]

Atari Museum: Atari 7800. Technical documents. o. J. a <http://www.atarimuse­um.com/ahs_ar­chives/archives/archives-techdocs-7800.htm> [23.10.2019]

Atari Museum: The Atari 7800 ProSystem. o. J. b <http://www.atari­museum.com/vi­deo­games/consoles/7800/7800menu/> [23.10.2019]

Baer, Ralph H.: Videogames: In The Beginning. Springfield: Rolenta Press 2005.

Burstyn, Walther: Elektrische Kontakte und Schaltvorgänge. Grundlagen für den Praktiker. Berlin, Göttingen, Heidelberg: Springer 1956.

Coy, Wolfgang: Unsichtbar wird der Fehler, wenn sich alle daran gewöhnt haben. In: Kassung, Christian (Hg.): Die Unordnung der Dinge. Eine Wissens- und Mediengeschichte des Unfalls. Bielefeld: transcript 2009, S. 325–353.

Dijkstra, Edsger W.: My recollections of operating system design. 2000 <https:// www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/EWD1303.html> [23.10.2019]

Exidy: Werbeflyer „Crossbow“. 1983. <https://flyers.arcade-museum.com/?page= thumbs&db=videodb&id=253> [23.10.2019]

Fischer, Othmar: Mikroprozessoren für Anfänger. Programmieren leicht und schnell erlernbar. Wien, München: Oldenbourg 1982.

Hardy, Norman: History of Interrupts. 2002. In: <http://www.cap-lore.com/Hard­ware/int.html> [23.10.2019]

Havel, John: Exidy 440 Repair Logs. 2016. <http://www.screenburnarca­de.com/Re­pair%20Logs/Exidy%20440/Exidy440_Repair_Log.php> [23.10.2019]

History-Computer: PDP-1. o. J. <https://history-computer.com/ModernCompu­ter/ Elec­tronic/PDP-1.html> [23.10.2019]

Höltgen, Stefan: „All Watched Over by Machines of Loving Grace“ – Öffentliche Erinnerung, demokratische Informationen und restriktive Technologien am Beispiel der „Community Memory“. In: Reichert, Ramón (Hg.): Big Data. Analysen zum digitalen Wandel von Wissen, Macht und Ökonomie. Bielefeld: transcript 2014, S. 385–404.

Höltgen, Stefan: JUMPs durch exotische Zonen. Portale , Hyperräume und Teleportationen in Computern und Computerspielen. In: Hensel, Thomas; Neitzel, Britta; Nohr, Rolf F. (Hg.): „The Cake is a Lie“. Polyperspektivische Betrachtungen des Computerspiels am Beispiel von „Portal“. Münster: LIT 2017, S. 107–134.

Höltgen, Stefan: Logik für Medienwissenschaftler. In: Ders. (Hg.): Medientechnisches Wissen, Bd. 1. Berlin, Boston: De Gruyter 2017, S. 14–149.

Huizinga, Johan: Homo Ludens. A Study Of The Play-Element In Culture. London, Boston, Henley: Routledge & Kegan Paul 1944.

Jindroush: 6502C. 2004a <https://www.atarimax.com/jindroush.atari.org/7800c­cpu.html> [23.10.2019]

Jindroush: Sally. 2004b <https://www.atarimax.com/jindroush.ata­ri.org/ach­sally.html> [23.10.2019]

JonnieCache: Spacewar PDP1 Source Code. 2012 <https://gist.github.com/Jon­nieCache/4258114> [23.10.2019]

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

McMahon, John: Atari 7800/Crossbow/C. 2012. <https://github.com/Open­Sour­ced­Games/Atari-7800/tree/master/CROSSBOW/C> [23.10.2019] (!)

Moby Games: Crossbow (Commodore 64). o. J. <https://www.mobygames.com/ga­me/c64/crossbow> [23.10.2019]

Moll, Sven Oliver: Bouncing on the Beam. Demo-Hacking des Atari VCS/2600 – Ein Werkstatt-Bericht. In: Höltgen, Stefan (Hg.): SHIFT – RESTORE – ESCAPE. Retrocomputing und Computerarchäologie. Winnenden: CSW 2014, S. 65–80.

Montfort, Nick; Bogost, Ian: Racing the Beam. The Atari Video Computer System. Cambridge, London: MIT Press 2009.

Nake, Frieder: Das doppelte Bild. In: Pratschke, Margarete (Hg.): Bildwelten des Wissens. Kunsthistorisches Jahrbuch für Bildkritik, Bd. 3,2: Digitale Form. Berlin: Akademie-Verlag 2005, S. 40–50.

National Museum of American History: The Brown Box Lightgun, 1967–68. o. J. <https://americanhistory.si.edu/collections/search/object/nmah_1302000> [23.10.2019]

o. A.: Photodiode. 1998. In: Spektrum.de: Lexikon der Physik. <https://www.spektrum.de/lexikon/physik/photodiode/11179> [23.10.2019]

Pias, Claus: Die Pflichten des Spielers. Der User als Gestalt der Anschlüsse. In: Warnke, Martin; Coy, Wolfgang; Tholen, Georg-Christoph (Hg.): HyperKult II. Zur Ortsbestimmung analoger und digitaler Medien. Bielefeld: transcript 2005,
S. 313–342.

RetroGames: Crossbow: The Legend of William Tell – Atari 7800. o. J. <https:// www.retrogames.cz/play_880-Atari7800.php> [23.10.2019]

Schemer-Reinhard, Timo: Interface. In: Beil, Benjamin; Hensel, Thomas; Rauscher, Andreas (Hg.): Game Studies. Wiesbaden: Springer VS 2018, S. 155–172.

Schöler, Thorsten: Informatik für Medienwissenschaftler. In: Höltgen, Stefan (Hg.): Medientechnisches Wissen, Bd. 2. Berlin, Boston: De Gruyter 2018, S. 7-130.

Smotherman, Mark: Interrupts. 2017. In: <https://people.cs.clemson.edu/~mark/ in­terrupts.html> [23.10.2019]

System 16. The Arcade Museum: EXIDY 440 SYSTEM HARDWARE. 2014 <https:// www.system16.com/hardware.php?id=994&page=1#19349>

tom’s Hardware: Exidy 440 survey. 2005 <https://forums.tomshard­ware.com/ threads/exidy-440-survey.126670/#post-1443098> [23.10.2019]

Ullmann, Bernd: AN/FSQ-7: The Computer that shaped the Cold War. Boston, Berlin: De Gruyter 2015.

Ullmann, Bernd: Man in the Loop. Zeitaspekte in analogen Simulationen und Spielen. In: Höltgen, Stefan; van Treeck, Jan Claas (Hg.): Time to Play. Zeit im Computerspiel. Glückstadt: Verlag Werner Hülsbusch 2016, S. 85–119.

UMC: UM6532/A. RAM, I/O, Timer Array. o. J. <http://elektronikjk.pl/ele­men­ty_czynne/IC/UM6532.pdf> [23.10.2019]

Yull, Simon: Interrupt. In: Fuller, Mathew (Hg.): Software Studies. A Lexicon. Boston: MIT Press 2008, S. 161–167.

1. Havel: 440 Exidy Repair Logs. 2016[↩]
2. System 16: Exidy 440 System Hardware. 2014[↩]
3. Tom’s Hardware: Exidy 440 survey. 2005[↩]
4. Moby Games: Crossbow. o. J.[↩]
5. Atari Mania: Crossbow. o. J.a.[↩]
6. RetroGames: Crossbow. o. J.[↩]
7. Atari Mania: Crossbow. o. J.b.[↩]
8. Mein Beitrag verwendet das generische Maskulinum und meint damit alle Geschlechter.[↩]
9. Nake: Das doppelte Bild. 2005, S. 47, 49[↩]
10. Pias: Die Pflichten des Spielers. 2005, S. 314[↩]
11. wie sie sich auch in anderen Überwachungstechnologien zeigen – etwa Bewegungsmeldern und Sensoren[↩]
12. Jüngst sind zu dieser Spielkonsole die Entwurfsschaltpläne wieder aufgetaucht (vgl. Atari Museum: 7800 ProSystem. o. J.b).[↩]
13. Atari Museum: Atari 7800. o. J.a.[↩]
14. McMahon: Atari 7800. 2012[↩]
15. Vgl. Höltgen: All watched over. 2014, S. 396–400.[↩]
16. Vgl. Schöler: Informatik. 2018, S. 33 f.[↩]
17. Vgl. ebd., S. 24–27.[↩]
18.  Bei der Harvard-Architektur, die beispielsweise dem Arduino-Einplatinencomputer zugrunde liegt, sind Daten- und Programmspeicher voneinander getrennt (vgl. ebd., S. 34).[↩]
19. Vgl. Höltgen: JUMPs. 2015.[↩]
20. Vgl. Coy: Unsichtbar. 2009, S. 6.[↩]
21. Hardy: History of Interrupts. 2002; Smotherman: Interrupts. 2017[↩]
22. Vgl. Levy: Hackers. 1984, S. 26–36.[↩]
23. Dabei wurden Programme vom Studenten manuell auf Lochkarten gestanzt, um sie dann stapelweise (‚batch‘) einem Operator zu übergeben, der sie dann in den Computer eingab, welcher sie dann abarbeitete, um dem Operator schließlich ein Ergebnis oder eine Fehlerausgabe zu präsentieren, die dieser an den Studenten weiterreichte (vgl. ebd., S. 13).[↩]
24. Ebd., S. 8.[↩]
25. Vgl. ebd., S. 109 ff.[↩]
26. Dijkstra: My recollection. 2000[↩]
27. ebd.: 13[↩]
28. Pias: Die Pflichten des Spielers. 2005, S. 337[↩]
29. History-Computer: PDP-1. o. J.[↩]
30. Vgl. Levy: Hackers. 1984, S. 42 ff.[↩]
31. Jindroush: Sally. 2004b[↩]
32. Kerne moderner Prozessoren, die mit 4 Gigahertz getaktet sind, führen bereits mindestens 4 Milliarden Operationen pro Sekunde (und pro Kern) aus.[↩]
33. Bildquelle: eigenes Foto[↩]
34. Vgl. Völz: Mensch-Technik-System. 1999, S. 201.[↩]
35. Dies gilt für die Fixationsdauer bei der Bilderkennung. Falls Text gelesen werden soll, muss die Anzeige- und Wartezeit deutlich verlängert werden, weil hierbei nur 18–45 Bit/Sekunde an Informationen aufgenommen werden können (vgl. ebd., S. 75).[↩]
36. Der Maschinensprachebefehl NOP (No Operation) ist in den Befehlsvorrat jedes
    Mi­kroprozessors integriert und dient genau dazu: Takte-lang soll die CPU nichts zu tun haben außer zu warten. Dies wird zumeist für Synchronisationszwecke oder Warteschleifen benötigt.[↩]
37. Der Interface-Baustein UM6532, der in die Atari 7800 eingebaut ist, besitzt einen solchen Timer, der beim Erreichen der Null sogar ein Interrupt-Signal an die CPU sendet (vgl. UMC: UM6532/A. o. J.).[↩]
38. Vgl. Fischer: Mikroprozessoren. 1982, S. 127.[↩]
39. Direct Memory Access (DMA) ermöglicht es Spezialbausteinen (z. B. für Grafik und Sound), ohne Umweg über die CPU direkt auf den RAM-Speicher des Prozessors zugreifen zu können. Dies beschleunigt die Ausgabe und ‚entlastet‘ die CPU von dieser Arbeit.[↩]
40. Vgl. Völz: Mensch-Technik-System. 1999, S. 51 f.[↩]
41. Hardy: History of Interrupts. 2000. Das Interrupt-Handling des Spiels Spacewar! lässt sich in dessen Source Code nachvollziehen (vgl. JonnieCache: Spacewar. 2012).[↩]
42. Jindroush: 6502C. 2004a. In der Konsole ist der von Atari mit dem Code-Namen ‚Sally‘ bezeichnete Chip entweder mit der Nummer UM6502I oder CO14806 verbaut.[↩]
43. Die zweite Spannungsversorgungsleitung der 6502C stellt einen der Unterschiede zur herkömmlichen 6502-CPU dar.[↩]
44. Auch diese HALT-Leitung unterscheidet 6502C vom 6502. Der Grafikchip GCC1702 (Code-Name ‚Maria‘) ist mit 7,4 MHz viermal schneller als die CPU getaktet, was dazu führt, dass er eine wesentlich höhere Grafikauflösung pro Bildschirmzeile erzeugen kann als sein Vorgänger TIA (vgl. Moll: Bouncing the Beam. 2014, S. 71–73).[↩]
45. Bildquelle: eigene Zeichnung[↩]
46. In der PAL-Norm werden pro Sekunde 50 Vollbilder generiert, die aus jeweils 320 Zeilen bestehen. Das bedeutet, dass pro Sekunde 50 ( 320 = 16.000 Rasterzeilen-Inter­rupts gesendet werden. Diese Werte sind allerdings von der möglichen Zeilenauf­lösung des Grafikchips abhängig. Der Zeilentrafo des Monitors erzeugt dabei ein leises Pfeifgeräusch mit genau dieser Frequenz.[↩]
47. Beispiele hierfür wären das Locomotive-BASIC der Amstrad CPCs oder das MSX-BASIC.[↩]
48. Schemer-Reinhard: Interface. 2018, S. 159[↩]
49. Bildquelle: https://commons.wikimedia.org/wiki/File:SAGE_conso­le_and_light_gun_ at_CHM.jpg [25.03.2020][↩]
50. Ulmann: AN/FSQ-7. 2015, S. 57 f.[↩]
51. National Museum of American History: Brown Box Lightgun. o. J.[↩]
52. Vgl. Baer: Videogames. 2005, S. 163–168.[↩]
53. Bildquelle: http://1bigvideogame.com/blog/out-to-launch-video-games [02.07.2019][↩]
54. Übersichten zu Modellen, Plattformen und Spielen bieten die Seiten Lightguninfo. o. J. (http://www.lightguninfo.de/ [23.10.2019]) und Light-Gun. o. J. (http://www.light­gun.de/ [23.10.2019]). [↩]
55. Bildquelle: eigenes Foto[↩]
56. Die genauen quantenphysikalischen Effekte, die in diesem Bauteil wirken, können hier nachgelesen werden: o. A.: Photodiode. 2018.[↩]
57. Vgl. Höltgen: Logik. 2017, S. 92–97. Realisiert wird diese logische Verknüpfung in der kleinen Schaltung in der Light Gun. Der IC TC4011BP ist ein vierfaches NAND-Gatter mit je zwei Eingängen pro Gatter. In diesem werden die beiden Signale des Triggers und der Sensor-Diode zunächst negiert (ein Signal auf beide Eingänge eines NAND) und dann in ein drittes NAND eingespeist. Vermutlich wurde dieser etwas merkwürdigen Doppel-Umwandlung aufgrund der damals niedrigeren Kosten eines NAND- gegenüber eines AND-Bausteins der Vorzug gegeben.[↩]
58. Vgl. Völz: Mensch-Technik-System. 1999, S. 28 f.[↩]
59. Bildquelle: eigener Screenshot[↩]
60. Vgl. Datei BM/ADDR.S, Zeile 400 in: McMahon: Atari 7800. 2012.[↩]
61. Die linksbündigen Elemente, die mit einen Punkt (.) beginnen sind (mit Ausnahme von .if, .endif und .include) die Label-Namen, sie stellen symbolische Sprungziele dar.[↩]
62. Damit wird nicht nur verhindert, dass ein Schuss abgegeben wird, während der andere noch ausgeführt wird; dieses Bit regelt auch die Schusswiederholgeschwindigkeit bei gedrückt gehaltenem Trigger (vgl. die Datei BM/BDF.S, Zeile 1705–1708, in: ebd.).[↩]
63. Derartige ‚Racing-the-Beam‘-ähnliche Programmier-Verfahren wurden jedoch bereits an anderer Stelle ausführlich, hard- und softwarenah diskutiert (vgl. Moll: Bouncing the Beam. 2014, S. 73, 78; Montfort/Bogost: Racing the Beam. 2009: S. 27–30).[↩]
64. Yull: Interrupt. 2008, S. 163[↩]
65. ebd., S. 164[↩]
66. Ullmann: Man in the Loop. 2016, S. 116[↩]
67. Als Prellen wird das mechanische Zittern von Schaltern bezeichnet (ausgelöst durch den menschlichen Muskeltonus oder durch die Vibrationen des Schaltvorgangs [vgl. Burstyn: Elektrische Kontakte. 1956, S. 80–83]), welches durch Hardware- oder Software-Techniken gefiltert werden kann. Entprellen wäre im Sinne des hier verhandelten Diskurses eine Unterbrechung der Unterbrechungen.[↩]
68. Bildquelle: eigener Screenshot[↩]
69. Huizinga: Homo Ludens. 1944, S. 12[↩]