Shift Restore Escape am 11.6.2013 in Berlin

Gestern am 11.6.2013 durfte ich im Rahmen der Vortragsreihe „Shift Restore Escape“ meinen Beitrag dazu präsentieren. Es ging um die Programmierung eines Spieles für die Atari 8- Bit Computer nach rund 20 Jahren Programmierabstinenz. In 6502 Assembler!

Ein Abstract finden sich auf der offiziellen Seite der Vortragsreihe.

Eine PDF Version der Folien gibt es da (leider ohne die Filme):  Vortrag Foliensatz

Das Video zum Vortrag kann man auf auf dem Blog Simulationsraum anschauen, oder, direkt hier:

Dirk Ollmetzer hat eine sehr schöne Zusammenfassung meines Vortrages – garniert mit einigen Bildern – auf seinem Blog veröffentlicht.

Im Folgenden eine Zusammenstellung der Kapiteln des Vortrages und den dazu gehörenden Quellenangaben und Erläuterungen zu einigen meiner Aussagen und abschließend einige interessante Fragen aus dem Kreis der Zuhörer:

Motivation
War „Thrust“ vor oder nach Boulder Dash.Zur meiner Aussage, BD hätte eine der ersten Physik Engines besessen.Das Spiel „Thrust“ war, zumindest gem. Angaben aus der englischsprachigen Ausgabe von Wikipedia, von „Gravitar“ inspiriert. Es gibt noch weitere Beispiele eine einigermaßen reale Physik auf die Spielewelt zu projizieren. „Spacewar“ wäre ein weitere Vertreter. Insofern war meine Aussage gewagt und sollte Anlass zu Diskussionen und weiteren Recherchen bieten 🙂

https://retrozock.com/2012/07/06/boulder-dash-alikes/
Eine kleine Übersicht div. BD Clones oder durch BD inspirierte Programme für die Atari 8- Bit Computer.

Die Zielplatform
Zu meiner Aussage, in den Atari 8- Bit Computern ist ein 6502 Prozessor verbaut:In allen Atari XL Modellen wurde ein leicht abgewandelte Form des 6502 eingesetzt, um die Zusammenarbeit mit dem ANTIC- Chip zu unterstützen. Auch in einige der spät produzierten Atari 800/ 400 Modellen wurde diese CPU bereits verwendet, der Atari den Spitznahmen „Sally“ gab. In frühen Modellen wurde der Standard 6502 verbaut, die geforderte Funktionalität im Bezug auf den ANTIC dann aber mittels 4 zusätzliche Custom Chips erkauft.

http://6502.org/documents/books/
MOS Programminig Manualhttp://www.faqs.org/faqs/atari-8-bit/faq/section-12.html
Der 6502 im Atari und weiterführendes zum ANTIC

Original vs. Emulation
http://www.atarimac.com/atari800macx.php
AtariMac800X, Homepage des Entwicklers

Die IDE zur Auswahl standen….
Zu Meiner Aussage, Compiler erzeugen i.d.R. Reinen, Maschinen lesbaren Objekt- Code.Ist doch eigendlich klar, oder? Nein, nicht alle Compiler übersetzen direkt in Maschienensprache, sondern gehen einen Umweg. Es wird ein sog. Pseudo- Code erzeugt, der über ein sog. Runtime Environment gestartet werden kann. Turbo Basic für den Atari 8-Bit ist ein Beispiel.

http://sdx.atari8.info/index.php?show=en_introduction
Sparta DOS Homepage

Assembler
Zu meiner Aussage, der „Atari Macro Assembler“ wurde in zeitgenössischen Testberichten unterschätzt:Drei Assembler für Atari Computer im Vergleich:

  • Happy Computer 3/85, Julian F. Reschke.

http://www.atarimagazines.com/v2n7/nightmare.html
Artikel aus: Antic, Ausgabe Nr. 7, Oktober 1983, Seite 83
Zeitgenösischer Bericht zur Auswahl des passenden Assemblers
zur Realisierug eines Spieleprojektes aus professioneller Sicht.

http://www.atarimagazines.com/compute/issue43/177_1_REVIEWS_MAC_65.php
Artikel aus Compute! Ausgabe 43, Dezember 1983, Seite 43
Zeitgenössischer Testbericht zum MAC 65Zu Meinen Erläuterungen zum Thema Zeilenorientierte Editoren, die nach der Eingabe einen Syntax Check durchführen und die eingegebenen Befehle in sog.Token umwandeln und damit den Arbeitsspeicher wesentlich effizienter nutzen.Das Prinzip der Token – es ist auch die Rede vom sog. „Pre- Compiler – und die Vor- sowie Nachteile von Compiler vs. Interpetierten Sprachen wird in „The Atari Basic Source Book“ sehr schön erläutert.

Optimierung
Querverweis zur Stüzung meiner Aussage, „Schleifen sind elegant aber langsam“

  • MOS Programming Manual, MOS Technology INC, Seite 74

Programmierte Grafik
Zur Aussage es gibt Möglichkeiten alle 256 Farben des Atari gleichzeitig darzustellen. 

Wer’s ganz genau wissen will, der schaut nach im:

  • 1. Atari Sonderheft der Happy Computer, Sonderheft Nr. 2/86

Einige Interessante Fragen aus dem Kreis der Zuhörer:

Zur Physik Engine: Es gab den Vorschlag, zur Geschwindigkeitsoptimierung, einen andern Algorithmus zu verwenden. Und zwar sollten nur die Koordinaten jener Objekte überprüft werden, die zur Auslösung eines Ereignisses benötigt werden. Also die der Felsen und Diamanten. Aus meiner Sicht ein sehr guter Ansatz, wobei dann aber ein besonderes Augenmerk auf die konstante Ablaufgeschwindigkeit des Spieles gerichtet werden muss. Denn: Je mehr Objekte – Steine und Diamanten – desto langsamer wird die Hauptschleife durchlaufen (oder bei weniger Objekten eben schneller…). Es müsste eine Methode implementiert werden, die dafür sorgt, dass das kontrolliert und dem entgegengesteuert wird. Des weiteren wäre zu beachten, dass mehr RAM benötigt wird. Bei meiner Methode ist die Information zur Position der zu manipulierenden Objekte direkt in der Bildschirmgrafik selbst enthalten. Bei der Vorgeschlagenen Methode, ist eine Matrix im RAM anzulegen – zusätzlich zum Bildschirmspeicher – die die Koordinaten (X + Y) der Objekte enthält. Wie ich das sehe, gäbe es auf modernen Plattformen nur diese eine Möglichkeit das Spiel zu realisieren, da man dort ja nie direkt auf den Bildschirmspeicher zugreift.

Warum die Hauptschleife und die Bewegung der Spielfigur nicht im Vertical Blank Interrupt realisieren: Ebenfalls ein sehr guter Ansatz. Von mir aber nicht umgesetzt, weil ich zu beginn meiner Arbeit an „Rock“ noch keine Ahnung von derlei Dingen hatte. Das Ganze nun umzuarbeiten ist nicht möglich, weil die Bewegungs- und Animationsroutine zu viele Unterprogramme anspringt. Dabei ist nun zum Einen nicht klar, wie viele Taktzyklen dabei verbraucht werden, das sollte man bei Anwendung dieser Methode schon wissen, sonst gerät der Bildschirmaufbau durcheinander, und zum Anderen viele „JSR“ – Jump to Subroutine – den Stack stark beanspruchen, das tut die Interrupt Routine aber auch. Da ist es schwer den Überblick zu behalten, selbst wenn man das von Anfang an so (Interrupt-gesteuert) machen wollte.

Ablaufgeschwindigkeit optimieren, in Assembler?…..: Tja, dass überrascht! Aber, wenn man seinerzeit von Basic auf Assembler umgestiegen ist und nun geglaubt hat, man habe den Stein der Weisen gefunden, dann irrte man! Bei unüberlegter Programmierung gerieten auch einfache Programme schnell an ihrer Grenzen. Das habe ich anhand der Schleifen- Thematik – im Vortrag unter der Überschrift „ Optimierung, das Programm wird schneller„ anhand der Schleifen-Problematik dargestellt. Wer viele Schleifen nutzt und die auch noch miteinander verknüpft, der potenziert die Anzahl der Schleifendurchläufe und damit die Verlangsamung des Programmablaufs. Nutzt man zeitkritische Interrupt gesteuerte Routinen, ist die Optimierung des Programmlaufs sowieso unabdingbar.

Advertisements

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

%d Bloggern gefällt das: