Archiv der Kategorie: Projekt Rock

Shift – Escape – Restore zum nachlesen

Shift – Escape – Restore ist der Name eine Vortragsreihe die im Sommer 2012 an der Berliner Humbolt Universität stattgefunden hat. 

Mehr als einem Duzend 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 zu entdecken.

image

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.

Das Buch kann direkt beim Verlag vorbestellt werden:
CSW Verlag, Shift – Restore – Escape

Mehr zu dem Projekt aus dem der Vortrag und schließlich der Artikel entstanden sind, kann man hier im Blog nachlesen:
Projekt Rock

Und last, but not least, hier gibt es das Video zum Vortrag selbst:

 

 

 

 

Advertisements

Computerspiele analysiert….

…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).

9_Ablauflogik

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.

Diskussion erwünscht 🙂


Es rockt wieder..

Ich habe den guten alten 6502 in der letzten Zeit etwas vernachlässigt. Für mein kleines Spieleprojekt gilt das selbe.

Abgelenkt hat mich dieses Projekt:
https://retrozock.com/2013/11/13/neocrome-atari-8-bit/

Titelbild für "Rock". Ein erster EntwurfEigentlich 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 🙂

Bildschirmfoto 2013-12-02 um 20.32.44


Die Highscore Jagd kann beginnen…

Ein Spielchen macht warscheinlich mehr Spass, wenn man seine High Score mit anderen teilen kann.

Rock speichert seit heute die jew. erreichte Höchstpunktzahl!

Wie? Schau mal hier.

Bildschirmfoto 2013-07-07 um 22.07.01

Schau an, schau an. rechts oben sehen wir, wie gut der Vorgänger war.

Noch ein paar Gedanken zum Thema: Wann machen Arcade Games Spass?

Quelle: The Making of Karateka, Jordan Mechner

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…..


Atari im Rausch der Farben

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. Der Effekt entsteht mittels DLI.

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!

Bildschirmfoto 2013-06-17 um 22.50.08

Ab dem Label „FG“ beginnt der Teil der DLI- Routine die den Regenbogeneffekt erzeugt.


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.


Atari Boot Sektor, Update….

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:

http://wiki.strotmann.de/wiki/Wiki.jsp?page=Boot%20from%20Cassette

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:

https://retrozock.com/2012/05/21/boot-sektoren/

So geht’s:

Bildschirmfoto 2013-05-30 um 18.54.12

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....

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….