Die gute alte Highscore. Was täten wir nur ohne Sie. Die Highscore macht das Spiel erst zum Wettbewerb. Wie aber sage ich es meinem Computer in 6502 Assembler.
Ja, wie kann ich in 6502 Maschinensprache zwei beliebig große Zahlen miteinander vergleichen?
So geht’s:
….Einen zeitgenössischen Artikel dazu findet man da:
Electronic Games, Dezember 1984, Seite 69
Ob Concorde, Percom oder Rana. Alles da um es nachzulesen.
Percom: 704kB? Welches DOS? Fragen über Fragen…..
Ohne Vergleich!
Im Modus 12 bzw. 13 – beides Textgrafik Modi, in der Regel 4 Fraben je Zeichen. Die fünfte Farbe kommt jenseits von Zeichen 127 ins Spiel (ATASCII – Code). Dort beginnt der inverse Zeichensatz.
Wird bei diesen Zeichen bei der Zeichensatz Definition die Bit- Kombination 11 Gesetzt, dann läßt sich diesem Bildpunkt mit dem Farbregister 711 (Schatten: 53273) die jeweilige Farbe zuweisen. Das ist dann Farbe Nr. 5!
Ab ATSCII>127 wiederholt sich der Zeichensatz, auch der selbst definierte!
Ein Beispiel:
DIe Blöcke mit dem schönen Regenbogenfarb- Effekt sind ATASCII Code 128 Zeichen (! invers). Der Effekt entsteht indem in einer DLI Routine in jeder neuen Zeile eine neue Farbe über das Register 53273 zugewiesen wird.
Ein Nachteil der im Bild gezeigten Methode ist, dass das die DLI Routine die Ablaufgeschwindigkeit des Hauptprogramms negativ beeinflusst!
Ab dem Label „FG“ beginnt der Teil der DLI- Routine die den Regenbogeneffekt erzeugt.
Display List Interrupt, eine Spezialität der Atari 8- Computer.
Das Folgende Büchlein beschäftigt sich eingehend damit:
Atari Graphics and Arcade Game Design
Schaut mal in Kapitel 6, da steht es geschrieben….
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 🙂
http://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:
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“
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:
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.
RetroZock 