Intel 80386: Wie x86 zur 32-Bit-Plattform wurde

Um 1990 ließ Intel in Anzeigen eine große „286“ mit einem roten X durchstreichen. Käufer sollten beim nächsten PC ausdrücklich einen 386 verlangen. Die Botschaft war ungewöhnlich deutlich: Der erfolgreiche Vorgänger, an dem Intel weiterhin verdiente, gehörte plötzlich zum alten Eisen. Viele Kunden sahen das anders. Ein günstiger 286 erledigte unter DOS dieselbe Textverarbeitung und dieselbe Tabellenkalkulation. Der 80386 war technisch weit voraus, doch seine 32-Bit-Architektur brachte den meisten Anwendern zunächst wenig Sichtbares.

Dieses Problem hatte Intel bereits während der Entwicklung beschäftigt. Anfangs war keineswegs sicher, dass es überhaupt einen vollständig kompatiblen 32-Bit-Nachfolger des 286 geben würde. Der spätere 386 begann als Nebenprojekt einer Prozessorfamilie, die Intel langfristig ersetzen wollte.

Der 286 galt als Sackgasse

Als Intel Anfang 1982 mit dem 80386 begann, stand der 80286 gerade erst vor der Markteinführung. Sein Protected Mode konnte Programme und Speicherbereiche voneinander abschirmen. Für Mehrbenutzersysteme und Unix-Rechner war das vielversprechend.

Im PC erwies sich der neue Betriebsmodus als sperrig. Hatte der 286 einmal in den Protected Mode gewechselt, führte kein einfacher Weg zurück in den 8086-kompatiblen Real Mode. DOS und die vorhandene PC-Software lebten weiterhin in dieser alten Umgebung. Gene Hill, der bei Intel die Fertigstellung des 286 betreute, erinnerte sich später, Bill Gates habe den Prozessor als „Brain Dead“ bezeichnet. Auch bei IBM sei er als architektonische Sackgasse betrachtet worden. Hill sollte das Entwicklerteam nach Abschluss des Projekts ursprünglich auflösen.

Gleichzeitig wuchs der Druck durch Motorola. Dessen 68000 galt im Intel-Team als die elegantere Architektur und eignete sich gut für Unix-Workstations. Intel hatte beim 8086 bereits mit „Operation Crush“ dagegengehalten: einer Vertriebsaktion, bei der der Hersteller Prozessoren, Zusatzbausteine, Entwicklungswerkzeuge und technische Unterstützung als Gesamtangebot verkaufte. Mit dem kommenden Motorola 68020 drohte Intel erneut ins Hintertreffen zu geraten. Ein bloß schnellerer 286 hätte kaum gereicht.

Intels geplante Zukunft hieß nicht x86

Rückblickend wirkt die Linie vom 8086 über 286 und 386 zum 486 beinahe selbstverständlich. Innerhalb Intels sah die Zukunft anders aus.

Das große Architekturprojekt des Unternehmens hieß iAPX 432. Es sollte Funktionen moderner Betriebssysteme direkt in der Hardware unterstützen und leistungsfähige Mehrbenutzersysteme ermöglichen. Der Entwurf war ehrgeizig, komplex und langsam. Daneben entstanden weitere Prozessorprojekte, die x86 langfristig ablösen sollten.

8086, 8088, 186 und 286 galten in dieser Planung teilweise als Überbrückungen. Sie sollten die Zeit füllen, bis eine grundsätzlich neue Architektur fertig war.

John Crawford, der spätere Chefarchitekt des 386, erhielt zunächst den Auftrag, eine kompatible 32-Bit-Erweiterung des 286 zu untersuchen. Das Projekt verfügte anfangs über wenig Personal und stand im Schatten der aufwendigeren Neuentwicklungen.

Während diese Projekte zurückfielen und der PC-Markt schneller wuchs als erwartet, änderte sich die Lage. Aus der pragmatischen Alternative wurde Intels wichtigster Prozessorentwurf.

Das Problem lag auf den Disketten

Die grundsätzliche Richtung war klar: Der neue Prozessor sollte 32 Bit breite Daten verarbeiten und einen entsprechend großen Speicherraum beherrschen. Schwieriger war die Frage, wie viel Vergangenheit er mitnehmen musste.

Intel zeigte potenziellen Kunden verschiedene Entwürfe. Einige hielten die Kompatibilität zum 8086 und 286 für entbehrlich. Programme könnten für eine neue Architektur schließlich neu übersetzt werden. Andere verlangten, vorhandene Software unverändert weiterzuverwenden.

1982 war der IBM PC erst wenige Monate auf dem Markt. Niemand wusste, welchen Wert seine Softwarebibliothek einmal besitzen würde. Im PC-Handel wurden Programme jedoch zunehmend als fertiger Maschinencode auf Disketten verkauft. Diese Ausgaben ließen sich nicht nachträglich für eine andere Architektur übersetzen.

Vor allem Intels Außendienst drängte deshalb auf vollständige Binärkompatibilität. Wer einem Kunden gerade einen 286 verkaufte, musste versprechen können, dass dessen Programme auch auf der nächsten Generation liefen. Die Entscheidung zog sich über Monate. Intel verzichtete schließlich auf einen sauberen Neuanfang und brachte die 32-Bit-Technik innerhalb der vorhandenen x86-Architektur unter.

Wie Intel 32 Bit mit der alten Architektur verband

Der größte Ballast der bisherigen Prozessoren war ihre Speicheraufteilung. Beim 8086 bestand eine Adresse aus einem Segment und einer Position innerhalb dieses Segments. Ein einzelner Bereich war auf 64 Kilobyte beschränkt. Mit wachsenden Programmen und Datenstrukturen mussten Entwickler ständig verwalten, in welchem Segment sich etwas befand. Der 286 hatte dieses Modell erweitert und mit Schutzrechten versehen. Einfacher war es dadurch nicht geworden.

Crawfords Lösung behielt die Segmentierung für ältere Programme bei. Ein Segment durfte beim 386 jedoch bis zu vier Gigabyte groß sein. Moderne Betriebssysteme konnten einen solchen Bereich einrichten und den Speicher anschließend weitgehend wie einen zusammenhängenden Raum behandeln. Zwischen die Adresse eines Programms und den tatsächlich vorhandenen Arbeitsspeicher setzte Intel den linearen Adressraum. Paging zerlegte ihn in Seiten von jeweils vier Kilobyte und ordnete diese dem physischen Speicher zu. Ein Betriebssystem konnte Seiten verschiedenen Programmen zuteilen, schützen oder auf einen Datenträger auslagern. Damit besaß der 386 einen vollständigen 32-Bit-Adressraum und die Grundlage für virtuellen Speicher. MS-DOS nutzte davon zunächst kaum etwas. Es arbeitete weiterhin im Real Mode und behandelte den Prozessor weitgehend wie einen besonders schnellen 8086.

Unix-Systeme konnten den flachen Adressraum, Paging und Speicherschutz wesentlich besser verwenden. Der 386 musste deshalb zwei sehr unterschiedliche Welten bedienen: moderne Betriebssysteme und die vorhandene DOS-Software. Für letztere erhielt er den Virtual-8086-Modus. Ein Betriebssystem konnte mehrere DOS-Programme gleichzeitig in getrennten Umgebungen ausführen. Jede Anwendung glaubte, auf einem eigenen 8086-PC zu laufen. Direkte Zugriffe auf Hardware oder geschützte Speicherbereiche ließen sich kontrollieren.

Windows/386 verwendete diese Möglichkeit ab 1987. Damit wurde eine der neuen Fähigkeiten des Prozessors erstmals auch für gewöhnliche PC-Nutzer sichtbar.

Mehr Transistoren auf kaum mehr Platz

Zwischen 8086 und 386 lagen nur sieben Jahre. Die Zahl der Transistoren hatte sich in dieser Zeit fast verzehnfacht.

Der 8086 bestand aus ungefähr 29.000 Transistoren und wurde zunächst mit Strukturen von rund drei Mikrometern gefertigt. Beim 286 waren es etwa 134.000 Transistoren in einem 1,5-Mikrometer-Prozess. Der erste 386 blieb ebenfalls bei ungefähr 1,5 Mikrometern, enthielt aber bereits rund 275.000 Transistoren.

Die Strukturen wurden also nicht bei jeder Generation automatisch kleiner. Intel brachte auf derselben Fertigungsgröße wesentlich mehr Schaltung unter. Dazu gehörten die breiteren Register, die Paging-Einheit, der Virtual-8086-Modus und die umfangreiche Schutzlogik. Der Entwurf stieß dabei an eine physische Grenze. Er durfte nicht größer werden als der Bereich, den Intels Belichtungsanlage in einem Arbeitsgang auf den Wafer übertragen konnte. Auf einem Teil des Layouts fehlte deshalb sogar Platz für regulär angeordnete Anschlüsse. Ein geplanter interner Cache musste weichen. Motorola hatte dem 68020 einen Cache von 256 Byte gegeben; Intel plante 512 Byte. Simulationen zeigten jedoch, dass ein so kleiner Speicher kaum Leistung brachte und wertvolle Chipfläche beanspruchte. Intel strich ihn und bereitete den Bus stattdessen für größere externe Caches auf der Hauptplatine vor.

Intel lernte CMOS während des Projekts

Der 386 war der erste Prozessor der x86-Reihe, den Intel von Anfang an für seinen CMOS-Prozess CHMOS entwickelte. Diese Technik benötigte weniger Strom und lieferte sauberere elektrische Pegel als das bisher verwendete NMOS. Intel entwickelte den Fertigungsprozess parallel zum Chip.

Besonders die zweite Metallschicht bereitete Schwierigkeiten. Die Waferoberfläche war noch nicht so plan wie bei späteren Verfahren. Leiterbahnen mussten über Unebenheiten geführt werden, konnten reißen oder unerwünschte Verbindungen bilden. Bestimmte Abstände waren deshalb verboten. Das Team sprach vom „forbidden gap“.

Designregeln und Leistungswerte änderten sich, während das Layout bereits entstand. Ein Teil des Chips wurde noch von Hand angeordnet. Für andere Bereiche verwendete Intel neue automatische Werkzeuge, darunter das an der Universität Berkeley entstandene Platzierungsprogramm Timberwolf.

Der zuständige Doktorand reparierte Fehler teilweise über ein Terminal in seinem Zimmer am MIT. Ein Schlüsselprojekt Intels hing damit zeitweise auch davon ab, ob ein Student für Rückfragen erreichbar war.

NoOp, NoOp, Halt

Im Juli 1985 war das Layout fertig. Wenige Wochen später lagen die ersten Chips vor. Das erste Testprogramm bestand aus drei Befehlen: zweimal nichts tun, danach anhalten. Es funktionierte nicht. Eine Logikstruktur, die den Einsprung in die interne Steuerung des Prozessors regelte, arbeitete überhaupt nicht. Die Entwickler versuchten, die nötigen Änderungen direkt an der Fertigungsmaske vorzunehmen. Ein erster Reparaturversuch mit einem Laser ruinierte die Glasmaske, weil der Strahl im Material reflektiert wurde und weitere Stellen beschädigte. Ein anderer Anbieter konnte die Strukturen schließlich mit einem fokussierten Ionenstrahl bearbeiten. Danach führte der Prozessor immerhin seine einfachsten Befehle aus. Weitere Fehler blieben. Probleme traten unter anderem auf, wenn ein Befehl wegen einer fehlenden Speicherseite unterbrochen und anschließend fortgesetzt werden sollte. Auch die Zusammenarbeit mit dem mathematischen Coprozessor war zunächst unzureichend simuliert worden. Die frühen Revisionen enthielten Fehler bei Taskwechseln, Paging, gemischtem 16- und 32-Bit-Code sowie bei Debug- und Coprozessorfunktionen. Intel veröffentlichte dafür Umgehungslösungen und überarbeitete den Chip mehrfach.

Ein später entdecktes Problem in der Recheneinheit konnte bei bestimmten 32-Bit-Multiplikationen falsche Ergebnisse liefern. Fehlerfreie Exemplare erhielten nach einem Test zwei Sigma-Zeichen. Betroffene Chips wurden mit „16 BIT S/W ONLY“ gekennzeichnet und waren nur für 16-Bit-Software vorgesehen. Das Layout war fertig. Bis zum zuverlässigen Serienprodukt blieb noch Arbeit.

Intel stellte den 386 früh vor

Während die Entwickler um den Chip kämpften, geriet Intel wirtschaftlich unter Druck. Das Unternehmen zog sich aus großen Teilen des Speichergeschäfts zurück, schloss Werke und baute Stellen ab. 1986 verlor Intel 173 Millionen Dollar. Der 386 sollte nun das künftige Mikroprozessorgeschäft tragen. Intel stellte ihn bereits am 17. Oktober 1985 vor. Geplant waren zunächst Versionen mit 12,5 und 16 MHz. Die Entwicklung des Prozessors und der dazugehörigen Unterstützungsprodukte hatte nach Angaben des Unternehmens ungefähr 100 Millionen Dollar gekostet.

Zu diesem Zeitpunkt war der 386 noch nicht in großen Mengen lieferbar. Die Entwickler verfügten erst seit wenigen Wochen über ausreichend funktionsfähige Exemplare. Der Prozessor der Präsentation steckte über einen Adapter in einem umgebauten 286-System. Sorgfältig ausgewählte Programme und zusätzliche Fehlerbehandlungen hielten die Vorführung am Laufen. Die Serienfertigung begann erst 1986. Intel hatte den neuen Prozessor gezeigt. Einen vollständigen 386-PC konnte noch niemand kaufen.

Compaq wartet nicht auf IBM

Das änderte sich am 9. September 1986. Compaq präsentierte den Deskpro 386, den ersten serienmäßig angebotenen vollständigen 386-PC eines großen Herstellers. Das Basismodell mit 40-Megabyte-Festplatte kostete 6.499 Dollar. Für private Käufer war der Rechner kaum gedacht. Beim IBM PC von 1981 und dem PC/AT von 1984 hatte IBM den Generationswechsel vorgegeben. Nun brachte Compaq den neuen Prozessor zuerst in ein fertiges System. IBM musste folgen.

Der Deskpro blieb in vielen Punkten mit dem PC/AT verwandt. Erweiterungskarten verwendeten weiterhin den 16 Bit breiten ISA-Bus, während Compaq den Hauptspeicher über einen schnelleren 32-Bit-Pfad anband. In damaligen Tests lief der Rechner bei vielen Aufgaben ungefähr doppelt so schnell wie zuvor geprüfte AT-kompatible Systeme. Der Vorsprung hing nicht allein am Prozessor. Compaq hatte auch den Speicher und die Festplatte auf hohe Leistung ausgelegt. Mit dem Deskpro zeigte ein Hersteller kompatibler Rechner, dass IBM die technische Richtung des PC-Markts nicht mehr allein bestimmen konnte.

Ein 32-Bit-Rechner für 16-Bit-Programme

Der Deskpro offenbarte zugleich den Widerspruch des 386. Seine CPU besaß 32-Bit-Register, einen 32-Bit-Datenbus und einen Adressraum von vier Gigabyte. Das mitgelieferte DOS arbeitete weiterhin im Real Mode. Die meisten Anwendungen bestanden aus 16-Bit-Code und kannten weder Paging noch den flachen Adressraum.

Sie liefen schneller, weil der Prozessor höher getaktet war und Compaq ein leistungsfähiges System darum gebaut hatte. Die eigentliche 32-Bit-Architektur blieb jedoch meist ungenutzt.

Betriebssysteme konnten die neuen Möglichkeiten früher übernehmen als Anwendungsprogramme. Windows/386 führte mehrere DOS-Anwendungen in getrennten Umgebungen aus. Windows 3.0 brachte den erweiterten 386-Modus 1990 in einen größeren Markt. Unix-Systeme verwendeten den flachen Adressraum und den Speicherschutz umfassender.

DOS-Extender erlaubten später auch einzelnen Programmen und Spielen, mehr Speicher zu nutzen, ohne DOS vollständig aufzugeben.

Viele Käufer erwarben einen 386 deshalb als Investition in kommende Software. Ein teurer PC sollte mehrere Jahre halten. Die Aussicht auf zukünftige Betriebssysteme war oft wichtiger als der unmittelbare Nutzen unter DOS.

Vom teuren Spitzenchip zum Marktstandard

Der erste 386 war groß und schwierig herzustellen. Verbesserte Fertigungsprozesse verkleinerten später die Chipfläche, senkten die Kosten und ermöglichten höhere Taktraten. Der Prozessor erschien mit 20, 25 und 33 MHz.

1988 folgte der preiswertere 386SX. Er behielt die 32-Bit-Architektur im Inneren, verwendete nach außen aber einen schmaleren Bus. Hersteller konnten dadurch günstigere Hauptplatinen bauen und vorhandene Technik aus der 286-Klasse weiterverwenden. Der ursprüngliche 80386 erhielt zur Unterscheidung nachträglich den Zusatz DX.

Die Unterschiede zwischen SX und DX verdienen eigene Artikel. Für die Entwicklung der Plattform war entscheidend, dass 386-Rechner nun auch für gewöhnliche Büro- und Heimcomputer erschwinglicher wurden.

Intel wollte die neue Architektur zugleich stärker kontrollieren. Bei älteren Generationen hatte AMD aufgrund von Austauschverträgen kompatible Prozessoren gefertigt. Beim 386 stellte Intel dem Unternehmen keine Technologie als Second Source zur Verfügung. AMD berief sich auf die bestehenden Vereinbarungen und entwickelte parallel einen eigenen Prozessor.

Der Am386 erschien im März 1991, als Intel bereits den 486 verkaufte. Er blieb mit der 386-Software kompatibel und erreichte Taktraten von bis zu 40 MHz.

Damit endete weitgehend die frühere Selbstverständlichkeit, dass große Kunden Intel-Prozessoren von mehreren Lieferanten beziehen konnten. Die x86-Architektur war zum Kern von Intels Geschäft geworden.

Warum Intel den 286 durchstrich

Der 286 blieb dennoch lange attraktiv. Er war billiger, für DOS häufig schnell genug und den Käufern vertraut. Intel hatte Prozessoren zuvor vor allem an Computerhersteller verkauft. Endkunden interessierten sich eher für den Namen auf dem PC-Gehäuse als für den Hersteller des Chips im Inneren.

Dennis Carter entwickelte deshalb eine Kampagne, die sich direkt an PC-Käufer richtete. Intel strich die Zahl 286 mit einem roten X durch und erklärte daneben die Vorteile des 386. Kunden sollten im Geschäft ausdrücklich nach dem neueren Prozessor fragen. Der günstigere 386SX machte diese Forderung auch außerhalb teurer Hochleistungssysteme realistisch. Die Kampagne bereitete Intels spätere Endkundenwerbung und das 1991 gestartete „Intel Inside“ vor.

Zeitgenössischen Berichten zufolge entfiel 1991 ungefähr die Hälfte von Intels Jahresumsatz auf Prozessoren der 386-Familie. Der frühere Nebenentwurf hatte die geplanten Nachfolgearchitekturen überlebt und Intels Geschäft neu ausgerichtet.

Der 386 verband einen vollständigen 32-Bit-Adressraum, Paging und Speicherschutz mit der vorhandenen PC-Software. Betriebssysteme konnten sich weiterentwickeln, während ältere Programme weiterhin liefen. Darauf bauten die folgenden PC-Generationen auf.

Sega TeraDrive – wer brauchte einen PC von Sega?

Picture is taken from: https://segaretro.org/Teradrive

Ein Mega Drive war 1991 eine aktuelle Spielkonsole. Ein IBM-kompatibler PC erledigte Textverarbeitung, Tabellenkalkulation und Datenverwaltung. Weshalb sollten beide Geräte auf derselben Hauptplatine sitzen?

Diese Frage führt näher an den TeraDrive heran als jede Aufzählung seiner Prozessoren. Wollte Sega zusätzlich in Büros vordringen? Sollte der Rechner Familien ansprechen, die Computer und Konsole nicht getrennt kaufen wollten? Oder erprobten Sega und IBM Japan eine Nische, deren Größe niemand genau kannte?

Sega und IBM nannten keine klar umrissene Zielgruppe. Die Werbung stellte „Amusement & Computer“ nebeneinander und zeigte Arbeitsprogramme ebenso wie Mega-Drive-Spiele. Der britische New Computer Express berichtete bereits vor der Veröffentlichung, Sega wolle Menschen an ernsthaftere Computeranwendungen heranführen, die sich bislang vor allem für Spiele interessierten. Das spricht für einen vielseitigen Heim- und Personalcomputer. Hinweise auf eine geplante Eroberung japanischer Büros gibt es nicht.

Ganz neu war der Gedanke für Sega nicht. Bereits 1983 hatte das Unternehmen den SC-3000 als „Game Computer“ angeboten. Er verband Spiele mit BASIC und weiterer Computersoftware am heimischen Fernseher. Der TeraDrive griff diese Idee acht Jahre später mit der Hardware des Mega Drive und einem IBM-kompatiblen PC wieder auf.

Auch für IBM Japan passte das Projekt in die Zeit. Das Unternehmen hatte im Oktober 1990 DOS/V angekündigt. Diese japanische Ausgabe von PC DOS stellte Kanji und andere japanische Schriftzeichen mithilfe von Software im VGA-Grafikspeicher dar. Das V stand ursprünglich für VGA.

Ein DOS/V-PC war keine eigene Rechnerarchitektur. Gemeint war ein weitgehend international kompatibler PC, der japanische Texte darstellen konnte. Das war auf einem Markt wichtig, auf dem NECs PC-98 und weitere landesspezifische Systeme ihre jeweils eigene Hard- und Softwarewelt mitbrachten. DOS/V sollte gewöhnliche PC/AT-Technik für japanische Anwender öffnen.

Für IBM dürfte der Reiz in Segas Zugang zum privaten Spielemarkt gelegen haben. Sega erhielt im Gegenzug eine fertige Grundlage für einen DOS/V-kompatiblen Rechner. Ob beide Unternehmen damit eine neue Gerätekategorie schaffen oder zunächst eine schmale Marktnische erproben wollten, bleibt offen.

Am 31. Mai 1991 erschien der TeraDrive in Japan. Sega bezeichnet ihn als gemeinsame Entwicklung mit IBM Japan. Seine PC- und Mega-Drive-Komponenten teilten sich eine Hauptplatine und konnten je nach Betriebsart unabhängig nebeneinander laufen oder auf Bereiche der jeweils anderen Seite zugreifen.

Sega und IBM auf einer Platine

Ein zeitgenössischer japanischer Bericht schrieb IBM die Fertigung der Hauptplatine zu. Bekannt sind damit die gemeinsame Entwicklung und die Beteiligung IBMs am zentralen Bauteil. Wer Gehäuse, Netzteil und Endmontage verantwortete, ist nicht dokumentiert.

Der PC-Teil verwendet einen Western-Digital-Chipsatz, der auch in anderen 286- und 386-Rechnern zu finden war:

  • WD76C10LP als System- und Speichercontroller
  • WD76C30 für serielle und parallele Schnittstellen
  • WD76C20 für Diskettenlaufwerk, Echtzeituhr und nichtflüchtigen Speicher
  • WD90C10 für die VGA-Grafik

Ähnliche Bausteine kamen im japanischen IBM PS/55 5510Z zum Einsatz. Hinzu kommt der IBM 79F2661. Auf der TeraDrive-Platine ist er mit „BUS SW“ beschriftet. Er verbindet den 68000-Bus der Mega-Drive-Seite mit dem ISA-Bereich des PCs und verwaltet den Zugriff auf ein zusätzliches Firmware-ROM.

Diese Verwandtschaft macht den TeraDrive nicht zu einem PS/2 Model 30 mit schwarzer Front. Seine Hauptplatine nimmt PC- und Mega-Drive-Technik gemeinsam auf und wurde für deren Verbindung eingerichtet. Auch Gehäuse und Erweiterungsmöglichkeiten unterscheiden sich deutlich von den entsprechenden IBM-Rechnern.

Der TeraDrive misst 360 Millimeter in der Breite, 80 Millimeter in der Höhe und 334 Millimeter in der Tiefe. Je nach Ausführung wiegt er zwischen 5,6 und 6,2 Kilogramm. Die flache schwarze Bauform erinnert eher an eine Hi-Fi-Komponente als an einen Büro-PC der frühen Neunziger.

Drei Modelle, ein Prozessor

Sega bot drei Ausführungen an. Prozessoren, Grafik und grundlegende Architektur blieben gleich. Unterschiede bestanden beim Arbeitsspeicher und bei den Laufwerken.

Modell PC-Arbeitsspeicher Laufwerke Preis 1991 vor Steuer Heutige Kaufkraft, etwa
Model 1 640 KB ein 3,5-Zoll-Diskettenlaufwerk 148.000 Yen 1.000 Euro
Model 2 1 MB zwei 3,5-Zoll-Diskettenlaufwerke 188.000 Yen 1.270 Euro
Model 3 2,5 MB ein Diskettenlaufwerk, 30-MB-Festplatte 248.000 Yen 1.680 Euro

Die Eurobeträge zeigen die ungefähre heutige Kaufkraft der japanischen Preise. Grundlage sind der japanische Verbraucherpreisindex von Mai 1991 bis Juni 2026 und der EZB-Referenzkurs vom 3. August 2026. Die Beträge entsprechen keinem damaligen deutschen Importpreis. Der schwache Yen drückt die umgerechneten Eurozahlen zusätzlich.

Alle drei Modelle verwendeten einen 80286 mit 10 MHz. Der konkrete Hersteller konnte variieren. Auf der in den Hardware Notes dokumentierten Platine sitzt ein AMD N80L286-10/S. „Intel 286“ beschreibt daher die Prozessorfamilie, nicht zwingend den Hersteller des eingebauten Chips.

Der PC-Teil besaß 256 KB VGA-Speicher. Er stellte unter anderem 640 × 480 Punkte mit 16 Farben oder 320 × 200 Punkte mit 256 Farben dar. Der Arbeitsspeicher ließ sich offiziell auf höchstens 2,5 MB erweitern.

Als Betriebssystem lieferte Sega IBM DOS J4.0/V samt TeraDrive-Treibern aus. Beim Model 3 war DOS/V bereits auf der 30-MB-Festplatte installiert. Die kleineren Modelle arbeiteten von Diskette, sofern sie nicht nachträglich einen Massenspeicher erhielten.

Zur PC-Seite gehörten außerdem ein paralleler Druckeranschluss, eine serielle RS-232C-Schnittstelle und ein PS/2-kompatibler Mausanschluss. Manche späteren Tabellen nennen zwei serielle Schnittstellen. Sega führt nur eine auf; der separate Mega-Drive-EXT-Anschluss wurde offenbar gelegentlich mitgezählt.

Das TERA-Menü im Zusatz-ROM

Neben dem 128 KB großen PC-BIOS besaß der Rechner ein zusätzliches 512-KB-ROM. Darin liegen ein Kanji-Zeichensatz, Firmware für die Mega-Drive-Seite und ein ROM-Disk-Abbild des TERA-Menüs. Der IBM-Busschalter blendet daraus jeweils 8 KB große Bereiche in den PC-Adressraum ein.

Das TERA-Menü bot eine einfachere Oberfläche als die DOS-Eingabeaufforderung. Es führte zu den vorhandenen Betriebsarten und stellte grundlegende Datei- und Laufwerksfunktionen bereit. Damit konnte der Rechner unmittelbar nach dem Einschalten eine eigene Bedienoberfläche anzeigen.

Das zusätzliche Kanji-ROM widerspricht dem DOS/V-Prinzip nicht. DOS/V stellte japanische Texte grundsätzlich über Software und VGA dar. Der TeraDrive benötigte Schriftzeichen jedoch bereits für sein eigenes Startmenü und seine Firmware, bevor DOS/V geladen war.

Wie alt war der 286 wirklich?

Ein 10-MHz-286 war 1991 eine vorsichtige Wahl. 386-Rechner waren etabliert, der 486 bereits erhältlich. Anspruchsvollere Programme und die weitere Entwicklung von Windows verlangten nach mehr Rechenleistung und mehr Arbeitsspeicher.

Der 286 war trotzdem kein unverkäuflicher Restposten. Auf dem jungen DOS/V-Markt erschienen weiterhin neue Rechner mit dieser Prozessorfamilie. Ein zeitgenössischer Bericht verglich den TeraDrive mit einem IBM PS/55 5510Z mit 12-MHz-286 und einem 16-MHz-Rechner von Kansai Denki. Der Sega-Rechner war langsamer, enthielt dafür DOS/V und die vollständige Mega-Drive-Hardware. Sein Preis erschien dem Magazin im damaligen Umfeld nicht abwegig.

Für Textverarbeitung, Tabellen, Datenbanken und typische DOS-Anwendungen reichten 10 MHz aus. Auch japanisches Windows 3.0 wurde von Sega gezeigt. Die knappen Reserven ergaben sich aus dem Gesamtpaket: offiziell höchstens 2,5 MB RAM, ein einzelner Erweiterungssteckplatz und 30 MB Festplattenspeicher im teuersten Modell.

Der Prozessor war fest verlötet. Ein gewöhnlicher Austausch gegen einen schnelleren 286 oder ein Aufrüstmodul war nicht vorgesehen. Der TeraDrive kam als brauchbarer DOS/V-Rechner auf den Markt, bot aber wenig Spielraum für die folgenden Jahre.

Ein verändertes Mega Drive

Die Konsolenseite orientiert sich an frühen Mega-Drive-1-Platinen, entspricht ihnen aber nicht vollständig. Sie enthält einen 68000, einen Z80A, Segas Video Display Processor, einen diskreten Yamaha YM3438 sowie die üblichen Anschlüsse für Module und Controller.

Der dokumentierte Toshiba TMP68HC000N-10 ist für 10 MHz ausgelegt. Bei gewöhnlichen Mega-Drive-Modulen läuft er mit dem üblichen Konsolentakt von etwa 7,67 MHz. TeraDrive-spezifische Betriebsarten können ihn auf 10 MHz umschalten.

Der höhere Takt beschleunigt weder automatisch den Grafikprozessor noch gewöhnliche Mega-Drive-Spiele. Normale Module bleiben beim vorgesehenen Konsolentakt, damit Spielgeschwindigkeit, Musik und zeitkritische Routinen unverändert arbeiten.

Auch beim Speicher unterscheidet sich der TeraDrive von der Serienkonsole. Er besitzt 128 KB VDP-Speicher und insgesamt 16 KB Z80-RAM. Das ursprüngliche Mega Drive hatte jeweils die Hälfte. Normale Module erhalten dadurch keine besseren Grafiken oder aufwendigeren Klänge. Die zusätzlichen Reserven standen besonderen TeraDrive-Betriebsarten und angepasster Software zur Verfügung.

Beim FM-Klang verwendet der Rechner einen eigenständigen Yamaha YM3438. Eine separate Logikschaltung korrigiert dabei das Verhalten bestimmter Statusabfragen. Dieses Detail zeigt, wie weit die Konstruktion über das Einsetzen einer unveränderten Mega-Drive-Platine hinausging.

Der Z80A läuft mit 3,58 MHz und übernimmt vor allem Klang- und Nebenaufgaben. Segas Werbespruch „Zwei Gehirne docken an“ bezog sich auf 80286 und 68000. Der Z80 arbeitete weiter, ohne im Slogan mitzuzählen.

Dual Boot und Bus Swap

Die oft verwendete Formulierung vom „gleichzeitigen Betrieb“ verdeckt zwei unterschiedliche Betriebsarten.

Im Dual-Boot-Modus laufen 80286 und 68000 gleichzeitig und weitgehend unabhängig voneinander. Der PC kann ein DOS-Programm ausführen, während auf der Mega-Drive-Seite ein Modul läuft. Fast alle TeraDrive-spezifischen Zugriffe zwischen den beiden Hardwarebereichen sind in diesem Modus gesperrt. Die beiden Rechner arbeiten parallel, bleiben dabei aber weitgehend unter sich.

Beim Bus Swap wird die Verbindung enger. Setzt der 286 das entsprechende Steuerbit, hält er selbst an und gibt den 68000 aus dem Reset frei. Übergibt der 68000 die Kontrolle zurück, wird er zurückgesetzt und der 286 setzt seine Arbeit fort. Die Hauptprozessoren arbeiten dabei nacheinander.

Der TeraDrive konnte somit beide Hauptprozessoren gleichzeitig betreiben oder eine engere Verbindung zwischen den Systemen herstellen. Beides geschah nicht im selben Modus.

Fenster in die jeweils andere Maschine

Der 286 erhielt ein 8 KB großes Speicherfenster. Über Register wählte die Software aus, welcher Ausschnitt des 68000-Adressraums oder des zusätzlichen Firmware-ROMs dort erschien.

Der 68000 konnte umgekehrt ein 1 MB großes Fenster in den PC-Adressraum einblenden. Ab einer weiteren Adresse erreichte er außerdem den PC-I/O-Bereich und damit grundsätzlich PC-Speicher, VGA-Register und weitere Schnittstellen.

Die Prozessoren teilten sich keinen gemeinsamen Arbeitsspeicher. Sie sahen ausgewählte Ausschnitte der anderen Seite. Software musste diese Fenster einrichten, Daten übertragen und anschließend die Kontrolle wechseln.

Die Architektur ging damit deutlich über zwei getrennte Platinen mit einem Umschalter hinaus. Ein symmetrisches Mehrprozessorsystem, in dem 286 und 68000 frei auf denselben Speicher zugreifen und gemeinsam denselben Programmablauf bearbeiten, war sie nicht.

Zwei Programme auf zwei Bildschirmen

Sega und IBM führten den unabhängigen Parallelbetrieb öffentlich vor. Ein Bericht in Beep! MegaDrive vom August 1991 zeigt fünf TeraDrives im IBM-Informationszentrum in Tokio. Zu jedem Rechner gehörten zwei Monitore. Auf einem Bildschirm lief die PC-Seite, auf dem anderen ein Mega-Drive-Spiel.

Der Rechner bot dafür einen analogen RGB-Ausgang für 15- und 31-kHz-Signale sowie einen Composite-Ausgang für die Konsolenseite. Ein gewöhnlicher VGA-Monitor konnte den PC darstellen, während das Mega Drive gleichzeitig sein Bild an einen Fernseher oder Videomonitor ausgab.

Segas separat angebotener HTR-2200 akzeptierte beide Zeilenfrequenzen. Er konnte wahlweise die PC- oder die Mega-Drive-Ausgabe anzeigen. Für beide Bilder zur selben Zeit waren weiterhin zwei Bildschirme nötig.

Der 14-Zoll-Monitor kostete 79.800 Yen vor Steuer, nach derselben Kaufkraftberechnung rund 540 Euro. Model 3 und Monitor kamen zusammen auf etwa 2.220 Euro. Der Spezialmonitor war bequem, wegen des zusätzlichen Videoausgangs aber nicht zwingend erforderlich.

Tastatur, Maus und Controller

Zum Rechner gehörte eine schwarze japanische JIS-Tastatur mit 106 Tasten. Bauform und Anschlag erinnern an IBMs Model-M-Familie. Eine eindeutige Zuordnung zu einer bestimmten Model-M-Ausführung oder IBM-Teilenummer gibt es nicht.

Sega legte einen Mega-Drive-Controller bei. Manche späteren Datenbanken nennen zwei Pads, Segas eigener Lieferumfang führt jedoch nur eines auf. Die Zahl zwei in den technischen Daten bezeichnet die vorhandenen Controlleranschlüsse.

Die passende Maus HTR-2300 wurde separat für 6.800 Yen verkauft. Das entspricht heute ungefähr 46 Euro. Sie verwendete eine PS/2-kompatible Schnittstelle und arbeitete mit 200 Zählschritten pro Zoll. Mit der 1993 erschienenen Sega Mouse für das Mega Drive war sie nicht identisch. (

Hinter Klappen an der Vorderseite lagen die Anschlüsse für Tastatur, Maus und Controller. Der Modulschacht befand sich links im Gehäuse. Mit geschlossenen Abdeckungen wirkte der Rechner weniger nach Arbeitsplatz als die meisten kompatiblen PCs dieser Zeit.

Firmware für verschiedene Programmtypen

Die Firmware der Mega-Drive-Seite erkennt neben gewöhnlichen Modulen zwei besondere Kennungen:

  • TERA68K
  • TERA286

Ein TERA68K-Modul wird unmittelbar auf dem 68000 gestartet. Bei einem TERA286-Modul kehrt die Firmware zunächst zum 286 zurück und hält die Möglichkeit offen, die Mega-Drive-Hardware vom PC aus freizuschalten. Zusätzlich sucht sie im Option-ROM-Bereich des PCs nach Segas Lizenztext.

Damit waren zwei Formen angepasster Software vorbereitet. Ein Programm konnte direkt auf dem 68000 laufen oder den 286 als Hauptprozessor verwenden und auf Teile der Konsolenhardware zugreifen.

Die Firmware sollte außerdem verhindern, dass gewöhnliche Module bequem über den PC ausgelesen wurden. Erkennt sie ein normales Modul statt eines TERA286-Typs, blockiert sie bei späteren Starts die entsprechende Freigabe. Die Verbindung zwischen den Systemen sollte nicht nebenbei als Modulkopierer dienen.

Puzzle Construction

Sega veröffentlichte Puzzle Construction als TeraDrive-exklusive Software. Das Programm verband einen Editor auf der PC-Seite mit einem fallenden Blockspiel und führte damit die Zusammenarbeit beider Hardwarebereiche vor. Es gehörte nicht zum regulären Lieferumfang jedes Rechners.

Wie Puzzle Construction intern zwischen 286 und 68000 aufgeteilt ist, wissen wir nicht. Sicher ist, dass der PC als Editor diente und das Ergebnis die Mega-Drive-Seite einbezog. Welcher Prozessor im Spielmodus die Programmlogik ausführte, geht aus den bekannten Unterlagen nicht hervor.

Die TERA286-Betriebsart würde einen direkten Zugriff des 286 auf VDP, Klang und Controller erlauben. Die Existenz dieser Betriebsart beweist jedoch nicht, dass Puzzle Construction sie auf genau diese Weise verwendet.

The Manhole

Ein weiteres TeraDrive-Programm tauchte erst 2024 wieder auf. Die erhaltene Fassung von The Manhole, dem frühen grafischen Adventure von Cyan, wurde teilweise gesichert und basiert offenbar auf der japanischen FM-Towns-Version.

Nach Angaben des Finders läuft das eigentliche Programm auf der PC-Seite, während die Mega-Drive-Hardware die Musik übernimmt. Die genaue Aufgabenteilung zwischen beiden Seiten ist noch nicht geklärt. Auch der damalige Veröffentlichungsstatus der erhaltenen Fassung bleibt offen.

Weitere Titel wurden ausdrücklich für den TeraDrive angeboten oder entsprechend gekennzeichnet. Das belegt ihre Lauffähigkeit auf dem PC-Teil, aber keinen Zugriff auf 68000, VDP oder Mega-Drive-Klanghardware. Eine TeraDrive-Ausgabe eines DOS/V-Spiels war daher nicht automatisch Hybridsoftware.

Entwicklungsrechner oder vielseitiger PC?

Die Firmware war auf spezielle TeraDrive-Programme vorbereitet. Entwickler konnten Code auf der PC-Seite erstellen, Daten in erreichbare Speicherbereiche übertragen und Programme oder Routinen auf der Mega-Drive-Hardware ausführen. Zeitgenössische Berichte erwähnten dafür vorgesehene Werkzeuge.

Ein allgemein erhältliches Entwicklungspaket mit vollständiger Hardwarebeschreibung und kommerziellem Mega-Drive-SDK ist nicht bekannt. Segas Werbung stellte Programmierung und Entwicklung neben Büroanwendungen, Multimedia und gewöhnliche Spiele.

Der TeraDrive eignete sich für Entwicklungsaufgaben und war technisch darauf vorbereitet. Als reine Entwicklerstation wurde er nicht angeboten. Seine Firmware zeigt, was möglich war; eine breite Verwendung in professionellen Studios ist nicht dokumentiert.

Aufrüsten: ein Steckplatz und zu viele Möglichkeiten

Sega sah zwei reguläre Ausbauwege vor. Der PC-Arbeitsspeicher ließ sich bis 2,5 MB erweitern, und ein einzelner AT-Bus-kompatibler Steckplatz nahm eine Half-Size-Karte auf.

Für einen DOS-PC war dieser eine Steckplatz schnell vergeben. Eine Sound-Blaster-kompatible Karte verbesserte viele Spiele deutlich, weil die PC-Seite ab Werk nur einfache Beep- und PCM-Funktionen bot. Die FM- und PSG-Klangerzeugung des Mega Drive stand gewöhnlicher DOS-Software nicht automatisch als Soundkarte zur Verfügung.

Die Karte musste in das flache Gehäuse passen und mit der Stromversorgung des TeraDrive auskommen. Eine volle ISA-Kompatibilität auf dem Papier bedeutete noch nicht, dass jede zeitgenössische Karte mechanisch und elektrisch problemlos funktionierte.

Mehr als 2,5 MB RAM

Die Hauptplatine und das BIOS begrenzten den regulären Ausbau auf 2,5 MB. Model 3 war bereits vollständig bestückt.

Spätere Umbauten erreichten deutlich mehr Speicher, teilweise bis zu 8,5 MB. Dafür reichen größere Module allein nicht aus. Zusätzliche Verdrahtung und Eingriffe in die Platine sind nötig.

Mehr RAM verbessert Windows und speicherhungrige DOS-Anwendungen. Für die meisten gewöhnlichen Mega-Drive-Spiele ändert sich nichts, da deren Speicherbereich von der PC-Aufrüstung getrennt bleibt.

Der fest verlötete 286

Auch ein CPU-Upgrade war nicht vorgesehen. Der 80286 sitzt direkt auf der Hauptplatine. Ein Austausch erfordert das Auslöten des Prozessors, einen nachgerüsteten Sockel und je nach Beschleuniger weitere Änderungen an Takt und Platine.

Solche Umbauten zeigen, was technisch möglich ist. Für einen seltenen Rechner sind sie kein naheliegender Standardausbau. Der größte Flaschenhals blieb zudem nicht allein die CPU: wenig RAM, der einzelne Steckplatz und die begrenzte Festplatte wirkten gleichzeitig.

Die 30-MB-Festplatte

Model 3 enthielt eine 30-MB-Festplatte aus IBMs WDL-330-Familie. In erhaltenen Geräten wurde unter anderem eine WDL-330PS dokumentiert. Die gelegentlich genannte WDL-320 mit 20 MB passt weder zu Segas offizieller Model-3-Ausstattung noch zu den untersuchten Rechnern.

Die Bezeichnung der Schnittstelle sorgt bis heute für Verwirrung.

XTA steht für XT Attachment. Dabei handelt es sich um eine frühe 8-Bit-Festplattenschnittstelle für Rechner der XT-Klasse. Ein großer Teil der Controller-Elektronik sitzt bereits im Laufwerk. XTA ähnelt damit im Grundgedanken dem späteren ATA beziehungsweise IDE, ist aber nicht mit dessen 16-Bit-Schnittstelle kompatibel.

Die in frühen IBM-PS/2-Systemen verwendete Lösung wird häufig ebenfalls als XTA bezeichnet. Technisch verwendet sie jedoch andere Befehle und Register. Eine gewöhnliche XTA-Festplatte lässt sich deshalb nicht einfach anschließen. „XTA“ beschreibt hier eher die Geräteklasse als einen vollständig kompatiblen Standard.

ESDI steht für Enhanced Small Device Interface. Dieser Standard aus den Achtzigern verlagerte einen Teil der Signalaufbereitung vom Controller in das Laufwerk und erlaubte höhere Datenraten als die ältere ST-506-Technik. Gewöhnliches ESDI arbeitete mit getrennten Steuer- und Datenkabeln.

Der MAME-Treiber bezeichnet die noch nicht nachgebildete TeraDrive-Festplattentechnik als eingebautes ESDI-Interface und ausdrücklich nicht als IDE. Das WDL-330-Laufwerk des TeraDrive verwendet jedoch keinen normalen ESDI-Kabelsatz, sondern einen IBM-spezifischen Anschluss, über den auch die Stromversorgung geführt wird.

Für den Leser ist der praktische Punkt wichtiger als die strittige Bezeichnung: Eine normale IDE-, XTA- oder ESDI-Festplatte lässt sich nicht direkt einsetzen.

Heute gehört das Originallaufwerk zu den schwierigsten Bestandteilen des Rechners. Ein funktionierendes Exemplar sollte zunächst vollständig gesichert werden. Für einen Ersatz sind ein zusätzlicher Controller, ein angepasster Adapter oder ein moderner Massenspeicherumbau nötig.

XT-IDE- und CompactFlash-Lösungen bieten mehr Speicher und höhere Zuverlässigkeit. Ihr Controller belegt jedoch den einzigen regulären Erweiterungssteckplatz. Damit konkurriert die neue Festplatte unmittelbar mit der Soundkarte.

Moderne Ersatz-Riser können mehrere ISA-Steckplätze bereitstellen und diesen Konflikt entschärfen. Sie verändern den ursprünglichen Ausbau und benötigen je nach Kartenbestückung eine angepasste Stromversorgung.

Für einen heute regelmäßig verwendeten TeraDrive ist eine zuverlässige Speicherlösung die sinnvollste Aufrüstung. Danach folgt für DOS-Spiele eine kompatible Soundkarte. Mehr RAM hilft ausgewählten Anwendungen; ein CPU-Umbau greift dagegen tief in die seltene Hardware ein.

Mega-CD, 32X und Mega Adapter

Der TeraDrive besitzt den Erweiterungsanschluss des Mega Drive. Die dokumentierte Pinbelegung enthält auch Signale, die vom Mega-CD verwendet werden. Ein gewöhnliches Mega-CD passt wegen der Gehäuseform trotzdem nicht direkt an den Rechner.

Zeitgenössische Berichte erwähnten eine eigene CD-ROM-Erweiterung für den TeraDrive. Sie sollte offenbar sowohl PC- als auch Mega-Drive-Anwendungen dienen. Eine Verkaufsversion erschien nicht.

Mit einer angepassten Verlängerung des Erweiterungsbusses lässt sich ein gewöhnliches Mega-CD technisch verbinden. Das war weder eine von Sega angebotene Aufrüstung noch eine Lösung, die ein damaliger Käufer aus der Verpackung nehmen konnte.

Beim 1994 erschienenen Super 32X liegen die Schwierigkeiten an anderer Stelle. Die dokumentierte Speicherbelegung des TeraDrive führt die üblichen MARS- und 32X-Registerbereiche auf, falls ein 32X vorhanden ist. Die Grundarchitektur steht dem Zusatz damit nicht vollständig im Weg.

Der versenkte Modulschacht verhindert jedoch das direkte Aufstecken. Mindestens eine Modulverlängerung ist erforderlich. Hinzu kommt die Bildausgabe: Das 32X muss sein eigenes Bild mit dem Videosignal des Mega Drive verbinden. Der TeraDrive besitzt dafür nicht die gewöhnliche Mega-Drive-Verkabelung. Ein vollständiger Aufbau benötigt daher weitere Anpassungen. Eine offizielle Unterstützung ist nicht bekannt.

Der japanische Mega Adapter für Mark-III- und Master-System-Spiele scheitert bereits an seiner Form. Sega nennt ausdrücklich, dass er weder am Mega Drive 2 noch am TeraDrive angebracht werden kann. (SEGA セガ | 製品情報)

Der eingebaute Mega-Drive-Chipsatz machte den Rechner damit nicht automatisch zu allen früheren und späteren Zusatzgeräten kompatibel. Modulschacht, Gehäuse und Videoanschlüsse setzten eigene Grenzen.

Ein Markt ohne Verkaufszahlen

Der TeraDrive blieb auf Japan beschränkt. Westliche Vorberichte spekulierten über eine Veröffentlichung in Großbritannien und weiteren Ländern, doch dazu kam es nicht.

Sega veröffentlichte keine bekannten Verkaufszahlen. Auch ein genaues Produktionsende ist nicht dokumentiert. Angaben wie „nach wenigen Monaten eingestellt“ oder „nur 10.000 Exemplare gebaut“ haben keine gesicherte Grundlage.

Seine geringe Marktwirkung ist trotzdem erkennbar. Es gab keinen regulären Nachfolger, nur wenige speziell angepasste Programme und keine internationale Vermarktung.

Für einen Käufer, der hauptsächlich Mega-Drive-Spiele spielen wollte, war bereits Model 1 teuer. Wer vor allem einen PC benötigte, bekam leistungsfähigere oder leichter erweiterbare Rechner. Der TeraDrive musste seinen Preis mit der Verbindung beider Hardwarebereiche rechtfertigen.

Diese Verbindung existierte. Das Softwareangebot nutzte sie nur selten.

Was vom TeraDrive bleibt

Der TeraDrive war kein gewöhnlicher PC mit einer zusätzlich eingesetzten Konsolenkarte. Sega und IBM Japan kombinierten einen 286-Rechner, eine veränderte Mega-Drive-Architektur, zwei Videosysteme und einen kontrollierten Austausch zwischen den Adressräumen auf einer gemeinsamen Hauptplatine.

Die Hardware beherrschte zwei klar getrennte Betriebsweisen. PC und Mega Drive konnten unabhängig und gleichzeitig laufen. Für den engeren Zugriff übergab eine Seite der anderen die Kontrolle. Ein zusätzliches Firmware-ROM verwaltete Startmenü, Kanji-Zeichensatz, Modulschutz und mehrere Formen TeraDrive-spezifischer Software.

Die Grenzen waren ebenso konkret. Der 286 bot wenig Zukunftsreserve, der offizielle RAM-Ausbau endete bei 2,5 MB, und der einzige Erweiterungssteckplatz zwang zur Wahl zwischen Sound, Massenspeicher und anderer Peripherie. Die ungewöhnliche Festplattenschnittstelle erschwert Reparaturen bis heute. Spätere Konsolenzusätze benötigen Adapter oder weitere Umbauten.

Sega und IBM bauten eine technisch ernst zu nehmende Verbindung zwischen zwei Rechnerwelten. Für ein ebenso überzeugendes Angebot aus Software und Erweiterungen reichte es nicht.

 

Uridium (1986): Woran man einen Braybrook erkennt

Einen Van Gogh erkennen viele auch ohne Kunststudium: an der unruhigen Pinselführung und den kräftigen Farben, oft noch bevor Sonnenblumen oder Zypressen ins Bild kommen. Auch Andrew Braybrooks Spiele besaßen Mitte der achtziger Jahre eine erkennbare Handschrift. Metallische Oberflächen gewannen durch harte Schatten räumliche Tiefe, Fahrzeuge und Roboter wirkten wie Bauteile einer größeren Maschine.

Uridium zeigt diese Merkmale bereits auf dem ersten Bildschirm. Ein kleiner Raumjäger gleitet über die Oberseite eines gewaltigen Kriegsschiffs, vorbei an Landebahnen, Generatoren und technischen Aufbauten. Zeitgenössische Tester erkannten darin sofort den Stil von Paradroid. Commodore User verwies auf Braybrooks bekannte Metalloptik, Your Commodore sprach von „pseudo 3D metallic graphics“, Zzap!64 hob die Reliefwirkung der Schatten hervor.

Trotzdem wiederholte Braybrook seinen Vorgänger nicht. Paradroid verband Erkundung, Roboterklassen, Kämpfe und das Übernahmesystem. Uridium konzentrierte sich auf die Bewegung eines einzigen Fahrzeugs. Der vertraute Metallic Look blieb erhalten, während sich Grafik, Steuerung und Programmstruktur einem neuen Ziel unterordneten: Geschwindigkeit.

Die Zahl, die das Spiel bestimmte

Nach mehreren Dragon-32-Konvertierungen wechselte Braybrook zum Commodore 64, den er zunächst bei der Umsetzung von Steve Turners Lunattack kennenlernte. Mit Gribbly’s Day Out und Paradroid folgten eigene Spiele. Für Uridium setzte er sich ein klares technisches Ziel: 50 Bildschirmaktualisierungen pro Sekunde auf einem PAL-C64.

Gribbly’s Day Out hatte nach seiner späteren Erinnerung ungefähr 25 Bilder pro Sekunde erreicht, Paradroid etwa 17. Für das neue Spiel strich er Funktionen, die zu viel Rechenzeit beanspruchten, und hielt den Entwurf bewusst einfacher. Braybrook beschrieb die Manta später als Ferrari: Die hohe Geschwindigkeit sei vorhanden, der Spieler müsse sie aber nicht auf jeder Strecke ausnutzen.

Damit verlagerte sich der Anspruch. Paradroid verlangte den Überblick über mehrere miteinander verbundene Systeme. Uridium verlangte die Beherrschung eines ungewöhnlichen Fluggeräts und die genaue Kenntnis der gegnerischen Schiffe.

Ein Kriegsschiff als Spielfeld

Fünfzehn Super-Dreadnoughts umkreisen Planeten und entziehen ihnen Rohstoffe. Jeder verarbeitet ein anderes Metall. Der Spieler übernimmt einen Manta-Raumjäger und soll die Schiffe nacheinander zerstören.

Ein Dreadnought ist dabei kein einzelner Gegner. Das gesamte Level liegt auf seiner Oberseite. Mauern, Generatorfelder, Antennen und Landebahnen ziehen horizontal unter der Manta hindurch. Feindliche Jäger greifen in Formationen an, Generatoren setzen zielsuchende Minen frei. Kleine Ziele können beschossen werden, hohe Aufbauten müssen umflogen werden.

Die Manta steuert sich anders als das übliche Schiff eines horizontalen Shoot-’em-ups. Der Joystick regelt Flughöhe und Geschwindigkeit. Starkes Abbremsen löst eine Kehrtwende aus: Der Jäger steigt kurz an, rollt über die Seite und fliegt in der Gegenrichtung weiter. Mit gedrücktem Feuerknopf lässt er sich außerdem um 90 Grad auf die Seite legen, sodass seine schmalere Silhouette durch enge Passagen passt.

Wende und Seitenrolle verändern Richtung, Höhe und Kollisionsfläche. Beide benötigen Platz und müssen ebenso bewusst eingesetzt werden wie die Waffen. Wer an der falschen Stelle abbremst, kann nach dem Manöver unmittelbar vor dem nächsten Aufbau landen.

Sobald genügend Angriffswellen abgewehrt wurden, erscheint „Land Now“. Der Spieler setzt auf der Hauptlandebahn auf; danach folgt die Fuel Rod Chamber. Die Anleitung beschreibt diesen Abschnitt als Entfernung von Brennstäben aus dem Metallkonverter. Spielerisch funktioniert er wie die Risikofunktion eines britischen Geldspielautomaten: Der Bonus steigt, während der Spieler rechtzeitig „Quit“ wählen muss. Verpasst er den Ausstieg, verliert er ein Leben. Your Commodore verglich den Ablauf bereits 1986 mit dem „gamble feature on a fruit machine“.

Nach dem Bonusspiel hebt die Manta wieder ab, während sich der Dreadnought von hinten nach vorn auflöst. Der wiederkehrende Ablauf aus Luftkampf, Landung und Abflug gibt den vergleichsweise kurzen Levels eine klare Form.

Wie der C64 das Tempo hält

Hewson warb in der Anleitung mit 50 Bildschirmzyklen pro Sekunde, Einzelpixel-Scrolling sowie einer Verbindung aus Hardware- und Software-Sprites. Eine spätere Untersuchung des veröffentlichten Programms macht nachvollziehbar, wie diese Leistung erreicht wurde.

Der unter dem Pseudonym mwenge arbeitende Autor untersuchte die C64-Fassung mittels Reverse Engineering. Er disassemblierte den Maschinencode, identifizierte Routinen und Datenstrukturen und kommentierte den rekonstruierten 6510-Assemblercode. Es handelt sich um eine nachträgliche Rekonstruktion des ausgelieferten Programms, nicht um Braybrooks ursprünglichen Quelltext. Der Code lässt sich wieder zu einer lauffähigen Fassung assemblieren und erlaubt daher einen genauen Blick auf die tatsächlichen Abläufe.

Die Hauptschleife läuft synchron zum Rasterstrahl des Fernsehbildes. Der VIC-II baut das Bild Zeile für Zeile auf und löst an festgelegten Rasterpositionen Interrupts aus. Sobald der Rasterstrahl den unteren Bildschirmbereich erreicht, beginnt die nächste Runde der Spielberechnungen. Das Programm aktualisiert unter anderem Schüsse, Scrollposition, Oberfläche, Sterne, Gegner und Eingaben und wartet anschließend auf dieselbe Phase des nächsten Fernsehbildes. Auf einem PAL-C64 wiederholt sich dieser Takt 50-mal pro Sekunde. Weniger dringende Aufgaben werden über mehrere Durchläufe verteilt.

Die Dreadnoughts liegen nicht als vollständige Bilder im Speicher. Ihre Oberflächen bestehen aus Zeichengrafik, die Braybrook aus wiederverwendbaren Bauteilen zusammensetzt. Größere Verschiebungen erfolgen in ganzen Zeichenpositionen, die Pixel dazwischen bewegt das Feinscrolling des VIC-II. Der Prozessor muss deshalb nicht fortlaufend eine komplette Bitmap neu zeichnen.

Auch der Sternenhintergrund entsteht innerhalb dieser Zeichengrafik. Das Programm verschiebt die Pixel besonderer Sternzeichen entgegen der Scrollrichtung. Die Metallfläche zieht vorbei, während die Sterne scheinbar im Weltraum stehen bleiben. Eine zweite frei bewegliche Hintergrundebene ist dafür nicht erforderlich.

Manta, Schatten und Gegner verwenden Hardware-Sprites. Die Laserschüsse zeichnet das Programm dagegen in veränderbare Bildschirmzeichen. Nach jedem Bewegungsschritt stellt es den ursprünglichen Hintergrund wieder her und setzt den Schuss an seiner neuen Position ein. So bleiben die begrenzten Hardware-Sprites für größere Objekte frei. Gary Liddon erwähnte diese Softwaregeschosse bereits im damaligen Zzap!64-Test.

Der Schatten der Manta belegt einen eigenen Sprite und wird abhängig von der Flughöhe versetzt. Zwei flache Grafiken vermitteln dadurch Abstand zur Oberfläche. Steve Turner schrieb die dreistimmige Titelmusik und programmierte die Soundeffekte; während des Spiels bleibt der Klang auf kurze Schüsse, Explosionen und Signale konzentriert.

Wenn die Geschwindigkeit weiter reicht als der Bildschirm

Das schnelle Scrolling erzeugt zugleich die deutlichste Schwäche des Spiels. Bei hohem Tempo zeigt der sichtbare Ausschnitt nur wenig von der vorausliegenden Strecke. Mauern und enge Durchgänge erscheinen spät, viele Stellen lassen sich beim ersten Versuch kaum sicher einschätzen.

Zzap!64 nannte den kleinen Bildausschnitt als wesentlichen Kritikpunkt und betonte, dass die Karten der Dreadnoughts gelernt werden müssten. Die Tipps des Sinclair User zur späteren Spectrum-Fassung empfahlen ebenfalls, sich den Aufbau einzuprägen, um mit voller Geschwindigkeit fliegen zu können.

Aus einem zunächst hektischen Flug entsteht dadurch eine feste Folge gelernter Manöver: vor einem Aufbau abbremsen, während der Wende über eine Mine steigen und den nächsten Kanal in Seitenlage durchqueren. Diese Streckenkenntnis gibt den kurzen Schiffen mehr Substanz, bringt aber Wiederholungen mit sich.

Die zeitgenössische Presse bewertete die technische Ausführung deutlich höher als die Grundidee. Zzap!64 vergab 94 Prozent und erklärte Uridium zu einem der stärksten Arcade-Spiele des C64. Commodore User und Your Commodore sahen Einflüsse von Defender und Scramble, lobten jedoch die präzise Steuerung, das Tempo und Braybrooks metallische Grafik.

Auch die deutschen Tests hoben Scrolling, räumliche Wirkung und Klang hervor. Happy Computer stellte zugleich fest, dass Uridium weniger strategische Tiefe als Paradroid besaß. Die ASM vergab Höchstnoten für Grafik und Sound, bewertete Spielidee und Motivation niedriger. Die Magazine beschrieben damit dieselbe Spannung: eine vertraute Shooter-Grundlage, ausgeführt mit einer für den C64 außergewöhnlichen technischen Sicherheit.

Dominic Robinson baut Uridium für den Spectrum neu

Die Spectrum-Fassung stand vor einem grundsätzlichen Problem. Braybrook hatte das Original um die Fähigkeiten des C64 gebaut. Der ZX Spectrum besaß weder Hardware-Sprites noch einen vergleichbaren Grafikchip für Feinscrolling; seine blockweise Farbdarstellung erschwerte schnelle, farbige Objekte zusätzlich.

Dominic Robinson begann mit einer technischen Demonstration. Sie zeigte, dass sich eine an Uridium erinnernde Oberfläche auf dem Spectrum mit mindestens 25 Bildern pro Sekunde scrollen ließ. Andrew Hewson hielt das zunächst kaum für den Ausgangspunkt eines vollständigen Spiels, weil die Demo den Hintergrund mehrfach im Speicher hielt. Steve Turner zog den gegenteiligen Schluss und drängte darauf, Robinson zu verpflichten.

Für die fertige Umsetzung reduzierte Robinson die Farbigkeit der Dreadnoughts. Große Teile des Spielfelds blieben zweifarbig, wodurch die Konturen bei hoher Geschwindigkeit lesbar blieben und viele Attributkonflikte vermieden wurden. Der Klang fiel schlichter aus als auf dem C64.

Sinclair User lobte das schnelle und gleichmäßige Scrolling. Die dort genannten 17 Bilder pro Sekunde stammten ausdrücklich aus dem Werbematerial und waren keine unabhängige Messung. Das Magazin vergab fünf Sterne und die Auszeichnung „Sinclair User Classic“. CRASH kam auf 90 Prozent, vermerkte aber auch die schwächere Farbwirkung und eine weniger unmittelbare Reaktion der Manta beim Wenden.

Robinson übertrug damit nicht jede Eigenschaft gleichwertig. Er bewahrte jedoch den schnellen Flug über eine zusammenhängende Oberfläche, die Richtungswechsel, die engen Passagen und den Wechsel zwischen Angriff und Landung. Diese Elemente hielten Uridium auch auf einer sehr anderen Maschine zusammen.

Zwei Joystickstandards und ein erfundenes Element

Der ursprüngliche ZX Spectrum besaß keinen eingebauten Joystickanschluss. Viele Besitzer verwendeten ein externes Kempston-Interface, das Spiele über eine eigene Ein-/Ausgabeadresse abfragten. Sinclair nutzte für seine Joysticklösung ein anderes Verfahren. Der Spectrum 128K +2 besaß zwar zwei eingebaute Buchsen, verwendete softwareseitig aber den Sinclair-Standard.

Ein Programm mit Kempston-Unterstützung erkannte die Anschlüsse des +2 deshalb nicht automatisch. Genau daran scheiterte die erste Auflage von Uridium. Obwohl die Verpackung Kompatibilität versprach, funktionierten frühe Exemplare am +2 nur über die Tastatur. Sinclair User zitierte einen Hewson-Sprecher:

“There was a problem with early batches of the game but that's been sorted-out and the new version of the game is fully compatible with the 128K +2 joystick.”

„Bei den frühen Versionen des Spiels gab es ein Problem, das inzwischen behoben wurde. Die neue Version ist vollständig mit dem Joystick-Anschluss des 128K +2 kompatibel.“

Hewson bestätigte damit den Fehler und lieferte eine korrigierte Fassung. Welche Routinen geändert wurden, wäre nur durch einen Vergleich beider Versionen festzustellen.

Der Titel des Spiels geht auf Robert Orchard zurück, einen früheren Kollegen Braybrooks bei GEC. Orchard hielt „Uridium“ offenbar für ein reales Element oder verwechselte es mit Iridium. Die Überprüfung ergab, dass es den Begriff nicht gab, was ihn für Graftgold gerade brauchbar machte. Die Anleitung vermerkt:

“Name created by Robert ‘I thought it really existed’ Orchard”

„Der Name wurde von Robert ‚Ich dachte, das gäbe es wirklich‘ Orchard erfunden.“

Der erfundene Name passt zu einer Welt aus metallischen Kriegsschiffen, während die fünfzehn Dreadnoughts nach tatsächlichen Elementen benannt sind.

Uridium ist an seinen Metallflächen und Schatten sofort als Braybrook-Spiel zu erkennen. Geprägt wurde es jedoch von seinem technischen Ziel. Levelaufbau, Grafiktricks und Steuerung mussten mit dem Tempo des Scrollings zusammenarbeiten. Dominic Robinsons Spectrum-Fassung bestätigte später, dass genau diese Bewegung den Kern des Spiels bildete.

 

Turbo Esprit – Die Stadt, die Regeln hatte

In Turbo Esprit hält der Verkehr an roten Ampeln, setzt den Blinker und weicht Baustellen aus. Fußgänger überqueren die Straße, Arbeiter stehen an Laternen, Tankstellen versorgen den Lotus mit neuem Treibstoff. Der Spieler fährt währenddessen einen Sportwagen mit eingebautem Maschinengewehr.

1986 war schon die funktionierende Stadt ungewöhnlich. Dass man ihre Regeln ebenso gut missachten konnte, sollte für den späteren Ruf des Spiels noch wichtig werden.

Die Ausgangsidee entstand bei Durell Software. Mike Richardson erinnerte sich bei Crash Live 2024, dass das Unternehmen einen Marketingberater hinzugezogen hatte. Dessen Empfehlung lautete, ein Autospiel zu produzieren. Durell-Gründer Robert White schlug vor, es in einer Stadt anzusiedeln. Richardson musste anschließend herausfinden, wie sich diese Idee auf einem ZX Spectrum mit 48 Kilobyte Speicher umsetzen ließ.

Rückblickend bezeichnete er Turbo Esprit als Höhepunkt seiner damaligen Spectrum-Arbeiten. Nach seiner Erinnerung dauerte die Entwicklung ungefähr zehn Monate. Schon 2004 hatte er gegenüber Retro Gamer denselben Zeitraum genannt und erklärt, dass er bis dahin an keinem Spiel länger gearbeitet hatte. Während der Entwicklung wurde sein erstes Kind geboren; programmiert wurde teilweise zwischen Betreuung und Füttern.

Die Spectrum-Version bildete die Grundlage. Turbo Esprit wurde zunächst für den Sinclair-Rechner geschrieben und anschließend auf Commodore 64 und Amstrad CPC übertragen. Mike Richardson programmierte die Spectrum-Fassung. Für den CPC werden Nicholas Wilson und Richardson gemeinsam genannt. Tim Hayward gestaltete Verpackung und Illustration. Durell warb außerdem mit technischer Unterstützung durch Lotus Cars.

Technik aus Combat Lynx

Richardson begann bei der Darstellung nicht vollständig von vorn. Er verwendete ein Verfahren, das bereits bei Combat Lynx zum Einsatz gekommen war. Die Landschaft wurde dort aus horizontalen Linien aufgebaut. Zu den einzelnen Bildschirmzeilen lagen Daten vor, aus denen sich unter anderem ergab, wie hoch ein Objekt an dieser Stelle erscheinen musste. Beim Näherkommen wurden Straßenränder, Gebäude und Fahrzeuge entsprechend größer dargestellt.

Nach Richardsons Erinnerung arbeitete die Darstellung mit ungefähr 80 horizontalen Linien. Die Stadt bestand nicht aus frei berechneten Polygonen. Ihre räumliche Wirkung entstand aus sparsamen Daten und einer genau auf den Spectrum abgestimmten Routine.

Der Speicher war vollständig ausgefüllt. Richardson komprimierte, wo immer es möglich war. Selbst das große Lenkrad im Cockpit wurde nicht als komplette Grafik abgelegt. Das Programm zeichnete seine Linien und füllte die entstehenden Flächen. So blieb Speicher für Verkehr, Fußgänger, Ampeln, Baustellen und Missionsfahrzeuge.

Die weitgehend monochrome Straßenansicht hält Fahrzeuge, Passanten und Straßendetails klar erkennbar. Der für den Spectrum typische Attribute Clash verschwindet zwar nicht vollständig, fällt während der Fahrt aber selten störend auf.

Vier getrennte Städte

Zur Wahl stehen Wellington, Gamesborough, Minster und Romford. Die vier Städte bilden kein zusammenhängendes Gebiet. Jede wird einzeln geladen. Wer wechseln will, muss zurück zur Auswahl und eine andere Karte nachladen.

Romford ist zugleich der Name eines realen Londoner Stadtteils. Die Spielstadt bildet ihn nicht nach. Richardson hatte Romford nach eigener Aussage nie besucht. Bei Crash Live zerlegte er den Namen scherzhaft in „read-only memory“ und „Ford“.

Jede Stadt besitzt ein Straßennetz mit Kreuzungen, Seitenstraßen, Einbahnstraßen und unterschiedlich breiten Fahrbahnen. Der Lotus kann beschleunigen, bremsen, die Spur wechseln, abbiegen und rückwärtsfahren. Eine Drehung der Umgebung wird beim Abbiegen nicht berechnet. Stattdessen wechselt das Spiel direkt in die Ansicht der neuen Straße.

Das Geschehen erscheint gleichzeitig aus zwei Perspektiven. Der Spieler blickt über Lenkrad und Instrumente aus dem Cockpit, sieht den eigenen Lotus aber zusätzlich als kleines Fahrzeug auf der Straße. Diese Außenansicht erleichtert Spurwechsel und Kollisionen. Tacho, Drehzahlmesser, Tankanzeige und Motortemperatur erfüllen spielerische Funktionen. Treibstoff muss an Tankstellen ergänzt werden. Schäden können den Motor überhitzen, Werkstätten setzen den Wagen wieder instand.

Der übrige Verkehr fährt nicht nur geradeaus über den Bildschirm. Fahrzeuge halten an Ampeln, biegen an Kreuzungen ab, zeigen Richtungswechsel an und reagieren auf Hindernisse. Baustellen blockieren einzelne Spuren. Fußgänger bewegen sich an den Straßen entlang und überqueren die Fahrbahn. CRASH erwähnte außerdem Arbeiter an Straßenlaternen. Viele dieser Details sind für die Mission unwichtig. Gemeinsam sorgen sie dafür, dass die Stadt nicht ausschließlich auf den Spieler wartet.

Lieferwagen, Treffpunkte und ein gepanzertes Fahrzeug

Der Spieler übernimmt die Rolle eines Agenten, der einen Heroinschmuggel unterbrechen soll. Ein gepanzertes Fahrzeug fährt durch die Stadt und beliefert vier Wagen der Bande. Diese transportieren die Ware anschließend zu ihren Verstecken.

Die Lieferfahrzeuge sollen möglichst nach der Übergabe gestoppt werden. Dann erhält der Spieler mehr Punkte und im Rahmen der Handlung bessere Beweise. Das gepanzerte Fahrzeug kann ebenfalls ausgeschaltet werden. Geschieht das zu früh, enden jedoch die weiteren Lieferungen und damit zusätzliche Möglichkeiten, Punkte zu sammeln.

Das wichtigste Werkzeug ist die Stadtkarte. Sie zeigt die Position des Lotus und der relevanten Fahrzeuge. Meldungen der Einsatzzentrale nennen Sichtungen und Straßenabschnitte. Wer die Routen beobachtet, kann mögliche Treffpunkte erkennen, eine Abfangposition suchen und auf die Ankunft eines Lieferwagens warten.

Die Karte pausiert das Spiel nicht. Während der Spieler auf den Stadtplan blickt, rollt der Lotus weiter, der Verkehr bewegt sich und die Schmuggler setzen ihre Fahrt fort. Wer zu lange auf die Karte schaut, kann beim Zurückschalten bereits vor einer Wand stehen.

Die Lieferwagen lassen sich beschießen oder durch wiederholtes Rammen zur Aufgabe zwingen. Eine Festnahme bringt mehr Punkte als die Zerstörung des Fahrzeugs. Gepanzerte Wagen müssen gerammt werden, weil das Maschinengewehr gegen sie wirkungslos bleibt. Hinzu kommen sogenannte Hit Cars, deren Insassen auf den Lotus feuern. Treffer können die Steuerung und den Motor beschädigen.

Wer Karte, Meldungen und Fahrzeugrouten ignoriert, fährt lange ohne erkennbares Ziel durch die Straßen. Erst die Beobachtung der Lieferkette macht aus der Stadtrundfahrt eine geplante Verfolgung.

Der andere Highscore

Das Spiel erlaubt auch Handlungen, die mit dem Auftrag wenig zu tun haben. Der Spieler kann zivile Fahrzeuge rammen, Autos beschießen, Ampeln missachten und Fußgänger überfahren. Dafür werden Strafpunkte vergeben. Neben der normalen Bestenliste besitzt Turbo Esprit eine eigene Tabelle für besonders rücksichtslose Fahrer.

CRASH bemerkte bereits 1986, dass selbst das Sammeln von Strafpunkten unterhaltsam sein konnte. Für viele Spieler lag darin bald ein eigener Reiz: Wer die Schmuggler nicht fand, konnte immer noch Kreuzungen blockieren, Fahrzeuge rammen und den Strafpunktestand in die Höhe treiben.

Warum heute viele an GTA denken

Diese Freiheit erklärt den späteren Vergleich mit Grand Theft Auto. Turbo Esprit bietet eine frei befahrbare Stadt, zivilen Verkehr, Fußgänger, Verfolgungsjagden und Schusswaffen im Fahrzeug. Verstöße gegen die Verkehrsordnung und Angriffe auf Unbeteiligte werden vom Spiel registriert.

Viele Spieler und Retroautoren sehen darin heute eine Art Proto-GTA. Der Vergleich beschreibt erkennbare Gemeinsamkeiten. Ob Turbo Esprit die Entwickler der späteren Reihe tatsächlich beeinflusste, bleibt hypothetisch.

Mit einer offenen Welt im heutigen Sinn hat das wenig zu tun. Der Fahrer bleibt im Lotus, Gebäude sind nicht zugänglich, Nebenaufträge gibt es nicht und die vier Städte bilden getrennte Karten. Für 1986 war schon die Kombination aus freier Navigation, zivilem Verkehr und beweglichen Missionszielen ungewöhnlich.

Die britische Presse erkennt die Leistung

Die britischen Spectrum-Magazine reagierten ausgesprochen positiv.

John Gilbert vergab im Sinclair User vom Mai 1986 fünf Sterne und nahm Turbo Esprit als „Sinclair User Classic“ auf. Er bezeichnete es als spektakuläre Simulation und hob die flüssige Straßendarstellung sowie die Zahl kleiner Details hervor.

CRASH widmete dem Spiel in Ausgabe 28 zwei Seiten und vergab 88 Prozent. Grafik und Computernutzung erhielten jeweils 90 Prozent, Spielbarkeit 89 Prozent und Suchtfaktor 90 Prozent. Die Tester beschrieben die Steuerung zunächst als gewöhnungsbedürftig, lobten anschließend aber die Verfolgungsjagden und die Reaktionen des Stadtverkehrs. Besonders fielen Fahrzeuge auf, die Ampeln beachteten, Hindernissen auswichen und ihre Blinker benutzten.

Your Sinclair erklärte Turbo Esprit im Juni 1986 zum „Megagame“ und vergab neun von zehn Punkten. Die großen britischen Spectrum-Magazine bewerteten das Spiel damit durchweg hoch.

Die deutsche ASM reagierte verhaltener. Der Test erkannte die Verbindung aus Cockpitansicht, Stadtkarte und Verbrecherjagd an, sah darin aber mehrere bereits bekannte Elemente. Das Fazit lautete:

„Interessant – aber nichts umwerfend Neues!“

Grafik, Sound und Motivation erhielten überwiegend sieben Punkte, die Spielidee acht. Der Beitrag behandelte C64, Spectrum und Schneider gemeinsam und erlaubt daher keinen sauberen Versionsvergleich.

Drei Rechner, drei Geschwindigkeiten

Die Spectrum-Fassung bleibt die Referenzversion. Hier greifen Verkehr, Spurwechsel und Verfolgung am besten ineinander. Die weitgehend monochrome Straßendarstellung wirkt sparsam, bleibt aber scharf und vergleichsweise flüssig. Fahrzeuge, Passanten und Straßendetails sind trotz des begrenzten Bildausschnitts gut zu erkennen.

Auf dem Amstrad CPC kommt mehr Farbe ins Bild. Fahrzeuge und Umgebung lassen sich dadurch stärker voneinander unterscheiden. Wegen der niedrigeren horizontalen Auflösung wirken Cockpit und Straßendetails gröber. Bei geringem Verkehrsaufkommen bleibt die Fassung gut spielbar. Mit mehreren Fahrzeugen sinkt die Geschwindigkeit merklich. Die Stadt funktioniert weiterhin, die Verfolgungsjagden verlieren jedoch an Tempo.

Die C64-Version läuft erheblich langsamer. Das geringere Tempo macht besonders die Verfolgungsjagden zäh. Spurwechsel, Kreuzungen und die Jagd auf Lieferwagen bleiben vorhanden, wirken aber deutlich schwerfälliger.

Der berüchtigte Verriss in ZZAP!64 erschien erst im Mai 1989 und galt der Encore-Budgetausgabe. Das Magazin vergab neun Prozent und kritisierte die langsame Darstellung, die schwache Präsentation und den monotonen Ablauf. Das Urteil bezog sich auf die Wiederveröffentlichung von 1989, drei Jahre nach der ursprünglichen Vollpreisausgabe.

Akustisch ist die Rangfolge weniger eindeutig. Der Spectrum erzeugt mit seinem einfachen Beeper eine kurze Titelmelodie und knappe, raue Effekte. Ein kontinuierliches Motorengeräusch fehlt. CPC und C64 geben die Musik voller wieder und begleiten die Fahrt mit einem dauerhaften Motorton. Der C64 klingt differenzierter, während auf dem CPC einzelne Effekte deutlich hervortreten. Als Gesamtpaket bleibt dennoch die Spectrum-Fassung vorn, weil dort Tempo und Reaktion stimmen.

Veröffentlichungen und Neuauflagen

Die CPC-Fassung erschien in Großbritannien im Mai 1986 auf Kassette und Diskette. Auch die Versionen für ZX Spectrum und Commodore 64 kamen 1986 heraus. Die britische Spectrum-Ausgabe kostete 8,95 Pfund.

Erbe Software veröffentlichte im selben Jahr eine lizenzierte spanische Ausgabe für den Spectrum. Verpackung und Anleitung wurden für den spanischen Markt lokalisiert. Der Begleittext verlegte die Handlung nach Manhattan, während im Spiel weiterhin die vier bekannten Städte und der britische Linksverkehr zu sehen waren.

Encore brachte die Spectrum-Version 1988 als Budgettitel zurück. Die entsprechende C64-Ausgabe folgte 1989 und wurde von Elite Systems vertrieben. Die Spectrum-Neuauflage kostete 2,99 Pfund.

Der Lotus und die Stadt

Turbo Esprit beeindruckte 1986 nicht allein durch die Größe seiner Karten. Entscheidend war, was sich darin bewegte. Verkehrsfahrzeuge folgten ihren Routen, hielten an Ampeln und reagierten auf Hindernisse. Lieferwagen trafen sich mit einem gepanzerten Fahrzeug und transportierten ihre Ladung weiter. Der Spieler konnte diese Abläufe beobachten, unterbrechen oder vollständig ignorieren.

Auf dem Spectrum liefen diese Systeme schnell genug zusammen, um wie Teile derselben Stadt zu wirken. Die langsameren Konvertierungen zeigen, wie stark das Spiel von diesem Tempo abhängt. Sobald der Verkehr stockt, verliert auch die Verfolgung ihren Reiz.

Der Lotus lieferte Namen, Cockpit und Maschinengewehr. Richardsons eigentliche Leistung lag in den Straßen davor.

 

Nascom 2: Als zehn RAM-Chips zum Lieferproblem wurden

Der Nascom 2 sollte 1979 fast alles auf einer Platine vereinen, was ein brauchbarer Mikrocomputer benötigte: Z80A, Monitorprogramm, BASIC, Bildausgabe, Tastatur, Kassetteninterface und Erweiterungsbus. Die geplante RAM-Bestückung ließ sich jedoch nicht in ausreichender Stückzahl beschaffen.

Der Nascom 2 folgte auf einen erfolgreichen Vorgänger. Der Ende 1977 vorgestellte Nascom 1 kombinierte bereits einen Z80-Prozessor mit vollständiger Tastatur, Videoausgabe, Kassetteninterface und parallelen Schnittstellen. Damit bot er erheblich mehr als viele damalige Einplatinenbausätze, deren Bedienung sich auf Hexadezimaltastatur und Leuchtdioden beschränkte. Nascom gab 1979 an, innerhalb von 18 Monaten rund 12.000 Geräte verkauft zu haben. Der Hersteller betrachtete den Nascom 2 deshalb ausdrücklich nicht als Ersatz für das erste Modell. Er sollte die Reihe um einen stärker als vollständiger Computer ausgelegten Bausatz ergänzen, bei dem viele zuvor notwendige Erweiterungen bereits auf der Hauptplatine saßen: ein schnellerer Z80A, mehr Speicherplätze, Microsoft BASIC im ROM, der neue NAS-SYS-Monitor und eine erweiterte Tastatur.

Für den Nascom 2 wurden zehn Kilobyte RAM 1979 zu einem Produktionsproblem. Der britische Hersteller hatte den Rechner als ungewöhnlich vollständig ausgestatteten Einplatinencomputer entworfen. Neben Prozessor, Videoerzeugung und Ein-/Ausgabelogik sollten zehn statische Speicherbausteine vom Typ Mostek MK4118 auf der Hauptplatine sitzen.

Acht davon bildeten den Anwenderspeicher. Je ein weiterer MK4118 diente als Bildschirmspeicher und als Arbeitsbereich für Systemprogramme. Die vollständige Bestückung ergab damit zehn Kilobyte RAM.

Hinzu kamen zehn Kilobyte ROM. Zwei Kilobyte enthielten NAS-SYS 1, den Monitor zum Starten, Untersuchen und Bearbeiten von Programmen. Weitere acht Kilobyte waren mit Microsoft BASIC belegt. Zusammen ergab das die beworbenen 20 Kilobyte Speicher auf der Hauptplatine: zwei Kilobyte Monitor-ROM, acht Kilobyte BASIC, acht Kilobyte Anwender-RAM sowie je ein Kilobyte für Bildschirmspeicher und Workspace. Der Bausatz kostete 295 Pfund zuzüglich Mehrwertsteuer.

Speicher auf einer zusätzlichen Platine

Die Konstruktion setzte voraus, dass Nascom zehn MK4118 für jeden vollständig bestückten Rechner beschaffen konnte. Genau daran scheiterte die geplante Serienkonfiguration. Die Bausteine waren zeitweise nicht in ausreichender Menge verfügbar.

Nascom änderte deshalb das Angebot. Auf der Hauptplatine verblieben die beiden unverzichtbaren MK4118 für Bildschirmspeicher und Workspace. Die acht Bausteine für den Anwenderspeicher entfielen zunächst. Stattdessen erhielten Käufer eine separate dynamische 16-KByte-RAM-Karte für den NAS-BUS.

Zeitgenössische Anzeigen bezeichneten diese Karte als kostenlose Erweiterung und führten den Preis von 295 Pfund zuzüglich Mehrwertsteuer weiter. Die Werbung erklärte zugleich, dass der Rechner wegen der fehlenden MK4118 ohne die acht vorgesehenen Anwenderspeicher ausgeliefert werde.

Die geänderte Ausführung bot damit mehr nutzbaren Speicher als die ursprünglich geplante Vollbestückung. Sie benötigte allerdings eine zusätzliche Platine, eine Busverbindung und ein Netzteil, das auch die Erweiterung versorgen konnte. Aus dem als Einplatinencomputer entworfenen Nascom 2 wurde bereits in seiner frühen Lieferkonfiguration ein System aus mehreren Baugruppen.

Der gepufferte NAS-BUS machte diese Änderung überhaupt praktikabel. Die Erweiterungsschnittstelle gehörte von Beginn an zur Konstruktion und führte Adress-, Daten- und Steuersignale der CPU nach außen. Beim Nascom 2 war dafür keine separate Pufferplatine erforderlich. Die RAM-Karte nutzte somit eine vorhandene Systemfunktion, auch wenn ihr Einsatz ursprünglich nicht als Voraussetzung für die Grundausstattung gedacht war.

Tastatur, Video und Schnittstellen

Nascom zielte auf einen Rechner, dessen Ein- und Ausgabe nicht auf Hexadezimaltastatur und Leuchtdioden beschränkt waren. Auch dem Bausatz lag eine fertig aufgebaute alphanumerische Tastatur mit 57 Tasten bei. Zusammen mit der integrierten Videoerzeugung konnte der Nascom 2 nach dem Aufbau unmittelbar mit einem Fernseher oder Monitor verwendet werden. Eine vollständige Tastatur und eine Bildschirmschnittstelle waren bei Mikrocomputerbausätzen dieser Zeit noch keine Selbstverständlichkeit.

Ganz fehlersicher war die Verkabelung nicht. Das Hardwarehandbuch warnt ausdrücklich davor, die Tastatur mit dem benachbarten seriellen Anschluss zu verbinden. Dort lagen Spannungen an, die die Tastatur beschädigen konnten.

Als Prozessor diente ein Z80A. Frühe Beschreibungen nannten mehrere Taktstufen; das überarbeitete Lucas-Handbuch von 1981 dokumentiert eine Umschaltung zwischen zwei und vier Megahertz und bezeichnet vier Megahertz als normale Einstellung. Für die spätere offizielle Konfiguration sind daher zwei oder vier Megahertz die belastbarsten Angaben.

Zur Grundausstattung gehörten außerdem ein UART für serielle Kommunikation und ein Z80-PIO mit zwei parallelen Acht-Bit-Ports. Das Kassetteninterface arbeitete regulär mit 300 oder 1.200 Baud. Das Handbuch beschreibt zusätzlich eine 2.400-Baud-Konfiguration, für die Verbindungen auf der Platine geändert werden mussten. Auch RS-232 und eine 20-mA-Stromschleife waren vorgesehen. Diese Schnittstellen gehörten bereits zum Grundentwurf der Hauptplatine.

Textdarstellung und Zeichensatzgrafik

Die Bildausgabe zeigte 48 Zeichen in 16 Zeilen. Der Bildschirmspeicher belegte die Adressen 0800 bis 0BFF hexadezimal, der Workspace folgte von 0C00 bis 0FFF. NAS-SYS lag am unteren Ende des Adressraums, das acht Kilobyte große BASIC-ROM im Bereich E000 bis FFFF.

Eine frei adressierbare Bitmapgrafik besaß der Nascom 2 nicht. Auf der Platine befand sich jedoch ein Sockel für einen zweiten Zeichengenerator. Der optionale NAS-GRA-ROM ergänzte den normalen Zeichensatz um 128 grafische Zeichen. Microsoft BASIC konnte daraus eine blockbasierte Darstellung mit 96 × 48 Elementen zusammensetzen. Die häufig genannte Auflösung bezeichnet daher Zeichensatz-Semigrafik.

Eine integrierte Klangerzeugung besaß der Rechner nicht. Töne ließen sich über zusätzliche Hardware oder programmierte Ausgabeleitungen erzeugen, gehörten aber nicht zur serienmäßigen Ausstattung.

Konfiguration per Steckbrücke

Die acht Speicherplätze für den Anwenderbereich waren nicht ausschließlich für RAM vorgesehen. Über Linkblöcke konnten sie je nach Bestückung für MK4118-RAM oder 2708-EPROM eingerichtet und unterschiedlichen Bereichen des Adressraums zugeordnet werden.

Das Lucas-Handbuch widmet diesen Einstellungen mehrere Seiten. Falsch verdrahtete Linkblöcke konnten zu Fehlfunktionen oder Schäden führen. Flexibilität bedeutete hier elektrische Konfiguration: Der Benutzer musste Speicherart, Adressierung, Takt und mehrere Schnittstellenoptionen direkt auf der Platine festlegen.

Die erhaltene Ausgabe des Hardwarehandbuchs trägt das Datum 17. Juli 1981 und nennt Nascom bereits als Abteilung von Lucas Logic. Sie dokumentiert weiterhin die ursprüngliche Hauptplatine, ihre Speicheroptionen, Schnittstellen und das vollständige Schaltbild. Der Rechner blieb damit auch nach den wirtschaftlichen Schwierigkeiten des ursprünglichen Herstellers ein gepflegtes und erweiterbares System.

Der Nascom 2 entsprach noch nicht dem späteren Bild eines geschlossenen Heimcomputers. Netzteil, Gehäuse und Massenspeicher mussten ergänzt werden, und viele Einstellungen erfolgten über Schalter, Steckbrücken oder Verdrahtung. Dafür brachte die Hauptplatine bereits Tastaturanschluss, Videoerzeugung, Kassetteninterface, serielle und parallele Ein-/Ausgabe sowie einen gepufferten Erweiterungsbus mit.

Als die vorgesehenen MK4118 nicht in ausreichender Menge verfügbar waren, konnte Nascom die acht Kilobyte Anwenderspeicher auf eine externe DRAM-Karte verlagern. Die Lösung machte den Rechner aufwendiger, ermöglichte aber die Auslieferung ohne die vollständige SRAM-Bestückung. Der Erweiterungsbus wurde damit schon beim Marktstart zu einem wesentlichen Bestandteil des Systems.

Technische Daten

Merkmal Nascom 2
Vorstellung 1979
ursprünglicher Hersteller Nascom Microcomputers
spätere Firmenbezeichnung Nascom Microcomputers, Division of Lucas Logic
Preis £295 zuzüglich Mehrwertsteuer als Bausatz
Prozessor Zilog Z80A
Takt 2 oder 4 MHz in der Lucas-Dokumentation
geplantes RAM auf der Hauptplatine 10 KByte: 8 KByte Anwender-, 1 KByte Video- und 1 KByte Workspace-RAM
geänderte frühe Konfiguration 2 KByte RAM auf der Hauptplatine plus 16-KByte-DRAM-Karte
ROM 2 KByte NAS-SYS 1 und 8 KByte Microsoft BASIC
Bildausgabe monochrom, 48 × 16 Zeichen
Grafik optionaler Zeichengenerator für Semigrafik bis 96 × 48
Tastatur 57 Tasten, fertig aufgebaut
Massenspeicher Kompaktkassette, regulär 300 oder 1.200 Baud
Erweiterung gepufferter NAS-BUS
Sound keine integrierte Klangerzeugung

Acorn Archimedes A540 – Das professionelle Spitzenmodell

Als Acorn den Archimedes A540 im Sommer 1990 bewarb, rückte die Firma den Arbeitsplatz nach vorn. Nicht der Klassenraum war das Bild, sondern CAD/CAM, Desktop-Publishing, medizinische Bildanalyse, X-Ray-Astronomie, Multimedia-Training, TCP/IP und UNIX-Anbindung. Der Prospekt trug entsprechend selbstbewusst die Überschrift „High Performance Computer Systems“. Der A540 war der Archimedes, mit dem Acorn zeigen wollte, dass ARM und RISC OS nicht nur elegant, sondern auch professionell nutzbar waren.

Acorn Computers aus Cambridge war 1978 von Hermann Hauser und Chris Curry gegründet worden und hatte sich mit dem BBC Micro tief in britische Schulen, Universitäten und Entwicklerzimmer eingeschrieben. Der Archimedes war ab 1987 der radikale nächste Schritt: eigener RISC-Prozessor, eigenes Betriebssystem, eigene Bedienlogik. 1990 setzte Acorn mit dem A540 das Spitzenmodell auf diese Linie. Die in der Chris-Whytehead-Collection beim Centre for Computing History gespiegelte Seite Chris’s Acorns beschreibt den A540 als Flaggschiff der Archimedes-Reihe; genannt werden dort 4 MB RAM, Ausbau bis 16 MB, SCSI als Standard, eine 100-MB-Festplatte, RISC OS 2.01 und ein ARM3-Prozessor.

Der Abstand zu den kleineren Modellen war nicht nur eine Frage des Typenschilds. A410/1, A420/1 und A440/1 arbeiteten noch mit ARM2; der A540 bekam den ARM3. Dazu kamen 4 MB RAM ab Werk, Erweiterungen auf 8, 12 oder 16 MB, eine interne 100-MB-SCSI-Festplatte und SCSI als Serienausstattung statt als Nachrüstung. In Acorns eigener Tabelle fällt der A540 genau an diesen Stellen heraus: Bei den kleineren Archimedes-Modellen endet der RAM-Ausbau deutlich früher, beim A540 beginnt die Grundausstattung bereits dort, wo viele andere Anwender erst aufrüsteten.

Der ARM3 brachte einen internen 4-KB-Cache mit. Das klingt aus heutiger Sicht klein, war aber im Archimedes-System ein echter Vorteil. Acorn erklärte den Leistungssprung selbst damit, dass der Prozessor seltener Befehle und Daten aus dem Hauptspeicher holen musste. Der Cache entlastete also genau die Stelle, an der frühe Archimedes-Systeme empfindlich waren: den gemeinsamen Speicherzugriff von CPU, Grafik und Sound. Acorn formulierte im Prospekt entsprechend selbstbewusst, der A540 hole aus RISC OS und dem ARM3 deutlich mehr heraus als die kleineren Modelle der Reihe.

Solche Vergleiche wurden damals gern mit MIPS-Zahlen unterfüttert, also mit der groben Angabe, wie viele Millionen Instruktionen ein Prozessor pro Sekunde ausführen kann. Auf dem Papier sah der ARM3 dabei beeindruckend aus: vergleichsweise niedriger Takt, hoher Durchsatz. Trotzdem sollte man MIPS-Werte nicht wie eine Bundesligatabelle lesen. Ein ARM-Befehl, ein 68030-Befehl und ein x86-Befehl leisten nicht automatisch dasselbe, und Benchmarks hängen stark davon ab, welche Aufgabe gerade gemessen wird. Als grobe Orientierung erklären die Zahlen aber, warum ein Archimedes schon bei niedriger Taktfrequenz so direkt wirken konnte. Der A540 legte mit ARM3 und Cache noch einmal spürbar nach – besonders auf dem RISC-OS-Desktop, beim Fensteraufbau, beim Wechsel zwischen Anwendungen und bei speicherhungrigen Programmen.

Dazu kam Acorns eigenes Chipsatz-Konzept. MEMC, VIDC und IOC waren keine beliebigen Begleitbausteine, sondern Teil eines abgestimmten Systems: Der MEMC verband ARM-Prozessor, Speicher, VIDC und I/O-Bausteine, während der VIDC Video- und Soundausgabe bereitstellte und seine Daten aus dem RAM in interne Puffer las. Der A540 war also kein PC mit separater VGA-Karte, sondern ein eng verzahntes System aus ARM-CPU, Speichercontroller und Video-/Soundchip. Das hatte Grenzen, weil der Hauptspeicher eine geteilte Ressource blieb. Aber der ARM3-Cache entschärfte diesen Engpass: Je öfter die CPU aus dem Cache arbeiten konnte, desto weniger musste sie auf den Speicherbus zugreifen.

Auch bei der Grafik zielte Acorn klar auf Arbeit statt auf Spieleffekt. Der Prospekt nennt RGB- und Multiscan-Modi, VGA mit 640 × 480 Bildpunkten in 16 oder 256 Farben, SVGA mit 800 × 600 Bildpunkten in 16 Farben sowie hochauflösenden Monochrombetrieb mit 1152 × 900 Bildpunkten. Für DTP, CAD und technische Anwendungen war das eine brauchbare Ansage: Ein stabiler, scharfer Desktop zählte hier mehr als möglichst bunte Spielemodi.

Die Erweiterbarkeit passte zu dieser Rolle. Acorn listete I/O-Karten für Steuer- und Messaufgaben, ROM-Erweiterungen, MIDI, Genlock, Frame Stores, Echtzeit-Farbdigitalisierung, IEEE-488, STE-Bus, Ethernet und Econet. Sogar Direct Laser Printer Cards stehen im Prospekt, ausdrücklich mit hoher Druckqualität und Geschwindigkeit für DTP. Das klingt heute etwas exotisch, war aber kein Versehen: Acorn wollte den A540 in Arbeitsumgebungen sehen, in denen Druck, Bild, Netzwerk und Spezialhardware nicht nachträglich improvisiert wurden, sondern Teil des Systems waren.

Gleichzeitig blieb der A540 ein teures Gerät. Chris Whytehead nennt für 1990 einen Preis von 2.495 Pfund plus Mehrwertsteuer, ohne Monitor. Die britische Standard-VAT lag 1990/91 bei 15 Prozent; damit kam der Rechner inklusive Steuer auf rund 2.869 Pfund, weiterhin ohne Bildschirm. Nach der Bank-of-England-Inflationsrechnung entspricht ein Preis von 1990 bis Mai 2026 ungefähr dem Faktor 2,54. Daraus werden grob 6.350 Pfund ohne VAT beziehungsweise etwa 7.300 Pfund inklusive damaliger VAT. Zum aktuellen EZB-Referenzkurs von rund 1 Pfund = 1,17 Euro sind das ungefähr 7.400 Euro beziehungsweise 8.500 Euro. Das war kein „mal sehen, ob ich mir den gönne“-Computer, sondern eine Anschaffung für Labore, technische Büros, Bildungseinrichtungen oder sehr entschlossene Acorn-Anwender.

Im direkten Umfeld musste sich der A540 gegen sehr unterschiedliche Gegner behaupten. Ein Amiga 3000 bot 1990 einen Motorola 68030, SCSI, AmigaOS 2.0 und die bekannte Stärke der Commodore-Custom-Chips. Ein 386- oder früher 486-PC punktete weniger mit Eleganz, dafür mit wachsender Softwaremasse, Klonmarkt und dem sicheren Gefühl, auf den kommenden Standard zu setzen. Der Macintosh IIci blieb im professionellen Umfeld ebenfalls präsent, mit 25-MHz-68030, NuBus-Erweiterung und dem vertrauten Macintosh-Ökosystem. Der A540 saß zwischen diesen Welten: schneller und eleganter als viele DOS/Windows-Kombinationen, professioneller positioniert als die kleineren Archimedes-Modelle, aber ohne das weltweite Ökosystem der PC-Welt.

Ein kurzer Blick auf den Acorn R260 zeigt, wie professionell Acorn diese Hardware einordnete. Der R260 war eine eng verwandte Workstation-Variante auf A540-Basis, jedoch mit vorinstalliertem RISCiX, Acorns UNIX-System. Für den A540 blieb RISC OS der Normalfall – aber die Verwandtschaft zeigt, dass Acorn diese Maschine nicht als gehobenen Heimcomputer, sondern als ernsthaften Arbeitsplatzrechner verstand. Dieser Punkt bietet sich später gut für einen eigenen R260-Artikel an.

Belastbare Einzelstückzahlen für den A540 sind schwer zu finden. Whytehead deutet anhand eines Gehäuseaufklebers nur vorsichtig an, dass möglicherweise relativ wenige Geräte gebaut wurden; das ist ein Sammlerhinweis, kein Produktionsnachweis. Für die Archimedes-Familie insgesamt sind die Größenordnungen besser greifbar: Bis Ende 1989 wurden demnach etwa 50.000 Archimedes- und A3000-Systeme verkauft, Anfang 1991 rund 100.000, Mitte 1992 etwa 180.000 und bis zum Risc-PC-Start 1994 über 300.000. Diese Zahlen wurden aber vor allem vom A3000 und den günstigeren Modellen getragen, nicht vom teuren A540.

Nachfolger ist der Acorn A5000. Das Centre for Computing History beschreibt ihn als neues Archimedes-Modell, das den A540 ersetzte; Whytehead hebt beim A5000 vor allem RISC OS 3 hervor, das gegenüber RISC OS 2 ein großer Schritt war. Damit brachte Acorn ARM3-Leistung und ein moderneres RISC OS in ein alltagstauglicheres System. Der A540 blieb der schwerere, teurere und seltenere Vorläufer – und gerade deshalb einer der interessantesten Archimedes-Rechner.

Kurzdaten

Punkt Acorn Archimedes A540
Einführung Juni 1990
Stellung Spitzenmodell der Archimedes-Reihe
CPU ARM3, 32 Bit
Cache 4 KB im ARM3
RAM 4 MB serienmäßig, bis 16 MB ausbaubar
Massenspeicher 100 MB SCSI-Festplatte, 3,5″-Diskettenlaufwerk
Betriebssystem RISC OS 2.01 zum Start
Grafik u. a. 640 × 480 mit 256 Farben, 800 × 600 mit 16 Farben, 1152 × 900 monochrom
Sound 8-Kanal-Sound über VIDC
Erweiterung SCSI serienmäßig, Ethernet/Econet, MIDI, I/O, ROM, Video-/DTP-/Spezialkarten
FPU-Option ARM-FPA/FPA10-Umfeld
Preis 1990 2.495 Pfund plus VAT, ohne Monitor
Heutige Kaufkraft grob 6.350 Pfund / ca. 7.400 Euro ohne VAT; ca. 7.300 Pfund / ca. 8.500 Euro inkl. damaliger VAT
Nähe zum R260 verwandte Workstation-Variante mit RISCiX
Anschlussmodell Acorn A5000

Indiana Jones and the Last Crusade – Der Gral lag in der Schachtel

Die Schachtel überlebte keine zehn Minuten, und das lag nicht daran, dass sie schlecht gewesen wäre. Für ein Lucasfilm-Adventure von 1989 war sie beinahe ein Teil des Versprechens: Disketten, Handbuch, Codetabelle und Henry Jones’ Gral-Tagebuch kündigten ein Abenteuer an, das über den Bildschirm hinausreichte. Nur hatte ich das Spiel heimlich gekauft.

Nach Maniac Mansion und Zak McKracken war für mich klar, dass Lucasfilm Games andere Vorstellungen von einem Computerspiel hatte als viele Konkurrenten. Dazu kam Indiana Jones, der mit Hut und Peitsche durch Katastrophen stolperte und meistens nur knapp weniger beschädigt daraus hervorging als seine Umgebung. Also wanderte mein Taschengeld in Indiana Jones and the Last Crusade: The Graphic Adventure.

Meine Mutter hielt Computerspiele allerdings eher für teuren Unfug als für kulturelle Frühförderung. Ich nahm Disketten, Handbuch und Codetabelle heraus, zerriss die Verpackung und entsorgte sie. Ausgerechnet die Schachtel eines Spiels über den Heiligen Gral wurde damit zu meinem persönlichen Opfer an die Heimcomputerära.

Der Verlust war mehr als eine heutige Sammlersünde. Lucasfilm Games behandelte das Material in der Packung als Bestandteil des Spiels. Das Gral-Tagebuch lieferte Hinweise, vermittelte die Geschichte der Suche und erschwerte nebenbei das Spielen einer bloßen Diskettenkopie. Die Software endete nicht am Monitor. Das Tagebuch lag aufgeschlagen daneben, die Codetabelle kam regelmäßig zum Einsatz, und manche Information musste außerhalb des Computers gesucht werden.

Auch die Herstellung des Tagebuchs ging über eine gewöhnliche Kopierschutzbeilage hinaus. Den größten Teil des Textes schrieb Noah Falsteins Bruder, ein freier Autor mit einem Studium der mittelalterlichen Geschichte. Für einzelne Dokumente suchte das Team nach historischen Vorlagen. Ein italienisches Telegramm aus dem frühen 20. Jahrhundert orientierte sich beispielsweise an zeitgenössischen Originalen.

Das Tagebuch sollte wie Henry Jones’ über Jahrzehnte geführte Arbeitsunterlage wirken. Es lieferte Spielhinweise, ohne wie ein beigelegtes Lösungsheft auszusehen. Die Kopierschutzfunktion war fest in den Gegenstand eingebaut. Lucasfilm Games wusste, dass ehrliche Käufer unter solchen Abfragen litten, und versuchte deshalb, den unvermeidlichen Griff zur Packungsbeilage wenigstens in die Spielwelt einzufügen.

Neun Monate für Indiana Jones

Als das Graphic Adventure im Sommer 1989 erschien, lief der dritte Indiana-Jones-Film in den USA und Großbritannien bereits im Kino. In der Bundesrepublik startete er erst am 14. September. Lucasfilm Games arbeitete unter erheblichem Zeitdruck und musste das Spiel fertigstellen, solange der Film noch aktuell war.

Die Rechte für die Computerspielumsetzung waren zunächst extern vergeben worden. Als das Projekt dort nicht vorankam, holte Lucasfilm die Entwicklung zurück ins eigene Haus. Noah Falstein, David Fox und Ron Gilbert blieben anschließend ungefähr neun Monate für die gesamte Produktion.

Falstein hatte die Arbeit zunächst allein begonnen. Er entwickelte rund zwei Monate lang ein frühes Konzept, kam dann jedoch zu dem Schluss, dass sich das Projekt in der verfügbaren Zeit ohne zusätzliche erfahrene Entwickler kaum fertigstellen ließ. Fox hatte zuvor Zak McKracken and the Alien Mindbenders geleitet, Gilbert mit Maniac Mansion SCUMM und die Grundlage der Lucasfilm-Adventures geschaffen.

Alle drei arbeiteten bei Last Crusade als gleichberechtigte Projektleiter. Diese Konstellation blieb innerhalb des Studios einmalig. Sie entwarfen, programmierten und überprüften gegenseitig ihre Arbeit. Gelegentlich änderte einer direkt den Code des anderen oder hinterließ einen Kommentar darin. Grundsätzliche Konflikte blieben selten.

Die Dreierleitung war keine elegante Organisationsidee aus einem Lehrbuch. Sie war eine Reaktion auf einen Termin, den ein einzelner Projektleiter kaum halten konnte. Der Plan sah eine Veröffentlichung zum US-Kinostart Ende Mai 1989 vor. Dieses Ziel verfehlte das Team; im Juli kam das Adventure dennoch rechtzeitig heraus, um noch vom laufenden Kinoerfolg zu profitieren.

Parallel entstand bei Tiertex ein eigenständiges Actionspiel. Dort wurde Indiana Jones auf jene Eigenschaften reduziert, die sich unmittelbar in Level und Gegner verwandeln ließen: springen, schlagen, klettern und die Peitsche einsetzen. Die Filme liefern dafür genug Material.

Das Graphic Adventure setzte an einer anderen Stelle an. Indy untersucht Fundstücke, liest Texte, täuscht Gegner und muss seine Rolle der jeweiligen Situation anpassen. Körperliche Auseinandersetzungen gehören dazu, bestimmen aber nicht den gesamten Ablauf. Lucasfilm Games orientierte sich stärker an Indys Vorgehen als an der bloßen Zahl seiner Schläge und Stürze.

Die Lücken zwischen den Filmszenen

Die Entwickler verfügten über das Drehbuch, Setfotos und Material aus der laufenden Produktion. Einen fertigen Film, den sie Szene für Szene hätten nachbauen können, gab es während großer Teile der Arbeit noch nicht.

Damit entstand ein grundlegendes Problem. Hielt sich das Adventure eng an den Film, kannten dessen Zuschauer bereits die Lösungen. Entfernte es sich zu weit von der Vorlage, verlor es den Wiedererkennungswert einer Filmumsetzung. Die drei Projektleiter legten deshalb viele Rätsel in die Lücken zwischen den bekannten Szenen.

Das Spiel zeigt Vorgänge, die innerhalb der Filmhandlung stattgefunden haben könnten, im Kino aber nicht vollständig zu sehen sind. Bekannte Schauplätze und Wendepunkte bleiben erhalten. Der Weg von einer Filmszene zur nächsten wird mit neuen Hindernissen, Gesprächen und Handlungen gefüllt.

Dieses Prinzip löste gleich zwei Probleme. Der Spieler erkannte die Handlung wieder, konnte die Rätsel aber nicht allein mit seiner Erinnerung an den Film beantworten. Zugleich erhielt Lucasfilm Games genügend Spielraum, um Situationen für SCUMM und die Möglichkeiten eines Adventures zu entwerfen.

Erst wenige Wochen vor dem US-Kinostart sah das Team eine weitgehend fertige Filmfassung. Mehrere Szenen, auf denen bereits Teile des Spiels beruhten, waren inzwischen aus dem Film entfernt worden. Die Entwickler befürchteten zunächst, ihr Adventure passe dadurch nicht mehr zur Vorlage. Schließlich erkannten sie darin einen Vorteil und bewarben das zusätzliche Material als Einblick in gestrichene Filmszenen.

Besonders deutlich wird das an der Boxhalle der Universität. Das Drehbuch sah Indiana Jones als Boxtrainer vor und erklärte damit seine Fähigkeiten im Faustkampf. Die Szene wurde aus dem Film entfernt, blieb jedoch im Adventure erhalten. Dort dient sie zugleich als Einführung in die Kampfsteuerung.

Auch die Funkanlage des Zeppelins erhielt im Spiel mehr Gewicht. In der ursprünglichen Filmsequenz drang Indy in den Funkraum ein, überwältigte den Bediener und beschädigte das Gerät. Eine weitere gestrichene Einstellung zeigte später, dass es repariert worden war. Im fertigen Film blieb davon lediglich Indys beiläufige Bemerkung übrig, er habe nicht erwartet, dass die Deutschen das Funkgerät so schnell wieder in Betrieb nehmen könnten.

Das Adventure stellt den Zusammenhang wieder her. Es bewahrt damit keine verlorene Langfassung des Films, zeigt aber einzelne Handlungen und Verbindungen, die im Kino nur noch als Überreste vorhanden sind.

Andere Bestandteile der Vorlage verschwanden dagegen. Sallah tritt nicht auf, die Bruderschaft des Kreuzschwerts fehlt, und mehrere große Actionszenen wurden nur angedeutet oder ganz gestrichen. Das Team musste auswählen, welche Teile der Geschichte mit den verfügbaren Mitteln spielbar wurden.

Eine Verfolgungsjagd funktioniert im Kino durch Tempo, Schnitt und Bewegung. Im Spiel benötigt sie Regeln, Steuerung und genügend Abwechslung. Gespräche, Nachforschungen und Täuschungsmanöver ließen sich verlässlicher in Entscheidungen des Spielers verwandeln.

Das Adventure zerlegt Indys Vorgehen in Aufgaben. Hinweise müssen gefunden, Texte verstanden und Personen eingeschätzt werden. Manche Probleme lassen sich mit einem Gegenstand lösen, andere durch ein Gespräch oder eine passende Verkleidung. Wer den Film auswendig kennt, weiß, wohin die Reise führt. Den Weg durch die einzelnen Situationen muss er trotzdem selbst finden.

Mehrere Wege durch denselben Film

Ein Konzeptpapier vom 13. Oktober 1988 zeigt, dass Noah Falstein zunächst kein gewöhnliches Grafikadventure plante. Vorgesehen war ein Hybrid aus Computerspiel, gedrucktem Spielbuch und Actionsequenzen. Ein Buch sollte mehrere hundert nummerierte Abschnitte, Filmfotos und Auswahlmöglichkeiten enthalten. Der Computer hätte Inventar, Spielstand und Punktzahl verwaltet, auf die passenden Textstellen verwiesen und Actionszenen dargestellt.

Das Konzept nannte Fassungen für den Commodore 64 und IBM-kompatible Rechner. Die C64-Version entstand später nicht. Ausschlaggebend waren die sinkenden Verkaufsaussichten des Rechners. Amiga, Atari ST und vor allem IBM-kompatible PCs gewannen für Lucasfilm Games an Bedeutung.

Archivfund: Das frühe Konzeptpapier zu Indiana Jones and the Last Crusade

Noah Falsteins Konzeptpapier vom 13. Oktober 1988 zeigt, wie anders das Spiel ursprünglich gedacht war:
als Hybrid aus Computerspiel, Actionsequenzen und gedrucktem Abenteuerbuch. Viele Ideen verschwanden später
aus der fertigen Fassung, doch das Gral-Tagebuch, die Mehrfachlösungen und der Wechsel zwischen Lesen,
Entscheiden und Spielen blieben spürbar erhalten.


Konzeptpapier als PDF ansehen

Auch das Gral-Tagebuch war bereits vorgesehen. Es sollte Zeichnungen, fremdsprachige Notizen und historische Hinweise enthalten. Falstein beschrieb außerdem unterschiedliche Vorgehensweisen. Spieler sollten Hindernisse durch Action überwinden oder nach ausführlicheren Rätsellösungen suchen können. Das Dokument nennt Varianten wie den Kampf gegen Wachen und einen Umweg über die Außenwand eines Schlosses.

Vom gedruckten Paragraphenspiel blieb in der fertigen Fassung wenig übrig. Das Gral-Tagebuch, die Actionsequenzen und die alternativen Lösungen überlebten. Sie wurden mit SCUMM zu einem Adventure verbunden, das vertraut aussah, aber anders funktionierte als Maniac Mansion oder Zak McKracken.

Die bekannte Verbenleiste erhielt dafür die Befehle „Talk“ und „Travel“. Mit „Talk“ begann Indy Gespräche, während „Travel“ an bestimmten Stellen den Ortswechsel auslöste. In einzelnen Szenen konnte zwischen Indy und seinem Vater umgeschaltet werden.

Vor allem die Multiple-Choice-Gespräche erweiterten das Rätseldesign. Wachen ließen sich nicht allein durch Inventargegenstände oder einen Faustschlag überwinden. Der Spieler musste Antworten auswählen, Dienstgrade beachten und erkennen, welche Uniform oder welcher Ausweis in einer bestimmten Situation glaubwürdig war.

Ein falscher Satz konnte einen Kampf auslösen. Der richtige öffnete den Weg ohne weitere Gewalt. Personen wurden dadurch zu veränderlichen Bestandteilen der Rätsel. Das Dialogsystem blieb einfacher als später in The Secret of Monkey Island, doch Lucasfilm Games hatte bereits erkannt, dass ein Gespräch eine eigene Spielmechanik tragen konnte.

Schloss Brunwald führt diese Ideen zusammen. Indy sucht seinen Vater in einem Gebäude voller Wachposten. Einige Soldaten lassen sich täuschen, andere erwarten bestimmte Papiere oder Uniformen. Gegenstände können verschenkt oder zur Bestechung eingesetzt werden. Wer falsch gekleidet auftritt oder einen Bluff überzieht, muss sich mit den Fäusten helfen.

Der Abschnitt lässt sich bei einem weiteren Durchgang anders lösen. Eine Wache kann Gesprächspartner, Hindernis oder Gegner sein. Welche Rolle sie übernimmt, ergibt sich aus dem Vorgehen des Spielers.

Nicht jede Möglichkeit ist sauber angekündigt. Manche Dialogantwort erscheint schwer vorhersehbar, und die Faustkämpfe funktionieren weniger zuverlässig als die eigentlichen Adventure-Rätsel. Trotzdem zeigt Brunwald, was Lucasfilm Games aus einer festgelegten Filmszene gewinnen konnte. Der Ort besitzt mehrere mögliche Abläufe, obwohl das Ziel immer dasselbe bleibt.

Der Indy Quotient

Der Indy Quotient machte die verschiedenen Lösungen messbar. Das Spiel führte zwei Werte. Der Episoden-IQ galt für den aktuellen Durchgang, während der Serien-IQ dauerhaft festhielt, welche Lösungswege der Spieler bereits entdeckt hatte. Insgesamt waren 800 Punkte erreichbar.

Hinter dem System stand ein konkretes Problem des damaligen Marktes. Adventures wurden häufig nach ihrer Spielzeit beurteilt. Viele Käufer erwarteten mindestens zwanzig, möglichst sogar vierzig Stunden Beschäftigung. Wer das Ende zu schnell erreichte, konnte das Spiel als zu kurz empfinden, selbst wenn er einen großen Teil der möglichen Lösungen ausgelassen hatte.

Falstein entwickelte den Indy Quotient als Antwort darauf. Wer vor allem die Geschichte erleben wollte, konnte Kämpfe umgehen und einen vergleichsweise direkten Weg wählen. Spieler mit dem Wunsch nach Vollständigkeit erhielten mit den 800 Punkten ein zusätzliches Ziel.

Der Gral ließ sich lange vor dem Höchststand finden. Für den vollständigen Serien-IQ mussten Hindernisse auf unterschiedliche Weise überwunden werden. Eine Wache konnte besiegt, überredet oder umgangen werden.

Beschwerte sich jemand bei der Lucasfilm-Hotline über eine zu kurze Spielzeit, konnte die Gegenfrage lauten, ob er tatsächlich alle IQ-Punkte erreicht hatte. Wer das Ende gesehen, aber nur einen Teil der Punkte gesammelt hatte, bekam damit einen deutlichen Hinweis auf die ausgelassenen Möglichkeiten.

Das System schrieb keine einheitliche Spielzeit vor. Es trennte den Abschluss der Geschichte von der vollständigen Erkundung des Spiels. Der Abspann war ein Ziel; die 800 Punkte waren ein anderes.

Boris Schneider und die deutsche Fassung

Für die deutsche Übersetzung war Boris Schneider verantwortlich. Der damals noch junge Spielejournalist und Übersetzer arbeitete unter anderem für die Zeitschriften Happy Computer und Power Play und betreute die deutschen Fassungen mehrerer Lucasfilm-Adventures. Später wurde er unter dem Namen Boris Schneider-Johne auch außerhalb der klassischen Spieleszene bekannt: Als langjähriger Microsoft-Manager gehörte er zu den prägenden Verantwortlichen für die Einführung und Vermarktung der Xbox in Deutschland.

Seine Aufgabe bei Last Crusade bestand nicht allein darin, englische Texte ins Deutsche zu übertragen. Die Dialoge mussten in die begrenzten Textfelder passen und zugleich den Ton der Lucasfilm-Adventures bewahren.

Der Erfolg der Lucasfilm-Spiele in Deutschland hing auch mit der Qualität dieser Übersetzungen zusammen. Schneider kannte die deutsche und die amerikanische Sprache aus eigener Erfahrung und verstand dadurch Slang, Redewendungen und kulturelle Unterschiede. Lucasfilm Games arbeitete zudem häufig mit Übersetzern zusammen, deren Muttersprache der jeweilige Zielmarkt war.

Bei Last Crusade kam die Entfernung nationalsozialistischer Symbole hinzu. Für die deutsche Fassung wurden die betreffenden Grafiken bearbeitet und die Hakenkreuze durch schwarze Flächen ersetzt. Auch das Wort „Nazi“ verschwand weitgehend oder wurde umschrieben.

Die Handlung blieb verständlich. Schloss Brunwald wurde weiterhin von deutschen Soldaten bewacht, und der Besuch in Berlin verlor seinen historischen Zusammenhang nicht. Die schwarzen Flächen erzeugten dennoch eine sichtbare Lücke zwischen Vorlage und Spiel.

Im Film waren die Symbole Bestandteil eines eindeutig gegen den Nationalsozialismus gerichteten Szenarios. Computerspiele wurden damals rechtlich und kulturell anders behandelt. Publisher vermieden entsprechende Darstellungen, weil Beschlagnahmung, Indizierung und Vertriebsprobleme drohten.

Die Bearbeitung gehört deshalb zur Geschichte der deutschen Version. Sie zeigt, wie unsicher die Stellung des Mediums Ende der achtziger Jahre noch war. Was im Kino als Teil einer historischen Handlung akzeptiert wurde, galt im Computerspiel als vermeidbares Risiko.

Disketten, Farben und Soundkarten

Die ursprüngliche DOS-Fassung erschien mit 16-Farben-Grafik. Sie wurde auf sechs doppelseitigen 5,25-Zoll-Disketten oder drei 3,5-Zoll-Disketten ausgeliefert. Eine spätere DOS-Version brachte überarbeitete 256-Farben-Grafik für MCGA und VGA. Diese Farben ließen sich nicht in der ursprünglichen Ausgabe aktivieren; es handelte sich um eine eigene Fassung.

Eine Festplatte war für die frühe DOS-Version keine zwingende Voraussetzung. Ohne sie verlangte das Spiel allerdings regelmäßige Diskettenwechsel. Eine Installation auf Festplatte verkürzte die Unterbrechungen und machte Ortswechsel erheblich angenehmer.

Bei der Tonausgabe war eine AdLib-Karte die sinnvollste Aufrüstung. Ohne Soundkarte blieb dem PC im Wesentlichen der interne Lautsprecher. Ein schnellerer Prozessor oder zusätzlicher Arbeitsspeicher veränderte die Rätsel und Abläufe kaum. Festplatte und Soundkarte hatten im Alltag die deutlichere Wirkung.

1989 folgten Fassungen für Amiga und Atari ST, 1990 für den Macintosh. Die 16-Bit-Umsetzungen orientierten sich grafisch an der frühen PC-Version, unterschieden sich aber bei Musik, Geschwindigkeit und Diskettenzugriffen.

Die FM-Towns-Fassung erschien 1990 auf CD-ROM. Sie verband überarbeitete 256-Farben-Grafik mit Musik als CD-Audio und war technisch die aufwendigste zeitgenössische Ausgabe. Die spätere VGA-DOS-Version nutzte ebenfalls die farblich überarbeiteten Grafiken, behielt jedoch die vom Rechner erzeugte Musikwiedergabe.

1992 erschien außerdem eine CDTV-Fassung, die im Wesentlichen auf der Amiga-Umsetzung beruhte. Das CD-Format allein machte daraus keine vollständig neu gestaltete Version.

Das Gral-Tagebuch blieb über alle Ausgaben hinweg wichtig. Mehr Farben und bessere Musik konnten die Präsentation verbessern. Hinweise lesen, Notizen vergleichen und den richtigen Gral erkennen musste der Spieler weiterhin selbst.

Wo das Konzept an seine Grenzen kam

Last Crusade gehört zu einer Phase der Lucasfilm-Adventures, in der ältere Genregewohnheiten noch deutlich sichtbar waren. Die Katakomben unter Venedig verlangen Orientierung und Geduld. Wer keine Karte anlegte, lief schnell mehrfach durch dieselben Gänge.

Die Actionsequenzen fallen ähnlich uneinheitlich aus. Die Faustkämpfe passen zu Indiana Jones und erlauben teilweise einen direkten Weg durch Schloss Brunwald. Ihre Steuerung erreicht jedoch nicht die Präzision eines eigenständigen Actionspiels. Auch die Flucht im Doppeldecker bringt Abwechslung, unterbricht aber den Teil des Spiels, der am zuverlässigsten funktioniert.

Hinter diesen Passagen stand außer dem Wunsch nach Abwechslung eine handfeste Produktionsrechnung. Adventures wurden häufig danach beurteilt, wie viele Stunden sie beschäftigten. Ein Labyrinth ließ sich vergleichsweise schnell entwerfen, konnte den Spieler aber lange aufhalten. Dasselbe galt für Kämpfe, deren Programmcode in mehreren Begegnungen wiederverwendet wurde.

Die Entwickler hatten selbst wenig Freude an manchen Labyrinthen und wiederholten Kämpfen. Sie mussten jedoch mit begrenztem Speicher, knapper Diskettenkapazität und einem engen Zeitplan genügend Beschäftigung schaffen. Erleichterten sie alle Umwege und boten überall eine schnelle Abkürzung an, drohte der Vorwurf, das Spiel sei sein Geld nicht wert.

Das erklärt die Schwächen, entschuldigt sie aber nicht vollständig. Ein Spieler, der an einem Kampf oder in einem Gangsystem festhängt, spürt die eingesparte Entwicklungszeit sehr direkt. Die besten Teile von Last Crusade belohnen Beobachtung und Schlussfolgerung. Einige Action- und Labyrinthpassagen verbrauchen hauptsächlich Zeit.

Der Indy Quotient war ein Versuch, diesen Konflikt eleganter zu lösen. Zusätzliche Spielzeit sollte aus alternativen Wegen und freiwilliger Vollständigkeit entstehen. Fate of Atlantis führte diese Idee später konsequenter weiter und trennte unterschiedliche Spielweisen deutlicher voneinander.

Die zeitgenössische Presse erkannte die Unterschiede bereits. Power Play vergab 90 Prozent und lobte Umfang, Benutzerführung, Spiellogik und Handlung. The One kam auf 89 Prozent, The Games Machine auf 85 Prozent. Das Gral-Tagebuch, die Gespräche und die verschiedenen Lösungswege wurden wiederholt als Stärken genannt.

Auch die Kritik an Labyrinthen und Actionelementen ist keine spätere Reaktion auf ein unbequem gewordenes Spieldesign. Schon damals war erkennbar, dass Last Crusade am stärksten wurde, wenn Indy untersuchte, redete und kombinierte.

Das Gesamturteil fiel dennoch klar aus. Das Adventure gehörte zu den Filmumsetzungen, die aus den Eigenschaften ihrer Hauptfigur ein eigenes Spieldesign entwickelten.

Der Weg nach Atlantis

Indiana Jones and the Fate of Atlantis führte viele dieser Ideen 1992 systematischer weiter. Dort wurden verschiedene Spielstile in drei benannte Wege aufgeteilt: Wits, Team und Fists. Rätselweg, Zusammenarbeit mit Sophia Hapgood oder stärkerer Kampfeinsatz veränderten größere Teile des Abenteuers.

Diese Weiterentwicklung knüpfte unmittelbar an die Erfahrungen aus Last Crusade an. Das frühere Spiel hatte versucht, Rätsel, Tricks und Kämpfe innerhalb derselben Handlung unterzubringen. Bei Fate of Atlantis konnten sich Spieler von Beginn an stärker auf eine bevorzugte Spielweise konzentrieren.

Last Crusade ordnete seine Alternativen noch nicht in getrennte Routen. Sie stecken direkt in den einzelnen Situationen. Vor einer Wache entscheidet sich, ob ein Gespräch, eine Verkleidung, ein Gegenstand oder ein Faustkampf zum Ziel führt. Diese Struktur ist weniger übersichtlich, gibt den Szenen aber eine unmittelbare Offenheit.

Der Nachfolger musste keine gescheiterte Idee reparieren. Er konnte ein funktionierendes Konzept ausbauen und deutlicher gliedern.

Mit mehr als 250.000 verkauften Exemplaren wurde Last Crusade zum bis dahin meistverkauften Spiel von Lucasfilm Games. Der Erfolg zeigte, dass ein Filmspiel nicht auf die offensichtlichsten Actionszenen beschränkt bleiben musste. Die Vorlage bot genug Material für Rätsel, Gespräche und mehrere Lösungswege.

Was von der Schachtel blieb

Für mich hängt an Last Crusade trotzdem keine Verkaufszahl und keine Rangliste der besten Lucasfilm-Adventures. Geblieben ist die Erinnerung an eine heimlich gekaufte Schachtel, die ich zerstörte, bevor sie jemand entdecken konnte.

Die Disketten überlebten. Das Handbuch und die Codetabelle ebenfalls. Vor allem blieb das Gral-Tagebuch, das man während des Spiels immer wieder aufschlug.

Heute weiß ich, dass selbst dieses Stück Papier Ergebnis einer ungewöhnlich gründlichen Produktion war. Ein Autor mit historischem Hintergrund schrieb die Texte, alte Dokumente dienten als Vorbilder, und die Entwickler planten seine Funktion frühzeitig ein. Das Tagebuch sollte Kopierer bremsen, Käufer aber nicht mit einer beliebigen Passwortliste bestrafen.

Ohne Komplettlösung bedeutete ein Adventure damals, sich festzubeißen, falsche Antworten auszuprobieren und nach einer Pause noch einmal über denselben Hinweis nachzudenken. Manchmal führte der nächste Versuch nur zurück in einen bekannten Gang oder direkt in eine weitere Prügelei mit einer Wache.

Der Abspann beendete die Geschichte. Der Indy Quotient zeigte, dass längst nicht alles erledigt war. Irgendwo gab es noch eine Antwort, eine Verkleidung oder einen Weg, den man beim ersten Durchgang übersehen hatte.

Der Gral war gefunden. Das Spiel war noch nicht ausgeschöpft.

 

Commodore CBM 700 (1983) – Viel Rechner, wenig Erklärung

CC BY-SA 3.0, Wikimedia Commons, Curid 16547

Dr. Reinhard Grabowski wollte den Commodore CBM 700 1984 für die mc testen. Statt lediglich Leistung und Bedienung zu prüfen, musste er zunächst herausfinden, wie das System überhaupt arbeitete. Er suchte Systemadressen, untersuchte Befehle durch eigene Versuche und veröffentlichte seine Ergebnisse anschließend in seinem fünfseitigen Bericht „Computer mit Dokumentations-Defizit – Commodore-700“.

Die mc – Die Mikrocomputer-Zeitschrift war kein Magazin für Gelegenheitskäufer. Das seit 1981 im Franzis-Verlag erscheinende Fachblatt behandelte Prozessoren, Schaltungen und maschinennahe Programmierung. Seine Leser sollten Computer nicht nur bedienen, sondern ihren Aufbau verstehen. Wenn selbst der Autor eines solchen Magazins den CBM 700 teilweise selbst dokumentieren musste, saß das Problem nicht vor der Tastatur.

Auf den ersten Blick machte der Rechner einen freundlichen Eindruck. Der Bildschirm zeigte saubere grüne Zeichen, die abgesetzte Tastatur arbeitete leise, und das abgerundete Gehäuse wirkte neben den kantigen PET-Modellen wie der Beginn einer neuen Commodore-Generation. Im Inneren steckten reichlich Speicher, IEEE-488, RS-232 und sogar der SID des Commodore 64. Es fehlten jedoch Programme und Unterlagen, die daraus einen verlässlichen Arbeitsplatz machten.

Ein neuer Commodore für das Büro

Commodores PET- und CBM-Rechner hatten sich in Schulen, Laboren und kleineren Betrieben etabliert. Anfang der 1980er-Jahre stieß ihre Architektur jedoch an Grenzen. Größere Speichererweiterungen ließen sich nur mit angepasster Software sinnvoll nutzen, während neue Geschäftsanwendungen mehr Platz verlangten.

Die 1982 angekündigte CBM-II-Familie sollte diese Beschränkungen beseitigen. Die flachen 600er-Modelle arbeiteten mit einem externen Monitor, während die 700er einen eingebauten 12-Zoll-Bildschirm und eine frei aufstellbare Tastatur erhielten. In Europa kamen vor allem der CBM 710 mit 128 KByte RAM und der CBM 720 mit 256 KByte auf den Markt.

Daneben kursierten Bezeichnungen wie B700, CBM 128-80, CBM 256-80 oder PET 700. Commodore plante außerdem Modelle mit Doppellaufwerken und zusätzlichen Prozessoren. Ein übersichtliches Sortiment entstand daraus nicht.

Das Gehäuse entwarf Ira Velinsky, ein amerikanischer Industriedesigner bei Commodore. Seine Softline ersetzte die Blechkanten älterer PETs durch Rundungen und ein nach hinten abfallendes Monitorgehäuse. Die Bürocomputer-Serie erhielt 1983 eine iF-Auszeichnung. Später verwendete Commodore die Form unter anderem für den CBM 8032-SK, den 8096-SK und den 8296 weiter.

Grabowski lobte die praktische Ausführung des 700ers. Die entspiegelte Bildfläche zeigte kräftig grüne Zeichen, deren vergleichsweise lange Nachleuchtdauer für ein ruhiges Bild sorgte. Schnelle Veränderungen blieben allerdings kurz sichtbar. Auch der eingebaute Lüfter meldete sich hörbar – im stillen Büro lästiger als auf einem Messestand.

Viel Speicher hinter mehreren Türen

Im CBM 700 arbeitete ein MOS 6509A mit rund 2 MHz. Der mit dem 6502 verwandte Prozessor konnte mittels Bank-Switching zwischen mehreren Speicherbereichen wechseln. Das war nötig, weil ein gewöhnlicher 6502 nur 64 KByte unmittelbar ansprechen konnte.

Der 6509 teilte den Speicher in bis zu 16 Bänke mit jeweils 64 KByte auf. Damit entstand theoretisch ein Adressraum von einem Megabyte. Der CBM 710 besaß 128 KByte, der CBM 720 256 KByte; Erweiterungen sollten insgesamt bis zu 960 KByte ermöglichen.

Der Prozessor sah jedoch nie den gesamten Speicher gleichzeitig. Er arbeitete innerhalb einer ausgewählten Bank und wechselte bei Bedarf in eine andere. BASIC verteilte Programmtext, Variablen und Zeichenketten weitgehend automatisch auf die verschiedenen Bereiche. Wer ausschließlich in BASIC arbeitete, bekam vom Bank-Switching daher wenig mit.

In Maschinensprache wurde es schwieriger. Programmierer mussten wissen, in welcher Bank ihr Code lag, welche Systemroutinen erreichbar waren und auf welchen Speicherbereich ein Befehl tatsächlich zugriff. Genau hier ließ das deutsche Handbuch Grabowski im Stich. Es erklärte zwar die grundsätzliche Speicheraufteilung, enthielt aber keine vollständige Übersicht der vom Betriebssystem verwendeten Adressen. Grabowski suchte deshalb selbst nach Cursorposition, Bildschirmzeile, Textfenster und Tastaturpuffer und veröffentlichte seine Ergebnisse im Test.

BASIC war nicht das Problem

Nach dem Einschalten meldete sich der Rechner mit BASIC 4.0+. Das wirkte 1983 bei einem Bürocomputer bereits etwas konservativ, doch die Sprache war deutlich besser ausgestattet als das schlichte BASIC V2 des C64.

Mit PRINT USING ließen sich Zahlenkolonnen, Dezimalstellen und Währungsbeträge sauber ausrichten – nützlich für Rechnungen, Lagerlisten und Tabellen. Verzweigungen konnten übersichtlicher geschrieben und Programmfehler behandelt werden, ohne dass die Ausführung sofort abbrach. Hinzu kamen Befehle für Laufwerke, Dateien, Zeichenketten und die Speicherbänke. Grabowski beurteilte vor allem die Fehlerbehandlung positiv und sah in BASIC 4.0+ ein brauchbares Fundament für kaufmännische und technische Programme.

Auch die Tastatur passte zum Büroeinsatz. Sie besaß einen eigenen Ziffernblock und programmierbare Funktionstasten, auf denen Befehle oder kurze Eingabefolgen abgelegt werden konnten. Der Editor arbeitete komfortabler als beim CBM 8032.

Eine kleine Eigenheit fiel erst bei längerer Benutzung auf: Hielt man eine Cursortaste gedrückt, verschwand der Cursor während der Bewegung und tauchte erst am Ziel wieder auf. Der Benutzer konnte zwischendurch nur schätzen, wie weit er gewandert war.

Der SID im Rechnungsbüro

Zwischen Speichersteuerung und Schnittstellen saß ein MOS 6581 SID. Der Chip bot drei programmierbare Stimmen, Hüllkurven, mehrere Wellenformen und ein gemeinsames Filter.

Beim C64 wurde der SID zum Ausgangspunkt zahlloser Spiele und Musikprogramme. Im CBM 700 war er eher für Signaltöne und akustische Rückmeldungen gedacht. Ein Rechner für Buchhaltung und Textverarbeitung konnte damit drei Stimmen durch ein analoges Filter schicken, während der Anwender am Grünmonitor seine Zahlenkolonnen bearbeitete.

Für den Büroalltag wichtiger war der IEEE-488-Bus. Vorhandene Commodore-Laufwerke und Drucker ließen sich grundsätzlich weiterverwenden. Der CBM 700 benötigte dafür allerdings ein besonderes Adapterkabel, weil sein Anschluss nicht in der von älteren Geräten gewohnten Form herausgeführt wurde.

Hinzu kam eine RS-232-Schnittstelle für Drucker, Modems und Terminals. Auch hier verlief der praktische Einsatz nicht immer geradlinig. Commodores eigener Zeichencode stimmte nicht vollständig mit dem ASCII-Code vieler Geräte überein. Grabowski warnte daher vor möglichen Zusatzkosten für eine Codewandlung.

Z80- und 8088-Koprozessoren sollten später CP/M beziehungsweise MS-DOS zugänglich machen. Die 8088-Platine erreichte mehrere Entwicklungsstufen, wurde jedoch nie zu einer breit verfügbaren und verlässlich unterstützten Erweiterung.

Das Handbuch kam nicht beim Käufer an

Der Titel „Computer mit Dokumentations-Defizit“ bedeutete nicht, dass Commodore überhaupt keine Unterlagen verfasst hatte. Ein deutsches Handbuch existierte, und auch ein umfangreicher englischer Reference Guide ist erhalten geblieben. Entscheidend war jedoch, was der Käufer 1984 tatsächlich bekam.

Das deutsche Handbuch behandelte maschinennahe Fragen nur oberflächlich. Das ausführlichere englische Material war nach Grabowskis Angaben in Deutschland nicht erhältlich. Nach späteren Berichten aus der CBM-II-Szene stellte ein Mitarbeiter von Commodore UK das englische Programmiererhandbuch weitgehend aus eigener Initiative und teilweise in seiner Freizeit zusammen, weil die britische Niederlassung den Rechner an Geschäftskunden verkaufen wollte.

Der Autor verfügte demnach nicht über vollständigen Zugang zu den Entwicklern und ihren Unterlagen. Das könnte erklären, weshalb das Handbuch viele nützliche Angaben enthielt, an anderen Stellen aber unklar blieb oder Beispiele aufführte, die nicht zuverlässig funktionierten.

Auch der erhaltene Reference Guide wirkt nicht wie eine vollständig durchredigierte Systembeschreibung. Bereits auf den ersten Seiten werden Hoch- und Niedrigprofilmodelle sowie verschiedene Bezeichnungen miteinander vermischt. Wer tiefer einsteigen wollte, benötigte zusätzliche Bücher und musste selbst herausfinden, welche Angaben für das eigene Modell galten.

Diese Lücke traf den CBM 700 besonders hart. Die neue Speicherarchitektur machte Programme des CBM 8032 häufig inkompatibel. Reines BASIC ließ sich noch anpassen, doch kommerzielle Anwendungen verwendeten oft feste Speicheradressen, eigene Bildschirmroutinen oder Maschinensprache. Neue Software hätte geschrieben werden können – dafür benötigten Programmierer jedoch genau jene Systeminformationen, die Commodore nicht zuverlässig bereitstellte.

Zu spät für den Markt

Ein Geschäftskunde kaufte keinen Computer, um auf eine künftige Umsetzung seiner Buchhaltung zu warten. Das Gerät sollte am Tag der Lieferung eine konkrete Aufgabe übernehmen. Grabowski berichtete, einige Händler würden den CBM 700 bereits nur noch mit ausdrücklichen Vorbehalten verkaufen.

Die älteren Commodore-Systeme boten weniger Speicher, konnten dafür aber auf vorhandene Programme und erfahrene Anwender zurückgreifen. Gleichzeitig wuchs rund um den IBM PC ein Markt aus Software, Erweiterungskarten und kompatiblen Nachbauten.

Innerhalb Commodores beanspruchte der erfolgreiche C64 einen großen Teil der Entwicklungskapazitäten, Fertigung und Werbung. Änderungen an Hardware und Firmware verzögerten unterdessen die CBM-II-Reihe. Die europäischen Geräte gingen erst gegen Ende 1983 in Braunschweig in Produktion. Bereits 1984 endete die Fertigung wieder.

In Großbritannien senkte Commodore den Preis der 700er-Serie 1983 um 18 Prozent auf 650 Pfund. Inflationsbereinigt entspricht das rund 2.960 Pfund im Jahr 2026. Laufwerk, Drucker und Anwendungssoftware waren damit noch nicht bezahlt.

Der Nachlass änderte nichts am Kernproblem. 128 oder 256 KByte RAM waren für einen Betrieb nur dann nützlich, wenn am Montagmorgen ein Programm bereitstand, das damit arbeitete.

Die Benutzer übernehmen

In den USA gelangten viele Geräte über den Restpostenhändler Protecto an neue Besitzer. Rund um Chicago entstand eine Benutzergruppe, die Programme, technische Hinweise und interne Unterlagen sammelte. Sie hielt das aufgegebene System noch einige Jahre am Leben.

Vier Jahrzehnte später stieß ein heutiger CBM-II-Programmierer auf dieselben Lücken. Er wollte das alte, mit der Schreibmaschine erstellte Referenzmaterial zunächst nur neu setzen und besser lesbar machen. Beim Durcharbeiten fand er jedoch unklare Erklärungen und Beispiele, die nicht funktionierten. Aus der Neusetzung entstand deshalb ein neues Handbuch mit Speicherkarte, KERNAL-Routinen und eigenen Programmbeispielen.

Commodore verwendete das Softline-Gehäuse später für Rechner, deren ältere Technik besser dokumentiert war und auf eine vorhandene Softwarebasis zurückgreifen konnte. Der modernere CBM 700 verschwand dagegen aus dem Programm.

Der Rechner war längst ein Sammlerstück. Seine Gebrauchsanweisung war noch immer nicht fertig.

It Came from the Desert (1989) – 15 Tage bis Lizard Breath fällt

Am 1. Juni 1951 kehrt Dr. Greg Bradley aus dem Urlaub nach Lizard Breath zurück. Die kalifornische Kleinstadt liegt zwischen Farmen, Minen und flimmernder Wüste. Eine Woche zuvor ist in den nahen Bergen ein Meteorit eingeschlagen. Der örtliche Prospektor Geez hat einige Bruchstücke geborgen und zu Bradley gebracht, der die Sache zunächst als geologische Untersuchung betrachtet.

Schon bald häufen sich Meldungen, die nicht recht zusammenpassen wollen. Tiere verschwinden, auf Farmen werden ungewöhnliche Spuren entdeckt, und draußen in der Wüste soll sich etwas bewegen. Manche Einwohner berichten bereitwillig davon, andere halten alles für Gerede. Der Bürgermeister verlangt handfeste Beweise, bevor er tätig werden will.

It Came from the Desert beginnt deshalb weder mit einer Actionsequenz noch mit einer offen sichtbaren Bedrohung. Cinemaware lässt den Spieler zunächst einer Reihe von Hinweisen folgen. Jede Fahrt kostet Zeit, Personen sind nicht ständig erreichbar, und während Bradley noch versucht, die Berichte einzuordnen, verändert sich die Lage außerhalb der Stadt.

Nach den ersten Untersuchungen wird klar, was sich draußen in der Wüste bewegt: Der Meteorit hat die Ameisen der Umgebung in haushohe Raubtiere verwandelt. Ihre Kolonie wächst und rückt mit jedem Tag näher an Lizard Breath heran.

Greg Bradley bleiben 15 Tage.

Der Film, an den Bob Jacob noch nicht gedacht hatte

David Riordan kam nicht aus der Spielebranche. Er hatte als Musiker und Produzent gearbeitet und beschäftigte sich bereits früh mit der Frage, wie sich Film und interaktive Technik miteinander verbinden ließen.

Anfang der achtziger Jahre war er für ein Projekt bei Lucasfilm tätig. In diesem Zusammenhang besuchte er auch die Architectural Machine Group am Massachusetts Institute of Technology, aus der später das MIT Media Lab hervorging.

Dort setzte man ihn vor einen Bildschirm, gab ihm einen Joystick und ließ ihn durch gefilmte Straßen von Aspen fahren. Das als Aspen Movie Map bekannte System verwendete Laserdiscs. An Kreuzungen konnte der Betrachter selbst entscheiden, in welche Richtung die Fahrt weiterging.

Riordan interessierte sich vor allem für die Erzählweise dahinter. Ein Film musste nicht mehr zwangsläufig vom Anfang bis zum Ende in derselben Reihenfolge ablaufen. Der Betrachter konnte Entscheidungen treffen und einen eigenen Weg durch vorbereitetes Material wählen.

Die frühen Laserdisc-Systeme blieben allerdings teuer und empfindlich. Sie ermöglichten große Bilder und echte Filmaufnahmen, beschränkten die Interaktion aber meist auf wenige vorbereitete Reaktionen. In Spielhallen kamen Staub, Abnutzung und lange Zugriffszeiten hinzu.

Riordan glaubte bereits, dass er in den herkömmlichen Filmbetrieb zurückkehren würde, als ihm ein Freund Defender of the Crown auf dem Amiga zeigte. Cinemawares Debüt besaß keine Filmaufnahmen. Es arbeitete mit gemalten Bildern, kurzen Animationen und einzelnen spielbaren Szenen. Trotzdem kam es Riordans Vorstellung eines interaktiven Films näher als die bisherigen Laserdisc-Versuche.

Er schrieb Bob und Phyllis Jacob einen Fanbrief. Die Cinemaware-Gründer luden ihn daraufhin in das noch kleine Unternehmen ein. Dort traf Riordan auch John Cutter, den ersten fest angestellten Mitarbeiter der Firma und einen ihrer wichtigsten Produzenten und Designer.

Bob Jacob fragte den Besucher, welches Filmgenre er selbst in ein Computerspiel verwandeln würde. Riordan antwortete ohne längeres Nachdenken: einen „Big Bug Movie“, also einen jener Monsterfilme, in denen übergroße Insekten eine amerikanische Kleinstadt bedrohen.

Jacob musste lachen. Cinemaware hatte bereits Ritterfilme, Gangsterdramen, Weltraumserien und orientalische Abenteuer aufgegriffen. An Riesenameisen hatte noch niemand gedacht.

Die Ameisen aus Formicula

David Riordan war sieben Jahre alt, als er Gordon Douglas’ Them! sah. Der Film kam 1954 in die Kinos und erhielt in Deutschland den Titel Formicula. Seine mechanischen Riesenameisen wirkten nicht in jeder Einstellung überzeugend. Die Produktion behandelte ihre Geschichte jedoch mit größtem Ernst.

Them! beginnt mit einem verstörten Mädchen, das allein durch die Wüste läuft. Es folgen zerstörte Gebäude, verschwundene Menschen, seltsame Spuren und ein durchdringendes Geräusch. Erst nach und nach erkennen Polizei und Wissenschaftler, dass Atombombentests gewöhnliche Ameisen in meterhohe Raubtiere verwandelt haben.

Das Militär kann einzelne Tiere vernichten. Die wirkliche Gefahr liegt im Nest und in jungen Königinnen, die neue Kolonien gründen könnten. Die Suche führt schließlich unter die Erde, wo Soldaten mit Flammenwerfern gegen die Brut vorgehen.

Der Film gehörte zu einer ganzen Reihe amerikanischer Produktionen, in denen Strahlung oder Atomtests das Monster hervorbrachten. In Them! löst die Bombe die Bedrohung unmittelbar aus.

Cinemaware übernahm von Them! weit mehr als das Tier. Auch der Wüstenschauplatz, die Ameisensäure, die Suche nach Spuren, das Vorgehen gegen die Fühler und der spätere Einsatz der Nationalgarde erinnern an den Film. Der Titel spielt zusätzlich mit Jack Arnolds It Came from Outer Space von 1953.

Riordan wollte Them! nicht nacherzählen. Der Film blieb ein ernstes Warnstück, während It Came from the Desert seine Figuren mit trockenem Humor betrachtet. Der Bürgermeister verlangt vier unterschiedliche Beweise, bevor er sich zu der Annahme durchringt, dass haushohe Ameisen ein kommunales Problem darstellen. Jugendliche verabreden sich im Autokino zu Messerduellen, ein Sektenführer lebt außerhalb der Stadt, und das Krankenhaus hält für jede verlorene Auseinandersetzung ein freies Bett bereit.

Der Ton ist komisch, die Bedrohung bleibt ernst. Lizard Breaths Einwohner verhalten sich wie Figuren eines alten Monsterfilms, die lieber noch einen weiteren Beweis verlangen, bevor sie die Nationalgarde alarmieren.

Eine Kleinstadt auf Papier

Riordan hatte zuvor noch kein Computerspiel entworfen und behandelte das Projekt deshalb wie einen Film. Er zeichnete eine Karte von Lizard Breath, legte Figuren und Schauplätze fest und bereitete wichtige Szenen mit Storyboards vor. Aus Karten, Dialogen, Zeichnungen und Zeitplänen entstand eine umfangreiche Produktionsbibel. Riordan bewahrte sie auf und zeigte Teile davon noch Jahrzehnte später bei einem Rückblick auf die Entwicklung.

Darin war festgelegt, was geschehen sollte, wann es geschah und an welchem Ort. Ereignisse konnten an bestimmte Spieltage, Uhrzeiten, Schauplätze und vorherige Entscheidungen gebunden sein. Wer zu spät eintraf oder sich für einen anderen Weg entschieden hatte, bekam eine Szene möglicherweise nicht zu sehen.

Für die Verwaltung dieser Abläufe nutzte Cinemaware das auf Apples HyperCard beruhende Werkzeug MasterPlan. Damit ließen sich Orte, Ereignisse und Bedingungen miteinander verknüpfen. Die Actionsequenzen mussten weiterhin einzeln programmiert werden.

Riordan plante Lizard Breath als Terminplan mit Abzweigungen. Der Spieler konnte in einem Durchgang weder alles sehen noch an jedem Ort rechtzeitig eintreffen.

Die Uhr läuft weiter

Riordan störte an vielen Adventures, dass ihre Welt geduldig auf den Spieler wartete. Für It Came from the Desert entwarf er deshalb einen festen Zeitrahmen: Eine Sekunde entspricht ungefähr einer Spielminute, Fahrten benötigen mehrere Stunden, Untersuchungen dauern bis zum folgenden Tag und Bradley muss regelmäßig schlafen. Nach 15 Tagen wird Lizard Breath überrannt, sofern die Kolonie bis dahin nicht vernichtet wurde.

Zunächst benötigt Bradley vier Beweise: einen Abdruck, eine Geräuschaufnahme, Körperflüssigkeit und einen Teil einer Ameise. Professor Wells untersucht die Funde, bevor der Bürgermeister die Bedrohung anerkennt und die Nationalgarde anfordert. Danach lassen sich verfügbare Kräfte auf gefährdete Gebiete verteilen. Sie können den Vormarsch bremsen. Beenden kann ihn nur Bradley, indem er die Königin findet.

Viele Hinweise sind auf unterschiedlichen Wegen erhältlich. Wer einen Termin oder eine Begegnung verpasst, hat daher nicht sofort verloren, muss aber zusätzliche Zeit investieren. Lizard Breath besteht grafisch überwiegend aus Standbildern, doch im Hintergrund wechseln Personen ihren Aufenthaltsort, Meldungen treffen ein und die Lage verschlechtert sich.

Vom Revolver zum Flammenwerfer

Als Geologe ist Greg Bradley erstaunlich vielseitig. Er schießt auf die Ameisen, wirft Dynamit, fliegt über die Wüste, fährt einen Panzer und tritt im Autokino zum Messerduell gegen die örtlichen Hellcats an. Im Finale steigt er mit einem Flammenwerfer in das Nest hinab, sucht die Königin und legt eine Sprengladung.

Keine dieser Actionsequenzen besitzt für sich große Tiefe. Manche sind schnell durchschaut, andere steuern sich ungenau. Ihre Bedeutung ergibt sich aus dem jeweiligen Anlass.

Der Flug kann die benötigte Tonaufnahme liefern, der Panzer steht erst nach dem Eingreifen der Nationalgarde bereit, und das Messerduell folgt auf eine Begegnung mit den Hellcats. Dadurch wirken die einzelnen Abschnitte wie Szenen innerhalb der laufenden Geschichte und weniger wie frei wählbare Zusatzspiele.

Auch eine Niederlage beendet das Spiel meist nicht. Wird Bradley verletzt oder von einer Ameise überwältigt, wacht er im Krankenhaus auf. Dort kann er sich behandeln lassen oder in einer eigenen Draufsichtsequenz durch Flure, Treppenhäuser und Krankenzimmer zum Ausgang fliehen.

Der eigentliche Schaden ist der Zeitverlust. Während Bradley im Bett liegt, schließen Büros, Informanten verschwinden und die Ameisen rücken weiter vor. Ein Fehlschlag verändert damit den weiteren Ablauf.

It Came from the Desert verlangt nicht, dass jede Szene beim ersten Versuch gelingt. Es erzählt auch mit Bradleys Fehlern weiter. Nur die Uhr lässt sich davon nicht beeindrucken.

Neun Geschichten, Platz für eine

Riordans ursprünglicher Entwurf war erheblich größer. Er plante neun unterschiedliche Szenarien. Randy Platt prüfte schließlich, was davon auf den vorgesehenen Disketten unterzubringen war, und brachte seinem Designer eine nüchterne Nachricht: Auf drei Disketten passe ein Szenario, nicht neun.

Platt erscheint in den Amiga-Credits unter der ungewöhnlichen Bezeichnung „Computography“. Riordan bezeichnete ihn rückblickend ausdrücklich als leitenden Programmierer. Bei der späteren DOS-Fassung wurde seine Tätigkeit auch offiziell als Programmierung aufgeführt.

Platt musste Skripte, Bilder, Musik, Actionsequenzen und Spielzustände zu einer Fassung verbinden, die auf einem handelsüblichen Amiga lief. Tom McWilliams übernahm zusätzliche technische Arbeit, Richard S. Levine entwickelte die Scripting-Werkzeuge.

Cinemaware begrenzte seine Produktionen gewöhnlich auf zwei Disketten. It Came from the Desert erhielt als Ausnahme eine dritte und setzte zudem ein Megabyte Arbeitsspeicher voraus. Ende 1989 war das bei einem Amiga 500 noch keine selbstverständliche Ausstattung.

Die drei Disketten wurden passend zur Filminszenierung als „Reels“, also Filmrollen, bezeichnet. Wer nur ein Laufwerk besaß, wechselte regelmäßig zwischen ihnen. Die Datenkompression schuf Platz für mehr Bilder, Dialoge und Musik, konnte die Zugriffszeiten des Diskettenlaufwerks aber nicht beseitigen.

Der interaktive Film wurde daher immer wieder vom vertrauten Rattern des Laufwerks unterbrochen.

Künstler statt zeichnender Programmierer

Jeffrey Hilbers und Jeff Godfrey zeichneten die Spielgrafik, Art Huff steuerte weitere Bilder bei. Riordan sprach später meist von den „beiden Jeffs“, wenn er ihre Arbeit beschrieb.

Cinemaware engagierte für seine Grafiken ausgebildete Künstler. Art Director Rob Landeros brachte ihnen anschließend den Umgang mit Deluxe Paint bei. John Cutter fasste die damalige Vorgabe später knapp zusammen: Eingestellt wurde, wer malen konnte.

Jeder Schauplatz in Lizard Breath ist auf den ersten Blick zu erkennen. Die Bar ist mit Flaschen, Lampen und zweifelhaftem Wandschmuck ausgestattet, das Büro des Bürgermeisters wirkt so ordentlich wie sein Besitzer selbstzufrieden. Im Autokino ist auf der Leinwand ausgerechnet Rocket Ranger zu sehen, Cinemawares eigenes Science-Fiction-Abenteuer aus dem Vorjahr.

Auch die Figuren wurden nicht auf kleine Spielfiguren reduziert. Ihre Porträts nehmen einen großen Teil des Bildschirms ein: der Reporter mit seinem einstudierten Grinsen, der sture Bürgermeister, Professor Wells, die Krankenschwestern und die Hellcats im Autokino.

Die großen Gesichter erlaubten Cinemaware, eine Figur mit einem einzigen Bild einzuführen. Dafür brauchte es weder lange Dialoge noch aufwendige Animationen.

Musik in kurzen Schleifen

Greg Haggard und Jim Simmons komponierten kurze Themen für die einzelnen Schauplätze und Gefahrensituationen. Für einen durchgehenden Filmscore war auf drei Disketten kein Platz. Stattdessen erhielten Bar, Wüste, Krankenhaus und Ameisenangriffe jeweils eigene musikalische Schleifen.

Hinzu kommen digitalisierte Geräusche. Besonders das schrille Rufen der Ameisen verweist auf Them!, wo der Laut die Tiere häufig ankündigt, bevor sie zu sehen sind. Schon nach wenigen Takten oder einem einzigen Schrei ist klar, ob Bradley ungestört ermittelt oder gleich sehr große Probleme bekommt.

Vollpreis für drei Filmrollen

In Großbritannien kostete die Amiga-Fassung rund 30 Pfund. Das entspricht etwa 82 Pfund in Preisen von 2025.

In Deutschland nannten Power Play und ASM einen Preis von ungefähr 100 DM. Das entspricht rund 103 Euro in Preisen von 2025.

In der Packung lagen drei Disketten, eine ausführliche Anleitung und eine Karte von Lizard Breath, die bei der Planung der Fahrten tatsächlich gebraucht wurde.

Zwischen 73 und 96 Prozent

Die britische Spielepresse reagierte überwiegend begeistert. Zzap! vergab 90 Prozent, Amiga Action 91 Prozent und The One 92 Prozent. Die höchste Wertung kam von CU Amiga-64: Mike Pattenden gab 96 Prozent und bezeichnete das Spiel als Cinemawares bis dahin vollständigste Produktion. Das amerikanische Magazin INFO verlieh fünf von fünf Sternen.

Die deutsche Power Play blieb mit 73 Prozent deutlich zurückhaltender. Anatol Locker erkannte die Stärke der Inszenierung an:

„Das Flair der B-Movies ist derart gut eingefangen, daß man mit der Zeit völlig im Spiel aufgeht.“

Unter Grafik und Musik sah er zugleich ein vergleichsweise einfaches Strategiespiel, dessen Grundzüge erfahrene Spieler schnell durchschauen konnten.

Die ASM vergab keine Gesamtwertung in Prozent, bewertete Grafik, Atmosphäre und Sound aber hoch. Der Sound erhielt elf von zwölf Punkten, die Grafik zehn. Kritik gab es vor allem am ruckelnden Scrolling und am ebenfalls wenig geschmeidigen Abspann.

Die große Spanne der Wertungen erklärt sich aus den Erwartungen der Tester. Wer die Actionsequenzen einzeln betrachtete, fand weder einen besonders präzisen Kampf noch eine umfangreiche Flugsimulation. Wer Zeitplan, Schauplätze und Folgen als Ganzes bewertete, sah darin eine neue Form des erzählenden Computerspiels.

Antheads: Die zweite Geschichte aus dem alten Entwurf

Der Erfolg führte 1990 zu Antheads: It Came from the Desert II. Die Erweiterung entstand aus einem jener acht Szenarien, die Riordan aus Platzgründen nicht in das Hauptspiel aufnehmen konnte.

Die Handlung spielt nach den Ereignissen des ersten Teils. Eine weitere Bedrohung entwickelt sich rund um Lizard Breath, und Menschen verwandeln sich zeitweise in ameisenartige Wesen. Das Zeitlimit sinkt von 15 auf zehn Tage.

Cinemaware verwendete den technischen Unterbau des Hauptspiels weiter. Stadt, viele Bilder und ein großer Teil der vorhandenen Abläufe blieben erhalten. Neue Szenen, Dialoge und Bedingungen wurden in das bestehende System eingefügt.

Riordan beschrieb das Verfahren später vereinfacht so, dass eines der drei ursprünglichen Datenpakete durch neues Material ersetzt wurde. Damit ließ sich eine weitere Geschichte erzählen, ohne Lizard Breath vollständig neu bauen zu müssen.

Antheads erschien in Europa regulär im Handel. Die Packung enthielt zwei Disketten: die Master Disk und die Data Disk. Für die Installation wurden zusätzlich die drei Originaldisketten des Hauptspiels und drei leere Disketten benötigt. Das Kopierprogramm übertrug die vorhandenen Daten, ergänzte das neue Material und erzeugte daraus einen vollständigen Satz aus drei Desert II-Reels.

Bei dieser Verkaufsversion musste keine Originaldiskette an Cinemaware geschickt werden. Das Hauptspiel wurde benötigt, eine Einsendung war jedoch nicht erforderlich.

Als die echten Schauspieler kamen

Die drei Disketten waren für Riordan nur ein erster Schritt. Nach der Amiga-Fassung arbeitete seine Gruppe an einer aufwendigeren Version mit Schauspielern, Sprache und gefilmten Kulissen. Riordan bezeichnete dieses Projekt rückblickend gelegentlich als „Desert 3“, obwohl dies nie der offizielle Titel war.

Die Darsteller wurden vor grünen Flächen aufgenommen. Das Team setzte sie anschließend vor künstliche Hintergründe und experimentierte mit der Verbindung aus Film und Computergrafik. Für die Ameisen entstanden Stop-Motion-Modelle.

Die CD-ROM bot gegenüber Disketten eine gewaltige Speichermenge. Das Zielsystem erwies sich jedoch als Problem. NEC beteiligte sich 1990 an Cinemaware und band die Produktion an die CD-Erweiterung des TurboGrafx-16. In Japan war die Grundkonsole als PC Engine bekannt; in Europa spielte sie kaum eine Rolle.

Das CD-Laufwerk bot Platz, doch Prozessor und Videohardware der Konsole passten schlecht zu Riordans Plänen. Die aufgenommenen Bilder mussten stark verkleinert und komprimiert werden. Zugleich wurde der Spielablauf vereinfacht.

Riordan urteilte später offen, dass das TurboGrafx-Ergebnis schlecht aussehe und ihm manche gemalte Szene der Amiga-Fassung besser gefalle. Das Team sammelte dabei jedoch Erfahrungen mit Schauspielern, Greenscreen, Stop-Motion und großen Mengen aufgezeichneter Dialoge.

Riordan verwendete diese Kenntnisse später bei FMV-Produktionen wie Voyeur und der interaktiven Umsetzung der Fernsehserie Thunder in Paradise.

Für Cinemaware war das Experiment teuer. Bob Jacob bezifferte die Investition rückblickend auf mindestens 700.000 Dollar. Weil sich das TurboGrafx-System in Nordamerika schlecht verkaufte und die vertragliche Bindung eine Veröffentlichung auf anderen Plattformen verhinderte, ließ sich ein großer Teil der Kosten nicht zurückholen.

Die CD-Fassung war nicht der einzige Grund für Cinemawares Ende. Hinzu kamen hohe laufende Ausgaben, verspätete Umsetzungen, der schwächer werdende amerikanische Amiga-Markt und weitere kostspielige Projekte. Eine von Trip Hawkins und Teilen der Electronic-Arts-Führung unterstützte Übernahme scheiterte am EA-Vorstand. 1991 wurde Cinemaware aufgelöst.

Die Suche nach dem technisch echten interaktiven Film hatte damit ausgerechnet jene Firma überfordert, die den Eindruck eines Films auf drei Disketten überzeugender erzeugt hatte.

Fassungen, die Lizard Breath zurückließen

1990 folgte eine DOS-Fassung. Sie übernahm den grundsätzlichen Ablauf, erreichte aber nicht die Farbwirkung und den Klang der Amiga-Ausgabe.

Eine Atari-ST-Version tauchte in Vorschauen, Preislisten und Testkästen auf. Eine regulär veröffentlichte Handelsfassung ist jedoch nicht bekannt. Auch für den C64 bestanden Planungen, eine fertige Veröffentlichung lässt sich aber nicht nachweisen.

Noch weiter vom Original entfernte sich die Mega-Drive-Fassung. Sie war kein Adventure mit Stadtplan und Zeitmatrix, sondern ein schnelles Actionspiel aus der Draufsicht. Matt Harmon arbeitete als leitender Designer und Programmierer daran. Nach seiner Erinnerung war das Spiel beinahe fertig, als Electronic Arts das Projekt stoppte.

Die Fassung erschien damals nicht. Erst Jahre später gelangte das ROM in Umlauf.

Diese Umsetzungen zeigen, wie schwer sich das Original übertragen ließ. Seine Stärke lag in der Verbindung aus Riesenameisen, Zeitplan, Schauplätzen und Konsequenzen. Wer nur die Tiere und das Schießen übernahm, behielt das auffälligste Bild und verlor Lizard Breath.

Eine Stadt, die nicht wartet

It Came from the Desert ist kein besonders tiefes Adventure. Die strategische Truppenverteilung bleibt überschaubar, und mehrere Actionsequenzen sind entweder ungenau oder schnell durchschaut. Ein einzelnes Diskettenlaufwerk wird während eines Durchgangs ausgiebig beschäftigt.

Das Spiel funktioniert, weil eine Entscheidung Folgen für den weiteren Ablauf hat. Eine Information führt zu einer Fahrt, die Fahrt kostet Zeit, am Ziel wartet möglicherweise ein Kampf, und eine Niederlage verschiebt den restlichen Tagesplan. Das Labor benötigt Zeit, Personen wechseln ihren Aufenthaltsort, und der Bürgermeister glaubt erst, was ihm mehrfach bewiesen wurde.

David Riordan wollte eine Geschichte schaffen, in der die Entscheidung für einen Ort zwangsläufig bedeutete, einen anderen zu verpassen.

Cinemaware besaß 1989 weder hochauflösendes Video noch ein CD-Laufwerk. Das Team erzeugte Bewegung deshalb mit einer Karte, einem Kalender und einer Stadt, deren Bewohner nicht geduldig an derselben Stelle stehen blieben.

Am Ende trägt Greg Bradley einen Flammenwerfer durch die Gänge des Ameisennests. Hinter ihm liegen verpasste Termine, Krankenhausaufenthalte, ausgewertete Proben und Fahrten durch die Wüste. Vor ihm wartet die Königin.

Über der Erde liegt Lizard Breath in der Nachmittagshitze. Das Laufwerk greift auf die nächste Diskette zu.

Und die Uhr läuft weiter.

```html ```

Speedball (1988) – Vom abgelehnten Tennisspiel zur Stahlkugel-Arena

Kann man sich heute noch vorstellen, dass ausgerechnet Speedball bei seinem ersten Publisher keine Begeisterung auslöste? Jenes Spiel, das später so eng mit dem Namen der Bitmap Brothers verbunden wurde, fiel bei Mastertronic gleich zweimal durch. Dabei hatte die Geschichte zunächst weder mit gepanzerten Spielern noch mit einer schweren Metallkugel begonnen.

Mastertronic beauftragte die noch jungen Bitmap Brothers mit einer Umsetzung von Real Tennis. Die historische Hallensportart wird auf einem von Mauern, Vorsprüngen und Öffnungen eingefassten Feld gespielt, das mit einem modernen Tennisplatz nur entfernt verwandt ist. Mike Montgomery, Steve Kelly und Eric Matthews beschäftigten sich mit den Regeln, recherchierten den Platz in Hampton Court und investierten bereits einiges an Arbeit in das Projekt. Dann änderte Mastertronic seine Pläne und zog den Auftrag zurück.

Das Trio tat daraufhin etwas, das in der Firmengeschichte der Bitmap Brothers häufiger zu brauchbaren Ergebnissen führte: Es ging in den Pub. Dort entstand nach Montgomerys Erinnerung auf der aufgeklappten Rückseite einer Zigarettenschachtel das Grundgerüst eines neuen Spiels. Vom Real Tennis blieben die Mauern, das Spiel über die Begrenzungen und die Idee, den Ball durch Öffnungen an eine andere Stelle des Feldes zu befördern. Weitere Elemente kamen von den Flipperautomaten, an denen die drei Entwickler regelmäßig spielten.

Aus dem historischen Rückschlagspiel wurde eine Stahlhalle, aus dem Schläger ein gepanzerter Körper und aus dem Tennisball eine Metallkugel, die man ebenso gut ins Tor werfen wie einem heranstürmenden Gegner entgegenfeuern konnte. Mastertronic bekam auch dieses Konzept zu sehen – und lehnte erneut ab. Erst John Cook von Mirrorsoft erkannte, was aus dem gestrichenen Auftrag geworden war, und nahm Speedball für das Label Image Works unter Vertrag: halb Mannschaftsspiel, halb Flipperautomat und im Zweifelsfall eine recht handfeste Auseinandersetzung um den Ball.

Für die Bitmap Brothers war Cooks Zusage wichtig, weil Speedball unmittelbar nach Xenon ihr zweites Spiel werden sollte. Das junge Studio hatte zwar Aufmerksamkeit gewonnen, aber noch keine Erfolgsserie, auf die es sich verlassen konnte. Ein Publisher, der nicht nur das Spiel übernahm, sondern auch den Namen der Entwickler sichtbar machen wollte, passte deshalb genau zu ihren Plänen.

Montgomery, Kelly und Matthews kannten sich aus ihrer Zeit bei Leisure Genius. Kelly und Montgomery hatten dort unter anderem an Computerfassungen klassischer Brettspiele gearbeitet, Matthews steuerte Grafiken bei. Aus der gemeinsamen Arbeit, regelmäßigen Pubbesuchen und Abenden in Spielhallen entstanden schließlich die Bitmap Brothers. Mit Xenon hatten sie bereits einen auffälligen Einstand geliefert; Speedball musste nun zeigen, dass es nicht bei diesem einen Treffer bleiben würde.

Der Vergleich mit Norman Jewisons Film Rollerball lag nahe: gepanzerte Spieler, eine Metallkugel und ein Zukunftssport ohne übertriebene Rücksichtnahme. Montgomery erinnerte sich jedoch an keinen bewussten Einfluss des Films. Als Ausgangspunkte nannte er Real Tennis, Flipperautomaten und die gemeinsamen Spielhallenbesuche. Speedball sah aus wie ein Spiel zu Rollerball, war aber auf einem anderen Weg entstanden.

Mit Mirrorsoft fanden die Bitmap Brothers zugleich einen Partner für ihre ungewöhnliche Selbstdarstellung. Die Entwickler wollten nicht hinter dem Firmenlogo des Publishers verschwinden. Wer eines ihrer Spiele kaufte, sollte wissen, von wem es stammte – ähnlich wie ein Musikfan eine Platte wegen des Künstlers und nicht wegen des Plattenlabels auswählte.

Mirrorsoft unterstützte diesen Plan mit Presseauftritten und Fotoserien. Das bekannteste Bild zeigt Montgomery, Kelly und Matthews mit Sonnenbrillen und Lederjacken vor Robert Maxwells Hubschrauber. Das Trio wartete am Mirror-Gebäude einen großen Teil des Tages auf Maxwells Rückkehr von einem Pferderennen und bekam schließlich nur wenige Minuten für die Aufnahmen. Das tiefe Abendlicht erledigte den Rest. Aus einem hastig angesetzten Fototermin wurde eines der bekanntesten Entwicklerbilder der britischen Heimcomputerzeit.

Auf dem Bildschirm ließ Speedball seine Herkunft aus dem Real Tennis rasch vergessen. Zwei Mannschaften mit jeweils fünf Spielern jagten eine Metallkugel durch eine geschlossene Arena, spielten über die Wände und räumten Gegner mit Tacklings aus dem Weg. Fouls gab es nicht. Wer den Ball verlor, durfte ihn sich zurückholen; höfliches Nachfragen war dafür nicht vorgesehen.

Die Flippervergangenheit blieb dennoch überall sichtbar. Prallkuppeln veränderten die Flugbahn der Kugel, Tunnel beförderten sie an eine andere Stelle des Feldes, und die Bande gehörte zum Passspiel. Wer einen Winkel richtig einschätzte, umging damit einen Verteidiger. Wer ihn falsch einschätzte, bereitete dem Gegner einen erstaunlich präzisen Konter vor.

Die Ein-Knopf-Steuerung war schnell verstanden, aber nicht sofort beherrscht. Vor allem die automatische Wahl des ballnächsten Spielers konnte im Gedränge zu einer anderen Figur springen, als man gerade erwartet hatte. Symbole griffen kurzfristig in die Partie ein, während gesammelte Marken zwischen den Spielen sogar in Bestechungen investiert werden konnten. Schiedsrichter, Zeitnehmer und Trainer zeigten sich für finanzielle Argumente empfänglich. Korruption war hier kein Gerücht hinter verschlossenen Türen, sondern ein ordentlich beschrifteter Menüpunkt.

Seine Wirkung verdankte Speedball jedoch nicht den einzelnen Extras, sondern seinem Tempo. Ein Tackling konnte innerhalb eines Augenblicks die gesamte Spielfeldhälfte öffnen, ein Pass über die Bande ebenso gut einen Angriff einleiten wie im Rücken des eigenen Spielers verschwinden. Gegen einen menschlichen Gegner fiel zudem jedes berechenbare Verhalten des Computers weg. Dann wurde aus dem Zukunftssport ein unmittelbares Duell um Raum, Timing und die Frage, welcher der beiden Joysticks den Abend unbeschädigt überstehen würde.

Genau diese körperliche Unmittelbarkeit fiel den damaligen Magazinen auf. Die ASM testete im Dezember 1988 die Atari-ST-Version und vergab 10 von 10 Punkten für die Grafik sowie jeweils 9 für Spielablauf und Motivation. Klaus Vill lobte das „softe Scrolling“, die großen, gut animierten Sprites und den metallisch-blauen Hintergrund. Speedball stelle hohe Anforderungen an Joystick und Besitzer, schrieb er – eine Formulierung, die das Spiel besser trifft als manche ausführliche Regelerklärung.

Vill störte sich zwar an David Whittakers für ihn „betont eintönigen Musikstücken“, erklärte Speedball am Ende aber dennoch zum „Muß für Action-Fans“. Für die ASM war es keine nüchterne Simulation einer erfundenen Sportart, sondern Action unter ständigem Druck.

Auch Heinrich Lenhardt stellte in der Power Play nicht die Regelkunde in den Mittelpunkt. Speedball verlange gute Reaktionen, etwas Taktik und ein wenig Glück. „Das Geschehen ist so hektisch, daß man schon mal den Überblick etwas verlieren kann“, schrieb er. Gerade dieses Gefühl, der Partie ständig einen halben Schritt hinterherzulaufen, gehörte zu ihrer Spannung.

Im Sonderheft Die 100 besten Spiele erhielt die Amiga-Version 83 Prozent, der Atari ST 82 Prozent, der C64 78 Prozent und MS-DOS 68 Prozent. Amiga und Atari ST lagen damit praktisch gleichauf. Die DOS-Umsetzung bewahrte zwar den Spielablauf, wirkte mit EGA-Grafik und PC-Speaker-Klang aber deutlich spröder.

Für das sichtbare Gesicht des Spiels sorgte Mark Coleman. Die stahlblauen Flächen, schweren Helme und glänzenden Rüstungen tragen bereits jene Handschrift, die später eng mit den Bitmap Brothers verbunden wurde. Seine Figuren wirkten kräftig und schwer, blieben aber auch im Gedränge lesbar. Ballbesitz, Bewegungsrichtung und Tackling mussten auf den ersten Blick verständlich sein. Wenn zwei Sprites zusammenprallten, sah das nicht nach einer höflichen Berührung zweier Spielfiguren aus.

Die Verpackungsillustration von David John Rowe durfte diese körperliche Bedrohung größer ausspielen. Wo Colemans Figuren auf dem Bildschirm klein und funktional bleiben mussten, machte Rowes Titelbild aus dem Zukunftssport eine Veranstaltung, bei der vermutlich bereits die vorderen Zuschauerreihen Schutzhelme benötigten.

Musik und Soundeffekte stammten von David Whittaker. Während die ASM den Atari-ST-Klang wenig abwechslungsreich fand, wurde Whittakers Musik bei der späteren C64-Umsetzung zu einem der meistgelobten Elemente.

Diese Version erschien 1989 und wurde von Andrew Bowen bei Pantheon Software umgesetzt; Sam Mohabull passte Colemans Grafik an den Commodore 64 an. Die Konvertierung opferte sichtbare Details, bewahrte aber das Tempo. Tacklings, Bandenspiel und Zweispielermodus blieben erhalten – und damit alles, worauf es bei Speedball wirklich ankam.

Commodore User zeichnete die Umsetzung im Mai 1989 mit einem „CU Screen Star“ und 88 Prozent aus. Besonders auffällig waren 95 Prozent für die Spielbarkeit und 91 Prozent für den Sound. Tony Dillon beendete seinen Test mit der Frage: „The perfect downward conversion? Probably not, but the closest anyone has been yet.“ – „Die perfekte Umsetzung auf ein kleineres System? Wahrscheinlich nicht, aber näher war bis dahin niemand gekommen.“

Auch Zzap!64 sah darin eine der eindrucksvollsten Übertragungen von 16 auf 8 Bit. Die Fassung sehe gut aus, klinge großartig und sei „an absolute scorcher in the addiction department“ – in Sachen Suchtwirkung also ein regelrechter Brenner. Vor allem gegen einen geübten zweiten Spieler sei das Geschehen „fast and furious“, schnell und furios.

Die C64-Version bildete nicht jedes technische Detail der Amiga- und Atari-ST-Fassungen nach. Sie bewahrte deren Rhythmus. Der Ball blieb schnell, die Spieler reagierten unmittelbar, und ein verlorenes Tackling öffnete noch immer innerhalb eines Augenblicks den Weg zum Tor. Selbst die Power Play stellte fest, auf dem „kleinen“ C64 gehe nichts vom Spielspaß verloren.

Weitere Umsetzungen folgten für das Sega Master System und 1991 für das NES, wo das Spiel unter dem Namen KlashBall erschien. Grafik und Geschwindigkeit änderten sich, doch der Kern blieb sofort erkennbar: gepanzerte Figuren, eine Metallkugel und ein Spielfeld, dessen Wände Teil des Spiels waren.

In Deutschland kostete Speedball laut ASM etwa 65 DM. Die Power Play nannte abhängig vom System Preise zwischen 49 und 85 DM. Für den C64 führten britische Magazine rund 9 bis 10 Pfund für die Kassette und etwa 13 bis 15 Pfund für die Diskette auf. Später nahm Mirrorsoft den Titel für 9,99 Pfund in die Budgetreihe Mirror Image auf.

Anlässlich dieser Neuauflage kennzeichnete The One Speedball als „Best Buy“. Die Redaktion musste das Spiel für ihren Rückblick offenbar nicht mühsam aus dem Archiv hervorkramen. Man erinnerte sich daran, dass der Büromonitor nach der ursprünglichen Veröffentlichung ständig besetzt gewesen sei und das metallische Krachen der Spieler zum Redaktionsalltag gehört habe. Erst Kick Off habe die internen Speedball-Partien vorübergehend verdrängt.

The One fasste das Spiel später mit einem Satz zusammen: „Two teams of heavily-armoured men beating each other up – and occasionally trying to get the ball in their opponent’s goal.“ – „Zwei Mannschaften schwer gepanzerter Männer prügeln aufeinander ein – und versuchen gelegentlich, den Ball ins gegnerische Tor zu bekommen.“

1990 baute Speedball 2: Brutal Deluxe nahezu jeden Bereich aus und prägte die Erinnerung an die Reihe so stark, dass der erste Teil später häufig nur noch als Vorstufe erschien. Für die Redaktionen von 1988 und 1989 war Speedball jedoch längst ein vollständiges Spiel: schnell, laut, fordernd und im Zweispielermodus schwer wieder aus dem Laufwerk zu bekommen. Bei The One musste erst Kick Off erscheinen, um die internen Partien vom Büromonitor zu verdrängen. Für ein Spiel, das Mastertronic zweimal nicht haben wollte, war das eine recht deutliche Antwort.