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. Im Gegenteil: Für ein Lucasfilm-Adventure von 1989 war sie fast heiliges Beiwerk. Disketten, Handbuch, Übersetzungstabelle, Gral-Tagebuch – alles daran roch nach großem Abenteuer, nach Kino, nach dem Versprechen, dass ein Heimcomputer mehr konnte, als Raumschiffe abschießen oder Männchen über Plattformen scheuchen. Nur hatte ich ein Problem: Ich hatte das Spiel heimlich gekauft.

Nach Maniac Mansion und Zak McKracken war für mich klar, dass Lucasfilm Games etwas anderes machte als der Rest. Und Indiana Jones war ohnehin keine normale Lizenzfigur, sondern der Mann mit Hut, Peitsche und dieser beneidenswerten Fähigkeit, aus jeder Katastrophe mit einer neuen Schramme herauszukommen. Also wanderte mein Taschengeld in Indiana Jones and the Last Crusade: The Graphic Adventure. Meine Mutter sah Computerspiele allerdings nicht als kulturelle Frühförderung, sondern eher als teuren Unfug. Also nahm ich Disketten, Handbuch und Codetabelle heraus, zerriss die Verpackung und entsorgte sie im Müll. Heute wäre das für Sammler kein Kavaliersdelikt, sondern Sakrileg. Bei einem Spiel über den Heiligen Gral immerhin passend.

Ausgerechnet diese vernichtete Schachtel erzählt aber schon viel über Last Crusade. Lucasfilm Games behandelte das Drumherum nicht als Verpackungsmüll, sondern als Teil des Spiels. Henry Jones’ Gral-Tagebuch war kein hübsches Gimmick, sondern Hinweisgeber, Atmosphärenträger und halber Kopierschutz. Handbuch, Codetabelle und Tagebuch lagen nicht nur neben dem Spiel, sie verlängerten es auf den Schreibtisch. Man spielte nicht nur am Bildschirm. Man blätterte, verglich, notierte, übersetzte und hoffte, dass Henry Jones senior wenigstens diesmal wusste, was er tat.

Drei Männer gegen den Kinokalender

Als Indiana Jones and the Last Crusade: The Graphic Adventure im Sommer 1989 erschien, lief Steven Spielbergs dritter Indiana-Jones-Film in den USA und Großbritannien noch frisch in den Kinos; in Deutschland kam er erst im September an. Offiziell wird die ursprüngliche DOS-Fassung heute auf den 1. Juli 1989 datiert; in der damaligen Wahrnehmung war es dennoch ein Spiel dieses Filmsommers. Das passte, denn genau dort musste Lucasfilm Games landen: nahe genug am Kinostart, um vom Hype zu profitieren, aber gut genug, um nicht wie ein gewöhnliches Lizenzspiel zu wirken. Gerade Letzteres war die eigentliche Herausforderung.

Drei Männer, ein Kinotermin, keine Ausrede: Noah Falstein, Ron Gilbert und David Fox mussten aus dem dritten Indiana-Jones-Film ein Adventure bauen, bevor der Sommer vorbei war. Das klingt heute nach Dream-Team, war 1988 aber vermutlich vor allem viel Arbeit. Falstein gehörte zu den frühen Köpfen von Lucasfilm Games, Fox hatte mit Labyrinth bereits eine Filmvorlage in Spielform gebracht und mit Zak McKracken gezeigt, dass SCUMM mehr konnte als Türen öffnen und Hamster ärgern. Gilbert wiederum hatte mit Maniac Mansion das Werkzeug geschaffen, auf dem Lucasfilms Adventure-Ruhm überhaupt erst wuchs.

Eigentlich war Last Crusade Falsteins Projekt. Doch der Kinostart rückte näher, und ein einzelner Designer hätte ein Adventure dieser Größe kaum rechtzeitig stemmen können. Also kamen Fox und Gilbert dazu. Aus einem Projektleiter wurde ein Dreiergespann, das nicht nur ein paar Filmszenen abarbeiten sollte, sondern ein Spiel bauen musste, das der Figur Indiana Jones gerecht wurde. Das war bei Lucasfilm Games ungewöhnlich. Die Teams waren Ende der 80er noch klein, viele Projekte hatten einen klar erkennbaren Kopf. Hier aber zog die Firma drei ihrer wichtigsten Leute zusammen, weil diese Lizenz keine beliebige war. Indiana Jones gehörte zur eigenen Familie, und Familienangelegenheiten gibt man besser nicht an den billigsten Cousin ab.

Parallel zum Grafikadventure erschien auch ein separates Actionspiel, entwickelt von Tiertex und über die damalige U.S.-Gold/Lucasfilm-Schiene veröffentlicht. Mehr Peitsche, mehr Plattformen, mehr Prügel. Das war naheliegend, aber nicht zwingend klug. Denn Indiana Jones war im Kino nie nur der Mann, der schlägt. Er las Inschriften, bluffte sich durch gefährliche Räume, verstand manchmal zu spät, was alle anderen schon wussten, und gewann am Ende trotzdem. Genau diesen Indy wollte Lucasfilm Games auf den Bildschirm bringen.

Der Film war noch nicht fertig, das Spiel war quasi der Directors Cut

Heute lässt sich ein Filmspiel bequem am fertigen Film entlang nachbauen. 1988 sah die Sache anders aus. Das Team arbeitete mit Drehbuch, Produktionsfotos und Material aus der laufenden Filmproduktion. Den fertigen Film sahen die Entwickler erst spät. Das erklärt eine der schönsten Eigenheiten von Last Crusade: Das Spiel folgt nicht nur dem Film, sondern manchmal einer früheren Spur des Films.

Ein Beispiel ist der Zeppelin. Im Film wirkt Indys Bemerkung über das reparierte Funkgerät wie ein kleiner Nebensatz, den man im Kinotempo einfach hinnimmt. Im Spiel wird daraus eine Situation, die man selbst erlebt. Das Adventure bewahrt also nicht nur Filmhandlung, sondern auch Reste einer Fassung, die im Kino teilweise verschwunden war. Ähnliches gilt für andere Details, die aus Drehbuch- und Produktionsmaterial in das Spiel wanderten und dort plötzlich mehr Raum bekamen, als ihnen der fertige Film ließ.

Dadurch wirkt Last Crusade nicht wie eine gekürzte Nacherzählung. Eher wie eine alternative Führung durch dasselbe Abenteuer. Sallah fehlt, die Bruderschaft des Kreuzschwerts fehlt, manche Filmszenen werden verkürzt oder ganz ausgelassen. Dafür wächst Schloss Brunwald zu einem größeren Spielplatz aus Wachen, Türen, Verkleidungen, falschen Sätzen und Faustschlägen, die man besser nicht kassiert. Der Film gab den Weg vor, das Spiel stellte unterwegs zusätzliche Türen auf.

Vom Spielbuch zum SCUMM-Abenteuer


Konzeptpapier zu Indiana Jones and the Last Crusade von Noah Falstein, 13. Oktober 1988

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

Der spannendste Blick auf Last Crusade liegt nicht im fertigen Spiel, sondern in einem frühen Konzeptpapier vom 13. Oktober 1988. Dort beschreibt Noah Falstein noch kein reines Point-and-Click-Adventure. Sein Entwurf ist ein Mischwesen aus Computerspiel, Actionsequenzen und nummerierten Buchabschnitten. Ein Teil der Handlung sollte in gedrucktem Material stattfinden, der Computer sollte Inventar, Punktestand, Entscheidungen und Action verwalten. Das klingt zunächst wie ein Umweg, erklärt aber fast alles, was das fertige Spiel besonders macht.

Das Gral-Tagebuch war deshalb nicht bloß eine hübsche Beilage, die der Packung Gewicht gab. Es war der sichtbare Rest einer Idee, bei der Papier und Bildschirm gemeinsam erzählen sollten. Falstein wollte die Bücher nicht nur als Dekoration nutzen, sondern als tragenden Teil des Abenteuers. Der Spieler sollte lesen, vergleichen, übersetzen, deuten. Also im Grunde genau das tun, was Henry Jones senior ohnehin für eine angemessene Freizeitbeschäftigung gehalten hätte.

Das fertige Spiel wurde klassischer als der Entwurf. Kein Paragraphenbuch, kein ständiges Hin und Her zwischen nummerierten Textstellen und Computerbildschirm. Aber der Ursprung blieb spürbar. Man liest das Tagebuch, weil man es braucht. Man merkt sich Hinweise, weil das Spiel sie nicht in gelbe Questmarker verwandelt. Man kann scheitern, weil falsche Entscheidungen Folgen haben. Und man kann später noch einmal spielen, weil derselbe Filmstoff andere Wege zulässt.

SCUMM lernt reden

Vor Last Crusade hatte SCUMM schon viel geleistet. Maniac Mansion machte aus Verben, Objekten und Figuren ein neues Adventure-Gefühl. Zak McKracken trieb die Weltreise und den Unsinn weiter. Aber Indiana Jones brauchte etwas anderes. Er musste nicht nur Dinge nehmen und Türen öffnen. Er musste mit Menschen umgehen.

Also wurden Talk und Travel wichtiger. Mit „Talk“ begann Indy Gespräche, mit „Travel“ wechselte er an passenden Stellen den Schauplatz. Dazu kamen spezielle Befehle wie „To Indy“ und „To Henry“, wenn Vater und Sohn in bestimmten Situationen getrennt oder gemeinsam handeln. Das klingt nach Bedienungsdetail, ist im Spiel aber viel mehr. Mit „Talk“ wird eine Wache nicht nur Hindernis, sondern Figur. Nicht unbedingt eine kluge Figur, aber eine, die auf Sätze reagiert. Ein falscher Spruch kann Ärger auslösen, ein richtiger öffnet Wege. Und manchmal bleibt natürlich immer noch die Möglichkeit, sich mit einem Faustschlag in Schwierigkeiten zu bringen.

Das trifft die Figur ziemlich gut. Indy ist kein makelloser Rätselheld. Er ist ein improvisierender Archäologe mit zu wenig Zeit, zu viel Selbstvertrauen und einem Vater, der ihn selbst aus der Ferne noch korrigieren würde. Last Crusade versucht deshalb gar nicht, ein lupenreines Adventure zu sein. Es versucht, Indiana Jones gerecht zu werden.

Schloss Brunwald: reden, prügeln, bereuen

Schloss Brunwald ist der Abschnitt, an dem man Last Crusade am besten erklären kann — und manchmal auch am lautesten beschimpfen möchte. Auf dem Papier ist das großartig: Indy sucht seinen Vater, überall stehen Wachen, und fast jeder Soldat ist eine kleine Entscheidung. Trägt man die richtige Uniform? Hat man den passenden Ausweis? Versucht man es mit einem Bluff? Gibt man etwas ab? Oder endet alles wieder in einem Faustkampf, bei dem man sich fragt, warum ein Archäologieprofessor offenbar nach Feierabend im Boxclub trainiert?

Gerade hier zeigt das Spiel seine Herkunft aus Falsteins Action-vs.-Story-Gedanken. Der direkte Weg führt oft über Gewalt, ist aber selten der klügste. Wer beobachtet, ausprobiert und Dialoge ernst nimmt, findet Alternativen. Das ist schön, weil Indiana Jones dadurch nicht nur eine Spielfigur mit Peitsche bleibt, sondern eine Rolle: Professor, Hochstapler, Sohn, Fluchtkünstler und gelegentlich Prügelknabe. Nicht jede Lösung ist elegant, nicht jede Verkleidung überzeugt lange, und manche Wache wirkt nur deshalb gefährlich, weil die Kampfsteuerung selbst schon ein Gegner ist. Aber das Schloss ist ein starkes Beispiel dafür, dass Last Crusade den Spieler nicht auf eine einzige Route festnagelt.

Diese Freiheit war 1989 kein kleiner Luxus. Viele Filmspiele zerlegten ihre Vorlage in Levels. Last Crusade zerlegte sie in Möglichkeiten. Eine Wache konnte ein Rätsel sein, ein Gespräch, ein Bluff, ein Kampf oder ein Fehler, den man nach dem Laden besser nicht wiederholte. Das machte das Spiel manchmal kantig, aber auch ungewöhnlich lebendig.

Der Indy Quotient misst nicht nur Fortschritt

Dann ist da noch der Indy Quotient. Ein Punktesystem, ja. Aber nicht im üblichen Sinn. Sierra-Adventures hatten Punkte schon lange vorher. Dort klang jeder Fortschritt ein bisschen nach Lehrerkalender: richtig gemacht, Häkchen, weiter. Last Crusade macht daraus etwas Passenderes. Der aktuelle Durchlauf zählt, was man in dieser Partie erreicht hat. Der Serien-IQ merkt sich dagegen dauerhaft, welche Lösungen man irgendwann schon gefunden hat. Maximal sind 800 Punkte möglich.

Das ist eine elegante Idee. Wer den Gral findet, hat das Spiel beendet. Wer den höchsten IQ will, muss herausfinden, was er unterwegs alles anders hätte tun können. Damit belohnt Last Crusade nicht nur Erfolg, sondern Neugier. Man kann einen Gegner besiegen. Man kann ihn überreden. Man kann ihn umgehen. Man kann einen Gegenstand nutzen, den man beim ersten Mal für Dekoration hielt. Und irgendwo in diesen Alternativen wächst die Punktzahl weiter. Der Indy Quotient sagt im Grunde: Schön, dass du den Film kennst. Aber kennst du auch das Spiel?

Boris Schneider und die schwarzen Quadrate

Die deutsche Fassung bekam ihre eigene kleine Archäologiegeschichte. Verantwortlich für die Übersetzung war Boris Schneider, später Boris Schneider-Johne, damals längst kein Unbekannter mehr in der deutschen Spieleszene. Seine Lucasfilm-Übersetzungen blieben nicht deshalb hängen, weil sie Wörter brav von links nach rechts übertragen hätten. Sie trafen diesen trockenen, manchmal leicht schnoddrigen Ton, den Lucasfilm-Adventures brauchten: genug Nähe zum Original, aber mit einem Gefühl dafür, wie ein deutscher Spieler einen Satz tatsächlich lesen würde, ohne dass er wie Bedienungsanleitung klingt.

Bei Last Crusade kam eine Aufgabe hinzu, die mit Sprachgefühl wenig zu tun hatte. Für die deutsche Veröffentlichung mussten NS-Symbole aus dem Spiel verschwinden. Schneider griff dafür selbst zu Deluxe Paint und übermalte die Hakenkreuze mit schwarzen Flächen. Ob das wirklich Pixel für Pixel geschah oder mit der Rechteckfunktion erledigt wurde, ist fast egal; das Bild bleibt stark genug. Da sitzt der Übersetzer vor einem Indiana-Jones-Spiel und malt Geschichte schwarz, weil Computerspiele auf dem deutschen Markt damals anders behandelt wurden als Filme. Im Kino durfte Hitler Indys Tagebuch unterschreiben, im Spiel musste der Hintergrund entschärft werden.

Auch die Texte wurden angepasst. Das Wort „Nazi“ verschwand in der deutschen Version weitgehend oder wurde umschrieben. Dadurch wurde die Handlung natürlich nicht unverständlich. Jeder wusste, wer da im Schloss patrouillierte und warum Berlin kein neutraler Ausflugsort war. Aber die deutsche Fassung bekam diesen merkwürdigen Schleier, den viele Spiele jener Jahre trugen: Die Geschichte war gemeint, durfte aber nicht immer beim Namen genannt oder im Bild gezeigt werden. Gerade bei Last Crusade fällt das auf, weil der Filmstoff ohne Nationalsozialisten kaum denkbar ist. Der dritte Indiana-Jones-Film lebt ja wesentlich davon, dass der Gral nicht von beliebigen Schurken gesucht wird, sondern von Leuten, deren Symbolik und Ideologie der Film klar benennt.

Das macht die deutsche Version nicht schlechter, aber historisch interessant. Sie zeigt, wie stark Computerspiele damals noch um Anerkennung rangen. Was im Kino als Abenteuerfilm mit historischem Feindbild lief, wurde am Heimcomputer zur heiklen Bilddatei. Dass ausgerechnet ein Adventure über Archäologie, Erinnerung und die richtige Deutung alter Zeichen seine eigenen Zeichen übermalen musste, ist eine Pointe, die man kaum besser erfinden könnte.

Sechs Disketten und ein bisschen Geduld

Wer Last Crusade 1989 auf dem PC spielte, bekam kein leichtes Nebenbei-Päckchen. Die damaligen deutschen Tests nannten Preise um 80 bis 90 Mark, dazu kamen mehrere Disketten, Handbuch, Codetabelle und Gral-Tagebuch. Eine Festplatte war nicht zwingend, aber dringend empfehlenswert. Wer von Diskette spielte, lernte schnell, dass Archäologie nicht nur aus Staub und Geduld besteht, sondern gelegentlich auch aus Laufwerksgeräuschen.

Technisch stand Last Crusade zwischen den Welten. Auf dem PC profitierte es von EGA- und später VGA-Fassungen, AdLib machte den Sound deutlich erträglicher, während der PC Speaker eher pflichtschuldig mitfiepte. Amiga und Atari ST boten die vertraute 16-Bit-Heimcomputer-Atmosphäre; die ASM stellte zudem fest, dass beide Umsetzungen auf ihren Testsystemen rund 20 Prozent schneller liefen als die getestete PC-Fassung auf einem XT mit 8 MHz und VGA. Trotzdem wirkte das Spiel groß. Nicht nur wegen der Lizenz, sondern wegen der Art, wie es Räume, Dialoge und Beilagen zusammenzog. Ein Menü am unteren Bildschirmrand, ein Inventar, ein Tagebuch auf dem Schreibtisch, eine Codetabelle daneben — das war eine andere Form von Immersion als heutige Vollvertonung und 4K-Kulissen. Man saß nicht vor einem glattpolierten Filmspiel, sondern vor einem Abenteuer, das den eigenen Schreibtisch mitbenutzte. Weitere Konvertierungen umfassten eine Macintosh, sowie eine CDTV Version. Später erschien mit der FM Towns Variante die wahrscheinlich schönste Version.

Wo der Hut wackelt

Natürlich ist Last Crusade nicht perfekt. Die Labyrinthe sind ein gutes Beispiel. Unter Venedig passt das Motiv zwar wunderbar: Katakomben, alte Hinweise, verborgene Wege, dunkle Ecken. Spielerisch bedeutet es aber auch viel Herumlaufen, Erinnern, Verirren und gelegentliches Fluchen. Das ist noch nicht die spätere LucasArts-Eleganz, bei der fast jede Hürde so wirkt, als sei sie aus einer Pointe heraus gebaut. Hier steckt noch mehr altes Adventure-Handwerk drin: Karten machen, Wege testen, falsche Abzweigungen merken.

Die Actionsequenzen sind ebenfalls zwiespältig. Sie gehören zur Figur und waren von Anfang an Teil des Konzepts, aber sie sind nicht der Grund, warum man Last Crusade heute noch empfiehlt. Faustkämpfe, Flugzeugflucht und manche Bewegungssequenzen bringen Abwechslung, reißen aber auch aus dem besten Teil des Spiels heraus: aus dem Lesen, Kombinieren, Reden und Täuschen. Trotzdem sind sie nicht einfach Fremdkörper. Sie stammen aus demselben Wunsch, Indiana Jones nicht auf ein reines Knobelspiel zu reduzieren. Indy sollte nicht nur fragen, nehmen und benutzen. Er sollte gelegentlich auch zuschlagen dürfen — selbst wenn man dabei merkte, dass SCUMM nie als Boxtrainer geplant war.

Die Presse fand den Gral

Die damalige Presse sah das erstaunlich ähnlich. International kam Last Crusade stark an: The One vergab 89 Prozent und lobte vor allem Spielbarkeit, Humor und die Nähe zum Film. The Games Machine kam auf 85 Prozent, sah die Verwandtschaft zu Zak McKracken, hob aber die erweiterten Dialoge, die verschiedenen Lösungswege und das Gral-Tagebuch als Spielhilfe hervor. Games Preview bewertete die PC-Fassung mit 84 Prozent und sah ebenfalls vor allem im Adventure-Teil die Stärke des Spiels.

Auch die deutsche Presse fand deutliche Worte. Power Play vergab 90 Prozent und lobte Umfang, Spiellogik, Benutzerführung und Story. Die ASM gab Grafik und Atmosphäre jeweils die Höchstwertung, blieb bei Sound sowie Vokabular/Parser aber deutlich nüchterner. Damit ergibt sich ein ziemlich geschlossenes Bild: Als Adventure war Last Crusade ein großer Wurf. Wenn Indy las, redete, bluffte und kombinierte, saß der Hut. Wenn er boxte, flog oder Disketten nachforderte, wackelte er.

Das ist wichtig, weil die Kritik nicht erst aus heutiger Bequemlichkeit entsteht. Wer 1989 mit mehreren Disketten, AdLib-Hoffnung und einer Portion Geduld vor dem PC saß, merkte ebenfalls, dass der Gral nicht ohne Kratzer kam. Aber die Stärken überwogen deutlich. Last Crusade war nicht das glatteste Lucasfilm-Adventure, aber eines der interessantesten.

Warum das Adventure Indy besser verstand

Die parallel erschienenen Action-Umsetzungen hatten es auf den ersten Blick einfacher. Indiana Jones rennt, prügelt, springt, fährt, fliegt und fällt. Wer daraus ein Actionspiel macht, liegt nicht automatisch falsch. Nur greift er eben meistens nach dem offensichtlichsten Teil der Figur.

Lucasfilm Games nahm den komplizierteren Weg. Hier war Indy nicht nur ein Mann mit Peitsche, sondern ein Professor, Sohn, Lügner, Leser, Reisender und gelegentlich überforderter Faustkämpfer. Genau deshalb funktioniert das Adventure als Indiana-Jones-Spiel besser als viele Actionfassungen. Es übersetzt nicht bloß die Bewegung des Films, sondern seine Struktur: Hinweis finden, Ort wechseln, Person täuschen, Artefakt deuten, falsche Sicherheit verlieren, weiter improvisieren.

Der Weg nach Atlantis

Rückblickend ist Last Crusade auch deshalb spannend, weil es vieles vorbereitet, was Indiana Jones and the Fate of Atlantis später eleganter sortierte. Dort wurden unterschiedliche Spielstile in klarere Pfade gegossen: Denken, Teamwork, Action. Last Crusade macht das noch nicht so sauber. Es wirft diese Möglichkeiten direkt in die Szenen. Eine Wache ist nicht „der Actionpfad“, sondern erst einmal ein Problem. Was daraus wird, entscheidet der Spieler: Gespräch, Bluff, Gegenstand, Uniform, Prügelei oder „Neu laden“.

Das ist weniger elegant, aber unmittelbarer. Fate of Atlantis wirkt wie die ausgereiftere Abenteuerarchitektur. Last Crusade ist näher am Werkstattboden: Man sieht noch, wo Lucasfilm Games ringt, probiert, kürzt, ergänzt und verschiedene Ideen zusammenzieht. Gerade dadurch hat es einen eigenen Reiz. Es ist kein Vorläufer, den man nur wegen seines Nachfolgers ernst nimmt. Es ist das Spiel, in dem Lucasfilm Games den Filmstoff erstmals wirklich selbst in die Hand bekam.

Und es war erfolgreich. Rund 250.000 verkaufte Exemplare machten Last Crusade zum bis dahin erfolgreichstem Spiel von Lucasfilm Games. Diese Zahl erklärt nicht allein seine Bedeutung, aber sie zeigt, dass der Ansatz funktionierte. Das Publikum wollte nicht nur Indiana Jones sehen. Es wollte ihn spielen — und zwar nicht nur mit der Feuertaste.

Maniac Mansion, Zak McKracken oder Indiana Jones and the Last Crusade?

Heute lässt sich schwer entscheiden, ob Maniac Mansion, Zak McKracken oder Indiana Jones and the Last Crusade das beste Lucasfilm-Adventure der 1980er war. Maniac Mansion war der große Befreiungsschlag vom Parser. Zak McKracken war wilder, schräger, weltumspannender. Last Crusade war filmischer, zugänglicher und zugleich mutig in seiner Mischung aus Tagebuch, Dialogen, Action und alternativen Lösungen.

Für mich hängt an diesem Spiel trotzdem etwas anderes als eine Rangliste. Da ist diese heimlich gekaufte Box, die ich ausgerechnet bei einem Spiel über den Heiligen Gral vernichtete. Da sind die Disketten, das Handbuch, die Codetabelle, die Monate ohne Komplettlösung. Da ist dieses alte Gefühl, dass ein Adventure nicht einfach konsumiert wurde, sondern erarbeitet: mit Notizen, Sackgassen, falschen Antworten und dem Verdacht, dass irgendwo noch eine bessere Lösung wartet.

Vielleicht ist genau das der Punkt. Last Crusade endet zwar mit dem Gral, aber es lebt vom Weg dorthin. Vom falschen Satz vor der Wache. Vom Blick ins Tagebuch. Vom Versuch, nicht schon wieder zu boxen. Vom Wissen, dass der Film die Richtung kennt, das Spiel aber noch eigene Abzweigungen besitzt. Und wenn am Ende der Indy Quotient nicht bei 800 steht, ist das keine Niederlage, sondern fast ein Versprechen: Der Gral ist gefunden. Aber Indiana Jones war noch nicht fertig.

 

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 weniger für eine virtuelle Rundfahrt durch Colorado als 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 erst hervorbrachten. In Them! war die Bombe nicht nur Hintergrund, sondern Ursache der Bedrohung.

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! jedoch 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 nicht nur festgelegt, was geschehen sollte, sondern auch wann und wo. Ereignisse konnten an bestimmte Spieltage, Uhrzeiten, Orte 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 daher nicht als feste Szenenfolge, sondern als Terminplan mit Abzweigungen. Der Spieler konnte nicht alles in einem Durchgang sehen und auch nicht 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, aber nicht beenden – dafür muss Bradley die Königin finden.

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 weniger wie frei wählbare Zusatzspiele. Sie sind Szenen innerhalb der laufenden Geschichte.

Scheitern kostet Zeit

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 setzt den Ablauf damit nicht zurück, sondern verändert ihn.

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. Für Amiga-Besitzer gehörten solche Pausen ohnehin zum Spielabend.

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 suchte für seine Grafiken nicht nach Programmierern mit etwas Zeichentalent, sondern nach ausgebildeten Künstlern. 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.

Das zeigt sich in Lizard Breath. Jeder Schauplatz 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 offiziell 29,95 Pfund; einige Magazine nannten 29,99 Pfund. Versandhändler boten das Spiel teilweise günstiger an. Der Einführungspreis entspricht rund 82 Pfund heutiger Kaufkraft.

In Deutschland nannten Power Play und ASM einen Preis von ungefähr 100 DM. Das entspricht rund 103 Euro in der Kaufkraft 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 britischen Amiga-Magazine reagierten überwiegend begeistert. Zzap! vergab 90 Prozent, Amiga Action 91 Prozent. The One und Commodore User kamen jeweils auf 96 Prozent. Das amerikanische Magazin INFO verlieh fünf von fünf Sternen.

Gary Whitta bezeichnete das Spiel in The One als Cinemawares bis dahin vollständigste Produktion. Amiga Action urteilte ebenfalls, dass es sich um das stärkste Spiel des Unternehmens handele.

Die deutsche Power Play blieb mit 73 Prozent deutlich zurückhaltender. Sie 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.“

Gleichzeitig sah die Redaktion unter Grafik und Musik 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 eine Master-Diskette. Zusammen mit den drei Originaldisketten des Hauptspiels und drei Leerdisketten erzeugte das Installationsprogramm einen neuen Satz Spieldisketten.

Die gelegentlich wiederholte Geschichte, Käufer hätten eine Originaldiskette an Cinemaware schicken müssen, passt nicht zu dieser Veröffentlichungspraxis. Besitzer benötigten das Hauptspiel, mussten aber nichts einsenden.

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 nicht allein in den Riesenameisen oder einer bestimmten Actionsequenz. Wer nur die Tiere und das Schießen übernahm, behielt das auffälligste Bild, verlor aber 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 keinen Film bauen, bei dem der Spieler gelegentlich eine Taste drückt. Er wollte eine Geschichte, 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.

Atari 520ST (1985) – Ataris Neustart zwischen Amiga und Macintosh

Rama, CeCILL, via Wikimedia Commons

Ataris doppelter Neustart

Auf der Winter CES im Januar 1985 präsentierte Atari keinen einheitlichen Neubeginn, sondern zwei Computerlinien mit sehr unterschiedlicher Aufgabe. Der 65XE und der 130XE führten die vorhandene 8-Bit-Architektur weiter. Sie waren kompatibel zu den bisherigen Atari-Heimcomputern, erhielten jedoch ein flacheres Gehäuse, das bereits die Formsprache der neuen Modelle aufgriff. Daneben stand die ST-Familie: Rechner mit Motorola-68000-Prozessor, grafischer Benutzeroberfläche, Maus und einer Technik, die mit den älteren Atari-Computern kaum noch etwas gemeinsam hatte.

Die XE-Reihe hielt Ataris bestehendes 8-Bit-Geschäft mit vorhandener Software, Zubehör und Händlerkontakten am Leben. Der 520ST war daher nicht der erste Computer, den die neue Atari Corporation unter Jack Tramiel verkaufte. Er war jedoch die erste vollständig neue Rechnerarchitektur, die unter seiner Leitung bei Atari entstand.

Tramiel hatte Commodore im Januar 1984 nach einem endgültigen Bruch mit dem Aufsichtsratsvorsitzenden Irving Gould verlassen. Wenige Monate später gründete er gemeinsam mit seinen Söhnen Tramel Technology Ltd. und holte mehrere frühere Commodore-Mitarbeiter in das neue Unternehmen. Zu ihnen gehörte Shiraz Shivji, der zuvor im Entwicklungsteam des Commodore 64 gearbeitet hatte und nun die technische Leitung eines neuen Computerprojekts übernahm.

Ende April oder Anfang Mai 1984 begann das kleine Team mit den ersten Planungen. Der Rechner sollte die inzwischen erschwingliche 16/32-Bit-Technik nutzen, Bitmap-Grafik darstellen und über eine grafische Benutzeroberfläche bedient werden. Gleichzeitig musste er deutlich günstiger herzustellen sein als ein Apple Macintosh oder ein gut ausgestatteter IBM-PC. Der interne Arbeitstitel brachte diese Vorgabe ohne jede Werbepoesie auf den Punkt: RBP – Rock Bottom Price.

Zu diesem Zeitpunkt gehörte Atari noch Warner Communications. Das Unternehmen hatte durch den Einbruch des amerikanischen Videospielmarktes hohe Verluste angehäuft, und Warner suchte nach einem Käufer für die Heimcomputer- und Konsolensparte. Tramiel erhielt damit etwas, das Tramel Technology selbst nicht besaß: eine bekannte Marke, Produktionsmöglichkeiten, internationale Vertriebswege und ein bestehendes Sortiment, mit dem sich die Zeit bis zur Fertigstellung des neuen Rechners überbrücken ließ.

Am 2. Juli 1984 übernahm Tramiel Ataris Consumer-Sparte und formte daraus die Atari Corporation. Das vorhandene 8-Bit-Geschäft wurde nicht beendet, sondern mit der XE-Reihe kostengünstig fortgesetzt. Parallel zog Shivjis Mannschaft in Ataris Gebäude an der Borregas Avenue in Sunnyvale ein und arbeitete das RBP-Konzept zu einem serienfähigen Computer aus.

Anfang 1985 standen damit zwei Atari-Generationen nebeneinander: Die XE-Modelle verlängerten die vorhandene 8-Bit-Linie, der 520ST sollte Atari mit Maus, grafischer Oberfläche und Motorola 68000 in eine neue Rechnerklasse führen. Vor Tramiels Ankunft hatte das alte Atari allerdings bereits einen anderen Weg vorbereitet: den Vertrag mit Amiga Corporation über Lorraine.

Zwei Wege zum 68000-Rechner

Das noch von Warner Communications kontrollierte Atari hatte bereits seit 1983 mit der Amiga Corporation über deren neues Computersystem verhandelt. Im Zentrum stand Lorraine, eine auf dem Motorola 68000 basierende Architektur mit drei eigens entwickelten Bausteinen für Grafik, Ton und Speicherzugriffe.

Amiga Corporation verfügte über ehrgeizige Technik, benötigte aber dringend weiteres Kapital. Atari stellte dem Unternehmen im März 1984 zunächst 500.000 Dollar zur Verfügung. Die Vereinbarung war erheblich umfangreicher als ein gewöhnlicher Überbrückungskredit: Geplant waren eine Beteiligung an Amiga sowie weltweite Nutzungsrechte an den drei Spezialchips. Im Videospielbereich sollten Ataris Rechte exklusiv sein; einen eigenständigen Computer mit der Technik hätte das Unternehmen nach dem vorgesehenen Zeitplan ab März 1986 verkaufen dürfen.

Als Sicherheit musste Amiga technische Unterlagen bei der Bank of America hinterlegen. Dazu gehörten Logikpläne, Funktionsbeschreibungen, Software und Anweisungen für die Chipfertigung. Kam der endgültige Lizenzvertrag nicht zustande und wurde der Kredit bis zum 30. Juni 1984 nicht zurückgezahlt, hätte Atari auf diese Unterlagen und weitreichende, vollständig abgegoltene Nutzungsrechte zugreifen können. Einen automatischen Besitzübergang der gesamten Amiga Corporation sah die Vereinbarung jedoch nicht vor.

Das damalige Atari beschäftigte sich bereits mit einem eigenen Rechner auf Grundlage der Lorraine-Technik. In später aufgefundenen Atari-Unterlagen erscheint dafür die Bezeichnung Atari 1850XLD mit dem Codenamen Mickey. Der spätere ST-Entwickler Matt Householder erinnerte sich daran, den Lorraine-Chipsatz noch vor Tramiels Ankunft anderen Atari-Ingenieuren vorgestellt zu haben.

Amiga konnte die 500.000 Dollar nicht aus eigener Kraft zurückzahlen und suchte erneut nach einem Geldgeber. Kurz vor Ablauf der Frist sprang ausgerechnet Commodore ein und ermöglichte die Rückzahlung an Atari. Im August 1984 übernahm Commodore schließlich die Amiga Corporation und finanzierte die weitere Entwicklung von Lorraine bis zum späteren Amiga 1000.

Das bereits bei Tramel Technology begonnene RBP-Projekt entstand unabhängig von Lorraine. Nach dem Einzug in die Atari-Gebäude standen Shivjis Team zusätzliche Ingenieure, Entwicklungsräume und die Infrastruktur eines etablierten Computerherstellers zur Verfügung.

Atari klagte im August 1984 gegen Amiga und später auch gegen Commodore. Der Rechtsstreit zog sich bis 1987 hin und endete mit einer vertraulichen außergerichtlichen Einigung. Während die juristische Auseinandersetzung anlief, trieb Atari die einfachere und kostengünstiger konstruierte ST-Architektur voran; Commodore finanzierte dagegen die Fertigstellung der aufwendigeren Lorraine-Technik.

Commodore brachte damit einen Rechner zur Marktreife, dessen Spezialchips von früheren Atari-Ingenieuren um Jay Miner entwickelt worden waren. Bei Atari arbeitete währenddessen der frühere Commodore-Chef mit ehemaligen Commodore-Mitarbeitern am 520ST.

Fünf Monate bis zur CES

Nach dem Einzug in die Atari-Gebäude arbeitete Shiraz Shivjis Mannschaft auf die Winter CES im Januar 1985 hin. Bis dahin musste der neue Computer Programme ausführen, Grafik darstellen und sich über Maus und Fenster bedienen lassen. Für die Entwicklung von Hardware, Gehäuse und Systemsoftware blieben nur wenige Monate.

Zunächst war noch offen, welcher Prozessor zum Einsatz kommen sollte. Shivji und sein Team beschäftigten sich mit dem NS32016 und dem NS32032 von National Semiconductor, weil der neue Rechner ursprünglich als echtes 32-Bit-System gedacht war. Lieferbarkeit und Preis überzeugten jedoch nicht. Auch ein Versuchsgerät mit dem NS32032 blieb nach Shivjis Erinnerung hinter den Erwartungen zurück. Atari entschied sich deshalb für den bereits verfügbaren Motorola 68000.

Bei der Auswahl weiterer Bauteile spielte der Preis ebenfalls eine zentrale Rolle. Shivji berichtete später, Motorola habe Komponenten angeboten, die einzelne Spezifikationen nicht vollständig erfüllten und deshalb regulär schwer verkäuflich waren. Atari legte die Schaltung so aus, dass die betreffenden Eigenschaften nicht benötigt wurden, und konnte die Bauteile günstiger beziehen.

Das Hardwareteam bestand im Kern aus wenigen früheren Commodore-Ingenieuren und wurde durch Mitarbeiter des übernommenen Atari ergänzt. Die Konstruktion verband den 68000 mit einigen eigens entwickelten Logikbausteinen und einer Reihe verfügbarer Standardkomponenten. Auf einen Spezialchipsatz von der Größenordnung des Amiga verzichtete Atari.

Parallel entstand die grafische Arbeitsumgebung. Microsoft bot Atari eine Anpassung von Windows an, konnte nach Einschätzung der Tramiels jedoch nicht rechtzeitig liefern. Atari entschied sich daher für GEM von Digital Research. Im September 1984 zog ein großer Teil der Softwaremannschaft für mehrere Monate nach Monterey. Dort musste für den IBM-PC geschriebener 8086-Assemblercode auf den 68000 übertragen und weiterer Programmcode an die ST-Hardware angepasst werden.

Matt Householder arbeitete in Monterey an Routinen zum Zeichnen von Linien und Polygonen. Außerdem programmierte er eine Breakout-Variante als GEM-Desk-Accessory. Das kleine Spiel demonstrierte, dass ein Zubehörprogramm innerhalb der grafischen Umgebung aufgerufen werden konnte, ohne dafür den Desktop vollständig zu verlassen.

Zur CES brachte Atari fünf ST-Systeme nach Las Vegas. GEM lief dort noch auf CP/M-68K, und auch Gehäuse und Systemsoftware entsprachen nicht vollständig der späteren Serienausführung. Shivji bezifferte den Entwicklungsstand auf ungefähr 85 Prozent. Die oft genannten fünf Monate reichen daher vom Beginn der konkreten Entwicklungsarbeit bis zu funktionsfähigen Vorführgeräten – nicht bis zum endgültigen Verkaufsmodell.

Atari nannte zunächst einen 130ST mit 131.072 Byte und einen 520ST mit 524.288 Byte Arbeitsspeicher. Der 130ST verschwand noch vor dem Verkaufsstart. Da das Betriebssystem zunächst in den Arbeitsspeicher geladen werden musste, hätte die kleinere Ausführung nur wenig Platz für Anwendungen gelassen; zugleich sanken die Speicherpreise. Eine reguläre Serienfertigung des ebenfalls geplanten 260ST mit 256 KiB lässt sich bislang nicht belegen. Die dokumentierten europäischen 260ST-Geräte besitzen gewöhnlich bereits 512 KiB und unterscheiden sich vor allem durch Typenschild und frühe TOS-Ausführung vom 520ST.

Im Februar 1985 entschied sich Atari, CP/M-68K durch das noch junge GEMDOS zu ersetzen. Es bot eine höhere Leistung und ein hierarchisches Dateisystem, war aber noch nicht vollständig erprobt. Während die Software weiterbearbeitet wurde, fertigte Atari im Frühjahr ungefähr hundert ST-Systeme für externe Entwickler. Im Juni liefen in Taiwan die ersten Seriengeräte des 520ST vom Band.

Der 520ST auf dem Schreibtisch

Beim ursprünglichen 520ST steckten Rechner und Tastatur in einem flachen Gehäuse. Netzteil und Diskettenlaufwerk standen separat daneben, wobei auch das Laufwerk eine eigene Stromversorgung benötigte. Ein vollständiger Arbeitsplatz bestand damit aus mehreren Geräten und entsprechend vielen Kabeln. Dafür blieben Maus- und Joystickanschlüsse gut erreichbar an der rechten Gehäuseseite; bei den späteren STF- und STFM-Modellen wanderten sie unter das Gehäuse.

Motorola MC68000

Motorola MC68000

Im Inneren arbeitete ein Motorola 68000 mit 8 MHz. Seine allgemeinen Register waren 32 Bit breit, der externe Datenbus dagegen 16 Bit – daher die Bezeichnung ST für „Sixteen/Thirty-two“. Über den 24 Bit breiten Adressbus konnte der Prozessor theoretisch 16 MiB ansprechen. Ausgeliefert wurde der 520ST mit 512 KiB RAM. Bei den frühen Geräten belegte das von Diskette geladene TOS einen beträchtlichen Teil davon; mit dem späteren ROM-TOS stand entsprechend mehr Speicher für Programme bereit.

Atari ergänzte den 68000 um mehrere eigene Logikbausteine. Die MMU organisierte die Zugriffe auf den gemeinsamen Arbeitsspeicher und versorgte den Shifter mit den Bilddaten. GLUE erzeugte unter anderem Auswahl-, Takt-, Synchronisations- und Interruptsignale. Der DMA-Baustein übertrug Daten zwischen Speicher und Massenspeichern. Hardware-Sprites oder einen Blitter besaß der ursprüngliche 520ST nicht. Scrolling und das Verschieben größerer Bildbereiche mussten daher weitgehend durch den Prozessor erledigt werden.

Für die Bildausgabe standen drei feste Modi zur Verfügung. ST Low zeigte 320 × 200 Bildpunkte mit 16 gleichzeitig sichtbaren Farben aus einer Palette von 512. Die Darstellung lief bei europäischen Geräten gewöhnlich mit 50 Hz, konnte aber auch mit 60 Hz erzeugt werden. Die meisten Spiele verwendeten diesen Modus, da er als einziger 16 Farben gleichzeitig bot. Alle drei Bildschirmmodi belegten rund 32.000 Byte Bildspeicher; der Vorteil von ST Low lag daher nicht im Speicherbedarf, sondern in der höheren Farbtiefe.

ST Medium stellte 640 × 200 Bildpunkte mit vier Farben aus derselben Palette dar und arbeitete ebenfalls mit 50 oder 60 Hz. Der Modus erlaubte auf einem Farbmonitor eine Darstellung mit 80 Zeichen pro Zeile, blieb vertikal jedoch auf 200 Bildzeilen beschränkt. Er wurde vom Desktop und von einzelnen Anwendungen genutzt, erreichte für längere Text- und Konstruktionsarbeiten aber nicht die Bildschärfe des Monochrommodus.

Mit dem monochromen SM124 wechselte der Rechner automatisch auf 640 × 400 Bildpunkte bei ungefähr 71,2 Hz. Das Bild wurde ohne Zeilensprung aufgebaut und wirkte entsprechend ruhig. Viele Textverarbeitungen, Programmiersysteme, Tabellenkalkulationen, CAD- und später DTP-Programme bevorzugten diesen Modus oder setzten ihn voraus. Ein gewöhnlicher ST-Farbmonitor konnte die dafür benötigte Zeilen- und Bildfrequenz nicht darstellen, sodass Farb- und Monochrombetrieb unterschiedliche Monitore erforderten.

Motherboard des Atari 520 ST

Für den Ton sorgte ein Yamaha YM2149F, der eine Lizenzfertigung des AY-3-8910 darstellte. Er bot drei getrennt programmierbare Tonkanäle sowie einen gemeinsamen Rausch- und Hüllkurvengenerator. Die Ausgabe war monophon. Eigene digitale Audiokanäle besaß der 520ST nicht; Samples ließen sich dennoch wiedergeben, indem Programme die Lautstärkeregister des Yamaha-Chips in schneller Folge veränderten. Diese Methode beanspruchte den Prozessor und blieb technisch deutlich einfacher als die Sample-Hardware des Amiga.

Ab Werk waren MIDI In und MIDI Out vorhanden. Die Schnittstelle arbeitete mit den standardisierten 31,25 Kilobaud und erlaubte den direkten Anschluss von Synthesizern, Drumcomputern und anderen MIDI-Geräten. Shiraz Shivji erinnerte sich später, dass die dafür zusätzlich benötigte Hardware nur etwa 75 US-Cent gekostet habe. Für Musiker entfiel damit der Kauf eines separaten Interfaces.

Das erste Diskettenlaufwerk befand sich ebenfalls außerhalb des Rechners. Das einseitige SF354 speicherte formatiert ungefähr 360 KiB, das doppelseitige SF314 etwa 720 KiB. Die in der Werbung genannten 400 beziehungsweise 800 KB bezeichneten die unformatierte Kapazität. Weitere Laufwerke konnten angeschlossen werden; für Festplatten und andere schnelle Geräte besaß der ST bereits die als DMA-Port bezeichnete ACSI-Schnittstelle.

Zur weiteren Ausstattung gehörten eine serielle RS-232-Schnittstelle, ein paralleler Druckeranschluss, der Monitorport, der Anschluss für externe Diskettenlaufwerke und ein Cartridge-Schacht für ROM-Module. Der ursprüngliche 520ST besaß keinen HF-Modulator und konnte daher nicht ohne zusätzliche Hardware an den Antenneneingang eines Fernsehers angeschlossen werden. Erst der 520STM ergänzte einen solchen Ausgang.

Extern ließ sich das System ohne Eingriff in den Rechner um Laufwerke, Festplatte, Drucker, Modem oder MIDI-Geräte erweitern. Für interne Aufrüstungen fehlten jedoch Steckplätze. Bereits 1986 wurden Speichererweiterungen auf 1 MiB angeboten, deren Einbau je nach Ausführung Adapterplatinen, zusätzliche Leitungen zur MMU und Lötarbeiten erforderte. Spätere Lösungen erhöhten den Speicher auf bis zu 4 MiB, die reguläre Obergrenze der ursprünglichen ST-Speicherverwaltung.

Beschleuniger erschienen erst Jahre nach dem Verkaufsstart. Angeboten wurden später Karten mit einem 68000 bei 16 MHz sowie Lösungen mit 68020- und 68030-Prozessoren. Der Einbau erforderte je nach Modell Eingriffe am Prozessorsockel oder an der Hauptplatine; als einfacher Steckkartenrechner war der 520ST nicht konstruiert.

TOS kam zunächst von Diskette

TOS 1.0

Aus GEMDOS, den grafischen Bestandteilen von GEM und Ataris hardwarenahen Routinen entstand TOS. Atari löste die Abkürzung offiziell als „The Operating System“ auf; im Entwicklerumfeld war auch „Tramiel Operating System“ gebräuchlich. Auf dem Bildschirm erschien der GEM Desktop mit Laufwerkssymbolen, Fenstern, Pulldown-Menüs und Mauszeiger. Programme ließen sich per Doppelklick starten, Dateien konnten markiert, kopiert, umbenannt oder in den Papierkorb gezogen werden. Für Besitzer eines 8-Bit-Heimcomputers ersetzte diese Oberfläche viele zuvor von Hand eingegebene Lade- und Dateibefehle.

Unterhalb des Desktops verwaltete GEMDOS Dateien, Verzeichnisse, Speicher und den Start von Programmen. AES stellte Fenster, Menüs und Dialogfelder bereit, VDI übernahm die grafische Ausgabe. BIOS und XBIOS bildeten die Verbindung zu Laufwerken, Bildschirm, Tastatur und den übrigen Geräten.

Ein Teil der frühen 520ST enthielt noch nicht das vollständige Betriebssystem im ROM. Stattdessen saßen auf der Hauptplatine zwei Boot-ROMs mit zusammen 16 KiB, die TOS von einer Diskette in den Arbeitsspeicher luden. Der Start dauerte dadurch länger, und ein erheblicher Teil der vorhandenen 512 KiB war bereits belegt, bevor eine Anwendung lief. Ohne Systemdiskette konnte der vollständige Desktop nicht geladen werden.

Die spätere Ausführung enthielt TOS in sechs ROM-Bausteinen mit zusammen 192 KiB. Der Rechner startete nun direkt bis zum Desktop, während der zuvor von TOS belegte RAM für Programme verfügbar blieb. Disketten- und ROM-TOS gehörten beide zur frühen Produktionszeit des 520ST und lassen sich deshalb nicht einfach anhand der Modellbezeichnung unterscheiden.

Der feste Einbau erschwerte allerdings Aktualisierungen. Eine neue TOS-Version wurde nicht wie ein gewöhnliches Programm installiert; dazu mussten die ROM-Bausteine im geöffneten Rechner ausgetauscht werden. Im Gegenzug war das Betriebssystem sofort verfügbar und benötigte keine eigene Startdiskette mehr.

TOS führte normalerweise nur eine Hauptanwendung aus und bot kein präemptives Multitasking wie das Betriebssystem des Amiga. Kleine Desk Accessories – beispielsweise Uhr, Taschenrechner oder Kontrollfeld – blieben im Speicher und konnten über das Desk-Menü aufgerufen werden. Während ein solches Zubehörprogramm aktiv war, pausierte jedoch die eigentliche Anwendung.

Power without the Price

Im Juni 1985 liefen in Taiwan die ersten serienmäßigen 520ST vom Band. Bis der Rechner regulär bei den Käufern ankam, verging jedoch noch einige Zeit. Die Oktober-Ausgabe von COMPUTE! beschrieb ihn in den USA gerade erst als zunehmend breit verfügbar. In Westdeutschland wurde der 520ST seit Mitte September im Computerfachhandel und in einigen ausgewählten Kaufhäusern verkauft.

In den USA bot Atari den Rechner als vollständiges System an. Der 520ST kostete mit externem Diskettenlaufwerk, Maus, Systemsoftware und hochauflösendem Monochrommonitor 799 Dollar. Das entsprechende Paket mit RGB-Farbmonitor wurde für 999 Dollar angeboten. Damit trat Atari nicht nur gegen andere Heimcomputer an, sondern ausdrücklich gegen erheblich teurere Systeme von Apple und IBM.

Eine amerikanische Anzeige brachte diesen Vergleich besonders aggressiv auf den Punkt. Unter der Überschrift „There’s only one word for these prices: Rip-off“ stellte Atari seinem für 799,95 Dollar angebotenen Monochromsystem einen Macintosh 512 für 2.795 Dollar, einen IBM PC/AT für 4.675 Dollar und den Commodore Amiga für 1.795 Dollar gegenüber. Die Zusammenstellung war Werbung und kein neutraler Vergleich gleich ausgestatteter Rechner. Sie zeigt jedoch, in welcher Gesellschaft Atari den 520ST sehen wollte.

Auch in Großbritannien warb Atari Ende 1985 mit einem Paket aus Rechner, SF354-Diskettenlaufwerk und Monochrommonitor. Der Preis betrug 652 Pfund zuzüglich Mehrwertsteuer. Unter dem Slogan „The 520ST. Over-qualified and under-paid“ verwies die Anzeige neben GEM und MIDI auf Programmiersprachen, Textverarbeitung und ein Zeichenprogramm. Ob sämtliche angekündigten Programme zum Zeitpunkt der Anzeige bereits ausgeliefert wurden, geht daraus nicht hervor.

In Westdeutschland testete Happy Computer im Juni noch einen Prototyp. Für den 520ST mit Maus und Diskettenlaufwerk nannte die Redaktion einen angekündigten Preis von weniger als 2.800 DM; ein Monitor gehörte zu dieser Aufstellung nicht. Der Artikel bezeichnete den Rechner als „Bombenknüller“ und wegen seines Preis-Leistungs-Verhältnisses als „Volks-VAX“, enthielt jedoch noch mehrere Erwartungen, die beim Seriengerät nicht eintrafen.

Beim Verkaufsstart nannte Computer Kontakt einen Preis von 2.998 DM, erläuterte den dazugehörigen Paketumfang aber nicht vollständig. Ein direkter Vergleich mit dem amerikanischen Komplettsystem oder der britischen Anzeige ist deshalb nur eingeschränkt möglich. Für Besitzer eines C64, Atari 800XL oder Schneider CPC blieb der Wechsel trotz Ataris Niedrigpreisstrategie eine erhebliche Anschaffung.

Die ersten deutschen Käufer erhielten zunächst die sogenannte „Soft-Version“, bei der TOS von Diskette geladen wurde. Dem Lieferumfang lag nach dem Bericht von Computer Kontakt zunächst nur Dr. Logo bei. Von Personal BASIC existierten Vorabversionen, ein Termin für die Nachlieferung stand noch nicht fest. Händler kündigten außerdem GEM Paint und GEM Write an, doch auch diese Programme waren noch nicht verfügbar. In den USA berichtete COMPUTE! ebenfalls, dass der 520ST vorerst nur mit Logo ausgeliefert wurde.

Auch die ersten Testgeräte waren nicht immer frei von Problemen. Das von Creative Computing geprüfte Exemplar mit der Seriennummer 1080 startete TOS zunächst nicht; nach dem Öffnen des Rechners mussten Bausteine auf der Hauptplatine neu eingesetzt werden. Atari erklärte, dies betreffe nur die frühesten Produktionsgeräte. Die Redaktion kritisierte außerdem die noch umständliche Dateiverwaltung des GEM-Desktops und den Mangel an verfügbarer Software.

Creative Computing sah im 520ST einen großen Teil der grafischen Macintosh-Bedienung zu einem erheblich niedrigeren Preis. Happy Computer ordnete ihn wegen hoher Auflösung, Speicher und Schnittstellen sowohl für Heimanwender als auch für selbstständige und freiberufliche Nutzer ein.

Der 520ST trifft auf den Amiga 1000

Taken from the site: https://tech-vintage.fr/amiga-500-licone-creative-qui-a-defie-lindustrie/

Als Commodore den Amiga im Juli 1985 öffentlich vorstellte, hatte Atari bereits mit der Serienfertigung des 520ST begonnen. Beide Rechner verwendeten den Motorola 68000, eine Maus, eine grafische Benutzeroberfläche und 3½-Zoll-Disketten. Technisch gingen sie jedoch unterschiedliche Wege.

Der 520ST lief mit 8 MHz, der Amiga abhängig von der Fernsehnorm mit rund 7,1 MHz. Der höhere Takt konnte dem Atari bei Aufgaben helfen, die überwiegend der 68000 erledigte. Der Amiga verlagerte dagegen Grafik-, Speicher- und Audioarbeit auf seine Spezialbausteine.

In der für Spiele gebräuchlichen Auflösung blieb der ST auf 16 Farben aus einer Palette von 512 beschränkt, der Amiga zeigte 32 aus 4096. Hardware-Sprites, Blitter und Copper entlasteten den 68000 zusätzlich bei Animationen, Scrolling und grafischen Effekten.

Ataris SM124 bot dafür 640 × 400 Bildpunkte bei ungefähr 71,2 Hz ohne Zeilensprung. Schrift, Tabellen und Konstruktionszeichnungen erschienen ruhig und scharf. Der Amiga benötigte für 400 beziehungsweise 512 Bildzeilen auf normalen Monitoren Interlace, was bei feinen Schriften und kontrastreichen Flächen sichtbar flimmern konnte. Für Textverarbeitung, Programmierung, CAD und Desktop-Publishing war der monochrome ST-Modus daher besonders geeignet.

Beim Ton traf der dreistimmige Yamaha YM2149F des ST auf vier unabhängige 8-Bit-Samplekanäle des Amiga in Stereo. Sprache, Geräusche und Musik ließen sich dort ohne die beim ST nötigen Lautstärketricks wiedergeben. Atari hatte dafür MIDI In und Out serienmäßig eingebaut und benötigte zur Steuerung externer Instrumente kein zusätzliches Interface.

TOS führte gewöhnlich eine Hauptanwendung aus, während das Betriebssystem des Amiga präemptives Multitasking bot. Beim Einschalten waren zunächst beide frühen Systeme auf Disketten angewiesen: Der Amiga 1000 lud Kickstart und anschließend die Workbench, frühe 520ST luden TOS. Spätere 520ST starteten das Betriebssystem aus dem ROM.

In den USA kostete der 520ST mit 512 KiB RAM, Laufwerk, Maus, Systemsoftware und Monochrommonitor 799 Dollar. Commodore verlangte 1.295 Dollar für den Amiga 1000 mit 256 KiB und eingebautem Laufwerk; Monitor und Speichererweiterung wurden zusätzlich verkauft. Der Preisvergleich war wegen des Farbmonitors und der unterschiedlichen Ausstattung nicht vollständig gleichartig, der Abstand blieb jedoch erheblich.

1985 vermarkteten beide Hersteller ihre Rechner noch als vielseitige Personal Computer. Atari verband den niedrigeren Systempreis mit 512 KiB RAM, scharfem Monochrombetrieb und MIDI; Commodore bot die aufwendigere Grafik- und Audiotechnik sowie präemptives Multitasking. Ein breites Softwareangebot fehlte beiden zunächst, und die später vertraute Rollenverteilung hatte sich beim Marktstart noch nicht verfestigt.

Eine kurze Modellkarriere

Nur wenige Wochen nach dem westdeutschen Verkaufsstart des 520ST stellte Atari auf der Münchner Systems am 28. Oktober 1985 bereits zwei weitere Varianten vor. Der 520ST+ besaß ein Megabyte Arbeitsspeicher und wurde als Komplettsystem mit Monochrommonitor, Maus und SF354-Laufwerk weiterhin für 2.998 DM angeboten. Atari verdoppelte damit den Speicher, ohne den bisherigen Systempreis zu erhöhen.

Daneben erschien der 260ST als günstigeres Einstiegsmodell. Seine Bezeichnung erinnerte noch an die ursprünglich geplante Ausführung mit 256 KiB, doch der tatsächlich in Westdeutschland angebotene Rechner enthielt ebenfalls 512 KiB RAM. Technisch unterschied er sich nur geringfügig vom 520ST, wurde jedoch einzeln und ohne Monitor, Maus oder Laufwerk verkauft. Ab Dezember 1985 kostete er rund 1.300 DM.

Im Januar 1986 stellte Atari den 520STM vor. Das „M“ stand für den eingebauten HF-Modulator, über den sich ein Fernseher am Antenneneingang anschließen ließ. Netzteil und Diskettenlaufwerk blieben weiterhin externe Geräte. In den USA und Großbritannien kam der 520STM im Frühjahr 1986 auf den Markt, in Westdeutschland erst im Oktober.

Einen deutlicheren Umbau brachten die ebenfalls 1986 eingeführten Modelle 520STF und 1040STF. Das längere Gehäuse nahm nun sowohl das Netzteil als auch das Diskettenlaufwerk auf. Der 520STF wurde mit 512 KiB und zunächst einem einseitigen Laufwerk angeboten. Der 1040STF besaß ein Megabyte RAM sowie ein doppelseitiges Laufwerk. Maus, Monitor, Drucker, Festplatte und weitere Geräte blieben außen angeschlossen, auf dem Schreibtisch entfielen jedoch zwei separate Gehäuse und zusätzliche Netzteile.

Die grundlegende Technik änderte Atari dabei nicht. Motorola 68000, Grafikmodi, Yamaha-Sound, MIDI-Schnittstellen und TOS blieben mit dem ursprünglichen 520ST verwandt. Je nach Modell kamen mehr Speicher, ein HF-Modulator sowie ein eingebautes Laufwerk und internes Netzteil hinzu.

Die Produktion des ursprünglichen 520ST endete im April 1986. Bereits im Herbst 1985 hatte Atari den Speicher zum gleichen Systempreis verdoppelt; im folgenden Frühjahr integrierten 520STF und 1040STF Netzteil und Laufwerk. Der 520ST brachte die Plattform in den Handel, seine aus mehreren Einzelgeräten bestehende Konfiguration wurde aber rasch ersetzt.

 

Hawkeye (1988) – Vier Waffen, zwölf Levels und eine Gold Medal zu viel

Bei Hawkeye begann der Spaß nicht erst mit dem ersten Schuss. In der Kassettenfassung durfte der Spieler mit dem Mix-E-Load Bestandteile der Musik verändern, während die Datasette weiterarbeitete. Dazu kamen Robin Levys Ladebild, eine animierte Einführung und Musik aus dem Umfeld der Maniacs of Noise. Die Ladezeit wurde nicht kürzer, aber Thalamus machte wenigstens etwas daraus.

Der britische Publisher hatte mit Sanxion, Delta und Hunter’s Moon bereits mehrere technisch auffällige C64-Spiele veröffentlicht. Hawkeye fügte sich mit großen Figuren, farbigen Landschaften, einem breiten Kontrollpult und räumlich wirkenden Hintergründen in diese Reihe ein. Entwickelt wurde es jedoch nicht in Großbritannien, sondern von der niederländischen Gruppe Boys Without Brains.

Auf dem Planeten Xamox haben die nomadischen Skryksis große Teile der Bevölkerung vernichtet und die Atmosphäre radioaktiv verseucht. Die Überlebenden erschaffen Hawkeye, eine halb organische, halb mechanische Kampfgestalt. Da deren Steuerungsprozessoren angeblich nicht schnell genug arbeiten, wird sie mit einem menschlichen Bewusstsein verbunden. So erklärte die Anleitung zugleich, weshalb die Wunderwaffe aus der Zukunft noch immer einen Joystick benötigte.

Hawkeye umfasst zwölf horizontal scrollende Abschnitte und ein verstecktes Bonuslevel. In jedem Level müssen vier Puzzleteile eingesammelt werden, bevor der Ausgang erreicht werden kann. Die beiden Falkenköpfe im Kontrollpult weisen den Weg: Je nachdem, welches Auge blinkt, liegt das nächste Teil links oder rechts von Hawkeyes aktueller Position.

Zur Bewaffnung gehören Pistole, Maschinengewehr, Laser und Raketenwerfer. Nur die Pistole verfügt über unbegrenzte Munition; die stärkeren Waffen müssen gezielt eingesetzt und durch passende Symbole wieder aufgeladen werden. Viele kleinere Gegner lassen sich überspringen. Wer ständig mit dem Raketenwerfer auf alles feuert, was sich bewegt, steht bald wieder mit der Pistole vor einem deutlich größeren Problem.

Die C64-Version reagiert direkt, die Sprünge lassen sich gut dosieren, und das Scrolling bleibt auch bei mehreren Figuren stabil. Die Power Play schrieb: „Die Steuerung ist sehr exakt, das Tempo gerade richtig.“ Gegner erscheinen beim Zurücklaufen allerdings erneut, weshalb die Suche nach den vier Teilen gelegentlich dieselben Kämpfe mehrfach auslöst. Nach einem Game-over lässt sich der zuletzt erreichte Abschnitt im Übungsmodus trainieren.

Neue Landschaften, Gegner, Farben und Musikstücke sorgen für sichtbare Abwechslung. Spielerisch bleibt es jedoch bei derselben Aufgabe: Teile suchen, Hindernisse überwinden und den Ausgang erreichen. Hawkeye verändert sein Grundprinzip über die zwölf Level kaum. Seine Qualität liegt deshalb weniger in neuen Ideen als in der Sorgfalt, mit der die vorhandenen Elemente abgestimmt wurden.

Die Geschichte von Boys Without Brains begann in der niederländischen C64- und Demoszene. Grafiker Jacco van ’t Riet, bekannt als JAWS, zeichnete zunächst mit Koala Paint und lernte über einen lokalen Cracker Mario van Zeist und Laurens van der Donk kennen. Aus diesem Freundeskreis entstand die Gruppe, die schließlich den Schritt von Demos zu kommerziellen Spielen wagte.

Mario van Zeist programmierte für Hawkeye nicht nur das Spiel, sondern auch spezielle Werkzeuge für die Grafiker. Van ’t Riet und Arthur van Jole bauten damit Landschaften, Figuren und Hintergründe auf. Van ’t Riet bezeichnete die Technik später als „real parallax 2 layer scrolling“ und erinnerte sich, dass dafür ein eigener Editor notwendig gewesen sei. Seine Behauptung, Hawkeye habe diesen Effekt als erstes Spiel verwendet, bleibt eine persönliche Entwicklererinnerung und keine nachgewiesene Weltpremiere.

Der räumliche Eindruck entstand durch mehrere vorbereitete Zeichensätze, deren Hintergrundelemente leicht gegeneinander versetzt waren. Beim Umschalten schien sich die hintere Landschaft langsamer zu bewegen als Hawkeye und die Plattformen. Der C64 berechnete also keine zwei frei beweglichen Ebenen, sondern erzeugte eine sorgfältig vorbereitete Illusion. Im laufenden Spiel erfüllte sie denselben Zweck.

Die große Multicolor-Figur ist flüssig animiert und hebt sich deutlich von der Umgebung ab. Auch manche Gegner beanspruchen ungewöhnlich viel Bildschirmfläche. Dafür verkleinert das breite Kontrollpult das eigentliche Spielfeld. Falkenköpfe, Waffenanzeige, Munition, Energie und Punktestand nehmen mehrere Zeilen ein, geben Hawkeye aber sein sofort erkennbares Erscheinungsbild.

Die Originalcredits nennen Mario van Zeist für Programmierung und Konzept, Jacco van ’t Riet und Arthur van Jole für die Grafik sowie Robin Levy für das Ladebild. Jeroen Tel wird für Musik und Soundeffekte aufgeführt, Charles Deenen zusätzlich für Musik, Mix-E-Load und Effekte. Eine genaue Trennung einzelner Stücke ist anhand dieser Credits nicht möglich. Tel wurde zu einem der bekannten C64-Komponisten, während Deenen später als Audio Director bei Interplay und Electronic Arts arbeitete.

Paul Cooper produzierte Hawkeye für Thalamus, John Harries unterstützte die Produktion. Die Verpackung entstand unter Beteiligung von Oliver Frey und David Western. Freys muskulöser Science-Fiction-Kämpfer passte zum Stil des Newsfield-Verlags, dessen Magazine Crash und Zzap!64 ebenfalls stark von seinen Illustrationen geprägt wurden.

Für eine britische Werbeaktion versteckte Thalamus neun farbige Kassetten in regulären Packungen. Drei goldene Exemplare brachten jeweils einen Amstrad Studio 100, sechs gelbe einen Kassettenrekorder. Von außen waren die Sonderkassetten nicht zu erkennen. Die Aktion beweist keine hohen Verkaufszahlen, machte die erhaltenen Exemplare später aber zu gesuchten Sammlerstücken.

Wie viele Einheiten Hawkeye tatsächlich verkaufte, ist nicht bekannt. Thalamus veröffentlichte keine überprüfbare Stückzahl. Jacco van ’t Riet erklärte lediglich, das Spiel habe ihm etwas Geld eingebracht und seinen weiteren Lebensweg beeinflusst. Wiederveröffentlichungen bei Kixx und The Hit Squad belegen eine längere Vermarktung, aber keine sechsstelligen Verkäufe oder eine Finanzierung von Flimbo’s Quest durch Hawkeye-Tantiemen.

Die zeitgenössischen Urteile lagen auffällig weit auseinander. Die Power Play vergab für die C64-Version 82 Prozent und lobte Technik, Steuerung und Tempo, vermisste aber auf Dauer mehr Abwechslung. Computer & Video Games sah dagegen nur einen wenig originellen Plattform-Shooter und kam auf drei von zehn Punkten. Dazwischen liegt ein brauchbares Bild des Spiels: technisch sorgfältig, gut steuerbar, aber spielerisch schmal.

Für die anhaltende Diskussion sorgte Zzap!64 mit 96 Prozent und einer Gold Medal. Das Magazin lobte neben der Präsentation auch Steuerung, Waffenwahl und Trainingsmodus. Brisant war die Wertung, weil sowohl Thalamus als auch Zzap!64 zum Umfeld des Newsfield-Verlags gehörten. Eine direkte Einflussnahme ist nicht belegt, ein Interessenkonflikt lag dennoch vor. Als Kixx Hawkeye 1991 erneut veröffentlichte, reduzierte dasselbe Magazin die Wertung auf 82 Prozent. Der Nachtester schrieb: „Personally I’ve never thought it worth a Gold Medal.“ – „Ich persönlich hielt es nie für eine Gold Medallie.“

Die 1989 erschienenen Fassungen für Amiga und Atari ST entstanden bei Esprit Software Programs. Sie übernahmen Kontrollpult, Levelaufbau und Gestaltung weitgehend vom C64, wirkten auf den leistungsfähigeren Rechnern aber nicht mehr außergewöhnlich. The Games Machine vergab 81 Prozent für den Amiga und 78 Prozent für den Atari ST, räumte später jedoch ein, die Amiga-Version möglicherweise zu hoch bewertet zu haben.

Deutlich kritischer urteilten Zzap! mit 61 Prozent und die Power Play mit 66 Prozent. Letztere stellte fest: „Die Steuerung ist nicht ganz so exakt wie beim Vorbild.“ Außerdem erschienen an einigen Stellen zu viele Gegner gleichzeitig. Die 16-Bit-Versionen waren spielbar, verloren aber einen Teil der präzisen Abstimmung und der technischen Wirkung des Originals. Eine höhere Auflösung machte aus Hawkeye noch kein besseres Spiel.

Die britische C64-Kassette kostete 1988 9,99 Pfund, die Diskettenfassung 12,99 Pfund. Inflationsbereinigt entspricht das heute ungefähr 35 beziehungsweise 45 Pfund oder rund 40 beziehungsweise 52 Euro. Die Amiga-Version wurde 1989 für 19,99 Pfund angeboten, heute etwa 65 Pfund oder 75 Euro. Die Kixx-Neuauflage kostete 1991 nur noch 3,99 Pfund, entsprechend ungefähr 11 Pfund oder 13 Euro.

Ein Hawkeye 2 befand sich 1989 in Entwicklung. Mario van Zeist programmierte, Thomas Heinrich und Michael Detert arbeiteten an der Grafik, Thomas Detert und Markus Schneider an der Musik. Aufzüge, kleinere Abzweigungen und eine weniger geradlinige Levelstruktur sollten das Spiel erweitern. Das Projekt blieb bei einer frühen Vorschau; Teile der Grafiken wurden später in anderen Produktionen von X-Ample Architectures verwendet.

2010 begann Onslaught auf Grundlage des erhaltenen Materials eine vollständige Neuprogrammierung mit farbigem Parallax-Scrolling, zusätzlichen Sprites und acht Schussrichtungen. Auch diese Fassung wurde nicht fertiggestellt. Das gelegentlich als Hawkeye 2 bezeichnete Bamboo war dagegen ein eigenständiges Projekt.

Hawkeye blieb damit vor allem ein C64-Spiel, dessen Technik, Steuerung, Musik und Präsentation ungewöhnlich gut ineinandergriffen. Die zwölf Level wiederholen ihre Aufgabe häufiger, als die Gold Medal vermuten ließ. Die spätere Neubewertung mit 82 Prozent beschrieb das Spiel erheblich genauer: ein sorgfältig gebauter Actiontitel, dessen Ausführung stärker war als seine eigentliche Idee.

Hawkeye – kurz & kompakt

🎮 Titel: Hawkeye
📅 Erstveröffentlichung: 1988
🏢 Entwickler: Boys Without Brains
🏷️ Publisher: Thalamus Ltd.
💻 Systeme: Commodore 64, Amiga, Atari ST
🕹️ Genre: Action, Run-and-Gun, Plattformspiel
👤 Spieler: 1
👨‍💻 C64-Programmierung: Mario van Zeist
🎨 C64-Grafik: Jacco van ’t Riet, Arthur van Jole
🎵 Musik und Sound: Jeroen Tel, Charles Deenen
🖼️ Ladebild: Robin Levy
📦 16-Bit-Umsetzungen: Esprit Software Programs
🧩 Umfang: zwölf reguläre Level und ein verborgenes Bonuslevel
🔫 Bewaffnung: Pistole, Maschinengewehr, Laser und Raketenwerfer
👁️ Besonderheit: Blinkende Falkenaugen weisen den Weg zu den vier Puzzleteilen eines Levels
🏅 Bekannte Wertungen: Zzap!64 96 %, Power Play 82 %, C&VG 3/10
💷 Ursprungspreis: 9,99 Pfund auf Kassette, 12,99 Pfund auf Diskette

 

ACE 2 (1987) – Zwei Cockpits, ein Luftduell

Wer ACE 2 auf dem Commodore 64 startete, bekam nicht erst ein Einsatzbriefing, eine Karte voller Ziele und eine halbe Tastatur mit Flugfunktionen vorgesetzt. Zwei Cockpits lagen übereinander auf dem Bildschirm, und wenige Augenblicke später versuchten zwei Kampfjets, sich gegenseitig mit Kanonenfeuer und Lenkwaffen vom Himmel zu holen. Das funktionierte allein gegen den Computer. Gedacht war das Spiel jedoch vor allem für zwei Menschen, die am selben Rechner saßen und den Gegner nicht nur im eigenen Visier, sondern nebenbei auch auf dessen Bildschirmhälfte beobachten konnten.

Cascade Games veröffentlichte ACE 2 – Air Combat Emulator 2 1987 zunächst für den Commodore 64 und den Plus/4; Umsetzungen erschienen außerdem für ZX Spectrum, Amstrad CPC und DOS. Der Name des Publishers weckte nicht bei jedem Käufer Vertrauen. Cascade war noch immer mit Cassette 50 verbunden, jener Sammlung sehr einfacher Programme, deren Ruf dem Unternehmen lange anhaftete. Schon der erste Teil von ACE hatte allerdings gezeigt, dass Cascade auch aufwendigere Eigenproduktionen finanzieren und vertreiben konnte. Der Vorgänger verband Luftkampf mit Starts, Landungen, verschiedenen Einsatzarten, Bodenzielen, Luftbetankung und einer ungewöhnlichen kooperativen Rollenverteilung, bei der ein Spieler das Flugzeug steuerte und ein zweiter die Waffensysteme bediente.

Das Spieldesign von ACE 2 stammte erneut von Ian Martin, der auch die Commodore-Fassungen programmierte. Nach dem ersten ACE und dem technisch anders gelagerten Sky Runner schlug Martin beim Nachfolger eine deutlich direktere Richtung ein. The Games Machine beschrieb den ersten Teil als simulationsorientiert, während ACE 2 stärker wie ein Shoot ’em up funktioniere. Der Spieler sollte sich nicht mehr mit Fahrwerk, Landeklappen, Seitenruder und zahlreichen einzelnen Flugfunktionen beschäftigen, sondern möglichst schnell in ein Luftduell geraten.

Für die Grafik der Commodore-Versionen war wieder Damon Redmond verantwortlich. Er entwarf zwei voneinander unterscheidbare Cockpits: Das trägergestützte Flugzeug erhielt modernere Bildschirmanzeigen, während die gegnerische Maschine mit konventionelleren Instrumenten auskommen musste. Auf dem C64 ergänzte Rob Hubbard das Spiel um die Titelmusik. Sie läuft nicht während der eigentlichen Gefechte, sorgt aber schon vor dem Start dafür, dass ACE 2 erheblich professioneller auftritt, als es Cascades alter Ruf vermuten ließ.

Die Rahmenhandlung verzichtet auf reale Staaten. Vor der Küste einer fremden Macht liegt ein Flugzeugträger, dessen Besatzung eine Radarstation an Land beobachtet. Die Landmacht schickt daraufhin einen Abfangjäger los, während der Träger eine eigene Maschine startet. Die Anleitung identifiziert Plane One als F-18 Hornet und Plane Two als F-15 Eagle. Im Einzelspiel übernimmt der Spieler grundsätzlich die F-18, während der Computer die F-15 steuert.

Vor dem Kampf lassen sich unter anderem die Stärke des Computergegners, die Zahl der verfügbaren Maschinen und die erforderlichen Treffer einstellen. Zwei Szenarien stehen zur Wahl. Beim Close Range Dogfight befinden sich beide Flugzeuge bereits in der Luft, sodass das Duell ohne Anflug oder längere Orientierung beginnt. Im umfangreicheren Szenario starten die Maschinen vom Flugzeugträger beziehungsweise von einer Landbasis und können neben dem gegnerischen Jet auch die Radarstation oder den Träger angreifen.

Dabei unterscheidet ACE 2 zwischen Bordkanone, wärmesuchenden und radargelenkten Luft-Luft-Raketen sowie Waffen gegen Boden- und Schiffsziele. Flares und Chaff dienen zur Abwehr anfliegender Geschosse. Das gibt den Gefechten etwas taktischen Unterbau, ohne daraus wieder die kleinteiligere Einsatzsimulation des Vorgängers zu machen. Entscheidend bleibt, den Gegner im schmalen Sichtfeld zu finden, eine Zielerfassung herzustellen und nach dem Abschuss aus dessen Waffenbereich zu verschwinden.

Gesteuert wird mit dem Joystick. Vor- und Zurückbewegungen verändern den Steig- beziehungsweise Sinkwinkel, seitliche Bewegungen bringen das Flugzeug in die Kurve. Schub, Waffenwahl und Kartenansicht liegen auf zusätzlichen Tasten. Cascade bezeichnete diese Aufteilung in der Anleitung als vereinfachte Annäherung an HOTAS, also die Zusammenfassung wichtiger Funktionen an Steuerknüppel und Schubhebel. Von einer ernsthaften Cockpitsimulation kann keine Rede sein, doch der Spieler musste den Joystick nicht ständig loslassen, um nach einer langen Reihe verstreuter Flugbefehle zu suchen.

Mehrere Bestandteile des ersten ACE wurden bewusst gestrichen. Um Fahrwerk, Landeklappen, Seitenruder oder Triebwerkstemperatur kümmert sich der Pilot nicht mehr. Wer Treibstoff, Munition oder Reparaturen benötigt, kann im größeren Szenario zur eigenen Basis zurückkehren. In der Praxis spielte dies jedoch eine geringere Rolle als der unmittelbare Kampf zwischen den beiden Maschinen.

Das horizontale Splitscreen-Verfahren bestimmt den gesamten Ablauf. Jeder Pilot sieht sein eigenes Cockpit, die Landschaft und die Instrumente. Eine Kartenansicht kann vorübergehend die jeweilige Sicht ersetzen und zeigt Flugzeugträger, Radarstation, Küste und beide Maschinen. Für einen realistischen Luftkampf ist dieses Verfahren etwas durchsichtig, denn ein Spieler kann jederzeit einen Blick auf die Bildschirmhälfte des Gegners werfen. Für zwei Menschen, die nebeneinander vor einem Heimcomputer sitzen, funktioniert genau das als zusätzlicher Reiz.

Im Einzelspiel zeigt sich dagegen die größte Schwäche von ACE 2. Mehrere Tester empfanden den Computergegner bereits auf niedrigen Stufen als übermäßig treffsicher. Er konnte den Spieler erfassen und beschießen, bevor dieser die feindliche Maschine im kleinen Sichtfenster überhaupt entdeckt hatte. Längere Suchphasen entstanden vor allem dann, wenn beide Flugzeuge auf ähnlichen Kursen unterwegs waren oder direkt übereinander flogen. Die Karte zeigte zwar, dass sich die Kontrahenten nahezu am selben Punkt befanden, im Cockpit blieb dennoch oft nur Himmel, Horizont und ein Stück Küste zu sehen.

Gegen einen Menschen wirkten dieselben Regeln ausgewogener. Beide Spieler mussten mit den gleichen Sichtverhältnissen, denselben Waffenreichweiten und ihren eigenen Fehlentscheidungen zurechtkommen. Ein menschlicher Gegner hielt nicht stoisch die perfekte Kurve, reagierte nicht in jedem Augenblick auf eine Annäherung und schickte gelegentlich eine Rakete in den leeren Himmel. Genau dort fand ACE 2 seine eigentliche Rolle: nicht als ernsthafte Simulation eines modernen Kampfflugzeugs, sondern als lokales Duellspiel, das Schubkontrolle, Kartenorientierung und verschiedene Waffensysteme gerade weit genug vereinfachte, damit zwei Spieler ohne langes Studium der Anleitung aufeinander losgehen konnten.

Die C64-Fassung bildet den am besten dokumentierten Ausgangspunkt. Das Spiel läuft vergleichsweise zügig, die beiden Cockpits lassen sich gut auseinanderhalten, und Hubbards Titelstück sorgt schon vor dem ersten Start für den passenden Ton. Die Landschaft selbst bleibt spärlich. Über weite Strecken bestehen die Sichtfenster aus Himmel, einem waagerechten Horizont und einzelnen Boden- oder Küstenflächen. Das erleichterte die Berechnung zweier gleichzeitig dargestellter Perspektiven, vermittelt aber nur begrenzt Geschwindigkeit oder Flughöhe.

Die Plus/4-Fassung stammt ebenfalls von Ian Martin und Damon Redmond. Die ASM beschrieb den Bildschirm als eng und die Grafik als funktional: blauer Himmel, gelbliche Küste und Objekte, die beim Näherkommen zwar vergrößert wurden, aber wenig Einzelheiten zeigten. Der Test ordnete das Spiel dennoch relativ freundlich ein, weil vergleichbare Luftkampfspiele auf dem Plus/4 dünn gesät waren. Der entscheidende Satz lautete: „Zu zweit macht ACE 2 dann auch mehr Spaß.“

Für den ZX Spectrum entwarf Ian Martin das Spiel, während Keith Jackson die Programmierung übernahm; die Portierung wird ComTec zugeschrieben. Bei der Amstrad-CPC-Fassung ist Amazing Games als Portierungsstudio belegt, persönliche Programmierer-Credits lassen sich dagegen bislang nicht sicher zuordnen. Die gelegentlich anzutreffende Behauptung, die Spectrum-Version habe wegen des gemeinsamen Z80-Prozessors automatisch als direkte Grundlage der CPC-Fassung gedient, ist nicht nachgewiesen.

Die CPC-Version bewegt die beiden Cockpits merklich bedächtiger als die C64-Fassung. Ein moderner Direktvergleich beschrieb sie dennoch als gut spielbar und im Einzelspiel etwas zugänglicher als die Commodore-Version. Auch dort lag die Stärke nach Erinnerung des Spielers eindeutig im Zwei-Spieler-Modus. Der Eindruck passt zu den zeitgenössischen Tests: Allein konnte sich ACE 2 zäh und gelegentlich unfair anfühlen, mit einem menschlichen Gegner entstand dagegen das Spiel, für das der geteilte Bildschirm gedacht war.

Die DOS-Fassung führt James Byrne, Nick Fitzsimons und Roger Taylor als Programmierer. James Hartshorn und Damon Redmond werden für die Grafik genannt, Ian Martin blieb als Designer eingetragen. Rob Hubbards Musik gehört dagegen ausschließlich zur C64-Version. Für eine CPC-Komposition Hubbards gibt es keinen entsprechenden Credit.

Die zeitgenössische Presse stritt weniger über die Funktionsweise als über die Frage, was ein Nachfolger von ACE sein sollte. Zzap!64 vergab im Oktober 1987 81 Prozent. Ein Redakteur fand, das Spiel „only really comes into its own when played head to head in two-player mode“ – „erst im direkten Zwei-Spieler-Duell wirklich zur Geltung kommt“. Sein Kollege sah gerade in der Vereinfachung das Problem: Von den vielen Abläufen des Vorgängers seien im Wesentlichen Lenken und Feuern übrig geblieben.

The Games Machine kam beim C64 auf 83 Prozent und bezeichnete ACE 2 als „an excellent two-player head to head combat game – very fast, very playable, and more often than not, very tense“ – „ein ausgezeichnetes Zwei-Spieler-Luftkampfspiel, sehr schnell, sehr spielbar und meistens ausgesprochen spannend“. Die Redaktion hielt den Computergegner dagegen für wenig befriedigend. Der Testpreis betrug 9,95 Pfund auf Kassette und 14,95 Pfund auf Diskette.

Commodore User bewertete die C64-Fassung insgesamt mit 7 von 10 Punkten. Die Einzelnoten lagen bei 5 für Grafik, 4 für Sound, 8 für Schwierigkeit, 7 für Langzeitmotivation und 8 für das Preis-Leistungs-Verhältnis. Tester Ken McMahon störte sich am unrealistischen Flugmodell und an der Genauigkeit des Computergegners, kam beim Mehrspielermodus aber zu dem Urteil: „On that basis alone it’s in a class of its own“ – „Allein auf dieser Grundlage spielt es in einer eigenen Klasse.“

Your Commodore vergab 5 von 10 Punkten für Originalität, aber jeweils 8 von 10 für Spielbarkeit, Grafik und Preis-Leistungs-Verhältnis. Das Magazin beschrieb die Gefechte als „fast and frantic“ – „schnell und hektisch“ – und sah ACE 2 als würdigen, wenn auch anders ausgerichteten Nachfolger.

Deutlich härter urteilte das Happy-Computer Special 1 beziehungsweise Power Play. Die Redaktion vergab 5 Punkte für Grafik, 7,5 für Sound und lediglich 3,5 als Power-Wertung. Ihr Urteil lautete: „Ace 2 ist ein reines Action-Spiel mit schwachem Simulations-Einschlag.“ Gelobt wurden vor allem Rob Hubbards Titelmusik und die grundsätzlich funktionierende Zwei-Spieler-Idee; die leere Landschaft, die einfache Steuerung und das geringe Fluggefühl drückten die Bewertung. Der deutsche Verkaufspreis lag bei 29 DM für die Kassette und 49 DM für die Diskette.

Die ASM testete die Plus/4-Version in Ausgabe 11/87 zum Preis von ungefähr 32 DM. Sie vergab 7 Punkte für Grafik, 7 für Handhabung, 9 für Technik und Strategie sowie jeweils 8 für Spielwert und Preis-Leistungs-Verhältnis. Gleichzeitig warnte der Text vor einem Computerpiloten, der die eigene Maschine mitunter abschoss, bevor man ihn selbst auf dem Bildschirm entdeckt hatte. Für C64-Besitzer sah das Magazin bessere Alternativen; innerhalb des kleinen Plus/4-Angebots fiel das Urteil günstiger aus.

Als Gamebusters ACE 2 1989 für 2,99 Pfund erneut veröffentlichte, stieg die Zzap!64-Wertung auf 90 Prozent. Das war weniger eine späte Entdeckung technischer Qualitäten als eine veränderte Preisfrage. Für ein Vollpreisspiel musste sich ACE 2 mit dem umfangreicheren Vorgänger und ausgewachsenen Flugsimulationen messen. Für 2,99 Pfund bot dasselbe Programm einen schnell verständlichen Zwei-Spieler-Wettkampf. Weitere Verbreitung erhielt es durch die Sammlung Supreme Challenge, in der es neben Elite, Tetris, The Sentinel und Starglider erschien. Separate Verkaufszahlen für ACE 2 oder einzelne Portierungen veröffentlichte Cascade nicht.

Der erste Teil war für das Unternehmen deutlich besser dokumentiert. Zeitgenössische Berichte brachten die verschiedenen 8-Bit-Fassungen von ACE mit mehr als einer halben Million Verkäufen in Verbindung. Cascade-Mitgründer Guy Wilhelmy erinnerte sich später daran, dass das Unternehmen in den folgenden Jahren Umsätze von mehr als einer Million Pfund erreichte. Welchen Anteil ACE 2 daran hatte, wurde nicht separat ausgewiesen. Der Nachfolger blieb durch Wiederveröffentlichungen und Compilations jedoch mehrere Jahre im Handel.

Die britische C64-Kassette für 9,95 Pfund entsprach nach heutiger Kaufkraft grob 37 Pfund, die Diskettenversion für 14,95 Pfund etwa 55 bis 56 Pfund. Der deutsche Kassettenpreis von 29 DM entspricht inflationsbereinigt ungefähr 33 Euro, die Diskettenfassung für 49 DM etwa 55 Euro. Die Plus/4-Ausgabe für rund 32 DM läge heute bei ungefähr 36 Euro. Der Gamebusters-Preis von 2,99 Pfund aus dem Jahr 1989 entspräche ungefähr zehn heutigen Pfund.

Für diesen Preis musste sich ACE 2 nicht mehr als Nachfolger einer umfangreicheren Flugsimulation rechtfertigen. Es reichte, dass zwei Spieler vor demselben Rechner Platz nahmen, die Maschinen in entgegengesetzte Kurven legten und darauf warteten, dass der erste Zielton erklang.

🕹️ Artikeltyp: Computerspiel
📅 Erstveröffentlichung: 1987
🏢 Entwickler: Cascade Games; Portierungen durch ComTec und Amazing Games
📦 Publisher: Cascade Games; spätere Budgetausgabe über Gamebusters
🧭 Genre: Luftkampf-Action, vereinfachte Combat-Flugsimulation
👥 Spieler: 1–2 Spieler, horizontaler Splitscreen
🎮 Spieldesign: Ian Martin
💻 Programmierung: Ian Martin (C64, Plus/4), Keith Jackson (ZX Spectrum), James Byrne, Nick Fitzsimons und Roger Taylor (DOS)
🎨 Grafik: Damon Redmond; James Hartshorn bei der DOS-Fassung
🎵 Musik: Rob Hubbard – Titelmusik der C64-Version
🕹️ Steuerung: Joystick mit zusätzlichen Tastaturbefehlen
🌍 Plattformen: Commodore 64, Commodore Plus/4, ZX Spectrum, Amstrad CPC, DOS
📚 Serie: ACE – Air Combat Emulator

Sinbad and the Throne of the Falcon (1987) – Bill Williams’ Abenteuerfilm zwischen Strategie und Säbelkampf

Nach Defender of the Crown verbanden Amiga-Besitzer den Namen Cinemaware mit großen Figuren, farbigen Schauplätzen und Szenen, die eher an einen gezeichneten Abenteuerfilm als an ein gewöhnliches Computerspiel erinnerten. Sinbad and the Throne of the Falcon bot ebenfalls Dialoge, Musik, Säbelkämpfe und Monster, sah jedoch nicht durchgehend wie das nächste technische Schaustück des Herstellers aus. Manche Hintergründe wirkten grob, Animationen fielen unterschiedlich aufwendig aus. Dafür brachte das Spiel Seereisen, Gespräche, Geschicklichkeitstests und eine strategische Kriegskarte auf knapp zwei Megabyte unter. Bill Williams hatte versucht, einen vollständigen Abenteuerfilm auf Disketten zu pressen – und einen großen Teil der Arbeit selbst übernommen.

Die Zusammenarbeit entstand nach der Fertigstellung von Mind Walker, einem der frühen kommerziellen Amiga-Spiele. Williams wusste noch nicht, welches Projekt er als Nächstes beginnen sollte, als Robert „Bob“ Jacob mit Cinemawares Vorstellung eines „interaktiven Films“ an ihn herantrat. Der Spieler sollte nicht nur eine bekannte Filmhandlung verfolgen, sondern selbst in jene Szenen eingreifen, die er aus Kino und Fernsehen kannte.

Jacob schlug mehrere mögliche Themen vor. Sobald der Name Sinbad fiel, war Williams entschieden. Zur Vorbereitung lieh er sich eine Reihe von Sinbad-Filmen aus und notierte deren wiederkehrende Motive.

“I rented a whole bunch of Sinbad videotapes.”

(„Ich lieh mir einen ganzen Stapel Sinbad-Videokassetten aus.“)

Williams suchte nicht nach einer bestimmten Geschichte, die er möglichst genau umsetzen konnte. Er sammelte die vertrauten Bestandteile des westlichen Sinbad-Kinos: exotische Inseln, Zauberer, Prinzessinnen, riesenhafte Kreaturen, gefährliche Seereisen, verfluchte Herrscher und Duelle mit blankem Stahl. Sinbad and the Throne of the Falcon basiert daher weder auf einem einzelnen Film noch auf einer bestimmten Erzählung aus Tausendundeiner Nacht. Williams baute aus den bekannten Versatzstücken eine eigene Abenteuergeschichte.

Im Reich Damaron wurde der alte Kalif durch einen Zauber in einen Falken verwandelt. Seine Tochter Prinzessin Sylphani bittet Sinbad, den Bann zu brechen. Dazu muss er mehrere magische Gegenstände finden und Informationen über das benötigte Gegenmittel zusammentragen. Eine große Sanduhr zeigt an, wie viel Zeit ihm dafür bleibt.

Gleichzeitig marschiert der Schwarze Prinz Camaral mit seinen Truppen gegen Damaron. Sinbad reist daher nicht nur als Seefahrer und Monsterjäger zwischen Städten, Inseln und Meeresgebieten, sondern trägt auch die Verantwortung für die Verteidigung des Reiches. Jede Reise kostet Zeit. Wer nur dem nächsten Abenteuer folgt, kann bei der Rückkehr feststellen, dass Camarals Streitkräfte inzwischen gefährlich nahe an die Hauptstadt herangerückt sind.

Die zentrale Bedienung erinnert stärker an ein grafisches Adventure als an ein reines Actionspiel. Über Menüs wählt der Spieler Reiseziele aus, spricht mit Verbündeten, betrachtet die Weltkarte oder wechselt zur militärischen Übersicht. Gespräche können neue Hinweise, Orte oder Begleiter erschließen, besitzen aber nicht die Tiefe späterer Adventures. Die Figuren verteilen vor allem Informationen oder leiten eine neue Szene ein.

Unterwegs warten Schiffbrüchige auf Rettung, Piraten bedrohen das Schiff, ein Roc greift die Reisegruppe an oder eine Kreatur stiehlt einen wichtigen Gegenstand. Manche Begegnungen führen unmittelbar in eine Geschicklichkeitssequenz. Sinbad kämpft mit dem Schwert, schleudert Steine auf einen Zyklopen, rettet Menschen aus dem Meer oder flieht aus einer aufbrechenden Erdspalte. Einige Abschnitte verwenden eine Seitenansicht, andere zeigen das Geschehen aus Sinbads Perspektive.

Parallel dazu läuft der Krieg um Damaron weiter. Auf einer aus Hexfeldern bestehenden Karte werden Landarmeen und Schiffe bewegt. Versorgungspunkte können geschwächte Einheiten unterstützen. Treffen gegnerische Verbände im selben Hexfeld aufeinander, beginnt ein Gefecht, das anhält, bis eine Armee vernichtet wird oder eine der Einheiten das Feld verlässt.

Die Strategieebene lässt sich dennoch weitgehend vernachlässigen. Das war kein übersehener Fehler, sondern Teil von Williams’ Entwurf. Seine Frau Martha Williams, die zusätzliche Grafiken beisteuerte, mochte nach seiner Aussage keine Brett- und Strategiespiele. Er wollte deshalb verhindern, dass ein einzelner ungeliebter Abschnitt den gesamten Ablauf blockierte. Wer lieber Monster bekämpfte und die Welt erkundete, sollte nicht ständig Truppen über eine Karte schieben müssen.

Diese Offenheit hat ihren Preis. Die einzelnen Bestandteile sind nur locker miteinander verbunden und werden selten vertieft. Wer die Bewegungsmuster der Geschicklichkeitstests erkannt hat, kann viele davon nach wenigen Versuchen bewältigen. Sie sollen kein vollständiges Actionspiel tragen, sondern jeweils eine neue Szene im Abenteuerfilm liefern. Sinbad wechselt deshalb häufig Perspektive und Steuerung, ohne aus einem dieser Ansätze ein eigenständiges Spielsystem zu entwickeln.

Für die ursprüngliche Amiga-Fassung war Bill Williams in ungewöhnlich vielen Bereichen verantwortlich. Er schrieb die Geschichte, entwarf und programmierte das Spiel, führte Regie und komponierte die Musik. Martha Williams lieferte zusätzliche Grafiken. John Cutter betreute das Projekt als Associate Producer, Bob und Phyllis Jacob fungierten als Executive Producers, und Kellyn Beeck schrieb das Handbuch.

Williams gehörte zu jener Generation von Spieleautoren, bei denen die Bezeichnung „Entwickler“ mehrere Berufe zugleich umfasste. Ende der 1970er-Jahre hatte er das Programmieren an einem computergesteuerten Synthesizer erlernt, bei dem Befehle unmittelbar als Hexadezimalwerte eingegeben wurden. Auf dem Atari 800 entstand anschließend Salmon Run, das über Ataris Program Exchange veröffentlicht wurde.

Für Synapse Software entwickelte Williams danach Necromancer und Alley Cat. Die Atari-Version von Alley Cat programmierte er selbst; anschließend setzte er das Spiel innerhalb von sechs Monaten für den IBM PCjr um. Mit Mind Walker wechselte er zum Amiga, wo er Programmierung, Musik und ungewöhnliche Spielkonzepte weiterhin miteinander verband.

Diese Arbeitsweise ermöglichte ihm, Grafik, Klang und technische Effekte unmittelbar aufeinander abzustimmen. Auf der Weltkarte setzte Sinbad eine bewegliche Lupe ein; hinzu kamen Pixelvergrößerungen und Hardware-Scrolling. Gleichzeitig musste Williams eine Arbeitsmenge bewältigen, die Cinemaware bei späteren Produktionen auf mehrere Spezialisten verteilte. Er berichtete von Arbeitstagen, die zwölf bis sechzehn Stunden dauern konnten.

Der Aufwand allein erklärt die uneinheitliche Grafik jedoch nicht. Williams wollte ein möglichst umfangreiches Spiel schaffen. Bei jedem Bild stellte er sich deshalb dieselbe Frage:

“What is the minimum I can get away with?”

(„Was ist das Minimum, mit dem ich davonkomme?“)

Die Grafiken sollten möglichst wenig Speicher beanspruchen, damit mehr Schauplätze, Ereignisse und Spielmechaniken untergebracht werden konnten. Williams räumte später ein, dabei zu weit gegangen zu sein. Einige Bilder seien unnötig grob ausgefallen. Für ihn war dies während der Entwicklung ein Tauschgeschäft zwischen Umfang und Präsentation. Käufer sahen dagegen zunächst nur, dass andere Amiga-Spiele detailliertere Bilder boten.

Gerade bei einem Cinemaware-Spiel fiel dieser Unterschied auf. Defender of the Crown konzentrierte sich auf eine kleinere Zahl wiederkehrender Szenen und präsentierte diese mit sorgfältig gezeichneten Burgen, Turnieren und Großfiguren. Sinbad bot mehr Orte und Mechaniken, verteilte seine grafischen Möglichkeiten aber auf eine wesentlich größere Zahl von Bildern.

Geschlossener wirkt die Musik. Williams komponierte einen fortlaufend wechselnden Soundtrack für Reisen, Kämpfe und andere Situationen. Seine Melodien orientierten sich an den von ihm angesehenen Sinbad-Filmen. Weitere Anregungen erhielt er durch eine in der Nachbarschaft lebende Bauchtänzerin, deren Übungsmusik er hörte. Der selbst entwickelte Musiktreiber sollte unterschiedliche Klangfarben erzeugen, ohne große Datenmengen zu beanspruchen.

Nach dem ungefähr einjährigen Projekt fühlte sich Williams ausgebrannt. Er zog sich für etwa ein Jahr aus der Spieleentwicklung zurück und arbeitete an einem Fantasyroman, bevor er mit Pioneer Plague zum Amiga zurückkehrte.

Cinemaware veröffentlichte 1988 Umsetzungen für Atari ST und Commodore 64, 1989 folgte DOS, 1990 der Apple IIgs. Die Konvertierungen waren keine einfachen Kopien. Große Teile der Grafik und mehrere Geschicklichkeitsszenen entstanden neu. Der Schiffbruch wird in späteren Fassungen aus einer anderen Perspektive gezeigt; auf dem Commodore 64 erscheinen die Schwertkämpfe teilweise aus der Ich-Perspektive statt in der seitlichen Darstellung der Amiga-Version.

Bei den Atari-ST- und DOS-Fassungen war das Team erheblich größer. Curt Toumanian übernahm die künstlerische Leitung, Steve Quinn lieferte Originalgrafiken, während Rob Landeros, Jeffrey Hilbers und Russell Truelove weitere Bilder beisteuerten. L. Allen McPheeters führte laut Credits Produktion und Regie.

Rob Landeros gründete später gemeinsam mit Graeme Devine das Studio Trilobyte, das 1993 durch das CD-ROM-Adventure The 7th Guest bekannt wurde. Bei Sinbad war er jedoch Teil eines größeren Grafikteams; die künstlerische Leitung lag bei Curt Toumanian.

Für die musikalische Umsetzung auf dem Atari ST werden Singing Electrons genannt. In der DOS-Fassung erhielten Peter A. Oliphant und Jim Simmons Credits für die Orchestrierung, während Jim Cuomo ebenfalls an der musikalischen Bearbeitung beteiligt war. Geschichte und ursprüngliche Kompositionen blieben Bill Williams zugeordnet.

Williams sagte später, Bob Jacob habe für die Grafik eine bestimmte Erscheinungsweise im Sinn gehabt. Zwischen beiden hatte es bereits während der Entwicklung unterschiedliche Vorstellungen darüber gegeben, wie das Spiel aussehen sollte. Williams war an den späteren Umsetzungen nicht mehr direkt beteiligt und hatte sie zum Zeitpunkt des Interviews noch nicht gespielt. Er erklärte sogar, dass er sich ein wenig davor fürchte, sie anzusehen.

Auf dem Atari ST kam ein praktisches Problem hinzu: das häufige Wechseln der Disketten. The Games Machine erinnerte im Juni 1989 in seinem Test der PC-Version daran, dass auf dem Atari 520 ST regelmäßig Datenträger getauscht werden mussten. Die DOS-Fassung kam mit zwei Disketten aus, die nach Ansicht des Magazins erheblich seltener gewechselt werden mussten.

Dafür reagierten die Tastaturbefehle der PC-Version etwas träge, besonders während der Schiffbruchsequenz. Außerdem bemerkte der Tester, Cinemaware scheine den Unterschied zwischen einem Zentauren und einem Minotaurus nicht zu kennen. Die PC-Version erhielt 65 Prozent. Als Preis nannte das Magazin 29,99 Pfund.

Bereits im Juni 1987 hatte die Happy Computer die Amiga-Fassung getestet. Das Magazin bezifferte den Programmumfang auf fast zwei Megabyte und erkannte an, dass im Spiel „zweifelsohne eine ganze Menge los“ sei. Darauf folgte jedoch das deutlich weniger schmeichelhafte Urteil:

„Aber dieser Masse fehlt es an Klasse.“

Die Geschicklichkeitstests seien zu einfach, die Grafik für Amiga-Verhältnisse wenig eindrucksvoll und die Motivation lasse nach dem erfolgreichen Abschluss der Mission deutlich nach. Besser kam die ständig wechselnde Musik davon. Die Einzelwertungen lauteten 65 Punkte für die Grafik, 80 Punkte für Sound und Musik sowie 57 Punkte in der Happy-Wertung. Die Amiga-Fassung kostete 89 Mark.

Bill Williams starb am 28. Mai 1998, einen Tag vor seinem 38. Geburtstag. Nach Sinbad entwickelte er unter anderem Pioneer Plague und Knights of the Crystallion. In den Credits der SNES-Fassung von The Simpsons: Bart’s Nightmare wird er unter der nicht näher erläuterten Bezeichnung „Miscellaneous“ geführt.

Die in der Happy Computer getestete Amiga-Fassung kostete in Deutschland 89 Mark. Nach dem Kaufkraftvergleich der Deutschen Bundesbank entspricht dies ungefähr 97 Euro in Preisen von 2025. Für die 1989 getestete PC-Version verlangte Mirrorsoft in Großbritannien 29,99 Pfund; nach der britischen Verbraucherpreisentwicklung entspricht dies rund 80 Pfund in Preisen von 2025.

Sinbad brachte auf knapp zwei Megabyte eine Weltkarte, Gespräche, Seereisen, Truppenbewegungen, Monster und mehrere unterschiedlich gesteuerte Actionsequenzen unter. Die Speicherersparnis, die diesen Umfang ermöglichte, blieb auf dem Bildschirm sichtbar. Nach zwölf- bis sechzehnstündigen Arbeitstagen und rund einem Jahr Entwicklungszeit legte Bill Williams anschließend eine ebenso lange Pause von der Spieleproduktion ein.

🎮 Spieltyp: Mischung aus Adventure, Geschicklichkeitsspiel und einfacher Strategie

📅 Erstveröffentlichung: 1987 für den Amiga

💻 Systeme: Amiga, Atari ST, Commodore 64, DOS, Apple IIgs

🏢 Entwicklung und Veröffentlichung: Cinemaware; europäischer Vertrieb teilweise durch Mirrorsoft

✍️ Autor, Designer und Regisseur der Amiga-Fassung: Bill Williams

🎵 Originalmusik: Bill Williams

🎨 Zusätzliche Amiga-Grafik: Martha Williams

📖 Handbuch: Kellyn Beeck

🗺️ Spielziel: Den verzauberten Kalifen von Damaron retten und gleichzeitig das Reich gegen die Armee des Schwarzen Prinzen Camaral verteidigen

⚔️ Spielbestandteile: Gespräche, Seereisen, Schwertkämpfe, Monsterbegegnungen, Rettungsaktionen und Truppenbewegungen auf einer Hexfeldkarte

💾 Besonderheit: Die späteren Fassungen waren keine direkten Kopien, sondern erhielten teilweise neue Grafiken, veränderte Perspektiven und anders aufgebaute Geschicklichkeitsszenen

💰 Preis: 89 DM für die Amiga-Fassung; entspricht ungefähr 97 Euro in Preisen von 2025

📰 Happy Computer, Amiga: Grafik 65 Punkte, Sound und Musik 80 Punkte, Gesamtwertung 57 Punkte

📰 The Games Machine, DOS: 65 Prozent

Commodore MDS 6500 – Der PET als Entwicklerwerkzeug

Wer Ende der 1970er-Jahre Software für einen 6502-Rechner entwickeln wollte, benötigte mehr als einen Texteditor und eine freie Steckdose. Quelltexte mussten eingegeben, übersetzt, auf Fehler untersucht und schließlich auf das eigentliche Zielsystem übertragen werden. MOS Technology hatte dafür zunächst das MDT650 entwickelt, ein kostspieliges Microcomputer Development Terminal mit Diskettenlaufwerk und eigener Entwicklungssoftware. Der spätere Commodore MDS 6500 übertrug dieses Prinzip auf eine wesentlich vertrautere Grundlage: den PET.

Die Abkürzung MDS stand für Microcomputer Development System. Hinter der besonderen Modellbezeichnung verbarg sich kein vollständig neu konstruierter Rechner, sondern ein für Entwicklungsarbeiten angepasster Commodore PET 2001-32N mit 32 KB RAM. Auf dem Gehäuse saß anstelle der üblichen PET-Modellbezeichnung ein MDS-6500-Schriftzug. Zum System gehörte ein passend beschriftetes CBM-2040-Doppeldiskettenlaufwerk, das Programmtexte, Objektdateien und weitere Entwicklungsdaten aufnehmen konnte.

Der PET brachte dafür bereits eine zweckmäßige Grundausstattung mit. Sein MOS-6502-Prozessor arbeitete mit ungefähr 1 MHz, der eingebaute Monitor stellte 40 Zeichen in 25 Zeilen dar, und über den IEEE-488-Anschluss ließ sich das externe Doppellaufwerk betreiben. Für gewöhnliche Büroarbeiten war diese Kombination ebenfalls geeignet, doch beim MDS 6500 lag der Schwerpunkt auf der Erstellung von Software für die MCS6500-Prozessorfamilie.

Der Name sorgt leicht für Verwirrung. MCS6500 war die Bezeichnung der von MOS Technology entwickelten Mikroprozessorfamilie, zu der neben dem bekannten 6502 auch der 6501 sowie mehrere Varianten mit abweichender Anschlussbelegung gehörten. Das MDS 6500 bezeichnete dagegen ein komplettes Entwicklungssystem. Es steckte also kein besonderer „6500-Prozessor“ im Rechner; im Inneren arbeitete weiterhin der aus dem PET bekannte 6502.

Wie solche Systeme eingesetzt wurden, zeigt das MCS6500 Family Hardware Manual. Es beschreibt neben Prozessoren, Speicherbausteinen, Bussystemen und Interruptsteuerung auch das ältere MDT – Microcomputer Development Terminal. MOS bezeichnete dieses als fertig zusammengestelltes System, mit dem Entwickler ihre Programme und die Verbindung zu Ein- und Ausgabegeräten prüfen konnten. Der Vorteil lag auf der Hand: Statt gleichzeitig nach Fehlern in selbst aufgebauter Hardware und im eigenen Programmcode suchen zu müssen, erhielt der Entwickler eine bekannte Arbeitsumgebung. Damit ließ sich das Problem wenigstens auf eine Seite des Schreibtisches eingrenzen.

Bei Commodore waren die ursprünglichen MDT650-Systeme nur in geringer Zahl vorhanden. Auf ihnen wurde der MOS Resident Assembler eingesetzt, mit dem unter anderem Software für den ersten PET und das CBM-2040-Laufwerk entstand. Als das 2040 verfügbar war, portierte Commodore-Mitarbeiter John Feagans den Resident Assembler auf den PET. Damit konnte Commodore die Entwicklungsarbeit von den seltenen und teuren MDT-Terminals auf die eigenen Serienrechner verlagern.

Bekannte Versionen des PET Resident Assemblers tragen die Datierungen 27. November 1979 und 15. Dezember 1979. Commodore veröffentlichte diese Software 1980 als Teil des PET Assembler Development System. Der Assembler verarbeitete Quelltexte, erzeugte Maschinencode und konnte Listen mit Speicheradressen, Opcodes und Fehlermeldungen ausgeben. Zusammen mit dem Diskettenlaufwerk wurde der PET damit zu einer vollständigen Entwicklungsstation, ohne dass dafür erneut ein spezielles Terminal von Grund auf konstruiert werden musste.

Die praktische Bedeutung dieser Arbeitsweise ging über den MDS 6500 hinaus. Commodore verwendete den auf den PET übertragenen Resident Assembler für Betriebssystem- und BASIC-Bestandteile späterer PET-Modelle, des VIC-20, des C64 und der CBM-II-Reihe. Auch ROMs verschiedener Diskettenlaufwerke, Drucker und Commodore-eigener Programme entstanden mit dieser Entwicklungsumgebung. Erst ab 1984 verlagerte Commodore einen größeren Teil der Arbeit auf einen unter VAX/VMS laufenden Cross-Assembler.

Wie deutlich sich ein MDS 6500 technisch von einem normalen PET 2001-32N unterschied, ist nur unvollständig dokumentiert. Die erhaltenen Beschreibungen sprechen von einem modifizierten PET mit Assembler und einem passend gekennzeichneten 2040-Laufwerk. Ob der Assembler fest im Rechner untergebracht war oder zum ausgelieferten Diskettensatz gehörte, lässt sich aus den derzeit verfügbaren Unterlagen nicht eindeutig ableiten. Auch eine vollständige Liste der zusätzlich gelieferten Programme, Handbücher und Kabel fehlt.

Eine häufig zitierte Commodore-Modellübersicht nennt 500 gefertigte Geräte, während eine weitere Beschreibung von weniger als 500 Exemplaren spricht. Eine dazugehörige Produktionsaufstellung von Commodore ist bislang nicht bekannt. Die Zahl sollte daher als überlieferte Größenordnung und nicht als abschließend bestätigte Stückzahl verstanden werden.

Der MDS 6500 war damit kein eigenständiger Heimcomputer und auch kein gewöhnliches PET-Sondermodell für Schulen oder Büros. Er gehörte zu den professionellen Werkzeugen, mit denen Software für die wachsende 6502-Rechnerfamilie entstand. Äußerlich blieb er ein PET mit passendem Doppellaufwerk. Seine eigentliche Aufgabe lag jedoch nicht vor dem Bildschirm, sondern in den Programmen, ROMs und Betriebssystemteilen, die mit seiner Hilfe entwickelt wurden.