angelsoft
retro computing und elektronik

KATEGORIE: atari 2600

März 2017

Noch ein Downport: Hugohunt für Atari® 2600

Hugohunt-Titelbild auf VCS

Und noch eine Portierung von Dorndorfs Hugohunt: Diesmal auf den Atari® 2600 (aka "VCS"). Aufgrund verschiedener Restriktionen dieser Konsole müssen dabei allerdings ein paar Hürden überwunden werden:

asymmetrisches Labyrinth in Dorndorfs Original
asymmetrisches Labyrinth in Dorndorfs Original-Version

Im Gegensatz zu anderen Labyrinthspielen wie etwa Pac-Man ist das Labyrinth von Hugohunt nicht symmetrisch. Das ist für die Umsetzung im Atari® 2600 schwierig, da dort für die zweite Hälfte des Labyrinths weitere Daten während des Zeilenaufbaus herangeschafft werden müssen. Weil zur gleichen Zeit noch verschiedene Player-Positionierungen nötig sind, ist die erste Designentscheidung daher, nur symmetrische Labyrinthe zuzulassen. Es müssen also neue Laybrinthe erstellt werden.

Es gibt aber noch weitere Herausforderungen: da Hugo und Geist beliebig positioniert werden können, kommt es vor, dass Hugo, Geist und weitere Hintergrund-Figuren in einer Zeile dargestellt werden müssen:

Viele Player in einer Zeile
viele Player in einer Zeile

Das VCS kann aber nur zwei 8-bittige Player an frei wählbarer Position horizontal nebeneinander darstellen. Als einziger Ausweg stellt sich das Interlacing/Multiplexing dar: in einem Frame-Durchgang werden die einen Elemente (hier Hugo und Geist) und im nächsten Frame-Durchgang die anderen Elemente (stationäre Objekte) dargestellt. Das führt naturgemäß zu einem Flimmern der Objekte auf dem Bildschirm, das weniger intensiv ist, je mehr der Bildschirm nachleuchtet. Die Entscheidung fürs Interlacing habe ich in der Tat nur widerwillig gefällt. Das Flimmern ist in den Emulatoren vergleichsweise intensiv (es sei denn man setzt im Stella den Phosphor-Wert entsprehend hoch). Auf der echten Hardware ist es aber interessanterweise weniger störend als im Emulator ohne "Phosphor". Die Interlacing-Technik wird in VCS-Homebrews auch zum Mischen von Farben für "Multicolor-Sprites" eingesetzt (z.B. beim Donkey Kong Remake für VCS).

8k-Schaltung auf Breadboard
8k-Schaltung auf Breadboard

Die erste Version des Hugohunt-Downport für VCS konnte 7 Labyrinthe in einem 4KB-Cartridge unterbringen. Es gab dann die Anregung, mit einem 8KB-Cartridge noch mehr Labyrinthe zu ermöglichen.
Die übliche Variante für 8k-Bankswitching ist 'F8', d.h. es wird in die Adresse $1ff8 geschrieben, um auf Bank 0 (0-$fff) zu arbeiten und nach $1ff9 für Bank 1 ($1000-$1fff). Da das VCS selbst gar nicht für Bankswitching ausgelegt ist, muss das Cartridge schlauer werden. Eine praktikable Schaltung dafür findet sich hier. - Oder bei AtariAge Cartridges kaufen, die Bankswitching unterstützen. Die 8k-Version von Hugohunt umfasst nun 14 Labyrinthe.

weitere Labyrinthe
weitere Labyrinthe im 8KB Cartrige vom Erfinder höchstperönlich

Hugohunt für Atari®2600 lief zunächst im PAL-Format mit 312 Bildschirmzeilen. Im amerikanischen NTSC-System gibt's aber nur 262 Zeilen im VCS. Dafür musste dann doch einiges zusammengedampft werden: die Überschrift entfiel, Labyrinth-Begrenzungen wurden schmaler und Anzeigezeschriften gedrungener:

Level 2 in der PAL- und in der NTSC-Variante
Level 2 in der PAL- und in der NTSC-Variante

Das Spiel fragt den Schwierigkeitsschalter am VCS ab: Wenn man ihn aktiviert (erkennbar an der roten Score-Anzeige), ist der Geist schon von Anfang an mit dabei.

erhöhte Schwierigkeit bei blutroter Score-Anzeige...
erhöhte Schwierigkeit bei blutroter Score-Anzeige...

Ach ja, die Musik erfuhr auch ein "Downgrade", da das VCS nicht alle Intervalle produzieren kann...

Hier gibt es Demo-Versionen zum Download. 4k-Versionen mit zwei Labyrinthen und 8k-Versionen mit vier Labyrinthen. Die NTSC-Versionen sind bislang nur im Emulator getestet.

4k PAL-Demoversion

4k NTSC-Demoversion

8k PAL-Demoversion

8k NTSC-Demoversion

Ergänzung von der Doreco-Party 2018. Hier lief Hugohunt 8k auch auf anderer Hardware:

Hugohunt auf 7800er
Hugohunt auf 7800er
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.


[ ↑ ]