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.
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.
Berufsbedingt setze ich mich momentan verstärkt mit Netzwerkthemen auseinander – auch ausserhalb der Arbeit. In den letzten Wochen habe ich mich mit einigen Leuten getroffen, die nicht nur mit dem aktuellen Internet arbeiten, sondern sich in der Freizeit auch mit Alternativen für bestimmte Spezialanwendungen auseinandersetzen.
Nun habe ich in zwei Gesprächen – immerhin unter wirklichen Nerds – das Thema „Store-and Forward in Netzen in denen Knoten nicht ständig verbunden sind“ angesprochen und ergänzt „so ähnlich, wie damals das Fido Net“. Beide Male habe ich in ratlose Gesichter geblickt. „Was war denn das Fido-Net?“
Ich hätte genausogut von Aufstieg und Fall des Osmanischen Reiches erzählen können. Kein Plan, kein Geschichtsbewusstsein. Das hatte ich nicht erwartet, weil Retrocomputing ja gerade ziemlicher Trend ist. Immerhin waren Mitte der 90er weltweit fast 40.000 Systeme mit mehreren 100.000 Nutzern vernetzt – alles von Privatpersonen betrieben.
Wer sich für die Vernetzung zwischen Ende der 70er bis Mitte der 90er Jahre, bevor es das Internet für Privatpersonen gab interessiert, dem kann ich die wirklich gute Dokumentation „BBS The Documentary“ ans Herz legen. Dankenswerterweise sind die Folgen bei Youtube zu sehen, da die DVDs nur in USA erhältlich waren.
Die Folge in der das Fidonet behandelt wird, ist diese. Viel Spass!
Dirk Ollmetzer | Mittwoch, 13 März 2013 | Gizmos, Retro
Seit geraumer Zeit interessiere ich mich für Mini-Computer abseites der üblichen PC Wüste. Der Vorteil von diesen Mini-Dingern ist, dass sie nicht allzuviel kosten (in der Regel zwischen 20 und 40 Euro) und sich so zum rumprobieren und basteln eignen. Mittlerweile habe ich drei von den Dingern zu Hause.
Der Nachteil ist, dass sie in der Regel leider auch nicht allzuviel Rechenpower und Speicher haben. So ähnlich, wie sich die drei Geräte in Größe und Preis auch sind – von der Charakteristik und vom potentiellen Einsatzzweck unterscheiden sie sich doch erheblich.
Level 1 – Arduino
Der Arduino ist ein kleines Board mit einem ATMEL Microcontroller, der vor allem für Steuer- und Regeltechnik taugt: Lichtspielereien mit LEDs, Heimautomatisierung mittels Licht, Temeperatur und Feuchtigkeitssensoren und kleine Roboterspielereien. Was er nicht hat: Anschlüsse für Bildschirm, Tastatur, Maus, Sound und andere Dinge, die man ein normalen Computer so erwartet. Programmiert wird er in einer einfachen, auf Processing basierenden Sprache – oder in C.
Arduino Uno
Level 2 – Duinomite
Der Duinomite kommt – obwohl ebenfalls auf einem Microcontroller basierend – der Idee eines Computers schon näher. Tastatur und Bildschirm angeschlossen und schon hat man einen Rechner auf dem technischen Niveau eines Heimcomputers aus den frühen 80er Jahren, allerdings mit interessanten Schnittstellen zum Basteln, wie einem CAN-Bus, der vor allem im Automobilbereich eingesetzt wird. Programmiert wird er in Basic, ähnlich wie es Microsoft in den 70er und 80er Jahren vertrieben hat.
Duinomite
Level 3 – Raspberry Pi
Der letzte Neuzugang in meinem Spielzimmer Maschinenpark ist ein Raspberry Pi. Das Teil basiert auf einem ARM Prozessor mit immerhin 700MHz Takt und 512 MB Speicher und läuft bei mir zur Zeit unter Raspian – einer von Debian abstammenden Linux Variante. Nach dem Start empfiehlt sich noch etwas Feintuning, wie von Christoph beschrieben und alles funktioniert.
Dieser Rechner in Kreditkartengrösse ist der Idee eines PC sicherlich am nähesten, da er eine grafische Benutzeroberfläche hat, normal mit Tastatur und Maus bedient wird und mittels Ethernet Schnittstelle an das Internet angeschlossen werden kann. Für ernsthaften Einsatz als PC Ersatz taugt er aber dennoch nicht, da dem Prozessor doch sehr schnell die Puste ausgeht.
Programmieren kann man das Gerät in nahezu jeder beliebigen Programmiersprache, wobei von der Raspberry Pi Foundation Python empfohlen wird. Genau dafür ist er nämlich entwickelt worden: Sein eigentlicher Daseinszweck ist, ein möglichst billiger Computer zu sein, auf dem man leicht programmieren lernen kann. Ganz in der Tradition der billigen britischen Heimcomputer der 80er Jahre.
Raspberry Pi
Alles da, funktioniert – und jetzt?
Was macht man denn nun mit den Teilen? Nun, seien wir mal ehrlich – wenig:
Der Arduino liegt bei mir in einer Kiste. Ich habe zwar schon etwas damit rumgebastelt („Nokia 6100 Display am Arduino„), aber solange ich nicht anfange Alarmanlagen, Bewässerungssysteme für die Topfpflanzen oder Roboter zu bauen, habe ich eigentlich keine rechte Verwendung für das Ding.
Dem Duinomite geht es ähnlich – er liegt nach einigem rumprobieren („Retroflash III: Duinomite im Selbstversuch„) in der Kiste. Er ist zwar sehr einfach und macht Spass, aber ich habe keinen richtigen Einsatzzweck für das Ding gefunden.
Beim Raspberry Pi bin ich mir noch nicht sicher. Ich könnte mir vorstellen, ihn als kleines Helferlein in meinem Heimnetzwerk laufen zu lassen.
So habe ich neulich erfolgreich einen OwnCloud Server installiert, mit dem ich zentral meine Kontakte, Kalender und Fotos verwalten könnte. Eine schöne Anleitung dazu gibt es im Artikel „Raspberry Pi Owncloud (dropbox clone)“ auf Instructables. Nach der Installation kann man das kleine Kistchen problemlos ohne Bildschirm und Tastatur hinter dem Regal verschwinden lassen.
Andererseits könnte ich mir den Winzling auch gut als Retro-Zentrale vorstellen, um alte Heimcomputer Spiele zu zocken. Einen Emulator für den guten, alten Sinclair Spectrum konnte ich vorhin ohne Probleme installieren. Dazu gibt man auf der Kommandozeile ein:
Das erste Kommando installiert den Sinclair Emulator, das zweite die Betriebssysteme der verschiedenen Spectrum Versionen (48K, 128K, Plus2, Plus3) und das letzte noch einige sinnvolle Hilfsprogramme um Audiodateien in den Emulator einspielen zu können (die Software war damals auf Audio Kassetten gespeichert), Basic Listings erzeugen zu können und ähnliches.
Ganz nett, aber so richtigen Nährwert hat das noch nicht. Ich bin aber sicher, mir fällt da im Laufe der Zeit noch was nettes ein…
Im Oktober hatte ich meinem Smartphone ein Betriebssystem Upgrade verpasst – das original HTC Upgrade von Android 3.6 auf 4.0.4. Mit dem Ergebnis war ich aber seinerzeit überhaupt nicht zufrieden, wie ich im Artikel „Update für HTC Desire S – leider ungeil!“ beschrieben hatte.
Seitdem ärgerte ich mich über allerlei fiese Hakeleien. Insbesondere der Browser zickte ziemlich rum. Ganz schlimm war das bei Websites, die mit unnötig kompliziertem Firlefanz erstellt wurden, wie Facebook, Twitter und Handelsblatt, um mal meine Top 3 „Worst ever mobile Websites“ zu nennen. Und genau das, was mich auch schon vorher an dem Telefon gestört hatte ist eher noch schimmer georden: Die Zwangsverdongelung mit Apps von Facebook, Titter und Dropbox, die einen ausspionieren und die Adressen abfragen oder sogar komplett durcheinanderwürfeln.
Beim Versuch, auf dem Telefon das Cyanogenmod Betriebssystem zu installieren, bin ich seinerzeit gnadenlos gescheitert, weil alle Anleitungen davon ausgingen, dass noch der ursprüngliche Bootloader installiert ist – was nach dem Update natürlich nicht der Fall war.
Wie es doch geht, wird in dem Blogbeitrag „Die Befreiung meines HTC Desire S“ hervorragend beschrieben. Der dortigen Anleitung bin ich am Wochenende gefolgt und habe nun CM7.2 auf dem Telefon. Leider gibt es für das Gerät keine neuere Version – aber neuer bedeutet ja nicht unbedingt besser, wie ich gerade gelernt hatte.
Nach der Instalation des Betriebssystems hatte ich zunächst etwas gezögert, dann aber doch die Google Apps nachinstalliert, weil ich sonst einfach keine einigermaßen sinnvolle Möglichkeit gesehen habe, meine Kontaktdaten und Kalendereinträge zu synchronisieren.
Lockscreen
Homescreen
Bis auf einen ziemlich blöden Bug bin ich auf den ersten Blick sehr zufrieden mit dem Ergebnis meiner Bemühungen. Im Einzelnen bedeutet das:
Positiv:
Der Browser läuft wieder flüssig. Auch problematische Websites funktionieren wieder.
Keine unnötigen Schrottapps verpesten das Phone.
Das Mailprogramm ist geschmeidiger, als das von HTC ausgelieferte und lädt nicht ungefragt Bilder nach.
Die Oberfläche ist irgendwie „snappy“.
Ein Telefon, mit eingebauter Unix Shell hat auch mal was … ;-)
Negativ:
Die Kamera hat jetzt leider eine schwere Macke: Das Vorschaubild friert nach einer halben Sekunde ein. Man sieht also nicht, was man gerade fotografiert.
Der USSD-Security Bug mit den Link-Handlern ist leider wieder an Bord – lässt sich aber patchen (siehe Anleitung bei Heise).
Das ganze Prozedere ist schon recht aufwändig und sicherlich nichts für Normale Nutzer.
Ich hatte seit längerem ein Arduino und das „Nokia 6100“ LCD Shield von Sparkfun (eine Platine mit 128x128Pixel Farbdisplay zum Aufstecken) in einer Kiste rumliegen, hatte aber nie etwas damit gemacht. Da ich auf dem 29c3 auch ein bischen rumgelötet habe, dachte ich mir, dass ich jetzt auch mal das LCD Shield fertigbauen könnte.
Gesagt, getan, gelötet
Um das Shield auf den Arduino aufstecken zu können, müssen zunächst einmal Stiftleisten angelötet werden. Das st mir trotz meiner beiden linken Daumen auf Anhieb gelungen. LCD aufgesteckt, Arduino an Strom angeschlossen und das Display ist beleuchtet, zeigt aber natürlich noch nichts an. Soweit ist erst einmal alles toll!
Bastelstunde
Nun wollte ich das Display gleich mal mit den Beispielen (siehe Sparkfun Produktseite) testen. Also zunächst die Treiber und Beispiele runtergeladen und installiert. Meine Arduino IDE läuft auf einem Netbook mit Linuxmint 12 – also quasi Ubuntu. Das komplette Verzeichnis ColorLCDShield wird unter
~/sketchbook/libraries/
abgelegt. Danach können die Beispiele in der IDE unter
Bei mir ließen sich die Beispiele natürlich erst einmal nicht übersetzen, sondern brachen mit der Fehlermedung „Fatal error : Arduino.h not found“ ab. Diese Headerdatei sollte eingentlich im Verzeichnis
zu finden sein. Das war bei mir nicht der Fall. Nach längerem Hin- und Her habe ich die Arduino Software, die ich über die Softwareverwaltung installiert hatte, gelöscht und durch ein aktuelles Paket von Google ersetzt. Danach funktionierte die Übersetzung.
Leider zeigte das Display nach dem Hochladen der Beispiele nur bunten Schnee an. Mein erster Verdacht (Lötbrücken oder so) bestätigte sich nicht. Die Ursache lag am falschen Displaytyp. Sparkfun schrieb auf der Produktseite, dass zwei verschiedene Displaytypen verbaut werden: Bei einem roten Aufkleber von Epson und bei einem blauen Aufkleber von Phillips. Mein Display hatte einen roten Aufkleber und war trotzdem von Phillips. Nachdem ich im Programmcode die initialisierung von
lcd.init(EPSON);
auf
lcd.init(PHILLIPS);
geändert hatte, lief alles wie gewünscht.
Letztlich doch Erfolg
Und jetzt schauen wir mal, was man tatsächlich mit dem Teil anfangen kann…
Extrem reduziert Grafik, aber tolles Gameplay. Wie fühlt es sich an? Wie eine Mischung aus Pac-Man, einem Shooter in 2D und Adventure. Ach, probiert es doch einfach aus…
Bin gerade über zwei lustige Dinge aus der Rubrik „Das passiert, wenn Leute zuviel Zeit haben“ gestolpert. Oder auch: „Wenn die Spielidee klasse ist, ist es egal, wie die Grafik ausieht“.
Portal auf TI Taschenrechner
Erinnert sich noch jemand an Taschenrechner? War mal ein heisses Ding in den 70ern und 80ern. Ich habe hier auch noch so ein Gerät rumliegen: Einen Texas Instruments TI-84, programmierbar und mit Klötzchengrafik. Irgendjemand hat sich nun den Spass gemacht, das Spiel Portal auf dem Gerät umzetzen. Sieht gut aus. Seht selbst:
Rollenspiel mit Textgrafik – im Browser!
Und wenn wir schon mal in den 70er/80er Jahren sind: Star Wars und Rogue. Ersteres kennt jeder, das zweite vielleicht nicht. Roguelikes sind Rollenspiele in denen man durch Dungeon rennt, Monster besiegt und Schätze einsammelt. Der Witz ist, dass das alles ohne Grafik, nur mit Text symbolisiert wird. Ondřej Žára hat nun ein solches Spiel programmiert – mit Star Wars Thema und im Broser lauffähig. Genial!
Dirk Ollmetzer | Montag, 19 November 2012 | Gizmos
Ich gebe zu: Ich vermisse die Zeiten der alten Homecomputer. Irgendwie wünsche ich mir so etwas zurück. Klar – ich bin mittlerweile ein alter Sack, der sich an seine Jugend erinnert und sentimental wird.
Sentimental – ist das alles?
Es gibt aber auch einige sachliche Gründe. Damals musste man sich einfach keinen Kopf um Totalüberwachung, Trojaner, laufende Sicherheitsupdates, Urheberrechtsterror und den ganzen Scheiss machen. Weil man damals ein Spielzeug hatte, dass kein normaler Mensch verstanden hat – sein eigenes Reich. Weil man die recht simple Technik damals noch selber im Griff haben konnte.
Was der Rechner, vor dem ich momentan gerade sitze wirklich alles tut – keine Ahnung. Hoffentlich nur das, was ich will; Vielleicht läuft aber auch still und leise jede Menge Mistsoftware im Hintergrund, die mich ausspioniert.
Werbeindustrie, Softwarehersteller, Medienunternehmen, Sicherheitsbehörden, Kriminelle – irgendwer wird mir (und jedem anderen) irgendwann irgendwas aus irgendwelchen Gründen unerkannt unterschieben. Und es ist dabei gleichgültig, ob man Windows, Mac, Linux nutzt, oder per iPad oder Android ins Netz geht.
Mal ehrlich – wer von Euch, hatte noch keinen Virus auf dem Rechner?
Dabei kam ein Tastaturcomputer heraus, der nur Anschlüsse für Monitor/Fernseher, Audio in/out und zwei bis vier USB-Schnittstellen hat. Technische Basis wäre irgendein billiges SoC (System-on-a-Chip). Das Betriebssystem ist auf einer tauschbaren, aber nicht beschreibbare Speicherkarte abgelegt.
Skizze Homecomputer 2.0
Dann habe ich Stift und Block aus der Hand gelegt, geseufzt und mir gesagt, dass so etwas ausser mir ja wohl niemanden interessieren würde.
Do-It-Yourself-Computer Revival?
Und dann kam der Raspberry Pi. Ein Minicomputer für weniger als €35,-. Eine einfache Platine im Scheckkarteformat. Kein Designergehäuse. Man muss sich selbst kümmern, die Platine selber irgendwo einbauen, selber das Linux-basierte Betriebssystem auf eine SD-Karte kopieren und einsetzen. Und genau das war beabsichtigt um Kindern Computer näherzubringen. Nicht einfach bedienen, sondern verstehen. Sich selber Wissen aneignen. Das ganze ist ein Non-Profit Projekt und man hatte Sorge, ob man überhaupt die 10.000 Rechner würde verkaufen können, die man mindestens herstellen musste um auf den angezielten Preis zu kommen.
Die Idee schlug ein, wie eine Bombe. Mittlerweile sind deutlich über 100.000 Stück verkauft. Die Projekte, was man mit dem Mini-Rechner so alles machen kann, werden immer mehr.
How low can you go?
So seltsam der Raspberry Pi dem normalen Betrachter auch anmuten mag – es ist immer noch ein vergleichsweise konventioneller Rechner auf Unix-Basis. Doch es geht noch seltsamer und reduzierter.
Geoff Graham hatte offensichtlich ähnliche Gedanken wie ich – und das nötige Fachwissen, so einen Computer selber zu entwickeln. Was er dann auch tat.
Herausgekommen ist der Maximite – ein in Basic programmierbarer Minicomputer mit PIC 32 Bit Prozessor, 128KB Ram dessen Teile zusammen weniger als $20,- kosten.
Der Maximite (Quelle: http://geoffg.net, Lizenz: CC BY-NC-SA 3.0) )
Faszinierend! Leider bin ich nicht gerade ein Meister des Lötkolbens. Aber dann habe ich entdeckt, dass es diverse (legale) Nachbauten gibt, wie zum Beispiel den Duinomite von Olimex. Sieht spannend aus und brennt finanziell nicht gerade ein Loch in die Tasche. Hmm…
