tiny little gizmos

The next big (little) things?

In den letzten 3-4 Jahren las man immer mal wieder etwas über 3D Druck. In technischen Veröffentlichungen ging es meist um die Technik an sich und in den normalen Medien wurde – wie leider mittlerweile üblich – wieder nur stupide Stimmungsmache und Panik verbreitet. Beide Arten der Veröffentlichungen finde ich mindestens sinnlos, wenn nicht sogar eher schädlich, weil sie eine sachliche Diskussion verhindern.

Einerseits, werden keine möglichen positiven Anwendungen, wie z.B. die Herstellung selten gebrauchter Ersatzteile gezeigt. Die Suche nach Chancen findet mal wieder nicht statt.

Andererseits werden aber die wirklich relevanten Herausforderungen, wie die möglichen Umwälzungen auf Produktion und Beschäftigung ebenfalls nicht thematisiert. Stattdessen werden ausschliesslich sensationsheischende Schlagzeilen wie „Waffen aus dem 3D Drucker“ thematisiert. Mein Gott! Als ob man Waffen nicht aus allem möglichen Zeug herstellen kann, wenn man es denn darauf anlegt. 3D Drucker sind da schon vom Metrial her eher nicht geeignet, wie ein Praxistest gezeigt hat, den die Zeitschrift C’t in Zusammenarbeit mit einem Büchsenmacher durchführte.

Wo liegen denn nun mögliche Einsatzzwecke?

Der eigentliche Witz beim 3D Druck ist, dass das Open Source Prinzip nach der Software nun auch in der Harware angekommen ist. Das wiederum gibt einem weiteren, interessanten Zukunftsthema weiteren Schwung: Der Robotik.

Robotik an sich ist zwar keinesfalls ein neues Gebiet, aber die Entwicklung erfolgte bisher Top-Down. Konzerne mit millionenschweren Forschungsbudgets und Universitäten haben sich hier hervorgetan und auch bereits beachtliches geleistet. Der wirkliche Durchbruch in der Alltagswelt der Menschen wird aber vermutlich eher durch eine Bewegung „von unten“ vorangetrieben werden. Genauso, wie erst die zunächst belächelten Microcomputerbasteleien einiger Freaks in den 70er Jahren den Computer als Alltagsgerät für die Massen ermöglichte.

3D Druck als Bottom-Up Treiber in der Robotik

3D Drucker selbst sind ja bereits eine spezielle Art von Robotern. Bei den meisten Modellen sind auch bereits viele Teile selbst per 3D Druck hergestellt, die Steuerelektronik basiert meist auf offenen Hardwarespezifikationen, wie dem Arduino und die Software von der Konstruktion bis zum Hardwaretreiber sind ebenfalls meist Open Source.

Dieses bei dieser mittlerweile bewährten Art der offenen Entwicklung durch eine motivierte Gruppe enstandene Know-How, wird nun zunehmend auf andere Bereiche der Mechatronik transferiert. Zwei wie ich finde interessante Projekte sind Shellmo und Poppy.

Während sich das insektenähnliche Shellmo eher als ein interessantes technisches Spielzeug darstellt, merkt man dem humanoiden Poppy Project sein ambitioniertes Ziel deutlich an. Viel Spass beim Ansehen.

 

 

 

Versionsmanagement mit Git

Denselben Effekt hat man aber auch mit Subversion oder ähnlichen Systemen.

Wieder mal ein Treffer von XKCD. Bin eben vor Lachen fast vom Stuhl gerollt. Schade, dass das nur Entwickler richtig verstehen…

Oxid Usergroup Berlin am 19.11.

Am letzten Dienstagabend fand nach längerer Pause wieder einmal das Treffen der Oxid Usergroup Berlin statt.

Die Veranstaltung fand ab 18:00 in den Räumen von SysEleven in Kreuzberg statt. Nach einer kurzen Vorstellungsrunde ging es gleich sehr technisch zur Sache. Felix Gilcher von Asquera startete mit einem Vortrag über den Suchindex Elasticsearch. Er begann mit einem Überblick über die Architektur (Clusterserver, Shards, Indizes, Documents…) und die grundlegende Benutzung per JSON Calls mit Indexern, Analyzern und Filtern.

eCommerce im Umspannwerk

eCommerce im Umspannwerk

Josha Krug von der Agentur Marmalade ergänzte das Thema mit den Erkenntnissen, die beim Einsatz von Elasticsearch bei einem Online Buchhändler gewonnen wurden. Es wird dort nicht nur für die Suche, sondern auch für das Ausspielen der Kategorieseiten genutzt.

Im Verlauf der Diskussion wurde als weiterer möglicher Einsatzzweck System- und Eventlogging besprochen. Dafür gibt es mit Kibana und Logstash auch bereits gute Frontends.

Es folgte ein etwas weniger technischer Teil. Ein Shopbetreiber fragte in die Runde nach Erfahrungen bei der Auswahl geeigneter ERP Systeme. Es wurde auf die hohe Anzahl an Spezialanbietern (z.B. jewils unterschiedliche Systeme für Tischler und Zimmerleute) hingewiesen und auch das Thema Cloud ERP mit Vorteilen beim Dropshipping wurde angerissen.

Im Abschluss wurde es wiederum sehr technisch. Daniel Niedergesäß von SysEleven führte anhand von OXID 4.7 CE vor, welch großer Performancegewinn sich durch den Einsatz von Facebooks HipHop Virtual Machine erzielen lässt. Mit HipHop compiliert man aus einer PHP Applikation samt PHP selbst und den notwendigen Libs eine Binärcode Anwendung.

Da HipHop aber noch nicht den vollständigen Sprachumfang von PHP unterstützt und an einigen wichtigen Stellen, wie der Sessionverwaltung von Standardverhalten abweicht, sind leider einige recht tiefe Eingriffe in den Core von Oxid, der vollständige Verzicht auf verschlüsselten Code und recht speziell eingerichtete Server nötig, um den Shop zum Laufen zu bekommen.

Für den Produktiveinsatz ist solch ein System daher leider noch nicht geeignet, aber es zeigt auf, welches Potential hier vorhanden ist.

Nach dem offiziellen Ende der Veranstaltung um 21:00 ließen einige Teilnehmer den Abend noch gemeinsam in einer Gaststätte ausklingen.

Brauchst’n Rechner? Bau ihn doch einfach schnell selber…

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

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

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

N8VEM

Hardware Revision 2

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.

Live Demo

Live Demo

 

 

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

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

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

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

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

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.

 

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

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

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

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

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

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.

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:

Shops ohne Full Page Cache Shops mit Full Page Cache
Vorteile
+ Dynamische Seitenerstellung ermöglicht jede denkbare Anpassung an Client, Herkunft, Marketing etc. 

+ Änderungen an Artikeln, Kategorien und Landingpages sind sofort online

+ Extrem schnell (für cachebare Seiten) 

+ Gesteigerte Skalierbarkeit

+ weniger Anfälligkeit für Lastspitzen

Nachteile
– Langsame Antwortzeiten 

– Hohe Systemlast

– Nur bestimmte Seitentypen sind cachebar 

– Die Invalidierung von Seiten kann komplex und fehleranfällig sein

– Gecachte Seiten sind nicht mehr personalisierbar

– Gecachte Seiten können nicht mehr serverseitig auf Geräteklassen angepasst werden

– Gecachte Seiten können nicht mehr serverseitig auf Marketingmassnahmen angepasst werden

– Gecachte taugen nicht zu serverseitigen multivariatem Testing

– Tools zur Erfolgsmessung von Marketingmassnahmen werden schwieriger

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.

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 CPC - Start

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 CPC - Viele Fenster

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 PCW Joyce

SymbOS auf PCW Joyce

SymbOS auf MSX2

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)

Retro – nein, noch früher…

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?

CPU_Altair_8800

CPU_Altair_8800 (Quelle: Wikimedia, Lizenz: Creative Commons)

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

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.

« Vorherige SeiteNächste Seite »