Auf diese Artikelserie habe ich mich schon lange gefreut, wusste aber bisher nicht wie ich sie aufbauen kann.

Vor einigen Jahren auf einem Klassentreffen in den Münchner Voralpen hatte eine damalige Mitschülerin kleine Zettel von einem Ratespiel der dritten Klasse dabei.
Auf diesen Zetteln sollten wir einen Mitschüler beschreiben und wir Kinder sollten dann erraten wer da beschrieben wurde. So wie in der Grundschule lief das dann auch auf dem Klassentreffen.
Die Zettel wurden vorgelesen, und man musste erraten wer beschrieben wurde. Auf einem Zettel Stand: Mit seinem Computer kennt er sich aus wie kein anderer, aber einen Kamm besitzt er nicht.
„Kindermund tut Wahrheit kund“ und das kann schmerzhaft sein. Da stehe ich drüber, und alle wussten sofort wer gemeint ist denn es hat mich in der Tat perfekt beschrieben.

Schätzungsweise irgendwann 1983 kam mein Paps mit einem Karton nach hause. Darin befand sich ein Commodore 64 auch liebevoll „Brotkasten“ genannt.

Inklusive Commodore 1530 Datasettenlaufwerk.

Die Daten oder in meinem Fall die Spiele wurden akustisch auf einer Musikkassette abgespeichert. Dieser Punkt ist wichtig, denn an dieser Stelle kam ich das erste mal mit dem Verfahren des Frequency Shift Keying (FSK) oder in deutsch Frequenzumtastung in Berührung. Dazu später mehr.
Dieser C64 wurde zusammen mit einem Bildschirm der gefühlt so groß war wie eine Briefmarke traditionell bei uns auf dem Küchentisch aufgebaut, bis ich Monate später für den Computer in meinem Kinderzimmer einen Schreibtisch bekam.
Das praktische an Datasetten war, das man die Spiele einfach mit einem normalen Kassettenrecorder kopieren konnte.
Das schlechte war, das man nach dem Starten des Ladevorgangs erst mal 30 Minuten warten musste, bis die Daten geladen waren.
Und dann musste man die Datassette auch noch zurück Spulen.
Nachdem bei mir die Begeisterung für Computer groß war, hat mein Paps einige Zeit später einen weiteren Karton mitgebracht.

Das Commodore 1541 Single Drive Floppy Disk Diskettenlaufwerk.
Der Vorteil war das damit die Spiele wesentlich schneller geladen wurden, wobei man trotzdem zwischendurch nen Kaffee kochen konnte.
Der Nachteil war das man gleich zwei davon brauchte, um die Disketten zu kopieren. Also hat mein Paps bald noch ein zweites Laufwerk mit nach Hause gebracht. In Summe waren diese wahrscheinlich teurer als der C64 selbst aber eben ein absolutes „must have“ der damaligen Zeit. Ein weiteres „must have“ aus dieser Zeit war ein technisches Meisterwerk der Ingeneurskunst, das sich nur die Fachkundigen unter den C64 Besitzern leisten konnten. Mit dieser aus heutiger Sicht unglaublichen Entwicklung, konnte man den Speicherplatz einer 5¼″-Diskette sage und schreibe verdoppeln. Der Diskettenlocher!

Zugegebener Weise habe ich als Bub keinen Kaffee getrunken. Trotzdem würden die Ladezeiten von damals die Jugend mal erden, wo ein Update des Betriebssystems zu schlimmsten Beschwerden führt obwohl das schon schneller geht als damals ein Spiel zu laden.

Die Technischen Details des Commodore 64

  • Prozessor: MOS 6510/8500
  • Architektur: 8 Bit
  • Tacktfrequenz: 0,985 MHz (PAL-Version)
  • Speicher: 64 KB RAM, 20 KB ROM
  • Grafik: VIC II
  • Auflösung: 320 × 200 Pixel – 40 Zeichen auf 25 Zeilen in 16 Farben
  • Speichermedien: Kassette 30Minuten a 100kByte, 5¼″-Diskette 164,7 kByte pro Seite
  • DFÜ: Terminal über dataphon s21-23d

Ohhhh … Raubkopien

Nicht das ich zugeben würde illegaler Weise „Sicherheitskopien“ erstellt zu haben…

Wenn man heute über die Blütezeit der Raubkopien liest wird man Wörter wie Napster, eDonkey oder BitTorrent finden, und wie enorm es der Musikindustrie geschadet hat. Um Himmels Willen, hinterlistige Personen haben Musik aus dem Internet geladen, die auch im Radio kam.
Wer zu Zeiten des Commodore 64 und folgend Amiga 500 schon dabei war und sich zurückerinnert weiß, das alles was später kam nur ein laues Lüftchen war. Schätzungen gehen davon aus, das 20 bis 100 Kopien auf ein verkauftes Spiel kamen. Bei manchen Spielen oder Regionen sogar mehr. In Italien Beispielsweise sollen mehr als 99% der Spiele Raubkopien gewesen sein.
Hinter vorgehaltener Hand wird gemunkelt das Diskettenhersteller wie Verbatim, Boeder und Maxell selbst Verbindungen 💰 zu Softwareschmieden wie Rainbow Arts hatten um eine Hand über die „geduldete Piraterie“ zu halten. Auch wurden Hardware-Module wie das Final Cartridge ganz offen in Computermagazinen beworben, um „Sicherheitskopien“ zu erstellen.

Programmieren

Das interessanteste waren für mich zu Beginn ganz klar die Spiele. Mit der Zeit hat mich dann das Programmieren in seinen Bann gezogen. Es gab damals die Zeitschrift 64’er in der immer wieder Programme zum lernen und abtippen enthalten waren, zusätzlich zu zahlreichen Informationen und Artikeln. Wen es interessiert kann sich hier mal umschauen

Natürlich gab es auch Haufenweise Bücher. Unter anderem für Commodore Basic V2. Programme sahen dann Beispielsweise so aus:

Commodore BASIC:
10 PRINT CHR$(147); : REM BILDSCHIRM LOESCHEN
20 PRINT "*** WUERFELGENERATOR ***"
30 PRINT
40 W = INT(RND(1) * 6) + 1
50 PRINT "DU HAST EINE"; W; "GEWUERFELT!"
60 PRINT
70 PRINT "NOCHMAL WUERFELN? (J/N)"
80 GET A$: IF A$ = "" THEN 80
90 IF A$ = "J" THEN GOTO 10
100 IF A$ = "N" THEN PRINT "TSCHUESS!": END
110 GOTO 80

Datenfernübertragung (DFÜ)

In den 90ern hat meine Mama mit mir öfters mal Verwandte besucht deren Tochter in meinem Alter war. Der ältere Bruder hatte auch einen Commodore 64 und hatte nach meiner Ansicht viel Ahnung. Bei einem dieser Besuche lag da eine Schachtel mit einem Akustikkoppler rum. Da Michael nichts damit anfangen konnte (oder wollte) hat er mir das Teil kurzerhand geschenkt. Es war ein dataphone in der Ausführung s21-23d/64. Dieses Modell war speziell für den User-Port des C64 vorbereitet, hatte ein passendes Schnittstellenkabel dabei, und als Highlight war noch eine Spezielle Plexiglas-Halterung beigelegt.

Das Verfahren das im Akustikkoppler genutzt wird habe ich oben bereits kurz erwähnt. Es heißt Frequency Shift Keying, und basiert auf exakt dem gleichen Prinzip wie beim Datasettenlaufwerk. Beim Senden werden digitale Zeichen in Töne umgewandelt was sich Modulation nennt, und beim Empfangen werden Töne in digitale Zeichen umgewandelt, also demoduliert. Daher kommt im übrigen auch der Begriff Modem. Nach dem Aufsetzen des Telefonhörers auf das Dataphone

konnte man das Gerät mit etwas Feintuning, Heimweh und viel Rückenwind dazu bewegen Daten mit 1200 Baud im Voll-Duplex Modus zu Übertragen.

Wie funktionierte die „Einwahl“?

An dieser Stelle möchte ich mit einem Gerücht aufräumen, das selbst in Fachkundiger Lektüre und auf sonst professionellen Websites immer wieder Erwähnung findet. Nämlich das Anwählen der Gegenstelle vom C64 aus im deutschen Festnetz mit Standardhardware. Dazu muss man zunächst die Funktionsweise hinter den analogen Telefonen verstehen. Es gibt im Grunde zwei Methoden wie ein analoges Telefon wählen kann.
IWV „Impulswahlverfahren“: hierbei wird der Stromkreis im Telefon Impulsweise geschlossen. Kennt man den richtigen „Tackt“ kann man auch Wählen, indem man die Gabel in der richtigen Geschwindigkeit drückt, was die Vermittlungsstelle auswertet.
DTMF „Mehrfrequenzwahlverfahren: steht für „dual-tone multi-frequency“. Hierbei werden pro Taste zwei Töne mit unterschiedlicher Frequenz zur Vermittlungsstelle geschickt und dort ausgewertet.
Da der Akustikkoppler galvanisch nicht mit dem Telefon verbunden war, war es diesem daher nicht möglich die Impulse zu erzeugen. Dazu kommt noch, das der Hörer ja abgenommen, und auf die Gummimuffen des Akustikkopplers aufgelegt war. Wählen also ausgeschlossen. DTMF wurde Mitte der 1980er Jahre testweise von der Deutschen Post eingeführt, aber etablierte sich erst 1989/90 großflächig als Standard. Hätte man also 1984 tatsächlich schon DTMF in der Vermittlungsstelle gehabt, war es dem Akustikkoppler trotzdem nicht möglich gezielt zwei verschiedene Töne gleichzeitig zu erzeugen und damit zu wählen, da es in der Elektronik fürs Frequency Shift Keying nicht vorgesehen war. Zu guter Letzt wurde der AT-Befehlssatz, auch bekannt unter dem Namen Hayes-Standard zwar schon 1981 in den USA eingesetzt, konnte aber von den Akustikkopplern nicht verarbeitet werden. Es gab ab 1981 schon Modems die eben jenes Verfahren beherrschten, wie eben das Hayes Smartmodem 300, aber eben keines für den C64. So setzt sich zwar die Basis des Hayes Standards wie folgt zusammen:

  • AT = Attention (Achtung, es folgt ein Befehl)
  • D = Dial (Wählen)
  • T = Tone (Tonwahlverfahren / Mehrfrequenzwahlverfahren)

Konnte aufgrund der Gegebenheiten aber damals noch nicht eingesetzt werden. Ebenso wenig wie ATDP wobei das P für Pulse, also Impulswahlverfahren steht, sollte dieser Einwand kommen. Denn selbst wenn CCGMS 1983/84 schon Hayes konnte, schlichtweg das erste richtige Modem mit AT Befehssatz für den C64 erst 1987 mit dem Commodore 1670 kam. Vorher hat Commodore auf das eigene Wählverfahren mit PEEK und POKE gesetzt.

Es sind auf jeden Fall ziemlich viele wenn’s. Es gab also keine Hardware von der Stange die das konnte, und wenn war es eine Bastellösung. Damit will ich keinesfalls sagen das das etwas schlechtes ist. Es wäre auch ein schönes Projekt für mich gewesen.

Kurzum, man nahm den Hörer ab, wählte die Nummer per Hand, wartete auf den Pfeifton und drückte den Hörer auf die Gummimuffen.
Hier ist bei vielen wohl der Wunsch der Vater des Gedankens gewesen!

Was konnte man mit diesen Modems damals überhaupt machen?

Anders als häufig (auch von mir) erwähnt, konnte man sich damit NICHT mit BTX verbinden.
BTX steht in der heutigen Zeit Symbolisch für das damalige „Internet“ so wie heute alle Taschentücher als Tempos bezeichnet werden.
Tatsächlich war BTX „Bildschirmtext“ das offizielle System der Deutschen Bundespost.

Man kann es sich als eine Art Videotext vorstellen. Jede Seite hatte eine feste Nummer zu der man navigieren konnte. Nur mit spezieller von der Post zugelassener Hardware konnte man sich mit BTX verbinden.
Wenn man sich ausschließlich die Anzahl der Zeichen pro Zeile und die Zeilenanzahl von 40×24 anschaut könnte man meinen, das es für den C64 problemlos möglich gewesen sein müsste BTX darzustellen. Schaut man sich aber die Details an, wird sofort klar warum es eben nicht ging. Ein BTX Zeichen hat 12×10 Pixel wodurch eine benötigte Bildschirmauflösung von 480×250 Pixel resultiert. Zum einen konnte der C64 nur 320×200 Pixel. Zum anderen konnte man keine 12×10 Pixel Matrix in eine 8×8 Pixel Matrix reinquetschen. Wenn also heute von BTX geredet wird, ist in den allermeisten Fällen BBS gemeint. Das Bulletin Board System war im Prinzip der Vorgänger des heutigen Internets. Wie der Begriff schon sagt, war die Kernfunktion das „Board“. Ein Forum in dem man sich mit anderen Usern austauschen also auch Nachrichten hinterlassen konnte. Weil es keiner besser wusste hat man auch in Deutschland einfach Mailbox dazu gesagt. Das war eigentlich nicht richtig, denn das BBS konnte viel mehr. Beispielsweise konnte man Daten hoch oder herunterladen. Spiele Online laden, oder sich mit einem anderen Spieler Verbinden um ein Spiel zu zweit zu spielen, und noch mehr… Später gab es ein neues System für E-Mails welches diese über Mailboxen verteilten. Und genau an dieser Stelle entstand der Konflikt. Es hat keiner mehr Mailbox gesagt wenn er über BBS redete. Und da es damals noch nicht für alles DEnglische Wörter gab war als Ersatz dafür das gute BTX der Deutschen Bundespost gerade recht.

Also wie war das Damals mit dem Bulletin Board System?

Eine Person, der sogenannte System Operator (SysOp) hat ein BBS gehostet. Dieser Host war über ein oder mehrere Modems mit dem Telefonnetz verbunden. Auf den Host konnten sich immer nur soviele User verbinden wie es Leitungen/Modems gab. Also meistens nur ein User. War besetzt musste man es später wieder probieren. Eigentlich war es immer gut wenn besetzt war, denn telefonieren war sünd teuer. Und wenn man nicht von einer Telefonzelle aus telefonierte, wusste man gar nicht so recht was es genau gekostet hat. Damals wurde nicht der Preis pro Minute verrechnet, sondern genau andersrum. Es gab eine feste Kosteneinheit von 20 Pfennig (wegen der Telefonzellen). Abhängig davon wohin man telefonierte und zu welcher Uhrzeit hat die Vermittlungsstelle dann einen Tackt ans Telefon geschickt. In der Telefonzelle ist dann der nächste 20er reingefallen. Zuhause hat man es garnicht mitbekommen.
Hatte man also das Pech, und die Leitung war frei, konnte man sich nach belieben auf dem BBS rumtreiben, mit dem SysOp chatten oder eben die beschriebenen Funktionen nutzen.

Die Grafik war genial, aber der Informationsgehalt auf 99% der Boards war nicht so berauschend. Multiplayer Spiele waren selten und außerdem war es viel zu teuer. Aus heutiger Sicht konnte man also nicht wirklich viel damit anfangen.

War man allerdings auf den richtigen Boards konnte man sich ein Telefonverzeichnis der Interessantesten BBS-Telefonnummern herunterladen. Oder aller BBS-Telefonnummern. Über mehrere Stunden so über Nacht, und musste diese auch gleich ausdrucken. Auf anderen Boards gab es spezielle Tools die man heute als Cyber-Security-Tools bezeichnen würde und konnte diese dort herunterladen. Und auf wieder anderen Boards gab es Informationen die, sagen wir mal nicht für die Allgemeinheit bestimmt waren. Und damit wurde es so richtig interessant.
Nehmen wir mal an man liest eine Telefonnummer die durch das weglassen sämtlicher Informationen indirekt als Superinteressant gekennzeichnet ist, und nehmen wir in diesem rein fiktiven Szenario weiter an das Systeme damals ausschließlich über Passwörter gesichert waren. Hätte man also damals diese Telefonnummer angerufen, wäre eine Eingabemaske erschienen zum Eingeben eines Passworts. Hätte man dann eines dieser Cyber-Security-Tools benutzt die man heute als Brute-Force bezeichnen würde, hätte ein kleiner Junge ein paar Stunden später festgestellt das er auf dem BBS einer bestimmten namhaften Firma ist, und dort eine Weiche verstellen kann. Theoretisch!

Anm. d. Red.

Im zarten Alter von 14 Jahren musste ich leider das gesamte C64 System inklusive Commodore MPS 1230 Drucker und vieler Diskettenboxen verkaufen, um Geld für den Amiga 2000 flüssig zu machen. Dieser hat den C64 abgelöst aber das ist eine andere Geschichte. Übrig geblieben sind nur 2 Disketten und der Akustikkoppler, mit dem die Käufer anscheinend nichts anfangen konnten oder wollten.

Disketten heißen übrigens im Original Floppy-Disk. „floppy“ übersetzt man im allgemeinen mit schlaff oder schwabbelig, weshalb wir früher Schwabbelscheiben dazu gesagt haben.

Da ich keine Bilder von meinen Commodore Geräten habe und um keine Bildrechte zu verletzen, habe ich mir alle Bilder in diesem Beitrag die einen weißen Hintergrund haben von Gemini erstellen lassen.

Die zwei Screenshots des Oasis BBS sollen einen Eindruck davon vermitteln wie BBS damals aussah. Dazu später mehr.

Da ich das Retro Feeling beim 64’er spüren wollte, habe ich mir einen emulierten Commodore 64 auf einen vorhandenen Raspberry Pi 3B+ installiert. Auch dazu später mehr.

Im zweiten Teil meiner Reihe möchte ich zeigen wie sich die Computertechnik während der Zeit in der ich sie nutze, verändert hat. Ich habe immer wieder den Eindruck das viele die Begriffe kennen aber nicht wirklich wissen was da überhaupt los ist. Hier möchte ich Datenmengen, Datenraten und Rechenleistung greifbar machen und eine Art Vorlage an die Hand geben, wie man diese Begriffe auch Kindern oder digitalen Einsiedlern verdeutlichen kann – gerade dann, wenn die Glasfaserleitung wieder mal zu langsam ist oder das 5G am Handy die Eieruhr rotieren lässt. Da der gesamte Beitrag sonst zu unübersichtlich wird, kann man die Grafischen Darstellungen mit einem klick auf das Blaue Pfeilchen Ein- und wieder Ausblenden.

Die Schlauberger unter euch werden während dem Lesen sagen: „stimmt ja alles nicht“.
Zumindest würde ich mir das denken. Da gibt es ja Stopp Bits, Parity, Kompression, Parallel Slowdown, Collision Avoidance, oder gar Protokoll Overhead, und vieles mehr. Ja das stimmt alles aber das geht zu sehr in die Tiefe und das lasse ich bei meinen Darstellungen und Rechungen bewusst weg, und zeige nur die Brutto Daten und Datenraten. Auch sind die Jahres- und Größenangaben keine Wissenschaftlich ermittelten Min, Max oder Mittelwerte, sondern von mir geschätzte Angaben. Also los gehts…

Speicherkapazität

Digital kommt vom Wort „digitus“ was Finger heißt. Da Menschen seit jeher mit den Fingern Zählen entstand daraus im englischen der Begriff Digital, für Ziffer. Im Digitalen werden Informationen in exakte, einzelne Werte zerlegt. Die Grundlage für frühe Rechenmaschinen und Computer ist das Binärsystem. 1 oder 0, Strom fließt oder nicht. Das ist die Basis und nennt sich Bit. Die nächst größere Einheit nennt sich Byte. In der Pionierzeit der Computer war die Größe eines Byte variabel und konnte aus 3 bis 12 Bit bestehen. Erst durch IBM wurde in den 1960ern der Standard von 8 parallelen Datenleitungen etabliert, da IBM damals den Markt beherrschte. Die Entwickler überlegten wie viele verschiedene Zeichen man darstellen will, und hat sich auf 256 geeinigt also 8 Bit.

Da Computer im Binärsystem (Basis 2) rechnen, passt der Teiler nicht beim SI-Präfix 1000, sondern bei 1024 und nennt sich dadurch IEC-Präfix. Demnach ist ein Kilobyte 1024 Byte groß. Die Schreibweise der Einheiten ist im Internet eine wilde Mischung. Hier kommen Kilobyte, KB, kByte, KiB und viele mehr zum Einsatz.
Mein erstes Speichermedium mit dem ich gearbeitet habe, war die Datasette. Auf 30 Minuten Band passten 100 kByte was 102.400 Zeichen/Buchstaben entspricht. Zur Einordnung: Ein durchschnittlicher Krimi/Thriller hat ~170.000 Buchstaben.

JahrMediumSpeicherplatzDetails / Schnittstelle
1983Datasette100 kByte100 kByte a 30 Minuten Band
19845¼“ Diskette166 kByte166 kByte pro Seite

Somit passen auf eine Seite einer 5¼“ Diskette 169.984 Zeichen.

JahrMediumSpeicherplatzDetails / Schnittstelle
19873½“ Diskette720 kBytez.B. Amiga
1987MFM-Festplatte20 MB’yte‘Zorro II Bus – Commodore Amiga
ISA Bus Einsteckkarte – x86 PC
19903½“ Diskette1,44 MBx86 PC
1990ATA-Festplatte40 MBISA Bus Einsteckkarte – x86 PC
1991SCSI-Festplatte100 MBISA Bus Einsteckkarte – Industrie Standard
1998CD ROM650 MBCD RW mit bis zu 700 MB
2000Ultra ATA/PATA30 GBPCI Einsteckkarte oder OnBoard – x86 PC
2003DVD RW4,7 GBUnterschiedliche Standards

Auf eine DVD passen 29.688 5¼“ Disketten

JahrMediumSpeicherplatzDetails / Schnittstelle
2004SATA200 GBPCI Einsteckkarte oder OnBoard
2006BlueRay25 GBBlueRay RW mit bis zu 75 GB
2006SATA II400 GBPCI Einsteckkarte oder OnBoard
2025M.2 SSD4 TBMulti Layer Cell Solid State
2026SATA III / SAS 444 TBHAMR Mozaic 4+

Hier sei angemerkt, das solche Festplatten aktuell für Rechenzentren gebaut werden und weniger für den Heimanwender.

Es ist also interessnat wie verschwenderisch wir seit langer Zeit mit Speicherplatz umgehen.

Datentransferraten

Kommen wir zum nächsten Punkt, und zwar wie schnell Daten von A nach B kommen. Mit welcher Technologie das gemacht wird ist erst mal egal. Die App liegt im App-Store und soll aufs Handy. Die Daten liegen im Speicher und müssen zur CPU.

Jeder der mit IT etwas zu tun hat sollte es kennen: Wargames! Wenn nicht das Buch, dann den Film. David Lightman dringt mit seinem überragenden IMSAI 8080 in einen Militärischen Supercomputer ein, und startet dadurch versehentlich den Weltweiten Thermonuklearen Krieg. Hat mich sehr in den Bann gezogen. Wargames das Buch hat 24047 Worte welche zumeist durch ein Leerzeichen getrennt werden. Im deutschen hat ein Wort durchschnittlich 6 Buchstaben, wobei wir mit Leerzeichen bei 7 sind.. Somit hat das Buch 168329 Buchstaben und passt gerade so, wenn nicht perfekt auf eine 5¼“ Diskette. Dieses Buch ist nun unsere Basis.

Zugegeben, ich hatte zunächst mehrere andere Bücher im Sinn. Zum Beispiel Colossus von D. F. Jones oder Nineteen Eighty-Four (1984) von George Orwell. Die hatten aber knapp über 300.000 Buchstaben, weshalb sie zwar auf eine 5¼“ Diskette gepasst hätten, aber nur mit Diskettenlocher und das hätte meine Rechnung verfälscht. Also hab ich geschaut und bin im Keller auf das Buch Wargames gestoßen. Das war ein sogenanntes „Movie Tie-in“. Bedeutet basierend auf dem Drehbuch geschrieben, und diese sind zwangsläufig ehr kürzer. Also gehen wir damit ins Rennen.

JahrVerbindungDatenrateDetails
1983Cassette Port800 Bit/s300 Baud – Pulse Length Encoding
Datasette
1983User Port960 Bit/s1200 Baud – 8N1
z.B. Akustikkoppler
1983Commodore Serial Bus3,2 kBit/sIEC-Bus
Diskette
1996ISDN64 kBit/spro Kanal, max 128 kBit/s
2000DSL768 kBit/sAsynchron
2004DSL 20002000 kBit/sOption zu FastPath

Um im Jahr 1983 das Buch „Wargames“ in Digitaler Form von einem BBS zu laden, hätte man theoretisch 7 Minuten gebraucht. Das ging nicht weil man die Daten nicht schnell genug weg schreiben konnte. Im Jahr 1996 benötigte man dazu noch ca. 21 Sekunden. Im Jahr 2000 waren es noch 1,8 Sekunden und im Jahr 2004 noch 0,66 Sekunden. Bildlich gesprochen: 2004 konnte man gedruckte Bücher gar nicht so schnell aus dem Fenster werfen, wie man sie in digitaler Form heruntergeladen hatte!

JahrVerbindungDatenrateDetails
2006ADSL2+16000 kBit/s
2010VDSL50000 kBit/s
2026Glasfaser1 GBit/sFibre to the Home
2026LAN2,5 GBit/sNetzwerk
2026USB-C40 GBit/sThunderbolt 4
0,8 Sekunden pro Film

Ab 2004 lese ich keine Bücher mehr. Ich schaue nur noch DVD’s, weshalb ich mir den Film kaufen musste. Dazu gab es dann von 20th Century Fox die Option zu einer „Digital Copy“. Der Film hat 114 Minuten Spielzeit wodurch die DVD mit ~3,9 GB nicht ganz voll ist. Um die Sicherheitskopie herunterzuladen benötigte man 2004 circa 4,5 Stunden. 2010 benötigte man 11 Minuten. Wenn wir diese „Digital Copy“ heute mit Gigabit Glasfaser aus dem Netz laden, müssen wir lediglich 32 Sekunden warten. Um das für unser Buch zu übersetzen. Mit Glasfaser kann man jede Sekunde 6317 digitale Kopien vom Buch „Wargames“ herunterladen.

Rechenleistung

Gordon Moore hat während der Anfangszeit der Chipfertigung (Integrated Circuit) bzw integrierten Schaltkreisen bereits 1965 erklärt, das sich die Packungsdichte, oder eben die Anzahl von Transistoren auf einem Wafer innerhalb von 2 Jahren verdoppelt. Das konnte er zu der Zeit eigentlich noch gar nicht belegen, da es schlichtweg keine Vergleichswerte gab. Trotzdem gab ihm die damalige Entwicklung recht, weshalb es später das Mooresche Gesetz (engl. Moore’s Law) genannt wurde. Nach dem die Theorie aufgestellt war, wurde diese ehr zu einer selbsterfüllenden Prophezeiung. Denn es sind verschiedenste Industriezweige an der Entwicklung besserer Mikrochips beteiligt. Diese müssen sich auf gemeinsame Meilensteine einigen und in ihrer Roadmap einplanen. Heute geht man von 18 Monaten aus.

Da die Packungsdichte und die Rechenleistung nur indirekt linear verlaufen, schauen wir uns der Einfachheit halber den MOS 6510 und einen Intel Core i7-14700K im direkten Vergleich an.

MIt der Einheit MIPS (Million Instructions Per Second) wird die Rechenleistung von älteren Prozessoren oder Mikrocontrollern ohne Fließkommaeinheiten gemessen. MIPS misst, wie viele Millionen Befehle ein Prozessor pro Sekunde ausführen kann. Das wäre wohl der fairste Vergleich.

  • Hier kommt der C64 auf ca 0.4 MIPS
  • Der Intel kommt auf mickrige 400.000 MIPS

Mit der Einheit FLOPS (Floating Point Operations Per Second) wird die Rechenleistung beim Berechnen von Fließkomma-Zahlen (Dezimalzahlen) gemessen. Da der C64 keine Hardware für Kommazahlen hatte, mussten diese mühsam per Software im BASIC berechnet werden.

  • Hier kommt der 64er immerhin auf rund 2 kFLOPS
  • Der Intel hingegen kommt bei Volllast auf wahnwitzige 1.500 GFLOPS

Gewichtet man das, ist eine moderne CPU im logarithmischen Mittelwert 22 Millionen Mal schneller als der MOS 6510. Um so beachtlicher ist es was man mit dem 64er damals schon alles machen konnte.

Nachdem die Theorie nun geklärt ist, geht es nahtlos zur Praxis über. Der Raspberry Pi 3B+ war wie erwähnt noch übrig. Dann benötigte dieser auch ein Zuhause. Dazu habe ich einen weiteren Mod meines vielfach verwendeten Raspberry Pi Gehäuses in 3d entworfen. Gedruckt habe ich das Gehäuse in dem schönen beige, das damals auch mein Commodore 64 hatte. Für die Joystickanschlüsse habe ich zwei 9-poolige D-Sub Buchsen mit Kabeln versehen. Es sollen ja die db9 Retro Joysticks verwendet werden. Leider sind die Competition Pro damals mit in den Verkauf gewandert. Dafür habe ich aber noch die Sticks vom Amiga.

Die Kabel mussten passend auf die 40-poolige Stiftleiste.

Alles einbauen.

Soviel zur Hardware meiner Commodore Station. Nun gehts an die Software.

Emulation des Commodore 64

Um den C64 zu simulieren, gibt es drei elegante Wege wobei es nicht die eine „perfekte“ Möglichkeit gibt.

  • Wer den C64 in seiner pursten Form haben will, den Pi beispielsweise in ein original Gehäuse einbauen und das System einfach über die Stromversorgung abschalten will, nutzt BMC64. Dieser Emulator ist eben so schnell in den Startbildschirm gebootet wie das Original, benötigt leider zusätzliche Dateien die im Packet nicht enthalten sind, und stellt ausschließlich die traditionelle Commodore Landschaft dar.
  • Wer hauptsächlich Spielen und ein flexibles System haben will, installiert sich Retropie direkt aus dem Raspberry Imager Baukasten. Erwarten darf man hier nicht zu viel. Gerade für ältere Pi Modelle wie 3B+ wird es hier problematisch. Alternativ setzt man sich die emulationstation selbst auf ein Debian System auf. Verhindert dadurch aber leider nicht die minimalistisch integrierte Installation von VICE.
  • Wer mehr machen will als Spielen und beispielsweise automatisiert in den C64 Starbildschirm booten will, sollte VICE als „Stand Alone“ Version Installiere. Hier hat man die maximale Freiheit und die meisten Optionen was Schnittstellen angeht. Problematisch ist hier vor allem das Ausschalten. Das System muss gezielt heruntergefahren werden um die SD Karte nicht zu beschädigen, wobei es hierfür aber keine Option im VICE gibt. Zumindest habe ich die bei mir bisher nicht gefunden.

BÄM – Hach wie herrlich

Sodala, das wichtigste sind die Screenshots für die Erinnerung. Wer sich für eine der letzten beiden Optionen entschieden hat, kann sich direkt aus Vice heraus Screenshots knipsen die so groß sind wie Briefmarken. Alternativ kann man sich scrot installieren. Dieses Tool macht einen Screenshot direkt aus dem Grafikspeicher (Framebuffer) des Raspberry Pi

Bash:

sudo apt install scrot -y

Knipsen kann man beispielsweise mit 5 Sekunden Verzögerung

Bash:

sleep 5 && scrot /home/steffen/c64_screenshot.png

oder auch ohne Verzögerung. Als nächstes wollte ich noch meine Joysticks einbinden. Dazu braucht es db9_gpio_rpi. Zunächst herunterladen

Bash:

git clone https://github.com/marqs85/db9_gpio_rpi.git
cd db9_gpio_rpi

dann Registrieren und Kompilieren

Bash:

sudo ./dkms-install.sh

und dann Konfigurieren

Bash:

sudo nano /etc/modprobe.d/db9.conf

Wichtig für meine Amiga Sticks ist die Zeile

Bash:

sudo nano /etc/modprobe.d/db9.conf

für zwei Joysticks

Nano:

options db9_gpio_rpi map=2,2

mit je zwei Feuerknöpfen.

Jetzt kann’s losgehen. Wie damals habe ich meine „Commodore Computeranlage“ auf dem Esszimmertisch aufgebaut. Dabei hatte ich irgendwie ein Déjà-vu. Muss das da sein? Was sollen jetzt die ganzen Kabel da? Das muss dann aber weg. Aber wie damals meine Mama musste meine Frau da einfach durch.

Mein erstes Spiel damals war Donkey Kong auf Datasette. Also Datasette ins Laufwerk, Im Kopf zurückspulen und LOAD

Am Laufwerk Play drücken und erst mal Kaffeepause.

Da war ich wieder in der Arcade.
Giana Sisters war dann auf Diskette mein Favorit. Also Diskette rein, LOAD“$“,8 … RUN

Nach dem Spaß beim Spiel heißt es alles wieder Abbauen. Dieses war der dritte Streich, und der vierte folgt so gleich.

So, Finger aus der Hosentasche. Jetzt gehts ans Eingemachte.
Ich bin dermaßen im Retrotunnel. Commodore is a helluva drug!

ACHTUNG: Das folgende ist übelstes Nerd Zeug!
Aber keine Sorge, ganz unten kommen ein paar Bilder, die könnt ihr euch anschauen 😉

Für das intensive Retro Feeling wollte ich meinen Akustikkoppler wieder zum pfeifen bringen. Wie bereits beschrieben findet man heute keine Bulletin Board Systems (BBS) mehr. Aus diesem Grund habe ich nach einer Alternative für das Terminalprogramm gesucht. Nach einigem Grübeln wollte ich es nutzen wozu man auch heute noch Terminalprogramme verwendet. Nämlich Remote per SSH mit einem Linux Server arbeiten. Dazu habe ich mir im Groben folgende Verbindungskette überlegt.

  • Über den C64-Emulator das Terminalprogramm CCGMS starten.
  • Von dort über eine virtuelle serielle Brücke auf dem Raspberry Pi zugreifen.
  • Weiter über einen USB zu Seriell Wandler zu meinem Dataphone s21-23d/64.
  • Dort ein echtes analoges Telefon auflegen und über die analoge Telefonleitung weiter.
  • Ein SLIC-Modul zur Simulation des Telefonnetzes verwenden.
  • Und von da über einen ESP32 via WLAN und SSH auf den Debian-Server.

Schien machbar zu sein. Also los geht es, aber nicht in dieser Reihenfolge.

Installation und Konfiguration von socat

Der wichtigste Baustein auf meinem Weg war ein kleines Tool namens socat welches die unterschiedlichsten Pipes erzeugen kann. Installiert wird das wie folgt:

Bash:

sudo apt update
sudo apt install socat -y

Danach kann man eine virtuelle serielle Schnittstelle /tmp/vtty0 erzeugen die später eine Pipe zu /dev/ttyUSB0 erzeugt. Nach dem starten mit

Bash:

socat PTY,link=/tmp/vtty0,raw,echo=0 EXEC:"bash --login",pty,ctty,stderr,icanon=0,echo=0,icrnl=1,opost=1

läuft das Tool zunächst mit einer Pipe zur lokalen Bash, und man muss zum Testen in einer anderen bash weiterarbeiten. Achtung beim Nachbauen, denn je nach Anwendungsfall und Aufrufparameter wird die Pipe gekillt, wenn eine etablierte Verbindung einseitig geschlossen wird. In einem solchen Fall muss man den Prozess überwachen, und die Pipe automatisiert neu starten, damit sie für die nächste Verbindung zur Verfügung steht. Testen kann man das nun in der zweiten bash mit

Bash:

socat STDIN,raw,echo=1 GOPEN:/tmp/vtty0,raw,echo=0

indem man socat als Client einsetzt. Da es kein Terminalprogramm ist erscheinen an manchen Stellen gegebenenfalls Steuerzeichen. Darüber muss man sich keine Gedanken machen. Diese werden durch die Verwendung eines echten Terminalprogramms entfernt. Noch ein Tipp: Ich will es nicht verheimlichen! Dieser Punkt hat mich am gesamten Projekt die bei weitem meiste Zeit gekostet, und um ein Haar auch meinen Verstand. Je nach Verbindungstyp wie zum Beispiel Telnet oder SSH reagiert der Server unterschiedlich auf Tastatureingaben und vor allem Zeilenumbrüche, carriage return (CR) oder line feed (LF). Dazu bei Bedarf im Manual folgende Parameter anschauen: isig,icanon,echo,xcase,lnext,noflsh,iexten,brkint,icrnl,inpck,istrip,inlcr,igncr,opost.
Wenn beim Test alles passt, keine Treppen oder Leerzeilen entstehen, ist alles richtig eingestellt

so wie hier. Nun können Client so wie Pipe mit STRG + C gekillt werden.
Jetzt kommt der wirklich heiße Scheiß. Mit denselben Formatierungsparametern in

Bash:

socat PTY,link=/tmp/vtty0,raw,echo=0 EXEC:"ssh -tt user@localhost 'stty -F /dev/ttyUSB0 1200 raw -echo; cat < /dev/ttyUSB0 & cat > /dev/ttyUSB0'",pty,ctty,stderr,icanon=0,echo=0,icrnl=1,opost=1

werden die seriellen Daten in eine SSH Verschlüsselung gezwungen und über /dev/ttyUSB0 mit 1200 Baud rausgeschoben. Ja, und natürlich auch wieder rein. Leider gibt es hier nun zwei Stolpersteine. Beim ersten Start wird gefragt ob der SSH Fingerprint gespeichert werden soll, was mit „Ja“ erledigt ist. Problematisch ist allerdings, das man zum Angegebenen user@server_ip jedesmal ein Passwort eingeben muss. Bevor man also die socat SSH Pipe durch crontab -e mit dem Eintrag

Bash:

@reboot socat PTY,link=/tmp/vtty0,raw,echo=0 EXEC:"ssh -tt user@localhost 'stty -F /dev/ttyUSB0 1200 raw -echo; cat < /dev/ttyUSB0 & cat > /dev/ttyUSB0'",pty,ctty,stderr,icanon=0,echo=0,icrnl=1,opost=1 > /dev/null 2>&1 &

in den Autostart integriert, fehlen noch ein paar Schritte. Zunächst muss der User auf jedem System vorhanden sein, auf das man sich verbinden will. Des weiteren benötigt man eine SSH-Key-Authentifizierung (oder auch SSH-Schlüsselpaar genannt). Mit

Bash:

ssh-keygen -t rsa -b 4096
ssh-copy-id user@127.0.0.1

wird das Schlüsselpaar generiert. Bei der Frage nach einer „Passphrase“ einfach Enter drückten, damit der Autostart später nicht nach einem Passwort für den Schlüssel selbst fragt. Mit dem Copy wird der Schlüssel in die Datei ~/.ssh/authorized_keys des Ziel-Users geschreiben. Wenn ssh dort einen passenden Schlüssel findet, lässt es einen ohne Passwort rein. Da hiermit der Generalschlüssel für diesen User vorhanden ist kann man ihn

Bash:

ssh-copy-id user@server_ip

per ssh auch auf die anderen Server kopieren. Der Befehl baut automatisch eine SSH-Verbindung zum Zielsystem auf. Das Prinzip bleibt dasselbe. Die 4096 ist die Schlüssellänge von SSH in Bits. Sicherheitsbedenken? Das Schlüsselpaar steht nur dem User der angegebenen Zieladresse und nur vom lokalen System aus zur Verfügung. Zum testen gibt man folgendes ein:

Bash:

ssh user@server_ip

Wenn man eine neue SSH-Verbindung öffnet, und alles geklappt hat, benötigt man dazu kein Passwort mehr.

FTDI FT232RL & Dataphone s21-23d/64

Als nächstes muss der Akustikkoppler mit einem Userport zu RS232 Adapter verbunden werden, welcher wiederum mit einem RS232 zu USB Adapter verbunden ist, welchen man dann in den Raspberry Pi stecken kann. So zumindest der Plan von meiner KI. Aber irgendwas daran ist doch Faul. Achja, die C64 Hardware hatte damals durch die Bank 5V Schnittstellen. Und somit hatte auch die C64 Version des Dataphones s21-23d/64 eine 5V Schnittstelle. Also nix Standard RS232 Adapter. Bei meinem Fräsenprojekt allerdings hatte ich eine Platine gelötet die man an den USB-Pot stecken konnte. Auf der Platine war der FT232RL-Chip von FTDI verbaut. Dieser Chip ist ein USB-zu-TTL/UART-Wandler, der serielle Signale auf einem 5V-Pegel ausgibt.

Leider gibt es beim Dataphone s21-23d/64 eine weitere Besonderheit zu beachten: Da der Userport des C64 mit invertierten TTL-Pegeln arbeitet, durfte ich die Signale des FTDI-Chips nicht einfach so einspeisen. Ich musste das Dienstprogramm FT_PROG von FTDI wieder rauskramen und den FT232RL so umprogrammieren, dass er die TTL-Signale (RX und TX) hardwareseitig invertiert.

Um die FTDI-Platine mechanisch mit dem Dataphone zu verbinden, habe ich das originale Kabel (das einen speziellen C64-Userport-Stecker hatte) abgezogen. Stattdessen habe ich einen neuen DIN-Stecker verwendet, die Leitungen angelötet und RX, TX sowie Masse (GND) direkt mit den entsprechenden Ausgängen des FTDI-Wandlers verbunden.

Nach einem kurzen Test über socat kam ein lautes, vertrautes Düdeln aus dem Lautsprecher des Dataphone! Scheiße, Gänsehaut…

Detailinformationen über die genaue Funktionsweise der Akustikkoppler und der Datenübertragung über analoges Kabel würde hier den Rahmen sprengen. Einfach mal nach FSK, CCITT, v.21 und v.23 suchen.
Somit wäre die eine Seite fertig und Bereit.

Die Brücke ins analoge Telefonnetz

Als nächstes kommt ein altes analoge Siemens Telefon ins Spiel da ich kein grünes Wählscheibentelefon der Post mehr hatte. Wenn man ein Telefon abhebt, erwartet es eine aktive Telefonleitung. Da ich keine Vermittlungsstelle der Post in meinem Keller gefunden habe, musste ich diese selbst bauen. Dazu muss man die typischen Zustände und Spannungen eines klassischen analogen Systems verstehen.

  • Im Ruhezustand wenn der Hörer aufgelegt ist, liegt eine hohe Gleichspannung von 48-60V DC am Telefon an.
  • Um das Telefon zum klingeln zu bekommen wird der Gleichspannung eine Wechselspannung aufmoduliert wodurch man stellenweise 90V AC bei 50 Hz auf der Leitung hat.
  • Hebt man ab (Off-Hook) schließt sich der Stromkreis im Telefon. Die Spannung auf der Leitung bricht durch den Innenwiderstand des Telefons ein was die Vermittlungsstelle erkennt. Diese entfernt die Wechselspannung (Klingeln) wodurch folgend ca. 10V DC auf der Leitung sind.
  • Wenn ich am Telefon eine Taste drücke, werden durch das IWF (Impulswahlverfahren) eben so viele Impulse erzeugt wie die Nummer die man drückt. Das erkennt die Vermittlungsstelle und wertet diese aus.

Um diese komplexen Aufgaben nicht diskret aufbauen zu müssen, habe ich mir für 3,49€ ein KS0835F SLIC-Modul (Subscriber Line Interface Circuit) bei AliExpress besorgt.

Ein SLIC übernimmt die typischen BORSCHT-Funktionen:

  • Battery (Speisung des Telefons mit Gleichstrom)
  • Overvoltage (Schutz vor Überspannungen)
  • Ringing (Erzeugung des Rufstroms)
  • Supervision (Überwachung, ob der Hörer abgenommen wurde)
  • Coding (Zweidraht- zu Vierdraht-Schnittstelle)
  • Hybrid (Trennung von Sende- und Empfangsaudio)
  • Testing (Testfunktionen)

Ich habe das Telefon direkt an die Ausgänge (Tip und Ring) des KS0835F angeschlossen. Die Steuersignale für den Gabelkontakt (Switch Hook) habe ich über einen Pegelwandler an den ESP32 übergeben, um die 5V-Signale des SLIC-Moduls auf die 3,3V des ESP32 zu reduzieren. Die Audio-Ein- und Ausgänge des SLIC-Moduls habe ich für den nächsten Schritt vorbereitet.

Signalverarbeitung TCM3105

Um die analogen FSK-Töne der Telefonleitung beziehungsweise des SLIC-Moduls wieder in ein digitales Signal zu verwandeln, benötigt man einen speziellen Modem-IC. Eine moderne Option wäre ein Entwicklungsboard mit dem FX614-Chip gewesen. Ich hatte jedoch kürzlich mein altes BayCom-Modem (das damals für Packet Radio im Amateurfunk genutzt wurde) in der Hand. Auf diesem ist der Klassiker TCM3105 verbaut. Also dachte ich mir: Warum nicht das nutzen? Ich musste das BayCom-Modem nur minimal modifizieren.

Normalerweise klaut sich dieses Modem seine Betriebsspannung parasitär aus den Handshake-Leitungen (wie RTS und DTR) der RS232-Schnittstelle des PCs. Da ich die RS232-Schnittstelle hier nicht nutze, funktionierte das natürlich nicht. Ich habe das Gehäuse geöffnet und kurzerhand drei Drähte direkt an den TCM3105 gelötet, um eine externe +5V-Spannungsversorgung einzuspeisen und die reinen TTL-Pegel (RX und TX) direkt abzugreifen. Diese Signale habe ich auf freie, unbelegte Pins der D-Sub-Buchse des Baycom-Modems herausgeführt.

Pegelwandlung ADUM1401

Da der TCM3105 mit 5V TTL-Pegeln arbeitet, mein ESP32 jedoch nur 3,3V an seinen GPIOs verträgt, musste eine Pegelwandlung her. In meiner Bastelkiste befand sich noch eine Platine mit einem ADUM1401 die ich als Testplatine für meinen Slotcar Tisch angefertigt hatte. Das ist ein digitaler Isolator, der nicht nur die Pegel sauber zwischen der 5V und der 3,3V Seite umsetzt, sondern die beiden Systeme auch galvanisch trennt. Da der 1401 drei Vor- und einen Rückkanal hat, ich aber wegen der „+5V“ Switch Hook Leitung zwei Rückkanäle brauchte musste ich die Richtung wechseln weshalb ich den 5V DAC für die Tests entfernen musste.

ESP-32 ssh WLAN Bridge

Die 3,3V Signale (RX, TX und das Switch-Hook-Signal vom SLIC) laufen nun im ESP32 zusammen. Die Software, die ich für den ESP32 geschrieben habe soll folgendes machen:

  • Beim ersten booten spannt der ESP32 ein eigenes WLAN auf über das man die Software Konfigurieren kann.
  • Danach verbindet sich der ESP32 mit dem eingestellten lokalen WLAN.
  • Sobald mein eingestellter Linux-Server erreichbar ist, baut der ESP32 im Hintergrund eine SSH-Verbindung dorthin auf.
  • Sobald die Verbindung steht, wartet das Programm im Hintergrund auf das Signal des Gabelkontakts (Switch Hook).
  • Wenn ich den Hörer des analogen Telefons abhebe (Switch Hook: aktive) initialisiert sich die UART zum TCM3105.

Das ganze habe ich dann Schrittweise getestet, und jeder dieser Schritte hat für einen erneuten Gänsehaut-Moment gesorgt. Wenn man den Telefonhörer abhebt und hört das klassische leise rauschen der Telefonleitung.

Und dann initialisiert man die UART Schnittstelle im ESP32. Die TX Leitung ist dann im Leerlauf immer auf Logisch-HIGH. Sobald der TCM3105 die 1 sieht, erzeugt dieser die typischen 1200 Hz womit das Carrier Signal steht. Aus der Hörmuschel kommt das typische monotone pfeifen der Gegenstelle. Yes!!!
Sobald man sich wieder einigermaßen im Griff hat, kann man den Hörer auf die Gummipads des Akustikkopplers drücken und schonmal den nächsten Test mit socat machen.

CCGMS unter Commodore 64

Jetzt wird es knifflig. Zunächst muss ich erwähnen das ich an dieser Stelle auf die stand allone Version von VICE umstellen musste da unter Emulationstation hier wichtige Funktionen nicht mitinstalliert werden. Dann habe ich mit dem CCGMS 2021 Fork von Alwyz gestartet, weil ich zunächst das Original nicht gefunden habe.

  • VICE starten und CCGMS laden.
  • Mit F12 das VICE Menü öffnen
  • Settings -> Peripheral devices -> RS232 settings
  • Userport RS232 emulation aktivieren
  • Device 1 auf /tmp/vtty0 setzen
  • Zurück zu CCGMS
  • Mit F7 Modem Parameter setzen
  • Mit M das Modem auf Userport stellen
  • Mit B die Baudrate auf 1200
  • Mit S kann man die Einstellungen speichern
  • Mit F8 den Zeichensatz von PETSCII auf ASCII umstellen

Wichtig ist, den Device nicht auf /dev/ttyUSB0 zu setzen. Da erreicht man zwar auch den Akustikkoppler, aber ohne den SSH Tunnel. Wenn alles richtig eingestellt ist kann man traditionell mit CONNECT 1200 den Device 1 öffnen

und einmal ENTER drücken. Und was soll ich sagen? Bin ich schon drin oder was?

Es hat alles funktioniert so als würde man direkt vor PuTTY sitzen, während das Dataphone vor sich hingedüdelt hat wie damals. Allerdings hat mich doch überrascht das die Farben so perfekt gepasst haben. Und je mehr ich mich damit beschäftigt habe, desto klarer wurde mir: Ich war nicht der Erste mit dieser Idee. Alwyz hatte viele zusätzliche Funktionen bereits fest in seinen modernisierten Fork integriert. Das war im ersten Moment ein echter Dämpfer, denn auch VICE wurde dahin gehend ergänzt die Schnittstelle ins Internet zur Verfügung zu stellen. Ich wollte aber keine aufpolierte, moderne Komfort-Software auf dem C64, die mir die Arbeit abnimmt – ich wollte das Original von damals! Also Rolle rückwärts. Nach längerer Suche habe ich dann das Original von 1984 in der Version 4.0 von Craig Smith gefunden.

Auch hier das selbe Vorgehen, aber zunächst wie damals den Hintergrund auf weiß und die Schriftfarbe auf Grau stellen. Das Farbschema sowie die geänderten Verbindungseinstellungen „S“peichern. Mit CONNECT 1200 den Device 1 öffnen.

Und siehe da, ein Träumchen. Da war er wieder, der Retro Tunnel

Noch was zu den Farben und dem Protokoll der Terminalkommunikation. Es heißt ja CCGMS (Commodore Color Graphics Manipulation System).
Da ich nicht verstanden habe warum es zwar nicht perfekt funktioniert, aber trotzdem Farbunterschiede vorhanden sind muste ich mich intensiver damit Beschäftigen.
Die Erfinder des ANSI-Standards (offiziell ECMA-48 bzw. ISO/IEC 6429) haben sich für die Terminals und Konsolen ein System ausgedacht, das man als Steuerung mit Escape-Sequenzen bezeichnet. Dabei ist der Teil der Textformatierung im Bereich SGR (Select Graphic Rendition) definiert.
Anschauen kann man sich das in der ANSI-SGR-Tabelle.
Zunächst zu den Farben:
Auf dem Commodore 64 kann man im CCGMS seine eigenen Farben einstellen.
Mit ctrl + B schaltet man die Hintergrundfarben hintereinander durch.
Mit ctrl + 1..8 wählt man die ersten 8 Farben als Schriftfarbe aus.
Mit C= +1..8 wählt man die nächsten 8 Farben als Schriftfarbe aus.
Im VICE Emulator kommt es auf das Keybordmapping an. Ich habe mir die CTRL Taste auf STRG und die C= Taste auf TABULATOR gelegt.
Die Farben der Escape Sequenzen allerdings kann man nicht verstellen. So wie ein Sys-Op sein BBS erstellt hat, exakt so sollte es ja dargestellt werden. Das kann man sich wie bei einer modernen Website vorstellen. Da wird die Schriftfarbe beispielsweise auch mit #FF0000 „rot“ vorgegeben, und der Browser bietet keine Option diese Schriftfarbe immer als #00FF00 „grün“ anzuzeigen.
Soweit hoffentlich verständlich. Nun zum System der Escape Sequenzen.

Escape String:

\x1b[32m

Die Farbeinstellung in der Konsole wird traditionell durch Escape ‚\x1b[‚ eingeleitet, gefolgt von einer oder mehreren durch ; getrennte SGR Nummern. Der Abschluss für SGR erfolgt durch den Terminator ‚m‘. Dazu haben die Entwickler des Standards zu der damaligen Zeit die SGR-Nummer in Zehnerblöcke aufgeteilt, mit viel Platz für Reserven.
0 – 9 beispielsweise waren die „Stile“ wobei die 0 für „Reset“ steht.
30-39 war die erste „Bank“ der Farbpalette wobei 38 & 39 unbelegt war.
40-47 war die erste „Bank“ der Hintergrundfarbe
Da zum Zeitpunkt der Entwicklung des Standards nur mit einer 8 Farben Palette zu rechnen war, wurde die 30-37 für diese ersten 8 Vordergrundfarben reserviert. Später kam für die zweite „Bank“ die 90-97 für die „Hellen“ Vordergrundfarben dazu. Beim Commodore VIC-II sah die Farbpalette etwas anders aus.

Das Prinzip war aber das gleiche.
Mit \x1b[7;32;41m beispielsweise stellte man die Textfarbe auf grün, die Hintergrundfarbe auf rot sowie den Text invertiert dar. Mit \x1b[0m stellte man es auf die „Standardfarben“ zurück.
Schaut man sich das beim C64 an, ist die 32 der Index $02 mit der Farbe rot. Die 41 hatte den Index $01also weiß, und die 7 hat den Text invertiert dargestellt.
Heute schaut das ganze nun beispielsweise so aus:

Escape String:

\x1b[38;2;255;0;0m

Die 38 die früher Reserve war besagt, es soll die Vordergrundfarbe detailiert eingestellt werden. Die 2 besagt, verwende den 24-Bit RGB Modus, gefolgt von den RGB Werten 255;0;0 also #FF0000. Das Escape und der Terminator ist unverändert geblieben. Warum ist es aber so, das der Interpreter des Terminalprogramms für diverse Farben der modernen Konsolen bei mir ein dunkles Grau verwendet?
Zunächst dachte ich, die 38 ist der VIC-II Index $08. Das hätte vom Verhalten her alles erklärt. Nur leider wäre das Orange gewesen.
Craig Smith allerdings war damals schon so weitsichtig, das er ein Emergency Fallback eingebaut hat. Er hat nämlich einprogrammiert, das bei unbekannten Nummern der Index $0C verwendet werden soll, was eben das Dunkelgrau der zweiten „Bank“ ist.
Das heißt also, sobald irgend eine moderne Farbe (38) eingestellt werden soll, fällt des CCGMS auf die Dunkelgrau zurück, und wird durch die 0m auf die Standardfarben zurückgesetzt. Funktioniert also perfekt auch mit modernen Escape Sequenzen.

Mein Ziel ist erreicht – und wie!
Der Akustikkoppler tüftelt vor sich hin und der Prompt der Linux-Bash blinkt auf dem C64-Bildschirm. Gänsehaut pur.
Ohne Abkürzung moderne Linux-Server steuern mit dem Sound, dem Look und dem unschlagbaren Vibe der 1980er Jahre.
Es ist laut, es ist langsam, es ist vollkommen verrückt.
Und genau deshalb liebe ich mein Hobby!

C64 goes Internet

Der Vollständigkeit halber! Wie oben bereits erwähnt, wurde VICE dahingehend erweitert, das man auf einen Lokalen TCP Port zugreifen kann, ohne groß Klimmzüge machen zu müssen. Deshalb möchte ich hier eine Aussage die ich in dieser Artikelserie getätigt habe zurücknehmen. Denn es gibt tatsächlich noch/wieder aktive Bulletin Board Systeme oder heute besser Bulletin Board Server. Man könnte über

Bash:

socat TCP-LISTEN:25232,bind=127.0.0.1,reuseaddr,fork TCP:<server_ip>:<port>

eine Verbindung zu einem BBS herstellen, und diese dann unter VICE nutzen. Die einfachste Methode ist allerdings das Tool tcpser. Dieses emuliert ein Modem auf einem lokalen Port das alles mitbringt inklusive ATDT.

Bash:

git clone https://github.com/FozzTexx/tcpser.git
cd tcpser
make

Nach der Installation startet man das Tool wie folgt.

Bash:

tcpser -v 25232 -p 23 -s 38400

Damit lauscht es intern auf dem Port 25232, und extern auf dem Port 23 (Telnet) falls man selbst ein BBS stellen will. Da es das damals so nicht gab, muss man auch nicht auf Authentizität achten. Deshalb können wir „für einen 64er“ ordentlich Gas geben, und die Verbindungsgeschwindigkeit auf 38400 Baud stellen. Alternativ 1200 wer es klassisch will. Unter Vice aktiviert man nun die ACIA Emulation auf $DE00 und einem Device seiner Wahl, dem Ziel 127.0.0.1:25232 und 38400 Baud. Danach CCGMS 2021 wie folgt einstellen

und mit RETURN bestätigen.
Nun kann man mit ATDT server:Port ein BBS seiner Wahl „anrufen“.

CCGMS:

ATDT 8bit.hoyvision.com:6400

Ein großes Lob an die Community, die BBS ins Internet-Zeitalter gerettet hat!
Es läuft gut, macht auch eine gewisse Zeit Spaß. Allerdings ist der Informationsgehalt wie früher ehr dürftig. Und so spannend diese Brücke zwischen den Welten ist: Für einen Romantiker wie mich fehlt ohne die analoge Telefonleitung, das klassische pfeifen, und alles drum herum schlicht das Herzstück des damaligen Erlebnisses. Es ist faszinierend, aber für mich nicht authentisch.

Ich hoffen ich konnte euch mit meinem Retrofieber anstecken und hoffe der ein oder andere hatte Spaß beim lesen. Über Anregungen bin ich wie immer Dankbar.

Schon bevor mein letzter Beitrag zur Commodore 64 Reihe online war, hatte ich schon einige mit meinem Retrofieber angesteckt. Zumindest in der Theorie. Denn man unterhält sich ja und dabei kommt zwangsläufig auf den Tisch womit man sich derzeit beschäftigt. Unter anderem ging es um den

Commodore 16

Das Modell war auch mal in meinem Besitz. Um 1985 kaufte ein Bekannter meines Vaters den Rechner, nutzte ihn jedoch nicht, sodass er irgendwann bei uns landete. Optisch war das Teil auch schick. Hab ich schon erwähnt das mir der Brotkasten sehr gut gefallen hat?!

Der C16 war nicht kompatibel mit dem C64. Zudem hingen die Ports beim 64er ungeschützt direkt an den Chips was ihn extrem anfällig für ESD-Schäden machte, wogegen der 16er unempfindlicher konstruiert wurde. Genau das machte ihn für mich zum perfekten Bastel-Objekt und er landete im Keller. Zum einen war wie erwähnt die Hardware robust, und zum anderen war die Syntax des Commodore BASIC die selbe. Wenn gleich die Speicheradressen zumeist andere waren wodurch man PEEK und POKE nicht eins zu eins übernehmen konnte. Commodore BASIC 3.5 hatte allerdings einige Neuerungen die recht gut waren. Man konnte beispielsweise einzelne Programmzielen anzeigen lassen mit LIST 250. Oder einen kompletten Abschnitt mit LIST 250-350. Mit RENUMBER konnte man neu in 10er Schritten durchnummerieren lassen. Zudem hat er mit dem TED einen neuen Chip bekommen der zu den 16 Grundfarben auch 8 Helligkeitsstufen pro Farbe konnte. Abzüglich 8x Schwarz und noch 8x Schwarz konnte er 112 Farben gleichzeitig darstellen. Und er besaß zwei Tonkanäle. Obwohl der 16er keine echte Bit-Samplerate besaß, nutzten Programmierer einen Trick: Sie steuerten das 8-stufige Lautstärkeregister im TED extrem schnell über CPU-Interrupts an (z. B. mit 4 kHz oder 8 kHz). Durch das schnelle Ändern konnte man eine Art 4-Bit-PCM-Audio erzwingen – das klang zwar etwas rauschig, spielte aber echte Sprache oder Musik ab. Damit war Commodore damals dem x86 um Jahre voraus.

1989 nahm unsere Hauptschule unter der Leitung von Lothar Waigand an dem Projekt „Informatik an Hauptschulen“ des Bayerischen Staatsministeriums für Unterricht und Kultus teil. Lothar, unser Lehrer meldete die Schüler an dem Wettbewerb zu diesem Projekt an. Dazu musste man sich ein Programm überlegen welches man in der Schule schreiben musste und welches dann eingereicht wurde. Ich hatte mein Programm zuhause unter Commodore Basic 3.5 vorbereitet.

Nun war es leider so, das Commodore Basic nicht ganz das selbe war wie GW-Basic welches wir in der Schule verwendet haben, wenn gleich die Basis beider aus der Hand von Bill Gates stammt. Vor allem aber gab es unter VGA nur 16 Farben von denen nur 8 für den Hintergrund zur Verfügung standen. Also habe ich in der Schule das Programm so umgebaut, das nicht die Helligkeit sondern die Farben durchgezählt wurden.

Die Commodore Version hatte potential für den ersten Platz, aber so hat es leider nur für den zweiten gereicht. 😉

Commodore 128

Das Zweite Thema war der Commodore 128.

In unserer Unterhaltung ging es speziell um das Modell 128D. Damals ein wichtiger Unterschied 🙂 Da kaum Spiele speziell für den 128er entwickelt wurden, haben die meisten Besitzer diesen in der Praxis fast ausschließlich als einen etwas moderneren, schickeren 64er genutzt. Da im inneren des C128 die Komplette Hardware vorhanden war die auch der C64 hatte, konnte man den 128er im C64-„Modus“ laufen lassen. Dazu gab es drei Möglichkeiten:

  • Automatisch über ein Cartridge Modul
  • Durch drücken der Commodore Taste beim Einschalten (Beim BMC64 Emulator je nach Tastaturlayout und Belegung z.B. SHIFT)
  • Durch Eingeben des Befehls GO 64

Da der 128er erst um 1986 auf den Markt kam war dieser außer bei meinem Nachbarn für mich kein Thema. Zwei Jahre später war bereits der Commodore Amiga 500/2000 am kommen.

Technische Daten:

  • Prozessor: MOS8502 – 2 MHz, Zilog Z80 4 MHz
  • Speicher: 128 KB RAM
  • Betriebssystem: Basic 7.0, CP/M Plus
  • Auflösung: 640×200 bei 112 Farben

Allerdings finde ich zwei Dinge doch recht beachtlich. Zum einen hatte der 128er bereits einen Nummernblock, und zum anderen ist die Ähnlichkeit zwischen Commodore 128 und Amiga 500 frappierend.

Ebenso sieht es beim 128D/128DCR aus, der bereits ein Desktop-Gehäuse hatte und dem Amiga 2000 ziemlich ähnlich sieht nur ein bisschen flacher.

Wer noch interessante Anmerkungen oder Geschichten zur Commodore Ära hat, immer her damit.

Last but not least habe ich für Interessierte hier noch ein paar nützliche Dateien wie Beispielsweise die Pinouts oder ROMs zum Download bereitgestellt.