SimulationsRaum Rotating Header Image

Porgrammiersprachen

/\///\\/\\\///\/\/\\\/\

Ian Bogost und Nick Montfort, die 2009 mit einem Buch über die Atari-VCS-Konsole die “Platform Studies” als neue (Inter)Disziplin zwischen Technikgeschichte, Informatik, Kunst und Game Studies eröffnet haben, kündigen für November ein neues Buch an: Der Titel “10 PRINT CHR$(205.5+RND(1)); : GOTO 10” sagt im Prinzip schon, worum es gehen soll: Eine Zeile C64-BASIC, die zufallsbasierte Blockgrafik auf den Bildschirm bringt, bietet den Anlass zu wissenschaftlichen Reflexionen der Herausgeber und ihrer Autoren über computererzeugte Zufallszahlen, die Geschichte von Labyrinthen, BASIC als Programmiersprache, den Commdore C64 usw. Das Buch kann bereits jetzt bei Amazon vorbestellt werden.

»Greeting to all Z80 programmers«

Rodnay Zaks hat heute eine kleine Grußbotschaft für das demnächst erscheinende LOAD-Magazin gesandt – angeblich, nachdem er von meinem Artikel über den Z80-Workshop erfahren hat. :-)

BattleCode

Gestern habe ich Kontakt mit Christopher Cantrell aufgenommen, der die Website Computer Archaeology betreibt. Dort analysiert er alte Computerspiele und fertigt kommentierte Disassembles davon an. Auf meine Frage, ob er nicht ein Disassemble von “Battle Zone” habe, hat er prompt eines angefertigt, das in der nächsten Zeit auskommentiert wird. Ich bin ja immer noch sehr an der Gestaltung der Treffer-Sequenz des Spiels interessiert. Künftig werde ich mit Christopher wohl regeren Austausch pflegen.

Neun Zeilen Code

BasicProgrammingBox

Als Homecomputer Ende der 1970er-Jahre anfingen, den Spielkonsolen langsam den Rang abzulaufen, verfuhr der bis dahin unangefochtene Marktführer Atari zweigleisig: Zum Einen entwickelte man eine eigene Homecomputer-Serie, die ihre Wurzeln allerdings in der Spielkonsolen-Technologie behalten sollte (alle 8-Bit-Atari-Computer behielten ihren Modul-Slot an der Oberseite, für den es etliche Spielmodule gab). Zum Anderen erstellte Warren Robinett 1978 für die massenhaft verkaufte “Atari 2600″-Spielkonsole ein “BASIC Programming”-Modul*:

Aufgrund des extrem kleinen Konsolen-RAM-Speichers von nur 256 Byte und der fehlenden Tastatur waren die Möglichkeiten dieses Programmiersystems natürlich beschränkt. Die Eingabe der Befehle erfolgte über zwei aneinander steckbare “Keyboard Controller” (Atari CX-50). Zusammen mit dem BASIC-Modul wurden dazu Overlay-Folien angeboten, die die Tasten des rechten Controllers mit alphanummerischen Zeichen beschrifteten und die des linken Controllers mit Befehls-Shortcuts und einer Programm-Ablaufsteuerung:

Der minimale Speicher machte es nötig, (im Vergleich zu zeitgenössischen anderen Dialekten} mächtige BASIC-Befehle auf dem Spielmodul-ROM anzubieten, damit die VCS-Konsole mit einer möglichst turingvollständigen Programmiersprache aufwarten konnte. Jedes Programm durfte nämlich nur maximal neun Zeilen lang sein. Deshalb gab es Befehle, die – ähnlich bei verschiedenen Assemblern – mehrere Funktionen gleichzeitig innehatten. Beeindruckend lässt sich dies an einer sechszeiligen(!) Version des Pong-Spiels mit Grafik- und Sound-Ausgabe verdeutlichen, dessen Listing im Handbuch des Moduls zu finden ist:

1 Hor 2!Hor 2+Key
2 If Ver 1>90 Then Ver 1!88
3 If Hit Then Ver 1!9
4 Ver 1!Ver 1+If Ver 1 Mod 2 Then 8 Else 92
5 Hor 1!Hor 1+7
6 Goto 1

Atari selbst plante bezüglich des Eingabemediums offenbar mehrfach, eine eigene, separate Tastatur für die “VCS 2600″-Konsole herauszubringen; es blieb jedoch bei Prototypen. Anstelle dessen wurden Zweitanbieter aktiv: Von SpectraVideo (Universum) gab es eine Tastatur namens “Compumate SV-010“, die jedoch – anders als die CX-50-Controller – nicht an den Joystickports der Konsole angeschlossen wurde, sondern am Modul-Schacht. Der Grund dafür war, dass dieses Gerät nicht als Ergänzung zum BASIC-Modul gedacht war, sondern ein eigenes Programmiersystem darstellte: Es beinhaltete ein 16 KB BASIC-ROM, zusätzliche 1,75 KB RAM sowie eine Schnittstelle für einen Datenrekorder zum laden und speichern der Programme. Letzteres fehlte dem BASIC-Modul, womit es – wie schon die “Odyssey II” (bzw. “Philips G-7000“) nur sehr bedingt zum Progammieren geeignet war. Na gut: Neun Zeilen Code sind schnell wieder eingetippt.

Ich habe mir das Modul, die Beschreibung und die Keyboard-Controller gekauft. Was mir noch “fehlt”, sind die Tastaturfolien, die ich in Kürze nachbasteln werde. Dann stelle ich hier ein paar Screenshots mit Programmbeispielen ein und drehe vielleicht auch mal ein kleines Video, das die Funktionalität des o.g. Pong-Programms vorführt.

*Nicht zu verwechseln mit dem jüngeren Entwicklungssystem BATARI BASIC!

Wenn du zu deinem Heimcomputer gehst, vergiss die Peitsche nicht

img033

Ich habe jüngst drei Bücher vom W.-Hofacker-Verlag erstanden, bei denen es mir – ehrlich gesagt – nur in zweiter Hinsicht auf den Inhalt ankam. Dabei handelt es sich um folgende Titel:

Die Sammlung wird ausgebaut …

Ball in a Box

IMG_0907

Als Vorstudie zu unserer “Tennis for Two”-Implementierung auf dem Analogcomputer Telefunken RA742 haben wir heute die Schaltung eines “Ball im Kasten” nach Anleitung gesteckt, nachdem wir die Schaltung zunächst mathematisch und physikalisch analysiert hatten. Verzichtet haben wir auf eine Darstellung des Balls als Kreis, was die ohnehin schon recht komplexe Schaltung etwas vereinfacht hat. Am Ende wird der “Tennis-Ball” im Spiel ohnehin als Punkt dargestellt werden. Vielleicht lassen sich die so freigewordenen Ressourcen (Operationsverstärker und Eingänge des Oszilloskops) dann für eine Darstellung des Spielfeldes verwenden.

Hier die fertig gesteckte Spielschaltung:

(Zum Vergrößern anklicken)

Auf der linke Seite befinden sich zumeist Elemente der y-Darstellung des Balls. Dazu gehört der Betrag einer abnehmenden Schwingungsgleichung. Die Abnahme des Hüpfvorgangs wird durch die Gravitationskonstante sowie die Koeffizienten, die die Impulsgleichung ergeben (Ballmasse und -härte), bestimmt. Auf der linken Seite finden sich zumeist Schaltungen, die für die x-Ausrichtung des Balls verantwortlich sind. Hier sind die begrenzenden Faktoren die Elastizitätskoeffizienten, die den Flug bremsen, wenn der Ball gegen die Wand (links oder rechts) prallt, sowie eine Konstante für den Luftwiderstand. Die einzelnen Koeffizienten (Spielvariablen) lassen sich mit Trimmpotenziomentern einstellen. Es ist also gar kein Problem ein Tennisspiel mit einem Ball, der so schwer wie eine Kanonenkugel ist, auf dem Mond zu simulieren.

Morgen testen wir die Schaltung (indem wir sie am Oszilloskop anschließen) und verbringen den Tag mit Debugging. Im letzten Block werden wir dann auch dem Ball in der Kiste ein Tennisspiel bauen, bei dem die Schläger durch an Kabelfernsteuerungen realisierten Tastern simuliert werden und die Schlagstärke durch Trimmpotentiometer eingestellt wird.

Insider-Informationen

 

Pagetable

Auf dieses Blog möchte ich dann doch mal hier, zentral hinweisen (und nicht bloß in meiner Blogroll): Pagetable.

Dort beschäftigt man sich seit ein paar Jahren mit “trivia, tricks, puzzles and whines about assembly language”, wie es heißt. Es findet sich eine unglaubliche Menge an detaillierten Auseinandersetzungen mit der Retro-Computer-Technik, insbesondere Commodore-Computern, die von Anekdoten bis hinunter auf die Assembler-Ebene reicht. Das Blog gehört in jede gut sortierte Link-Liste einschlägiger Webseiten!

Mit ELAN die Hardware vergessen (machen)

Als ich 1987 von der Haupt- an die Berufsschule in eine Wirtschaftsklasse wechselte, gab es dort (endlich!) auch einen richtigen Informatik-Unterrricht, in dem Programmieren gelehrt wurde. (In meiner vorherigen Schule gab es zwar eine “Computer-AG”, in der wurden allerdings lediglich an C64-Computern mit Bernstein-Monitoren BASIC-Listings aus dem Benutzerhandbuch abgetippt). Nun, an der Berufsschule, sollte die Sache aber ernst werden. Dazu hatte man in einem EDV-Raum ein Master-Slave-System, bestehend aus Olivetti M20 und M24 aufgebaut. Das Betriebssystem, das auf den Geräten lieft, hieß EUMEL und die Programmiersprache, die unterrichtet wurde, war ELAN … Gestern habe ich nun günstig ein ELAN-Handbuch erstanden und gleich einmal angefangen, darin herumzulesen.

(weiterlesen …)

Errors: OUT OF DATA / Out of date

img024

Kürzlich habe ich bei ebay “gefühlte 100.000 Programme” auf Kassette für den Sinclair ZX Spectrum erstanden. Erfreulich war nicht nur der sehr gute Zustand der Bänder, sondern auch, dass deren Inhalt vollständig dokumentiert war. Mit im Paket lag dazu ein kleines, rotes Ringbuch, das den Katalog der Software enthielt … aber noch mehr! Auf einigen Seiten fanden sich mit Bleistift geschriebene Programmlistings und Hardware-Schemata. Der Schrift nach zu urteilen und der Tatsache, dass der “U880″ mehrfach Erwähnung findet, dürfte es sich beim Vorbesitzer wohl um ein Kind oder einen Jugendlichen der späten DDR gehandelt haben.

Der Grund, warum ich das erwähne, ist aber, dass die meisten dieser Blätter handgeschriebene BASIC-Programme enthalten. (Das erinnert mich an meine eigenen Anfänge 1982/3, in denen ich nur alle 2-3 Wochen einmal am Wochenende Zugriff auf einen TRS-80-Clone hatte und in der Zwischenzeit meine Programme dafür auf Papier entworfen habe.) Unter den Listings findet sich auch das Folgende:

Ein Programm, das auf keinem BASIC-Interpreter so funktionieren dürfte, wie der junge Autor es sich gedacht hat. Der Hintergrund dieses Programmierfehlers ist allerdings historisch interessant. Das 1962 am Dartmouth-College ursprünglich veröffentlichte BASIC war nicht interaktiv konzipiert. Das heißt: Man konnte keine Programme schreiben, die einem später beim Ablauf nach Eingaben fragten, welche dann durch das Programm verarbeitet wurden. Den Ausweg dafür boten die Befehle DATA und READ. Mit DATA ließen sich innerhalb des Programmcodes Daten in serieller Reihenfolge ablegen, die dann beim Ablauf des Programm mit READ wie von einem Stapel abgerufen und verarbeitet werden konnten.

Der Befehl INPUT kam erst in späteren Revisionen von BASIC hinzu und “interaktivierte” die Programmiersprache durch eine Eingabeschnittstelle (Vgl. BASIC-Kapitel in Wexelblatt). Das obige Programm versucht nun quasi in den Zeilen 10 bis 40 den DATA-”Stack” interaktiv mit INPUT-Eingaben von Zahlen zu füllen. In der Zeile “30 DATA Z” glaubt der Autor, mit der Variable Z Daten in den “Daten-Speicher” zu schreiben, obwohl DATA ja eben Daten im “Programm-Speicher” ablegt. Es wird also nicht ein Wert durch die Variable Z in den Programmcode hinein geschrieben, sondern eben nur ein “Z”.

Das dürfte der Autor im zweiten Teil des Programms, indem er die zuvor eingegebenen Daten wieder auslesen und darstellen lassen wollte, schnell festgestellt haben. Es dürfte sich ein “OUT OF DATA”-Error ereignet haben, weil einfach keine 6 DATA-Werte vorhanden sind, sondern nur einer (“DATA Z”). Die FOR-NEXT-Schleife bricht also nach dem ersten Durchlauf mit einem Fehler ab.

Erstaunlich finde ich, dass der Autor ohne Kenntnis der Entwicklungsgeschichte der Sprache hier intuitiv auf den Widerspruch gestoßen ist, dass es zwei ganz unterschiedliche Daten-Eingabe-Konzepte in BASIC gibt (ein passives und ein interaktives), die beide zugleich gar nicht nötig wären, wenn man das (modernere) interaktive Konzept zusammen mit der (von Beginn an vorhandenen) Möglichkeit, Variablen zu indizieren/dimensionieren nutzt (also im ersten Programmteil einfach Z(1) bis Z(6) mit Daten füllt. Aufgrund dieser Möglichkeit ist das DATA-READ-Konzept in moderneren BASIC-Varianten dann oft zu einer bloßen Möglichkeit “verkommen”, Maschinensprache(unter)programme innerhalb des BASIC-Programms abzulegen.

Übrigens: Schon seine Programme auf Papier zu entwerfen, um sie erst später in den Computer einzugeben, widerspricht der Philosophie von BASIC, das ja eben angetreten war, um den Programmierer aus der Lochkarten-Operator-Tyrannei zu befreien. Dennoch äußert sich BASIC-Mitentwickler Kurtz heute wohlwollend über solche Programmierer, die ihren Code nicht dauernd testen, sondern erst einmal fehlerfrei entwerfen – denn auch dabei sollte BASIC helfen. (Vgl. BASIC-Kapitel in Warden/Biancuzzi).

  • Richard L. Wexelblatt (ed.) History of Programming Languages. New York: Academic Press, 1981.
  • Federico Biancuzzi, Shane Warden: Visionäre der Programmierung: Die Sprachen und ihre Schöpfer. Köln u.a.: O’Reilly 2009.