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.