Mein C64 ist tot

Im Jahr 1996 habe ich ihn von einem Lehrer an der Schule geschenkt bekommen, und ich liebte diese hellgrau-braune Kiste: Mein alter Commodore 64.

Die hohen Zeiten der Heimcomputer hatte ich natürlich nicht mehr miterlebt, doch schon damals, als gerade mein Wechsel von DOS zu Windows 95 stattfand, hatte dieser Großvater der PCs auch meine Aufmerksamkeit.

… vor allem weil Programmierung dort kein Zusatz sondern eine absolute Notwendigkeit war. Und so entstand nebenbei eine nette Freundschaft zum PC-Kollegen aus dem vergangenen Jahrzehnt.


C64 (Grafik von Wikipedia)

Wir sind heute gewohnt, dass jeder Computer mit einem Betriebssystem ausgeliefert wird und dieses automatisch beim Einschalten startet. Und wir erwarten, dass das Betriebssystem uns eine “einfache” Möglichkeit bietet Programme zu starten und Dateien zu verwalten.
Selbst das alte DOS verfolgte schon diesem Ansatz.

Doch das war nicht immer so.

Wer seinen C64 einschaltete landete vor einem BASIC Interpreter und konnte grundsätzlich nichts anderes tun, als Programmier-Kommandos einzutippen. … und mit BASIC war das alte Zeilennummern-BASIC gemeint und nicht die Luxusformen, die wir mit QBASIC, FreeBASIC oder Visual Basic heute kennen.

Das nenn’ ich mal Programmierer-freundlich: Einschalten, losproggen!

Wer BASIC Programme schreiben wollte, startete jede Zeile mit einer Zeilennummer, meist in Zehnerschritten (10, 20, 30) und anschließend dem eigentlichen Kommando.
Diese Kommandos waren zwingend einzeilig und man konnte nicht wie heute üblich Blöcke einrücken um Verzweigungen auszuführen.

Dafür gab es GOTO (Gehe-zu). Was wir heute in der Programmierung als Missgeburt bezeichnen, war damals Kernfunktion eines jeden Programmes. Man führte ein Kommando aus und hüpfte dann z.B.: per GOTO 120 zur Zeile mit der Nummer 120 um dort das nächste Kommando auszuführen.
z.B.: 100 IF A = B THEN GOTO 200 ELSE GOTO 300

Neben alten Klassikern wie PRINT um Text und Variablen auszugeben, und INPUT zum Einlesen von Tastatureingaben, waren die beiden Hardcore-Vokabel PEEK und POKE sehr beliebt.
Denn die beiden Kommandos lasen direkt von einer Speicheraddresse einen Wert, beziehungsweise schrieben einen neuen in eine Speicherzelle.

Und nachdem fast alles von Grafik bis Gerätesteuerung auf eine bestimmte Speicheradresse abgebildet war, wurden per PEEK und POKE kryptische Zahlenorgien in Programme gepackt, die Grafikanimationen und Soundeffekte produzieren konnten.

Es war wie eine Mathe-Olympiade für Brillenträger in einer ägyptischen Pyramide, wenn es darum ging zu verstehen, was mit diesen PEEKs und POKEs tatsächlich bewirkt werden sollte.


Und die Nicht-Programmierer mussten mindestens die Kommandos

  • LOAD "*", 8
  • und RUN

kennen, womit ein Programm von Diskette in den Speicher geladen (LOAD) und dann ausgeführt werden sollte (RUN). Jedes Spiel und jedes Programm lag auf seiner eigenen Disk und wurde auf diese Weiese per “Programmcode” geladen und ausgeführt.

Ich erinnere mich noch gut an Klassiker wie Great Giana Sisters, einem C64-Supermario-Äquivalent mit seinem unverkennbarem Intro, oder Mikie und ja, genau so einen Lehrer wie im Spiel hatte ich auch in meiner Schule.

Allerdings sah ich diese Spiele nie in Farbe sondern in Schwarz-Grün, weil der Monitor nur grüne Bildpunkte auf der Mattscheibe zum Leuchten bringen konnte.


Und genau dieses alte Gerät habe ich am Zweitwohnsitz wieder mal aus der Ecke geholt und musste feststellen, dass der Bildschirm leider leer blieb, als ich die fast antike Maschine einschaltete.

Tja, ich hatte nicht die Zeit die Geräte näher zu begutachten. Es könnte entweder am Monitor oder am C64 gelegen haben.
Aber nach über 30 Jahren kann man es keinem Kondensator oder anderem Bauteil übel nehmen, wenn er in den Ruhestand geht.

Vielleicht traue ich mich ja eines Tages, den alten Brotkasten zu zerlegen und nach dem Defekt zu suchen, aber vorerst muss ich leider sagen:

Lieber C64! Du warst eine Inspiration für mich und wirst in meinem Herzen und meinen Emulatoren immer weiter leben. Danke und alles Gute für deine Seele, wo immer sie nun ist.


Wenn sich eine triviale Erkenntnis mit Dummheit in der Interpretation paart, dann gibt es in der Regel Kollateralschäden in der Anwendung.
frei zitiert nach A. Van der Bellen
... also dann paaren wir mal eine komplexe Erkenntnis mit Klugheit in der Interpretation!