Shift – Restore – Escape ist der Name eine Vortragsreihe die im Sommer 2012 an der Berliner Humbolt Universität stattgefunden hat.
Mehr als einem Dutzend Retro- Aktivisten wurde hier die Möglichkeit geboten, ihre Projekte Vorzustellen.
Retro möchte dabei nicht als der verklärende Blick in die Vergangenheit verstanden werden, sondern als die aktive Beschäftigung mit alter Hard- und Software als Mittel zum Verständnis der modernen Medienwelt, auch zum Zweck der Kritischen Auseinandersetzung mit derselben. So zumindest habe ich die Motivation der meisten Teilnehmer aufgefasst. Manch einer mag aber auch nur deshalb aktiv sein, weil es schlicht und einfach Spass macht etwas neues (altes) zu entdecken.
Letzteres nun war für mich der Ausgangspunkt mich selbst einmal mit dem Thema auseinanderzusetzen.
Das Ergebnis kann im aus der Vortragsreihe entstandenen Buch aus dem CSW- Verlag nachgelesen werden, in dem ich ein Kapitel mitgestalten durfte.
Ich erkläre am Beispiel eines simplen Computerspieles für den Atari 8- Bit Computer, dass ich in 6502- Maschinensprache geschrieben habe, wie die Vorgänger der heutigen App- Macher vor knapp 30 Jahren gearbeitet haben, welche Software Tools zu Verfügung standen und wieviel Spass es mir gemacht hat mich nach einer Zeit der Abstinenz wieder kreativ mit dem Medium Computer auseinanderzusetzen.
…interessant, wenn man sich die Mühe macht und es versucht, für den interessierten, Aussenstehenden, einen komplexen Sachverhalt transparent darzustellen.
Konkret geht es darum zu zeigen, wie die einzelnen Programmteile eines Computerspieles prinzipiell zusammenarbeiten. Das Diagramm orientiert sich an meinem eigenen, kleinen, Spieleprojekt Rock(6502- Assembler. Platzbedarf Objekt- Code ca. 3kB).
In Stichworten: Die Hauptschleife steht zwischen der Init und der Game Over Routine.
Init wird immer aufgerufen: Beim Start des Programms und nach dem Durchlauf der Game Over Routine.
Die Hauptschleife wird solange durchlaufen bis eines der Unterprogramme signalisiert: Der Spieler ist Tot (KillFlag=1).
Die Unterprogramme zur Spielerbewegung, Physik Engine und Ablaufverzögerung – die Wartescheife – werden periodisch aufgerufen.
Solange das Programm nicht in ein Multitasking- Betriebssystem eingebettet ist, dürfte das beschriebene Prinzip für nahezu alle Spieleprogramme zutreffen.
Eigentlich wollte ich nur eine kleine Routine entwerfen, die eine Bilddatei im NeoCrome Format in eines der beliebte Atari 8- Bit Grafikformate wandelt. Herausgekommen sind bis jetzt eine nicht unbeträchtliche Anzahl C- Routinen die das gewünschte für die Grafikstufen 8,15 und 9 bis 11 (GTIA 1-3) erledigen sowie eine Anwendung die unter dem Cocoa Framework läuft. Das ganze also etwas zugänglicher macht.
Warum die Arbeit? Neugier und das Ziel vor Augen meinem Spielchen ein ansehnliches Titelbild zu verschaffen. Die ersten Ergebnisse könnt ihr hier bewerten (‚tschuldigung, bewundre 🙂
Man sollte jederzeit die absolute Kontrolle über seine Spielfigur haben. Ein Bespiel: Wenn mein Avatar stirbt, sollte ich nicht sagen müssen „na ja, da kommt der nächste“, sondern „ich hätte vielleicht doch in die andere Richtung gehen sollen“ oder vielleicht: „der Schutzschirm hätte geholfen“ (Phoenix).
Das Spiel sollte zum erreichen des Zieles – z.B. möglichst viele Punkte sammeln – die Entwicklung eigener Strategien unterstützen.
Rock tut das indem man es sich aussuchen kann möglichst viele der Diamanten zu sammeln (je nach Level werden mehr Diamanten angeboten als zur Lösung des Levels notwendig wären), möglichst schnell zu sein und damit einen hohen Zeitbonus einzuheimsen oder – die Königsdisziplin – Monster zu töten und damit richtig viel Bonuspunkte einzusacken. Deine Wahl, entscheide dich 🙂
So oder so, viel Spass!
PS: Es fehlen immer noch die Musik und ein schönes Titelbild. Ich arbeite daran…..
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.
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!
Eine PDF Version der Folien gibt es da (leider ohne die Filme): Vortrag Foliensatz
Das Video zum Vortrag kann man auf auf dem BlogSimulationsraum 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 🙂
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.
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.
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.
Vor einigen Monaten glaubte ich, ich habe es im Griff. Boot Programm geschrieben und siehe da, es lief anstandslos. Muss wohl ein Zufall gewesen sein.
Denn, es ist wohl nicht so einfach wie ich dachte! Internet durchstöbert und gesehen, ich bin nicht alleine. Um es nun kurz zu machen, dieser Artikel half:
Ist zwar für das Booten von Kassette gedacht, funktioniert aber genauso für die Disk. Der in meinem Artikel veröffentlichte Code, läuft wohl nur bedingt, warum weis ich noch nicht:
Hier sagen wir dem OS wieviele Sektoren zu lesen sind, wohin der Code ins RAM geschrieben wird und wohin nach dem Booten gesprungen wird – zur INIT Routine – Es folgt der BOOT- Continious Code, in diesem Fall wird einfach zum Start unseres Programms, hier tatsächlich die Fortsetzung des Boot- Prozesses – nämlich meine eigene Laderoutine. Zeichensatz, Titelbild und Hauptprogramm werden in den Speicher geladen!
Entscheidend ist die INIT- Routine, hier einfach durch RTS abgeschlossen. Die wird nach dem lesen der ersten 3 Sektoren aufgerufen. Danach folgt der BOOT Continious Code, in dem Fall der Beginn meines Programms….
Entwanzt und um den Titelbildschirm ergänzte Version meines Spieleprojektes. Nun noch die Boot- Routine und der Veröffentlichung steht nichts mehr im Wege.
Nun ja, bis 11.6.2013 – spätestens – muss ich das Teil auf die Menschheit loslassen. Da startet mein Vortrag in der Reihe „Shift – Restore – Escape“Dabei wird viel die Rede davon sein, welche Erfahrungen ich bei der Arbeit an dem Programm gesammelt habe und was mich dazu motiviert hat, nach über 20 Jahren wieder in die Programmierung des Atari 800 XL in 6502 Maschinensprache einzusteigen.
Nun, ich möchte nicht den Versuch unternehmen, dass am Beispiel bekannter Produkte aus der 8- Bit Ära zu erklären. Wohl aber möchte ich das am Beispiel meines eigene kleinen Spieleprojektes versuchen.
Tja, Photoshop o.ä. geladen, gezeichnet und im Spiel verwendet. Das Ergebnis hängt stark vom Talent desjenigen ab, der gezeichnet hat.
Wie war das denn in den Gründerjahren? Die netten kleinen Sprites wurden doch auch gezeichnet? Der Unterschied zum Hier und Jetzt bestand aber in den limitierten Ressourcen die eher grobe, mit wenigen Farben ausgestattete Bildschirm Protagonisten zum Ergebnis hatten. Talent konnte man hinter diesen Pixel- Haufen wunderbar verstecken oder es kam durch die beschränkten technischen Möglichkeiten erst so richtig zur Geltung!
Grafik wurde nicht gezeichnet, sondern programmiert.
Eine Spielfigur entsteht, von Hand
Das fertige Ergebnis meiner Bemühungen auf dem Bildschirm
Bevor ein Figürchen wie im Film oben auf dem Bildschirm erschien, hies es mit Papier und Stift zeichnen, rechnen und das Ergebnis in den Computer zu übertragen. Später gab es für so etwas Software- Tools, am Prinzip hat sich dabei aber nix geändert.
Farbe kommt durch geschicktes Kombination mehrerer Sprites ins Spiel, schaut mal da:
Tja und der Hintergrund? Pixel ja, aber in Portiönchen von 8 x 8 großen Bit- Matrizen, meist durch Manipulation des Systemeigenen Zeichensatzes in eigene Grafikzeichen verwandelt und dann, einem Puzzlespiel nicht unähnlich, zum Spielfeld zusammengesetzt. Ja, so war das Damals!
Typisches Spielfeld, zusammengesetzt aus manipulierten Zeichen des Systemzeichensatzes. Atari 800 XL, 64 kB RAM. Bildschirm: 2 Zeilen im Modus 1 am oberen Bildrand zur Textdarstellung , 11 Zeilen im Modus 13 für das Spielfeld. Farbwechsel zwischen Textanzeige und Spielfeld mittels Display List Interrupt. Vier mögliche Farben je Grafikzeichen im Spielfeld. Sechs Farben für die Spielfigur durch Kombination dreier Sprites (Atari Jargon: Player – Missile Grafik).
Sprites und manipulierte Zeichen des Systemzeichensatzes, diese beiden Elemente der Grafikdarstellung in Spielen, dass hatten beinahe alle Spiele der bekannten 8- Bit Systeme gemein. Der Spezielle Look des oben gezeigten Beispiels, aus meine Spieleprojekt „Diamonds“, alias „Rock“, entstand aus der Entscheidung einen bestimmten Grafikmodus – und damit eine bestimmte Bildschirmauflösung – zu verwenden.
Die Entscheidung wurde nicht etwa dadurch determiniert, dass dadurch – ästhetisch – das beste Ergebnis erzielt werden würde, sondern hatte handfeste technische Gründe. Doppelte Auflösung frisst mehr Rechenleistung, Speicher und setzt mehr Erfahrung beim Programmierer voraus. Beides fehlten mir. Der Atari hat nun mal nur 1,7 Hz, und ich lerne 6502 Maschinensprache.
Die Erkentnisse aus „6502 Lean Code durch sparsame Flags“ gleich ausprobiert. Spart einiges an Source Code und gewinnt damit mehr Speicherplatz für’s Editieren. Der Objekt Code wird ca. 12 Bytes kleiner. Schön!
Source, Projekt Rock. Stand: 9.4.2013
Die als Kommentar gekennzeichneten Zeilen können selbstverständlich entfallen. Was ehemals „MOVE“ hies und ein Byte verschwendete, wurde nun durch das Carry- Flag des 6502 ersetzt.
Schon Toll. Wir nähern uns einem Boulder Dash- alike, das nur knapp 2kB! RAM belegt.
RetroZock 