Dirk Ollmetzer | Monday, 9 September 2013 | Retro, Unterwegs
Der alte Gassenhauer von Extrabreit aus den frühen 80er Jahren hat aktuell für mich eine ganz spezielle Bedeutung. Meine (ehemalige) Schule, auf der ich in den 80ern von der 5. bis zur 13. Klasse war brennt zwar nicht – aber sie wird gerade abgerissen.
Auf dem Klassentreffen vor drei Jahren haben wir von den Plänen erfahren, unsere alte Schule aus dem Jahr 1974 abzureißen und durch einen Neubau zu ersetzen. Und nun ist es tatsächlich so weit, wie man auf den Fotos vom Neubau Tagebuch der IGS Mühlenberg sehen kann.
Ehemalige Mensa und Jugendzentrum Weisse Rose (Foto: Dr. Michael Bax)
Ehemalige Sporthalle 1 (Foto: Dr. Michael Bax)
Als dann neulich das Ehemaligentreffen angekündigt wurde, war für mich klar, dass ich nach Hannover fahren werde, um die alten Recken zu treffen und mir das Geschehen aus der Nähe anzusehen. Also fuhr ich am Wochenende nach Hannover. Je näher ich meinem Ziel kam, desto mehr verfinsterte sich der Himmel und als ich das Auto abgestellt hatte, bot sich das folgende Bild:
IGS Hauptgebäude auf freier Flur
Links hinter dem Hauptgebäude fehlt bereits die große Sporthalle und im Vordergrund die Mensa samt Brücke. Obwohl das Gebäude jetzt doch bereits erheblich kleiner ist, erinnert mich die Szene ein wenig an meine Einschulung im Jahr 1978. Wenn man damals aus der U-Bahn heraustrat, konnte man über einen schmalen Teerstreifen trockenen Fusses zur Schule gelangen. Seinerzeit stand das riesige Gebäude alleine auf dem Acker. Hat davon noch jemand Bilder? Der Stadtteil drumherum wurde erst in den 80er Jahren fertig gebaut.
Aus meiner Klasse waren wir zwar nur zu viert, aber das Wiedersehen war schön. Wir haben uns mit unserer Klassenlehrerin, die noch immer unterrichtet und flott unterwegs ist, über alte Streiche und aktuelle Erziehungsfragen unterhalten. Immerhin bin ich der einzige ohne Nachwuchs. Nun ja, that’s Life…
Abschließend gab es noch eine Schulbegehung durch die Klassentrakte, den naturwissenschaftlichen Bereich, den Werkbereich, über die “Schulstrasse”, vorbei an Freizeit, Kunst und Repro bis zur Verwaltung.
Zu meiner nicht geringen Verblüffung hat sich in den letzten 30 Jahren fast nichts an dem Gebäude geändert. So schlecht war die Bauqualität seinerzeit also gar nicht. Selbst der Disco-Turm im Freizeitbereich steht noch. Zwar wurden Stühle, Tische und Teppiche erneuert, aber ansonsten sind überall dieselben Einbauten, Türen, Schränke, Beschriftungen. Und vor allem diese Farben!!!
Klassenraum
Treppenhaus
Naturwissenschaften
Kunstbereich
Die 70er: Mut zur Farbigkeit
Den Abend habe ich dann beim Griechen im Lister Turm ausklingen lassen. Nach einer ruhigen Nacht (das Novotel an der Podbielskiallee neben Bahlsen kann ich guten Gewissens weiterempfehlen) traf ich dann am Sonntagmorgen noch meine Familie zum Mini-Brunch bei Loretta’s. Ich habe diesen schnuffigen Mini-Pavillon schon als Kind gemocht.
Nachmittags ging es dann über meine “geliebte A2” wieder zurück nach Berlin.
Am letzten Dienstag fand die abschliessende Veranstaltung aus der Vortragsreihe Shift – Restore – Escape an der Humboldt Universität in Berlin statt.
Während des Semesters gab es viele interessante Vorträge auf hohem Niveau zu hören, von denen ich ja auch hin und wieder berichtet hatte. Der Schwerpunkt der Vorträge lag auf technischen Gebiet. Dabei wurden häufig Dinge auf 30 Jahre alten Maschinen gezeigt, die seinerzeit nicht für möglich gehalten wurden. Antrieb für die Projekte war meist ein wenig Nostalgie, sportlicher Ehrgeiz oder die Suche nach Erkenntnisgewinn, der sich mit der überschaubaren Technik leichter einstellt als mit aktueller Technik. Die damit verbundenen philosophischen Fragen wurden zwar angesprochen, gaben aber eher den Hintergrund ab. Bei der Abschlussveranstaltung war es aber genau andersherum.
Podiumsdiskussion
Vor voll besetzten Rängen gab es eine Diskussionsrunde mit interssanten Gästen, die jeweils einen eigenen Schwerpunkt haben und daher eine eigene Sichtweise auf das Thema einbrachten.
Das Publikum war ebenfalls hochrangig besetzt. In die Diskussion brachten sich unter anderem ein: Dr. Ralf Bülow (ehem. wissenschaftlicher Berater beim Computermuseum Kiel), René Meyer (vom Leipziger Haus der Computerspiele) und Eva Kudrass (wissenschaftliche Mitarbeiterin in der Computerausstellung des Deutschen Technikmuseums Berlin).
Ausgangsthese: Retrocomputing gibt es eigentlich gar nicht
Die zentrale These, die Stefan Höltgen mit der Reihe zu belegen versuchte ist, dass es im eigentlichen Sinne kein Retrocomputing gibt. Sobald man die Maschine einschaltet und nutzt, ist man mit dem Rechner im Hier und Jetzt, was eindrucksvoll durch den SymOS Vortrag (Ist das noch Retro? SymbOS auf Z80 Rechnern) von Jörn Mika verdeutlicht wurde.
Diese Sichtweise hat natürlich starken Einfluss auf die Art, wie alternde Computertechnik für die Nachwelt aufbewahrt werden soll. Etwas überspitzt formuliert:
Ein Computer, der nur da steht und nicht genutzt wird, ist kein Computer, sondern Elektroschrott.
Ziel muss es daher sein, alte Computer nicht in die Vitrine zu stellen, sondern weiterhin in Betrieb zu halten. Dementsprechend ist ein „wahres Computermuseum“ nur eines, dass die Rechner funktionstüchtig erhält. Das Oldenburger Computermuseum ist strenger Verfechter dieser Haltung.
Funktionsfähigkeit erhalten – aber wie?
Das Berliner Computerspielemuseum würde das auch gerne tun, was aber bei ca. 70.000 Besuchern im Jahr nicht geht, weil die Geräte sonst schnell verschleissen. Man behilft sich daher zum Teil mit Emulationen, was in Ordnung ist, weil es hier weniger um die Hardware, sondern um das Spiel als solches geht.
Den starken Verschleiss eines Museums haben private Aktive zwar nicht zu befürchten, aber dennoch gehen immer mehr Maschinen kaputt. Der Verein zur Erhalt klassischer Computer hält daher Reparaturen mit aktuellen Bauteilen (z.B. auf FPGA Basis) für ein notwendiges Übel, aber vertretbar.
Ein besonderes Problem hat das Deutsche Technikmuseum mit seiner Zuse-Sammlung. Neben den fehlenden finanziellen Mitteln für Live-Vorführungen fehlen mittlerweile auch die Fachleute, die das nötige Know-How für die Maschinen aus den 50er und 60er Jahren haben. Zudem – welche Software soll man überhaupt demonstrieren?
Ein Vertreter aus dem Publikum vertrat die Ansicht, dass Emulatoren die sinnvollste Art sind, alte Software am Laufen zu halten. Anderen fehlt die Haptik (Originaltastaturen, Röhrenmonitore, ratternde Diskettenlaufwerke) oder der richtige Kontext. Man kann zwar alte Spielhallenautomaten auf PC emulieren, aber die Originalmaschinen hatten nicht nur besondere Hardware, sondern standen in der Öffentlichkeit im Bahnhof, in Kinos und Kneipen. Nur vor diesem Hintergrund kann man den Sinn der Highscore Listen und die Besonderheiten des Spieldesigns richtig verstehen.
Der Gesetzgeber als Problemverursacher
Neben den technischen und philosophischen Problemen gibt es eine Reihe weiterer Schwierigkeiten, die durch höchst problematische Gesetzgebung verursacht werden. Als Beispiele seien genannt: Urheberrecht und Jugendschutz.
Bei der Hardware geht man von einer Haltbarkeit von 40-50 Jahren aus. Im Bereich der Software besteht jedoch bereits jetzt dringender Handlungsbedarf. Die meist magnetischen Datenträger verrotten nämlich schon. Dieser Zerfallsprozess kann nicht aufgehalten werden, daher müssen die Daten umkopiert werden um sie zu retten, was aber aus mehreren Gründen eigentlich verboten ist.
Die überlangen Schutzfristen im Urheberrecht passen nicht zu dem extrem schnellebigen Computermarkt. Streng genommen dürften die Daten erst dann durch umkopieren gerettet werden, wenn garantiert kein Originaldatenträger mehr lesbar ist.
Zwar ist das Umkopieren gestattet, wenn ein Originaldatenträger vorhanden ist, aber nicht, falls ein Kopierschutz – wie leicht auch immer zu umgehen – auf dem Datenträger angebracht ist. Das ist bei Spielen eigentlich immer der Fall.
Es gibt gerade im Softwarebereich einen großen Anteil an verwaisten Werken. Das sind Titel, deren Rechteinhaber schon seit längerem nicht mehr bestehen. Auch diese Werke unterliegen unsinnigerweise noch immer dem Urheberschutz.
Weiterhin gibt es das Problem der gesetzlichen Altersfreigabe von Spielen. Wenn keine vorhanden ist, darf das Spiel nur Menschen ab 18 Jahren zugänglich gemacht werden. Die alten Heimcomputerspiele haben alle keine Altersfreigabe, weil es so etwas damals noch nicht gab. Daher ist der gewollte Bildungsauftrag, Kindern und Jugendlichen die geschichtlichen Ursprünge näherzubringen, eigentlich gesetzlich untersagt.
Was lehrt uns das?
Die Bewahrung des Kulturgutes Computer aus historischen Gründen ist dringend geboten, weil bereits jetzt viel Hardware, Software und Know-How unwiederbringlich verlorengeht. Neben den finanziellen und technischen Herausforderungen ist hier auch der Gesetzgeber gefordert, unsinnige und schädliche Vorschriften zu entschärfen oder besser ganz zu streichen.
Statements
Zum Schluss möchte ich noch einige Statements des Abends zum Besten geben:
„Der Computer ist kein geschichtliches Artefakt, wenn man ihn benutzt“
„Auch eine Ausstellung ist ein Medium.“
„Digital ist flüssig. Alles ist veränderbar. Es gibt kein Original, sondern nur Kopien.“
„Selbst wenn Barockmusik auf Originalinstrumenten gespielt wird, ist das Erlebnis aufgrund des anderen Kontexts und der eigenen Hörgewohnheiten ein anderes als damals“
Auch in dieser Woche gab es wieder einen hervorragenden Vortrag aus der Reihe Shift-Restore-Escape an der Humboldt Universität. Nachdem die bisherigen technischen Vorträge stets davon handelten, neue Software auf bekannter alter Hardware zum Laufen zu bringen, ging es diesmal ans Eingemachte. Das Thema des Abends lautete
Mit Lötkolben, Wire-Wrap-Pistole und Assembler – Z80 Selbstbaurechner
Prof. Dr. Bernd Ulmann – Spitzname “Vaxman” – ist eigentlich für den Umgang mit richtig grossen Geräten bekannt. Er sammelt alte VAX Rechner von Digital Equipment. Dennoch hatte er Lust “schnell mal eben” einen kleinen Z80 Rechner selbst zu bauen. Gesagt, getan. Das Projekt hat er auf seiner Homepage unter http://www.vaxman.de/projects/tiny_z80/ ausführlich dokumentiert, so dass ich mir hier Details spare.
Die naheliegende Frage “Warum macht man sowas?” beantwortete er gleich am Anfang augenzwinkernd mit “wegen einer kleinen Midlife-Crisis” und weil man an solch einfachen Systemen den heutigen Studenten die Grundfunktion von Rechnern gut erklären kann.
Die Idee - Handskizze
Das Ergebnis der Arbeit ist ein Einplatinenrechner, der per serieller Schnittstelle an andere Rechner angeschlossen wird. Er ist mit einem Mini-Betriebssystem, einem Monitorprogramm, einem Forth-Interpreter und experimentiell mit einem kleinen Basic Interpreter ausgestattet. Die weitaus meiste Arbeit steckt in dem Massenspeicher in Form eines CF-Karten Laufwerkes.
Hardware Revision 1
Mitten während der Entwicklung entdeckte Ulmann, dass mit dem N8VEM bereits ein vergleichbares Projekt existierte. Er hatte in der Veranstaltung sowohl den N8VEM, als auch die zweite Revision seines eigenen Rechners dabei, der mit einer deutlich kleineren Platine auskommt und mich ein wenig an den seeligen Sinclair ZX81 einnerte, der aus nur vier Chips bestand.
N8VEM
Hardware Revision 2
Die abschliessende Live Präsentation wurde mit einer Aufgabe durchgeführt, die in den 80er Jahren sehr populär war: Der Berechnung einer Mandelbrot-Menge. Einmal in Basic und einmal in Assembler. Ein- und Ausgabe erfolgten dabei in ASCII Code auf dem Terminalprogramm eines aktuellen Apple Laptops.
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.
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.
Dirk Ollmetzer | Friday, 17 May 2013 | Gizmos, Retro
…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.
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:
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.
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)
Der Vortragende – Pater Maria/Irrlicht Project – zog es vor, sein Incognito durch ein Tuareg-ähnliches Kopftuch zu wahren, gab mir jedoch die Erlaubnis, Fotos auf meinem Blog zu veröffentlichen.
Das Thema liess sich grob mit “Klangerzeugung per Computer” umschreiben. Klar ausgenommen waren jedoch heutzutage übliche Hard- und Software. Der Schwerpunkt war, was man stilistisch mit Chiptunes, 8-Bit oder Micromusic beschreibt – also Klänge, die man mit 80er Jahre Heimcomputern in Verbindung bringt.
Da es sich um eine Veranstaltung im universitären Rahmen handelte, bekamen Begriffsbestimmung, historische Wurzeln und weitere theoretische Abhandlungen einen angemessenen Rahmen – aber auch praktische Demonstrationen auf authentischer Hardware kamen nicht zu kurz. Zur Einführung, wie man überhaupt diese Art Musik erzeugen kann, wurde das Konzept der sogenannten Tracker, anhand der aktuellen kommerziellen Software Renoise erläutert.
Soundtracker Renoise
Die Vorführung begann mit dem 16 Bit Homecomputer Atari 1040 STE, der für damalige Verhältnisse zwar sehr viel Rechenleitung und Speicher hatte, aber mit dem seinerzeit sehr verbreiteten Standardchip AY-3-8910 (YM2149) nur einen durchschnittlichen Klangerzeuger an Bord hatte.
Es folgte eine kurze Demonstration des unausweichlichen 8 Bit Homecomputers Commodore 64. Von allen präsentierten Geräten hat der er mit dem MOS SID 6581 den leistungsfähigsten Soundchip an Bord und liefert den fettesten Klang. Die Vorführung zeigte jedoch das Potential des Gerätes meiner Meinung leider nicht richtig.
Vermutlich ist der Grund, dass sich Pater Maria auf Geräte spezialisiert hat, die von Haus aus eigentlich gar keine richtige Musik erzeugen können. Rechner vom Schlage eines Apple ][, IBM PC oder Sinclair ZX Spectrum haben keinen Soundchip und können eigentlich nur einen Piepser über einen einfachen eingebauten Lautsprecher von sich geben.
Die Erklärung, wie man auf derart reduzierter Hardware mit nur 1Bit trotzdem mehrstimmige Musik erzeugen kann, fand ich recht interessant. Insbesondere die Vorführung auf dem Sinclair ZX Spectrum, den ich seinerzeit auch besessen habe fand ich verblüffend – zumal das Tonsignal am Interface für den Kasettenrekorder abgegriffen wurde, der eigentlich nur zum Speichern von Programmen und Daten verwendet wurde. Aber es kam noch besser.
Die Überschrift dieses Artikels ist dem Song “Taschenrechner” entliehen. Auch wenn es Kraftwerk seinerzeit eher im übertragenen Sinne meinten – Pater Maria hat ihn wortwörtlich umgesetzt.
Musik auf dem TI-82
Die programmierbaren Taschenrechner der Serie TI-82 bis TI-84 Plus von Texas Instruments nutzen wie der Sinclair ZX Spectrum den Z80 Prozessor von Zilog. Anstatt mit 4MHz, wie im Sinclair, wird er in den Taschenrechner allerdings mit 6MHz, bzw. 15MHz spürbar schneller betrieben.
Der Z80 Programmcode konnte recht einfach vom Spectrum auf den Taschenrechner portiert werden. Zum Abschluss gab es daher noch kurze Musikdemos von zwei Taschenrechnern.
Alles in allem ein sehr gelungener Vortrag, der auch für Veteranen, wie mich, durchaus noch Neues zu bieten hatte.
Ein tolles Wochenende liegt hinter mir. Der Freitag Abend begann in der Z-Bar mit zwei wunderbar schrägen Folgen der Schmusetiersoap “Humana – Leben in Berlin“. Sehr lustig!
Da der Samstag Morgen bereits mit richtig schönem Wetter begann, beschloss ich, gleich nach dem üblichen Einkauf endlich mal dem Auto die Sommerschuhe anziehen. Unter der Woche komme ich einfach nicht zur Werkstatt, deshalb habe ich seit Jahren das erste Mal selber wieder zum Werkzeug gegriffen. Obwohl ich es ja nicht so mit Hardware habe – ging problemlos. Stolz!
Endlich Sommerräder
Der Sonntag war dann “Fun-packed”. Erst mal ausschlafen, lecker Frühstücken und dann zum Golfplatz. Noch etwas frischer Wind, aber sonnig. Feinstes Cabriowetter. In Pankow angekommen, stellte ich fest, dass der Rasen auf dem Platz mittlerweile ganz vernünftig aussieht. Dementsprechend war zwar ordentlich Betrieb auf der Driving Range, aber da sich die meisten dort nur für eine Runde warmspielten, war es kein Problem, einen Platz zu bekommen. Meine Abschläge werden mittlerweile auch etwas besser. Ich könnte so langsam mal wieder richtig auf den Platz.
Betrieb auf dem Golfplatz
Danach ging es in den Plänterwald um Bärlauch zu holen. Das war auf den letzten Drücker, weil er schon kurz vor der Blüte stand.
Bärlauch
Auf dem Rückweg stellte ich zu meinem Erstaunen fest, dass der ehemalige Spreepark im Plänterwald (ein bisschen) geöffnet war. Man durfte in den vorderen Teil und mit der Parkbahn eine Runde drehen. Das restliche Gelände darf man jedoch – wie bisher – nur mit einer Führung betreten.
In einem meiner letzten Artikel (Store and Forward, Offlinenetz… was bitte?) habe ich mich über die schwachen Kenntnisse heutiger Nerds über Rechentechnik der 80er und 90er beschwert. Das ist natürlich ein typisches Stossgebet alter Leute über die Jugend von heute. Denn die Herren sind ja erst später zu den Computern gekommen. Da gab es eben schon Internet. Alles davor war eben – früher. Steinzeit.
Wenn ich mal ehrlich bin geht es mir selbst ja nicht viel anders. Klar kenne ich die Heimcomputer der 80er aus. Schliesslich habe ich selber intensiv mit den Kisten rumgespielt. Aber was weiss ich denn von der Phase davor?
Als erster echter Heimcomputer gilt der Altair 8800 von 1974. Ich kannte das Gehäuse von etlichen Bildern und habe mich immer über die vielen Schalter und Lämpchen gewundert. Und wo sind Tastatur und Monitor? Wozu kann man solch eine Kiste denn überhaupt nutzen?
Eines ist klar – die Bedienung war damals vollkommen anders, als man das heute von einem Computer erwartet.
Letzte Woche war ich auf einem kleinen privaten Vortrag. In dem Raum lag eine PDP-11 von Digital Equipment herum – fein säuberlich in Einzelteile zerlegt wartet der Rechner auf die Wiederinbetriebname. Passend zu dem eigentlichen Rechner fand ich dort auch ein VT220 Videoterminal und ein Fernschreibterminal. Ersteres besteht aus Tastatur und Monitor, ähnlich wie wir Computer heute noch nutzen – natürlich ohne Maus, ohne Grafik und in schwarz-weiss, aber immerhin. Letzteres jedoch war damals Standard: Auf der Tastatur wird getippt, und die Ausgabe sofort ausgedruckt.
Das machte mich neugierig und ich habe etwas recherchiert.
In den 60er bis 80er Jahre war die Firma Digital Equipment extrem erfolgreich und zeitweilg nach IBM der zweitgrösste Hersteller von Computern. Die Firma hatte sich auf sogenannte “Minicomputer” spezialisiert. Der Begriff “Mini” ist heute etwas erklärungsbedürftig, wenn man die Rechner sieht. Im Gegensatz zu den Grossrechnern der Zeit, war das Komplettsystem nicht grösser als eine Wohnzimmerschrankwand und benötigte auch kein klimatisiertes Rechenzentrum mit Starkstromanschluss. Vor allem haben diese Maschinen nicht Millionen Dollar gekostet, sondern waren mit ca. $20.000 verhältnismässig günstig, so dass sie auch von kleineren Firmen und Forschungseinrichtungen gekauft wurden. Ausserdem mag ich das Design der PDP Rechner – sie waren so schön poppig :-).
DEC PDP 11-40 (Quelle: Wikimedia, Lizenz: Creative Commons)
Und sie hatten ebenfalls viele Schalter und Lämpchen. Ich habe auf Youtube ein paar Videos angesehen, wie diese Maschinen programmiert wurden. Tatsächlich wurde Binärcode per Kippschalter direkt in den Speicher eingegeben. Zumindest der Code, den nötig war, um das eigentliche Programm von einem Lochstreifen (schon wieder Fernschreiber-Technik) einzulesen. Die PDP-11 waren 16-Bit Rechner mit 32 KB Arbeitsspeicher. Der Vorgänger PDP8 hatte sogar nur 4KB, was aber eigentlich 6KB entspricht, weil es eine 12 Bit Maschine war. Aus heutiger Sicht also ziemlich exotisches Zeug, wie diese kleine “Zeitreise” in vier Teilen zeigt. Diese Folge zeigt, wie ein kleines Assemblerprogramm geschrieben wird.
