Asteroidenschauer in der Universität

Gestern hatte ich wieder das Vergnügen einem wirklich tollen Vortrag aus der Reihe Shift – Restore – Escape an der Humboldt Universität in Berlin beizuwohnen. Das Thema des Vortrags von Norbert Kehrer war:

Emulation des Spieleklassikers Asteroids für Homecomputer

Asteroids ist einer der absoluten Spielhallenklassiker, den Atari im Jahre 1979 herausgebracht hat. Es handelt sich um einen Weltraumshooter, der neben seinerzeit sehr innovativen Steuerung vor allem durch die präzise grafische Darstellung brilliert. Im Gegensatz zu den seinerzeit üblichen Rastermonitoren mit bescheidenen Auflösungen um 129 x 240 Pixel, zeichnet dieser Monitor die Umrisse der Spielfiguren ähnlich wie ein Oszilloskop direkt nach. Statt Pixel sieht man gestochen scharfe Linien.

Das Spiel ist natürlich bereits zigfach auf allen denkbaren Plattformen – erst recht auf dem Atari 800 und dem Commodore64 – nachprogrammiert worden. Eine besonders gelungene Adaption ist das Spiel Minestorm, dass in die 1982 erschienene Spielkonsole Vectrex fest eingebaut war. Das Vectrex hatte ebenfalls einen Vektorbildschirm.

Minestorm auf Vectrex

Authentizität durch Originalsoftware

Was den Ansatz von Norbert Kehrer so interessant macht, ist, dass er sich weder um eine Nachprogrammierung, noch um eine Emulation handelt, sondern, dass er den originalen Programmcode des Automaten auf dem Atari 800 zum Laufen gebracht hat, was ein nahezu authentisches Spielgefühl beschert.

Asteroids auf Atari 800XL

Das ist nur deshalb möglich, weil der Spielautomat einen 6502 Prozessor verwendet – genau wie die Heimcomputer von Atari und Commodore. Die Taktgeschwindigkeit ist vergleichbar und der Programmcode hat die bescheidene Grösse von 6KB. Norbert Kehrer ging detailliert auf die Gemeinsamkeiten und Unterschiede der Plattformen ein.

Spezifikation von Asteroids

Der Hauptunterschied ist natürlich die vollkommen andersartige Bildgenerierung, denn die Heimcomputer wurden an Fernsehern betrieben und hatten daher eine Rasterdarstellung.

Raster und Vektorgrafik im Vergleich

Eine theoretische Möglichkeit wäre, die Vektoren auf den Rasterbildschirm umzurechnen und linienweise zu zeichnen, wie es z.B. M.A.M.E. macht. Leider sind die kleinen Heimcomputer dafür bei weitem zu langsam. Kehrer hat den Gameloop an der Stelle gepatcht, wo der Bildschirmrefresh aufgerufen wird und ersetzt die Vektorlogik durch eine Bilderzeugung per Softwaresprites. Doch selbst das gelingt nur, weil bestimmte Positionen der Objekte vorberechnet im vergleichsweise großzügigen Hauptspeicher der Computer abgelegt sind.

Asteriods - gefühlsecht

Das Ergebnis ist beeindruckend nahe am Original. Kein Wunder – es IST ja tatsächlich das Original.

Weitere originelle Projekte, wie die Emulation einer PDP8 auf dem Atari 800(!) finden sich auf der Homepage von Norbert Kehrer: Norbert’s Emulators.

Schnell mal nach Fulda…

Am Freitag fuhr ich geschäftlich nach Fulda zu einem kleinen aber feinen eCommerce Workshop. Über den möchte ich aber nicht berichten, sondern lieber um das Drumherum.

Spass mit der Bahn

Dass bei der Bahn eigentlich nie etwas richtig funktioniert ist ja zu erwarten – speziell wenn es warm ist und noch spezieller, wenn einige Hauptstrecken aufgrund von Hochwasserschäden gesperrt sind. Tatsächlich wurde ich auch nicht enttäuscht.

Geplant war, mit dem ICE von Berlin Hauptbahnhof direkt nach Fulda zu fahren – was auch tatsächlich funktioniert hat. Nur das “wie” war mal wieder interessant. Laut Fahrplan sollte die Abfahrt 7:35 am Hauptbahnhof sein und bei einer ungefähren Fahrzeit von 2,5 Stunden über die Schnelltrassen in Richtung Westen bis Hildesheim und von dort in Richtung Süden bis Fulda führen. So hätte ich locker den Beginn des Wokshops um 10:30 geschafft.

Tatsächlich geschah folgendes: Ich komme rechtzeitig zum Bahnhof und informiere mich an den Hinweistafeln, ob es Probleme mit dem gebuchten Zug gab. Kein Hinweis – alles gut. Nur der Zug steht nicht an der Anzeigetafel am Bahsteig 14. Auf Nachfrage kommt heraus, dass der Zug auf Gleis 2 abfahren wird. Das bedeutet, dass der Zug nicht oberirdisch in Richtung Westen abfährt, sondern 30 m tiefer im Untergeschoss in Richtung Süden. Der eigentliche Witz ist aber, dass die Abfahrtzeit 30 Minuten vorverlegt wurde, was ich 5 Minuten vor der planmässigen Abfahrtzeit mitbekomme. Spitze!

Aber die Bahn wäre ja nicht die Bahn, wenn sie nicht massiv Verspätung hätte. In diesem Fall 40 Minuten. So bekam ich trotzdem locker den Zug. Die Klimaanlage ist auch nicht ausgefallen und da für mich freundlicherweise sogar erster Klasse gebucht war, verlief die Fahrt angenehm ruhig und komfortabel.

Spannend war die Strecke. Nach ungefähr einer Stunde schaute ich aus dem Fenster und sah, dass wir gerade an der Leipziger Messe vorbeifuhren und dann scharf rechts auf eine Nebenstrecke abbogen. Aha?

Den Rest der Fahrt kann ich nur unter der Überschrift “Die schönsten Nebenstrecken in Sachsen, Thüringen und Hessen” beschreiben. Durchaus malerisch, aber sehr langsam! Um 12:00 kam ich dann in Fulda an.

Das Schlosshotel

Malerisch ging es dann auch weiter, weil das Seminar und die Übernachtung im Schlosshotel gebucht war. Nun bedeutet der Name “Schlosshotel” ja in der Regel, dass sich das Hotel in fussläufiger Entfernung zu irgendeinem ehemaligen Adelssitz befindet. Nicht so in Fulda. Das Hotel ist tatsächlich das Schloss – naja, zumindest die ehemalige Orangerie. Seminarraum und Zimmer waren zwar in einem modernen Anbau untergebracht, aber Abendessen im Restaurant in den Kellergewölben oder Frühstück im Barocksaal mit Deckengemälde haben schon was!

Schlosshotel in Fulda

Restaurant Dianakeller

Frühstück im Apollo Saal

Deckengemälde im Saal

Vermeidbare Patzer

Leider entsprach der Service nicht ganz dem hochwertigen Ambiente. WLAN war im ganzen Hotel nicht verfügbar, so dass der Konferenzraum hässlich mit Ethernetkabeln verschandelt werden musste. Wenn man einen Seminarraum mit Verpflegung bucht und dann abgezählte, kleine Hefekuchenstückchen zum Kaffee bekommt ruft das bei mir ebenfalls Stirnrunzeln hervor.

Abends im Restaurant freut man sich über eine übersichtliche, aber Hochwertiges versprechende Speisekarte. Jedoch geht mitten in der Bestellung ein Gericht nach dem anderen aus, so dass ich letztlich keines der vier Gerichte bestellen konnte, auf die ich Appetit gehabt hätte. Nichts gegen Lammkarree, aber das wollte ich eigentlich nicht haben. Diese Knappheit der Speisen ist umso unverständlicher, als wir die Gruppe zu 20:00 angemeldet hatten.

Geweckt wurde ich am nächsten Morgen übrigens durch eine Hotelmitarbeiterin, die einfach in das Zimmer kam. Natürlich hat sie sich entschuldigt und hat sofort kehrt gemacht.

Sicherlich ist das alles kein Beinbruch, aber diese leicht vermeidbaren Patzer passen einfach nicht richtig ins Bild. Insofern kann ich das Hotel moment nur mit Vorbehalt empfehlen. Ein etwas aufmerksameres Management hätte den Aufenthalt perfekt gemacht. Es sei noch erwähnt, dass das Frühstück dann immerhin schmackhaft und sättigend war.

Sonstiges

Die Rückfahrt mit der Bahn war problemlos, aber leider auch wieder sehr langsam.

Das Wesentliche ist, dass der Erfahrungsaustausch im Workshop offen und konstruktiv war zu zu einer erstaunlichen Initiative geführt hat – aber davon wollte ich ja nicht erzählen… ;-)

Fassungsloses Schweigen

Heute. Kein Text.

Wunderschön

Darss. Entspannen, spazieren gehen, ordentlich ausschlafen. So wie es der Arzt verschrieben hat. Leider viel zu kurz.

Seebrücke Prerow

Strand

Kleines Hexenhaus

Bootshäuser

Bodden - bedrohlich

Steinschlag – mit 8Bit

Am Dienstag dieser Woche konnte ich wieder einen interessanten Vortrag aus der Reihe “Shift-Restore-Escape” an der Humboldt Universität hören. Das Thema:

Vom Wiedereinstig in die 8 Bit Welt – Die Programmierung eines Spiels für Atari Computer

Bevor der Vortrag begann, gab es zur Einstimmung ein paar astreine Chiptunes zu hören. Mein Eindruck war, dass sich der Sound gar nicht so sehr vom SID des Commodore 64 unterschied. In seiner Anmoderation erwähnte Stefan Höltgen dann zu meinem Erstaunen, dass die Musik vom TIA – also dem Grafikchip des Atari erzeugt wurde.

Berthold Fritz, Jahrgang ’69, begann seinen Vortrag damit, dass er die Motivation, heutzutage ein Spiel für den 30 Jahre alten Atari Homecomputer zu programmieren, darlegte. Den Entwicklungsprozess hat er in seinem Blog retrozock.com begleitend beschrieben.

Motivation

Fritz begann mit der Feststellung, dass er im Laufe der Zeit – von Heimcomputern über 16 Bit Rechner bis zu heutigen PCs immer mehr zum reinen Bediener und Konsumenten degradiert ist. Er war damit unzufrieden und wollte sich Wissen um die Funktion der Rechner erarbeiten. Die heutigen Rechner sind mit ihrer Komplexität, Mächtigkeit und zahlreichen API und Abstarktionslayern allerdings nicht gut geeignet. Daher erinnerte er sich an den Atari 800XL aus seiner Jugend.

Atari 800 XL von 1983

Die Frage was denn nun genau zu programmieren ist, war schnell beantwortet: Ein Spiel. Und zwar ein Spiel mit einfacher und bewährter Spielmechanik, bei der der Spass nicht unbedingt von umwerfender Grafik abhängt. Das Spiel Dirt, Rock, Diamonds and other Perils ist ein Nachbau des beliebten und of kopierten Boulder Dash. Der Entwicklungsprozess dauerte ca. 2 Jahre und ist noch nicht völlig abgeschlossen, da das Spiel zum Beispiel noch keine Musik hat.

Programmiersprache und Werkzeuge

Die Wahl der Programmiersprache wurde schnell entschieden. Die ersten Versuche, einen Spielbildschirm mit 800 Bytes in Basic aufzubauen führten zu dem erwarteten Ergebnis: Es ist viel zu langsam (ca. 3 Sekunden). Derselbe Algorithmus in Assembler schaffte das in weniger als einer 50stel Sekunde.

Die Frage, welche Werkzeuge zu verwenden sind, war bereits schwieriger. Soll es Crossdevelopment auf Macintosh mit einem Atari Emulator (Atari800MacX) sein oder soll direkt auf der Zielplattform entwickelt werden? Welcher Assembler mit welchem Vorgehen ist zu bevorzugen?

Fritz entschied sich dafür, direkt auf dem Atari zu entwickeln und zwar so, dass Sourcecode, Assembler und Objektcode gleichzeitig im Spiecher vorgehalten werden. Das ist komfortabel, schränkt jedoch die maximale Grösse des Programms stark ein. Das Spiel wurde letztlich ca. 5 KB gross.

Vom Werden und Wachsen

Die paar Befehle des 6502 Prozessors sind schnell gelernt, eine Memory Map hervorgeholt und los geht die Entwicklung. Die ersten Gehversuche sind noch völlig ohne Grafik und dienen der Überprüfung der Spielmechanik.

Spiel ohne Grafik

Nachdem hier die ersten Probleme gelöst wurden, kam handcodierte Grafik hinzu. Jetzt kann man schon das eigentliche Spiel erkennen. Die Farbigkeit hat mich sehr an DigDug erinnert.

Spiel mit erster Grafik

Manchmal ist selbst Maschinensprache nicht schnell genug – insbesondere wenn man innerhalb der Spiellogik mit verschachtelten Schleifen hantiert. Das Thema Code Optimierung kam daher im Vortrag nicht zu kurz. Drei oder vier gesparte Taktzyklen machen sich sehr bemerkbar, wenn die betreffende Stelle mehrere tausend mal pro Sekunde durchlaufen wird.

Code Optimierung

Obwohl das eigentliche Ziel bei der Spielentwicklung der Erkenntnisgewinn war und es nur an zweiter Stelle darum ging, ein tolles Spiel zu bauen, kann sich das Ergebnis absolut sehen lassen.

Das - fast - fertige Spiel

Nach dem sehr gelungenen Vortrag ging es dann anschliessend in etwas verkleinerter Runde in ein Restaurant, wo weiter gefachsimpelt wurde. Ein rundherum gelungener Abend.

Halbtagstourismus, Massenchillen, Robinien, Wasser und Weitblick

Während halb Deutschland mit Hochwasser kämpft, war in und um Berlin ein wunderschönes, erholsames Wochenende zu vermelden. Da mein schlechtes Gewissen auch niemandem hilft, habe ich mich entschieden, die beiden Tage einfach zu geniessen.

Samstag: Der Halbtags-Tourist

Am Samstagnachmittag habe ich mich mal wie ein Tourist in meiner eigenen Stadt gefühlt. Ein kleiner Rundgang durch Mitte machte es möglich. Ich wollte eigentlich nur auf einen Sprung in die Humboldt Universität und bin am Lustgarten ausgestiegen, der durch ganze Heerschaaren von Touristen belagert war.

Berlin Lustgarten: Touri-sit-in

Normalerweise nervt mich der ganze Rummel mit gaffenden Horden, die einem planlos vor die Füsse latschen, Strassenmusikanten und so weiter. Aber gestern war ich in der passenden Stimmung und habe mir sogar den Chor angehört, der vor dem Bodemuseum sang und die Tangotänzer im Monbijoupark angesehen. Mit etwas gelassenem Abstand kann ich sogar verstehen, warum die Touristen Berlin toll finden. Irgendwann war es aber dann doch genug. Zum Abendessen habe ich wieder den netten, leckeren und preiswerten Italiener bei mir im Viertel aufgesucht.

Chor vor Bodemuseum

Tango im Monbijoupark

Massenchillen an der Spree

Sonntag: Schorfheide

Sonntag lockte morgens gleich die Sonne – also auf zum Werbellinsee. Erstaunlicherweise gab es heute kaum Verkehr und auch nur wenige Badegäste. Tiefenentspanntes brutzeln war also angesagt. Nachmittags zog es mich dann noch weiter nach Joachimsthal, wo ich mir zunächst einmal einen famosen Überblick auf dem alten Wasserturm verschaffte. Im verschlafenen Stadtkern (mir sieht der Ort eher nach Dorf aus, aber man hat Stadtrecht), gab es dann noch lecker Rhabarberstreuselkuchen, bevor es gemütlich zurück nach Berlin ging.

Joachimsthal - Alter Wasserturm

Joachimsthal - Grimnitzsee

Kirche von Schinkel

Genau für solche Tage habe ich ein Cabrio: Offen und entspannt durch schöne Landschaft cruisen, die Vögel im Wald zwitschern hören und sich vom umwerfenden Duft der Robinien fast betäuben lassen.

Ge-ni-al!!!

Das Abendessen – Spargel mit Schinken und als Apperetiv einen selbstgemachten Holunderblütenlikör – sorgte für den passenden Ausklang eines sehr schönen Wochenendes.

Onlineshops – Geschwindigkeit versus Flexibilität.

Ladegeschwindigkeiten und Spitzenlastfähigkeit sind zunehmend wichtige Eigenschaften von Onlineshops. Gründe dafür sind steigende Besucherzahlen, Änderungen am Google Pagerank, nachweislich steigende Abbruchquoten bei längeren Ladezeiten und Lastspitzen z.B. durch Fernsehwerbung.

Need for speed

In den letzten 12 Monaten sind daher viele grosse und mittlere Onlineshops dazu übergegangen, Full-Page-Chaching einzusetzen. Der Erfolg der Bemühungen kann sich sehen lassen. Noch vor einiger Zeit waren Ladezeiten von 3-6 Sekunden für eine Kategorie- oder Artikeldetailseite eines durchschnittlichen Onlineshops normal. Anbieter, die bereits die Ladezeiten ihrer Shops optimiert haben verblüffen hingegen (falls es die eigene Internetanbindung hergibt) mit Ladezeiten von zum Teil unter 1,5 Sekunden – inklusive aller Bilder und Skripte wohlgemerkt. Die HTML Seite alleine ist meist schon nach 100ms ausgeliefert.

Ist nun also alles eitel Sonnenschein?

Nicht ganz. Es gibt im Leben nichts umsonst, wie meine Oma zu sagen pflegte. Die beeindruckende Steigerung der Geschwindigkeit wird mit anderen Einschränkungen erkauft. Stellen wir die Vor- und Nachteile doch einmal kurz gegenüber:

In der Gegenüberstellung wird deutlich, dass man sich den Geschwindigkeitszuwachs mit einer erheblichen Einschränkung der Flexibilität erkauft. Für einige Anbieter – Je nach Sortiment und Geschäftsmodell mag das unbedeutend sein. Für andere Anbieter ist dies jedoch eine empfindliche Einschränkung. Neue Geschäftsmodelle lassen sich so zudem ebenfalls nicht einführen.

Lösungen für die goldene Mitte

Zur Zeit gibt es nur Shops die entweder in die eine oder in die andere Richtung optimiert sind. Es fehlen jedoch Lösungen für die goldene Mitte: Shops, die flexibel sind und dennoch schnell. Der Bedarf dafür ist vorhanden, wie ich in einigen Gesprächen mit Shopbetreibern in letzter Zeit feststellen durfte. Was kann man nun tun?

Im Prinzip gibt es zwei Möglichkeiten, wie man das Ziel hoher Performance bei gleichzeitiger Flexibilität erreichen kann:

• Herausnahme von Snippets mit variablem Inhalt aus der gecachten Seite
• Ein geschwindigkeitsoptimierter Catalogserver.

Schauen wir uns bei Möglichkeiten etwas genauer an:

1.) Caching und Snippets

Wenn eine Seite nur deshalb nicht gecacht werden kann, weil sie ein oder zwei veränderliche Element enthält, bietet es sich an, diese Elemente als separates Snippet vom Caching auszunehmen. Ein Element, an dem das sehr deutlich wird, ist der Mini-Warenkorb, der heutzutage auf fast jeder Shopseite zu finden ist.

Sobald der Kunde etwas in den Warenkorb gelegt hat, ist dieser Bereich individuell. Somit kann für diesern Kunden quasi keine Seite mehr aus dem Cache bedient werden, obwohl sich der Rest auf den Seiten überhaupt nicht verändert hat.

Daher wird dieser Bereich als Snippet definiert. Das Caching System liefert weiterhin die Seite aus dem Speicher aus, ersetzt jedoch zuvor den Mini-Warenkorb Bereich per Server Side Include durch die individualisierten Code vom Application Server.

Vorteil: Der Anteil der direkt aus dem Cache auslieferbaren Seiten erhöht sich spürbar, Gesamtperformance und Systemlast sinken.

Nachteil: Durch die zusätzlichen Regeln wird das Caching komplizierter und langsamer. Falls mehrere Snippets pro Seite definiert werden, verringert sich die Performance signifikant durch mehrfache Abfrage des Application Servers und den damit verbundenen Overhead.

2.) Optimierter Catalogserver

Um wirkliche Flexibilität zurückzugewinnen, kommt man um einen optimierten Catalogserver nicht herum. Die Geschwindigkeit erreicht er durch konsequentes Weglassen und Datenoptimierung, wie ich bereits im Artikel “Schnell, schneller, noch schneller !!!” schrieb.

Es sollte ein radikal reduziertes, geschwindigkeitsoptimiertes Framework zum Einsatz kommen. Normale Shopframeworks haben durch die maximale Flexibilität zuviel Overhead

Die Datenstrukturen müssen auf minimierte Suchzeiten optimiert werden. Flattables sind hier normalisierten Strukturen vorzuziehen. Hier ist zu prüfen, ob Key-Value Stores, wie z.B. Couchbase signifikante Vorteile gegenüber SQL haben.

Vorteil: Eine immer noch hohe Geschwindigkeit, bei hoher Flexibilität

Nachteil: Langsamer als echte Full Page Caches, eine Anpassung von Code und Daten an das Produkte und Geschäftsmodell ist nötig, die Einbindung des eigentlichen Shopsystems als Transaktionsserver bietet einige Hürden.

Der Blick in die nahe Zukunft

Beide Wege zur Performancesteigerung haben ihr für und wieder. Je nach Angebot und Geschäftsmodell kann der eine oder der andere Weg sinnvoller sein.

Beide Wege sind nicht ohne Stolpersteine und mit den gegenwärtigen Shopsystemen nicht out-of-the-box realisierbar. Der zunehmende Druck in der Branche zu performanten und dennoch flexiblen Lösungen wird jedoch dazu führen, dass die Herausforderungen angegangen werden. Daher erwarte ich in der nächsten Zeit verstärkte Bemühungen auf beiden Wegen.

Oxid Commons 2013 – das eCommerce Klassentreffen

In dieser Woche fand am 16. und 17. Mai die Oxid Commons 2013 statt, bei der ich auch wieder zugegen war. Bei der Anreise war ich zunächst ein wenig beleidigt. Normalerweise ist das Wetter unten in Baden ja immer etwas schöner, als bei uns im Norden, aber diesmal war es andersrum: Berlin hatte 25 Grad, Freiburg aber nur 12. Die erste Enttäuschung wurde jedoch schnell durch die Veranstaltung und die persönlichen Gespräche bei weitem wieder wett gemacht.

Freiburg - kalt und regnerisch

OXID Commons - Ausstellerbereich

Mittlerweile fühlt sich die jährlich in Freiburg stattfindende Konferenz für mich wie eine Art Klassentreffen der eCommerce Szene an. Am Vorabend haben sich bereits viele Teilnehmer in der Innenstadt zu einem gemeinsamen Hallo und ausführlichen Plausch getroffen. Am Donnerstag ging es dann richtig zur Sache. Ich konnte drei thematische Schwerpunkte ausmachen, die die Branche momentan bewegen:

• Das Miteinander von TV und Internet
• Performance
• Responsive Design

Das Internet ist in der Bevölkerung alltäglich geworden. Die veränderte Mediennutzung, die Fernsehen wie zuvor bereits das Radio quasi zum medialen Hintergrundrauschen degradiert, während man gleichzeitig auf dem “second Screen” im Internet unterwegs ist, hat nun die breiten Massen erreicht. Treiber sind der Trend weg vom PC, hin zu diversen mobilen Endgeräten.

In mehreren Veranstaltungen wurden die Wechselwirkungen zwischen TV und eCommerce beleuchtet. Das betrifft Bereiche wie Apps auf Smart TV, Erfolgsmessungen von TV Werbespots, und die technische Bewältigung von kurzfristigen, extremen Belastungsspitzen auf Shopservern, bei der Schaltung erfolgreicher Werbespots im Fernsehen. Stichworte sind hier Full Page Caching und durch Virtualisierung gut skalierbare Hosting Enviroments.

Technischer Vortrag: Codeverwaltung auf Github

Die Tatsache, dass der “second Screen” nicht mehr automatisch ein PC oder Notebook ist, sondern zunehmend Tablets und Mobiltelefone jeglicher Art und Größe, macht eine geänderte Nutzeroberfläche notwendig, die sich automatisch dem Endgerät anpasst. Das betrifft nicht nur die Auflösung und das Layout, sondern tangiert viele Details, die zunächst leicht übersehen werden: Mouseover-Effekte machen auf Geräten mit Touch-Bedienung keinen Sinn. Dafür muss man hier bedenken, dass der Nutzer jederzeit von Hoch auf Querformat wechseln kann. Viele externe Module und Dienste lassen sich aber noch nicht gut in mobile Oberflächen und responsive Layouts integrieren. Daniel Beerden von WBL Konzept hat das in einer Session während der Unconference am Freitag für mich gut auf den Punkt gebracht:

“We need to THINK responsive. It’s not just about Layout”

Und dann gab es noch etwas, worüber ich mich persönlich sehr gefreut habe (Ich mache hier mal eine Ausnahme von der Regel, dass ich nicht über Firmen schreibe, für die ich arbeite oder gearbeitet habe).

…und – GEWONNEN!

Unter den Gewinnern des “Golden Cart Award” war dieses Jahr der Online Shop von Street One. Zwar habe ich Ende letzte Jahres meine Tätigkeit bei der CBR eCommerce GmbH beendet, aber nach über zwei Jahren harter Aufbauarbeit ist dieser Shop dennoch auch “mein Baby”. In der Ansprache wurden neben dem Fokus auf Produkt und Service auch die sehr hohe Geschwindigkeit des Shops erwähnt. Das freut mich wiederum, weil ich jetzt für den Hostingprovider SysEleven arbeite, der die technische Infrastruktur für die CBR Shops betreibt. Den Preis nahm mein ehemaliger Kollege und Nachfolger entgegen und wir haben diesen Erfolg im Nachgang zusammen gefeiert. Sehr schön!

Einstimmung auf das Abendprogramm

Abendstimmung

320 Bits, 40 Bytes, 40 Prozessortakte…

…ergeben eine Zeile Grafik auf dem guten alten Commodore 64.

Auch in dieser Woche gab es wieder eine Veranstaltung aus der Vortragsreihe “Shift-Restore-Escape” an der Humboldt Universität. Mein erster Eindruck: Nerd T-Shirts waren diese Woche Pflicht. Der Vortragende Michael Steil z.B. trug das Firmenlogo von Cyberdyne Systems, auf Stefan Höltgens schwarzem Shirt stand in weissen Buchstaben die Basicbefehle poke 53280,0, poke 53280,1 und poke 646,1. Das bewirkt auf dem Commodore 64, dass Bildschirmrahmen und Hintergrund schwarz und die Buchstaben weiss dargestellt werden. Das war eine schöne Einleitung in das Thema des Abends. Der Titel des Vortrags machte deutlich, dass es wieder technisch sehr ans Eingemachte gehen würde:

Rasterstrahl-Hacken: Grafik mit dem Commodore 64

Michael Steil begann seinen Vortrag mit der scheinbar einfachen Frage, wie man überhaupt Grafik aus einem Computer auf einer Bildröhre darstellen kann. Schnell wurde deutlich, dass die einfachsten Methoden mit den technischen Restriktionen (wenig und langsamer Speicher) der frühen 80er Jahre nicht zu einer befriedigenden Grafik führen konnten. Die seinerzeit sehr gute Grafikleistung des Commodore 64 wurde erst durch seinen sehr trickreichen Videocontroller VIC II möglich.

Grafik mit dem Commodore 64

Nachdem das Publikum mit dem Verständnis für die technischen Restriktionen der frühen 80er Jahre (Speichermenge, Speicherbandbreite und Preis) ausgestattet war, ging es daran, die Hintergründe für die clevere Umsetzung der verschiedenen Grafik und Textmodi, sowie der Sprites zu erläutern. Interessant ist, dass sich die komplexen Funktionen mit einem relativ übersichtlichen Chiplayout von nur 12.000 Transistoren verwirklichen liessen.

Der Blick auf den Chip

Nach der Vorstellung der von den Chipdesignern vorgesehenen Features kam der wirklich interessante Teil: Methoden und Tricks, die nicht geplant waren und im Laufe der Zeit von findigen Programmierern entdeckt wurden. Tricks mit denen sich wesentlich mehr Leistung aus dem Chip herauskitzeln liess, als eigentlich möglich ist. Hierzu gehörte die Darstellung von wesentlich mehr als 8 Sprites (ein Screenshot eines Spiels zeigte 21), die Erzeugung von mehr als 16 Farben, das Verschwinden lassen der Bildschirmrahmen und ähnliches.

Timing des Videocontrollers im Textmodus

Obwohl ich aus Programmierersicht nichts Neues erfahren habe, fand ich den Vortrag interessant und rund. Erst 30 Jahre, nachdem ich ich mich zum ersten mal mit 6502 Assembler, Rasterzeilen Interrups und ähnlichem auf dem “Brotkasten” beschäftigt habe, wurde mir wirklich bewusst, wieso man auf auf dieser eigentlich grottenlahmen Maschine (weniger als 1 MHz Systemtakt) so richtig gute Software schreiben konnte.

Der Witz liegt im perfekten Zusammenspiel von sehr gut aufeinander abgestimmten Komponenten. Somit liess sich trotz der beschränkten Ressourcen sehr viel erreichen. Dieser Erkenntnis lässt sich jenseits von Computern auch auf andere Bereiche, beispielsweise Teams oder kleine Firmen übertragen. Insofern hatte dieser sehr technische Vortrag auch wieder eine philosophische Komponente. Das ist genau das, was ich an dieser Vortragsreihe so schätze.

Ist das noch Retro? SymbOS auf Z80 Rechnern

Nachdem ich letzte Woche bereits den interessanten Chiptunes-Vortrag aus der Reihe “Shift-Restore-Escape”an der Humboldt Universität gesehen und gehört hatte, konnte ich auch diese Woche nicht widerstehen, da es diesmal um ein nicht weniger “wahnsinniges” Thema ging. Thema und Titel der Veranstaltung war:

SymbOS – ein grafisches Multitasking Betriebssystem für Z80-basierte Computer.

Kleine Nebenbemerkung: Trotz eines sehr technischen und “nerdigen” Themas war auch diesmal ein erfreulich hoher Anteil junger Damen im Saal.

Es standen die folgenden Rechensysteme bereit: Ein Schneider CPC 6128, ein Schneider Joyce ein Panasonic MSX2 und ein Amstrad Notepad (quasi ein Vorläufer von Notebooks). Letzterer entpuppte sich dann aber tasächlich als das Schreibgerät von Stefan Höltgen und gehörte nicht zur Demonstration.

Diese Rechner sind ca. 25-30 Jahre alt und haben folgendes gemeinsam: einen langsamen 8 Bit Z80 Prozessor, sehr wenig RAM, bescheidene Grafikauflösung und kleine Floppy Laufwerke als Massenspeicher. Die denkbar schlechtesten Voraussetzungen also für ein grafisches Betriebssystem im Stile von Windows oder Mac. Normal waren damals textbasierte Benutzeroberflächen mit kryptischer Befehlseingabe.

SymbOS auf CPC 6128 - Start

Jörn Mika begann seinen Vortrag mit einer kurzen historischen Rückblende auf die Entwicklung von Benutzeroberflächen:

• 40er bis Ende der 60er Jahre dominierten Lochkarten und Lochstreifen
• Seit Mitte der 60er Jahre waren textbasierte Terminals auf dem Vormarsch. Zunächst auf der Basis von Fernschreibern, später mit Bildschirm.
• Der Xerox Alto (1973) war der erste Computer mit grafischer Benutzeroberfläche (GUI). Er wurde jedoch nicht kommerziell vertrieben, sondern nur Xerox intern genutzt.
• Der Xerox Star (1981) war die erste kommerziell vertriebene Workstation mit grafischer Benutzeroberfläche.
• Der Apple Lisa (1983) Apples erster Computer mit GUI. Aufgrund des hohen Preises ein Flop.
• Apple Macintosh (1984) Der vergleichsweise geringe Preis (1/4 des Preiseder Lisa) brachte den kommerziellen Erfolg – trotz deutlich reduzierter Leistung.
• Atari ST, Commodore Amiga, Windows 1.0 (1985)
• Den endgültigen Abschied von der Kommandozeile für die breite Masse läutete aber erst Windows 95 (1995) ein.

Selbst die ältesten und noch relativ einfachen GUI Systeme hatten bereits 16 Bit Prozessoren, und verhältnismässig viel Speicher (mit Ausnahme von GEOS auf dem C64). Zum Vergleich: CPC-6128 hat 128KB RAM und 0.5 MIPS Rechenleistung, ein aktueller PC 4GB RAM und 150.000MIPS.

Wie bekommt man denn nun eine moderne Benutzeroberfläche auf 8Bit Hardware zum Laufen?

Für mich erstaunlich sind die modernen Kriterien, nach denen SymbOS entworfen ist:

• Portabel, dank Hardware-Abstraktion
• Microkernel
• Präemptives, priorisiertes Multitasking
• Interprozesskommunikation
• Bis zu 1024 KB Speicher mit Bankswitching

Jörn Mika erläuterte, weshalb sich SymbOS zwar auf dem Z80, aber nicht auf dem 6502 Prozessor umsetzen lässt, wie das Scheduling, die Speicherverwaltung, die Hardwareabstraktion die Fensterverwaltung und weitere zentrale Dinge funktionieren. Leider würde die Wiedergabe den Rahmen dieses Artikels sprengen.

SymbOS auf CPC 6128 - Viele Fenster

Der Erfolg kann sich auf jeden Fall sehen lassen. Auf dem CPC-6128 liefen in mehreren überlappenden Fenstern gleichzeitig gleichzeitig Pac Man, ein Spielfilmtrailers (passenderweise Matrix) mit immerhin ca. 5 Frames/s und ein Taskmanager.

Was bei einem hochoptimierten System nicht unbedingt zu erwarten war, ist die Portierbarkeit. SymbOS läuft auf Systemen mit unterschiedlichem Speicher und in verschiedenen Farbtiefen und Auflösungen.

SymbOS auf PCW Joyce

SymbOS auf MSX2

Auf die Frage nach der Motivation antwortete Mika mit “Neugier und Spass”. Als reine Entwicklungszeit gab er ‘ungefähr 3 Jahre’ an. Allerdings hat er in 20 Jahren dafür 3 Anläufe benötigt. Die Aneignung der notwendigen Grundlagen anzueignen hätte länger gedauert als die eigentliche Umsetzung.

Wie bereits in der Woche zuvor stellt sich auch hier die Frage, ob es eigentlich wirklich “Retro” ist, auf alter Hardware eine Software zu schreiben, die nach modernsten Kriterien konzipiert ist.

Abgesehen von dieser philosophischen Frage ist das Projekt technisch extrem beeindruckend.

(Alle Screenshots mit freundlicher Genehmigung von Jörn Mika)