angelsoft
retro computing und elektronik

Februar 2014

Downport: Pilot X auf Atari® 2600

PilotX für C16
Abbildungen auf der Kassetten-Hülle des Plus Paket II

Ein paar Jahrzehnte hat die Spielidee ja nun schon auf dem Buckel: Pilot X kam 1987 bei Kingsoft für den C16/Plus4 heraus.

Die Aufgabe ist, mit einem Raumschiff in einem Höhlensystem zu manövrieren. Dabei gibt es einige Situationen, in denen die Höhlenöffnung kleiner ist als das Raumschiff!

Was also tun? Nun, kurzerhand wird das Schiff in seine drei Bestandteile zerlegt und jeweils einzeln durch die Höhlen bugsiert. Ein Höchstmaß an Konzentration ist dafür erforderlich!

Selbstredend wird es im weiteren Spielverlauf immer kniffliger, die Höhlenpassagen zu durchqueren. Ziel des Spiels ist es, den Höhlenboden zu erreichen, wo auch schon ein zweites Schiff wartet.

Wäre es wohl möglich, dieses Spiel auf die legendäre Videospiel-Konsole Atari® 2600 zu portieren? Während der Commodore® C16/C116 als echter Homecomputer bereits einen Bildschirmspeicher von 1000 Bytes für Text-Zeichen und 8000 Bytes für Graphik aufwies, hatte das Atari®-System nur 20 Bits(!) vorzuweisen. Aufgrund dieses geringen Speicherplatzes muss der Programmierer während des Bildaufbaus in jeder Zeile die Register für die Graphikanzeige aktualisieren und penibel die wenigen verfügbaren CPU-Zyklen zählen, damit die Spielobjekte und Hintergründe auch korrekt angezeigt werden. Die Spiellogik selbst kann im wesentlichen nur in der vertikalen Austastlücke berechnet werden. Selbst das Darstellen des Punktestands wird damit zu einer Herausforderung. Speicher ist ebenfalls Mangelware: 128 Byte RAM sind verfügbar und ein einfaches Spiel-Cartridge hat 4 KByte ROM. Das sieht beim C16 schon ganz anders aus: 16K RAM und noch mehr ROM - aber leider keine Sprites!

Von denen hat der Atari® 2600 immerhin zwei Stück mit jeweils 8 Bit Breite, zwei einbittige Missile-Objekte und einen ebensolchen 'Ball' (letzterer war ganz offensichtlich für Sportspiele vorgesehen). Ferner kann man die Breite und Kopienanzahl dieser Objekte variieren und durch Änderung der Farbe je Rasterzeile so etwas wie Multicolor-Sprites erzeugen.

Die Herausforderung der Spieleprogrammierung mit dieser Systemarchitektur kann in dem vielzitierten Buch Racing the Beam nachgelesen werden.

Also los geht's: Pilot X soll portiert werden. Die erste Designentscheidung ist es, die beiden verfügbaren Sprites (im Atari-Jargon heißen sie 'Player") für die Außenkapseln des Raumschiffs zu verballern. Die Mittelkapsel wird durch die stark vergrößerten Missiles und den Ball angedeutet (und besteht damit sehr speichersparend nur aus 3 Bits je Zeile). Jedenfalls kann man so die Außenkapseln vom Mittelteil trennen.

Code mit Zyklen
Assemblercode mit Zyklen

Abenteuerlich ist auch die Positionierung der Sprites. Einfach eine X-Koordinate in ein Register zu schreiben, wäre ja zu einfach. Nein - man muss ein Strobe-Register setzen, wenn der Elektronenstrahl an der gewünschten Stelle angekommen ist und anschließend ist auch noch Feinjustierung nötig - also wieder Zyklen ausrechnen.

Das viele Zyklenzählen führt dazu, das der Assemblercode immer wieder mit Zahlen für CPU-Zyklen oder Graphikpixeln kommentiert wird, damit man überhaupt noch weiß, wo man ist...

Labyrinth
Das Labyrinth wird komprimiert

Das Labyrinth wird mit dem Bilschirmvordergrund des Atari® 2600 dargestellt - der besteht allerdings nur aus 40 groben Pixeln je Zeile. Und damit das Labyrinth nicht in der Mitte gespiegelt wird, muss in jeder Zeile dafür gesorgt werden, dass auch noch die Daten für die zweite Hälfte der Zeile herangeschafft werden.

Die Labyrinth-Daten mussten komprimiert werden, um überhaupt ein nennenswertes Labyrinth in 4 KBytes hineinzubekommen. Für ein Dekomprimieren in jeder Zeile ist aber nicht genug Zeit vorhanden - was also tun?

Da mit 40 Pixeln je Zeile nur 6 Bytes (eigentlich sogar nur 5) benötigt werden und 18 Pixel in Y-Richtung vorgesehen sind, kommt man mit 6*18 = 108 Bytes an Information für den auf dem Bildschirm sichtbaren Teil des Labyrinths aus. Wir können also die Dekomprimierung in der vertikalen Austastlücke vornehmen und das Ergebnis für einen Frame in den 108 Bytes zwischenspeichern. Und wird haben damit noch 128-108 = 20 Bytes an RAM für die ganze Spielsteuerung übrig - das ist nicht gerade üppig...

Man glaubt es kaum - aber das reicht aus!

Das Labyrinth sollte auch noch Farbe bekommen - und es scrollt ganz soft pixelweise über den Bildschirm. Was das angeht, ist die Umsetzung sogar besser gelungen als beim Original auf dem C16! Hier einige Spielszenen im Emulator:

PilotX im Atari®2600-Emulator
PilotX im Atari®2600-Emulator

Aber das Abenteuer ist damit noch nicht zuende. Das Spiel soll ja auch auf echter Hardware laufen. Also muss ein Cartridge her und das Spiel auf ein E(E)PROM geschrieben werden. Mehr dazu findet sich hier.

Während die Emulatoren oft sehr genügsam mit dem Zeilenzählen sind, muss auf echter Hardware schon alles passen, damit auf PAL oder NTSC ein Bild erscheint. Auch die Farben unterscheiden sich zwischen diesen beiden Bildschirm-Formaten.

Letztendlich hat es funktioniert: Pilot X läuft im Atari® 2600 auf einem (mittlerweile selten gewordenen) Röhrenfernseher:

PilotX im Atari®2600
Spielszenen auf Röhrenfernseher
PilotX im Atari®2600
Pilot X auf Atari® 2600

Die Zeilenzahl ist nicht immer ganz korrekt, so dass der eine oder andere Bildschirm kleinere Synchronisierungsfehler hat, aber das Spiel lässt sich gut spielen. Ob es schwieriger oder leichter ist als das Original auf C16 - darüber gehen die Meinungen auseinander...

Wer sich das Spiel ansehen möchte, kann das Binary hier herunterladen.


[ ↑ ]