Das offizielle Blog der h8u.de Gemeinde

The demoscene: you can't put more "sub" into "subculture", still being "culture".

-- SvOlli

In der deutschen Wikipedia findet man bei der Suche nach "Demo" unter anderen Bedeutungen "eine Form der digitalen Kunst, in Echtzeit auf digitaler Hardware erzeugte multimediale Präsentation, siehe Demoszene."

Treffender kann man es in einem Satz wohl nicht beschreiben, und doch greift diese Beschreibung recht kurz, weil in einem Demo im Allgemeinen immer auch eine Attitüde mitschwingt, die man mit einer gewöhnlichen multimedialen Präsentation nicht vergleichen kann. Am besten lässt sich dies aus der (Entstehungs-)Geschichte heraus klären.

The microprocessor stack is normally located from FF on down, and variables are normally located from 80 on up (hoping the two never meet).

-- Meine Lieblingsstelle im offiziellen "Stella Programmer's Guide" von Steve Wright

Viele Dinge, die ich unbedingt noch bloggen wollte... das meiste hat einfach "keinen Termin" zu wann es fertig werden muss. Deshalb schiebe ich es gerade vor mir her... seit Monaten. Das hier muss aber rechtzeitig raus.

Nachdem ich nun meinen Workshop auf dem Hackover als "gelungen" ansehe, scheinen es auch andere Leute so zu sehen, so dass ich das Ganze nochmal machen darf. Zwei mal um genau zu sein.

Das eine Mal ist diesen Samstag, am 8.2. an der Humboldt Universität in Berlin. Dort habe ich diesmal richtig Zeit, so dass der Workshop in zwei Teile zerfallen wird. Vormittags gibt es die Folien, und ich erkläre den Beispiel Sourcecode. Nach dem Mittagessen gibt es dann "betreutes Hacken": wir versuchen zusammen ein einfache lauffähiges Demo zu schreiben. Also jeder für sich. Soweit ich weiß (Stand Donnerstag), sind noch 2-3 Plätze frei. Details zur Anmeldung gibt es auf den Seiten vom SimulationsRaum.

Der zweite Termin ist wieder auf der Revision in Saarbrücken. Allerdings ist es diesmal nicht ein faches, einstündiges Seminar (was ich letztes Mal eh fett überzogen hatte), sondern es wird einen kompletten Abend lang den Workshop geben. Mein Vorschlag, das schon am Anreisetag zu machen, an dem sonst recht wenig Programm stattfindet, wurde dankbar aufgenommen. Dort werde ich mich dem anders zusammengesetzten Publikum anpassen: der Workshop wird in zwei Teile zerfallen. Teil eins behandelt nur das nötigste Wissen über den Prozessor, und der zweite Teil beschäftigt sich dann mit der Programmierung der Spielekonsole an sich. Dieses Aufteilen ist durchaus sinnvoll, weil es in der Demoszene die Konzertration der Leute, die den 6502 Prozessor beherrschen, deutlich größer ist als im Rest der Bevölkerung. Das liegt daran, dass der Prozessor in vielen Homecomputern eingesetzt wurde, für die die Leute ohnehin Demos schreiben.

Es gibt nur eine Möglichkeit zu lernen. Und das ist durch Handeln.

-- Paulo Coelho, "Der Alchimist"

Nach meinen beiden Vorträgen über das Atari 2600 VCS auf dem 28c3 und der Revision 3.0 gebe ich demnächst wieder einmal den Erklärbär zu dem Thema "the most retro you can get without spending big bucks". Diesmal wird es ein Workshop im Rahmen der hackover vom 1.11. bis 3.11.2013 mit der Zielsetzung innerhalb von drei Stunden zum eigenen Atari 2600 VCS Demo zu kommen. Nichts Großes, aber immerhin ein eigenes hüpfendes Logo, oder was vergleichbares.

So yeah, make no mistake ... the 2600 was ALWAYS about who could show the coolest stuff
[...]
our motivation was to blow each other away .. plain and simple.

-- Rob Fulop, Creator Of Cosmic Ark

Neulich habe ich mal jemand komplett unbelecktem ein paar meiner Experimente auf dem Atari 2600 VCS gezeigt. Die interessanteste Rückfrage war wirklich die nach dem "Warum?". Ja, warum mache ich das eigentlich, warum machen das andere eigentlich? Einen Versuch die Antwort auf diese Frage zu finden, startet ja der Film "Moleman 2", der die ungarische Szene der Demoprogrammierer beleuchtet, das trifft aber auch bis auf Details auf die Szenen anderer Länder zu.

Allerdings je mehr ich darüber nachdenke, desto mehr komme ich einfach zu der Überzeugung, die sich mit sechs einfachen Worten beschreiben lässt: "das ist eine Form von Kunst". Warren Robinett, der Autor des Spiels "Adventure", hat mal ein Vorwort für das Buch "The Video Game Theory Reader" geschrieben. Er beginnt mit der Frage, wer in der "artistic food-chain" noch unter Videospielen rangiert: "Comic books? TV sit-coms? X-rated films?" Heute dürfte sich das doch etwas geändert haben, nicht zuletzt deshalb, weil zum Einen die Etats für die Videospielentwicklung sich mittlerweile mit denen Hollywood-Produktionen messen lassen. Zum Anderen aber auch, weil es mittlerweile Spiele gibt, die man durchaus als Kunst verstehen kann.

Carlotta war ein Ort für Leute mit ausgeprägt einfachem Geschmack. Abends kam auf den Tisch, was man tagsüber überfahren hatte.

-- Rigby Reardon, "Tote tragen keine Karos"

Ich plane gerade, ein neues Bankswitch-Schema für das Harmony Cartridge zu entwickeln. Das Modul besteht hauptsächlich aus einem ARM Microcontroller, den ich jetzt gerade zu programmieren versuche. Die bisherige Firmware dafür wurde mit der Entwicklungumgebung von Keil programmiert, die allerdings nur für Windows erhältlich ist. Meinen Teil möchte ich gerne mit der GNU Toolchain programmieren, um die Entwicklung unter Linux machen zu können.

Der Code besteht aus reinem ARM7TDMI Assembler, der direkt ohne ein Betriebssystem auf dem Microcontroller läuft. Eine Portierung sieht nicht so schwer aus. Mein größtes Problem ist dabei das Arbeiten mit dem Linker, für den ich ein eigenes Linker-Script entwickeln muss. Das Layout im Flash-Speicher des Microcontrollers soll so aussehen:

Startvektoren
Bootstrapcode
ROM Simulator
2600 ROM Daten

Der Bootstrapcode initialisiert den Microcontroller, kopiert den ROM Simulator ins RAM und startet diesen dann. Der holt dann bei Bedarf die Daten aus dem restlichen Speicher. Die Reihenfolge ist dadurch vorgegeben, das ein ROM-Image durch das Hintereinanderhängen von ARM Code und 2600 Code erzeugt werden soll.

Ja gern, aber das schaffst Du nie.

-- Jac! am Ostersonntag 2013 auf der Revision Party 3.0

Das war die Antwort, die ich von Peter aka Jac! bekam, als ich ihn gefragt hatte, ob ich sein Demo in einen Demopack mit integrieren könnte. Aber ich muss hier weiter ausholen: wie bereits geschrieben hatte, war ich über Ostern auf der Revision 3.0 Party. Von meinem Platz dort konnte ich auf einen C64 sehen, auf dem das selbe Demo in lief, wenn der Besitzer nicht am Platz war. Das Demo selbst war okay, allerdings war es auch etwas schade, dass immer das selbe lief.

Aber so etwas wollte ich für mein Atari 2600 VCS auch. Also habe ich mal das eine, mal das andere Demo gestartet, aber wenn das in einer Schleife lief, wurde es doch recht schnell langweilig. Also überlegte ich: ein Demo ist meistens 4k oder 8k groß, im Modul habe ich 32k zur Verfügung. Warum also nicht die Demos so in ein Modul packen, dass die Demos sich gegenseitig in einer Schleife aufrufen? Gut, man müsste die Demos etwas patchen, aber wenn ich eine Freigabe dafür bekomme, dann ist das in Ordnung.

Die Wiederholung ist die Mutter der Weisheit.

-- Russisches Sprichwort

Ich durfte wieder einen Vortrag über das Atari 2600 VCS halten... aber ich sollte anders anfangen.

Der Dreisatz, den man in der Schule lernt ist bestenfalls die halbe Wahrheit. Solche Aufgaben, wie: "Wenn zwei Arbeiter 6 Tage für einen Tisch brauchen, wie lange brauchen dann drei?" Gegenbeispiel aus der Praxis: SvOlli braucht für einen Vortrag mit 90 Folien 60 Minuten. Davon schmeißt er die Hälfte weg, entwirft noch ein paar neue, kommt dann auf 60 Folien. Wie lange braucht er für diesen Vortrag? Richtig: 60 Minuten.

PHP steht für pupertierende Hauptschüler programmieren.

-- Eine beliebte Erklärung, glaub man Google

Vor ein paar Tagen habe ich eine schonungslose Abrechnung mit der Programmiersprache PHP gelesen. Sie ist lang, hervorragend argumentiert, und hinterlässt nicht den Funken einer Hoffnung, dass sich da noch was reparieren lässt. Außerdem ist sie auch noch recht gut geschrieben, so dass das Lesen auch Spaß macht.

Das Ökosystem PHP wird auf allen Ebenen zerlegt: in allen Facetten der Sprachdefinition genauso wie die Standardbibliothek, also die Funktionen, die mitgeliefert werden. Auch so ziemlich jedes "aber"-Argument wird genauso zerlegt. Ein kurze Kostprobe will ich mal übersetzen: das Argument "ein guter Programmierer kann in jeder Programmiersprache guten Code schreiben" wird meiner Meinung nach korrekt auseinandergenommen mit: "Ein guter Handwerker kann einen Nagel entweder mit einem Stein oder einem Hammer einschlagen, aber wie viele Handwerker sieht man, die auf Nägel mit Steinen einschlagen? Ein Teil von dem, was einen guten Entwickler ausmacht, ist die Fähigkeit die richtigen Werkzeuge auszuwählen."