modems-und-dataphon

Dataphon und frühe Post-Technik

Wer frühe DFÜ nur aus späteren PC-Modems kennt, unterschätzt leicht, wie stark die Gerätewelt in Deutschland lange von der Deutschen Bundespost geprägt war. Ein Dataphon war nicht bloß „ein Modem“, sondern wirkte wie ein amtlich ernstes Stück Fernmeldetechnik: schwer, grau, klar funktional, mit der Ausstrahlung eines Geräts, das mehr nach Behörde als nach Hobby aussah.

Diese Geräte waren Teil einer Zeit, in der man sich technische Kommunikation nicht einfach aus beliebigen Komponenten zusammensteckte. Anschlüsse, Zulassungen, Leitungsnutzung und Kosten standen unter deutlich engeren Rahmenbedingungen. Genau das gab der gesamten DFÜ-Praxis ihren eigenen Ton: weniger Bastel-Freiheit als später, dafür eine sehr konkrete Materialrealität.

Im BTX-Umfeld war das besonders sichtbar. Bildschirmtext arbeitete in seiner frühen Form mit einer asymmetrischen Übertragung: Seiten kamen typischerweise mit 1200 Bit pro Sekunde vom System zum Teilnehmer, die Anforderung zurück lief deutlich langsamer mit 75 Bit pro Sekunde. Das fühlt sich heute fast absurd an, war damals aber eine saubere Konsequenz des Nutzungsszenarios: viel Anzeige, wenig Rückkanal. Für den Benutzer hieß das in der Praxis: Seite anfordern, warten, zuschauen.

Gerade das war lehrreich. Man bekam ein unmittelbares Gefühl dafür, dass Datenverkehr nicht „einfach da“ ist. Er musste über reale Geräte, reale Leitungen, reale Schaltvorgänge und reale Gebühren erst hergestellt werden.

Was ein Modem wirklich macht

Das Wort Modem ist eine Zusammenziehung aus Modulator und Demodulator. Genau darin steckt die Kernaufgabe. Ein Rechner arbeitet intern mit digitalen Zuständen. Die klassische analoge Telefonleitung war dagegen für Sprache und damit für Signale in einem begrenzten hörbaren Frequenzbereich ausgelegt. Das Modem musste deshalb digitale Daten in ein für diese Leitung geeignetes analoges Signal übersetzen und am anderen Ende wieder zurückwandeln.

Die frühen Verfahren arbeiteten mit vergleichsweise einfachen Ton- beziehungsweise Frequenzzuständen. Spätere Modems nutzten komplexere Modulationsarten und konnten dadurch mit jedem übertragenen Symbol mehr als nur ein einzelnes Bit transportieren. Genau deshalb ist die umgangssprachliche Gleichsetzung von Baud und Bit pro Sekunde nur bei bestimmten einfachen Verfahren korrekt.

Ein Modem war damit immer auch ein Übersetzer zwischen zwei Welten. Auf der Rechnerseite standen Zeichen, Bytes, Schnittstellenleitungen und Protokolle. Auf der Telefonseite gab es Pegel, Frequenzen, Leitungsdämpfung und Störungen. Die Qualität eines Modems zeigte sich darin, wie zuverlässig es diese Welten miteinander verband.

Der heute nostalgisch wirkende Einwahlton war deshalb kein akustischer Zierrat. Er war die hörbare Form realer Signaltechnik. Solange der Lautsprecher eingeschaltet blieb, konnte man einen Teil des Verbindungsaufbaus unmittelbar mithören.

„Das Modem machte aus Bits Töne – und aus einer Sprachleitung für einige Minuten eine Datenleitung.“

Akustikkoppler gegen direktes Modem

Der Unterschied zwischen Akustikkoppler und Direktmodem ist technisch simpel und praktisch riesig. Beim Akustikkoppler wird der Telefonhörer in Gummimuscheln gelegt. Lautsprecher und Mikrofon des Kopplers verwandeln Daten in Töne und umgekehrt. Die Daten gehen also akustisch durch ein Gerät, das ursprünglich für Sprache gedacht war. Das ist elegant improvisiert, aber zwangsläufig störanfällig.

Das Direktmodem spart diese akustische Zwischenebene. Es koppelt elektrisch an die Leitung beziehungsweise an die dafür vorgesehene Schnittstelle. Dadurch entfallen einige der mechanischen und akustischen Schwächen des Kopplers: verrutschender Hörer, Nebengeräusche, Pegelprobleme durch schlechte Auflage oder wechselnde Hörerbauformen. Dafür braucht man aber mehr Normierung, passendere Hardware und eine sauberere Integration.

Für einen technisch geprägten Nutzerkreis waren beide Formen interessant, aber auf unterschiedliche Weise. Der Akustikkoppler lehrte unmittelbar, dass Übertragung ein fragiles Ereignis ist. Das Direktmodem verlagerte den Schwerpunkt: weg von der physischen Hörerkopplung, hin zu Parametern, Befehlen, Wahlroutinen und Softwaredisziplin.

300 / 1200 / 2400 Baud – was das praktisch bedeutete

Heute wirken 300, 1200 oder 2400 Baud wie reine Museumszahlen. Damals waren das klar unterscheidbare Lebensgefühle. Geschwindigkeit war nicht nur Benchmarksprache, sondern direkt sichtbarer Arbeitsunterschied. Man konnte beobachten, wie schnell eine Zeile kam, wie lange ein Login brauchte und ob ein Dateitransfer realistisch war oder eher Geduldsübung blieb.

Grob kann man sagen: 300 Baud bedeutete im Alltag etwa „warten und zuschauen“, 1200 Baud „benutzbar mit Geduld“ und 2400 Baud „endlich halbwegs flüssig“. Das klingt nüchtern, trifft die Praxis aber besser als jede spätere Nostalgie.

Wichtig ist auch der Unterschied zwischen theoretischer Datenrate und realer Erfahrung. Protokoll-Overhead, Steuerzeichen, Bestätigungen, Leitungsqualität und eventuelle Wiederholungen fraßen immer einen Teil des Tempos. Wer nur die nackte Zahl im Kopf hat, erinnert die Praxis zu freundlich.

Baud ist nicht automatisch Bit pro Sekunde

Historisch wird bei Modems sehr oft pauschal von „300 Baud“, „1200 Baud“ oder „2400 Baud“ gesprochen. Für die Alltagssprache ist das verständlich, technisch muss man aber unterscheiden. Baud bezeichnet die Zahl der übertragenen Symbole beziehungsweise Signalzustände pro Sekunde. Bit/s bezeichnet die tatsächlich übertragene Bitrate.

Wenn jedes Symbol genau ein Bit trägt, können beide Zahlen gleich sein. Sobald ein Modulationsverfahren mehrere Bits in einem Symbol codiert, steigt die Bitrate über die Baudrate. Das wurde mit den schnelleren Modemgenerationen immer wichtiger. Deshalb ist für die Standards selbst die Angabe in bit/s die sauberere Form.

V.21, V.22, V.23 und V.22bis – Standards hinter den Zahlen

Hinter den gebräuchlichen Geschwindigkeitsangaben standen internationale Empfehlungen der damaligen CCITT, heute ITU-T. Sie definierten nicht einfach nur eine Zahl, sondern das Verhalten kompatibler Modems auf dem öffentlichen Telefonnetz.

Die Standardisierung war entscheidend. Ohne gemeinsame Modulations- und Handshake-Regeln hätte ein Modem eines Herstellers nicht zuverlässig mit einem Gerät eines anderen Herstellers kommunizieren können. Die Gegenstelle musste dieselbe „Sprache“ auf der Leitung verstehen.

In der Praxis bedeutete das trotzdem nicht, dass jede Verbindung perfekt war. Leitungsqualität, nationale Zulassungsbedingungen, Implementierungsdetails und die Fähigkeit eines Modems, auf schlechte Verhältnisse zu reagieren, entschieden weiterhin darüber, ob eine Verbindung stabil blieb.

Simplex, Halbduplex und Vollduplex

Eine weitere Unterscheidung betrifft die Richtung des Datenverkehrs. Simplex erlaubt Daten nur in eine Richtung. Halbduplex erlaubt beide Richtungen, aber nicht gleichzeitig. Vollduplex ermöglicht gleichzeitiges Senden und Empfangen.

Für interaktive Terminal- und Mailboxsitzungen war Vollduplex besonders angenehm, weil Eingabe und Rückmeldung gleichzeitig stattfinden konnten. Asymmetrische Verfahren wie V.23 lösten eine andere Aufgabe: Sie stellten in einer Richtung deutlich mehr Datenrate bereit als in der Gegenrichtung. Für Dienste, bei denen der Teilnehmer nur kurze Anforderungen sendete und anschließend größere Bildschirmseiten empfing, war das durchaus logisch.

TAE, Amtsleitung, Besetztzeichen und Gebühren

Frühe DFÜ war immer auch Fernsprechalltag. Eine Verbindung begann nicht in einem Browserfenster, sondern an der TAE-Dose und an der Frage, ob die Leitung frei ist, ob die Gegenstelle erreichbar bleibt und was jeder neue Versuch an Kosten auslöst. Das klingt banal, war aber zentral. Leitungskapazität war knapp, und jede längere Online-Zeit hatte eine unmittelbar spürbare materielle Seite.

Das Besetztzeichen war dabei keine kleine Unannehmlichkeit, sondern Teil des normalen Betriebs. Einwählen bedeutete oft: Nummer wählen, auf Träger oder Antwort warten, scheitern, neu versuchen. Je nach Gegenstelle, Tageszeit und Dienst war das eher Routine als Ausnahme. Dazu kamen lineare Gebührenlogiken, bei denen man Zeit tatsächlich im Hinterkopf behielt.

• TAE und Leitung: Die Anschlussseite war kein beliebiger Stecker, sondern Teil einer reglementierten Fernmeldewelt.
• Amtsleitung: Wer eine Verbindung hielt, belegte real eine Leitung. Das war technisch und sozial spürbar.
• Besetzt: Wiederholtes Anwählen gehörte zur Praxis, nicht zur Randstörung.
• Gebühren: Grundkosten, Nutzungszeit und je nach Dienst weitere Gebühren machten Online-Zeit messbar teuer.

Genau deshalb entwickelte sich früh eine ökonomische Technikdisziplin. Man bereitete die Sitzung vor, kannte die Gegenstellen, notierte Kommandos, überlegte die Reihenfolge von Abrufen und tippte nicht planlos in die Leitung hinein. Online-Zeit war nicht die natürliche Grundbedingung, sondern ein bewusst hergestellter Zustand mit Preis.

„Man ging nicht einfach online. Man nahm Leitung, Zeit und Kosten bewusst in Kauf.“

Impulswahl, Tonwahl und der Weg zur Gegenstelle

Bevor zwei Modems miteinander verhandeln konnten, musste überhaupt erst eine Telefonverbindung entstehen. In älteren Netzen geschah die Wahl häufig noch per Impulswahlverfahren. Später setzte sich die Mehrfrequenzwahl durch, bei der jede Taste durch eine Kombination zweier Töne dargestellt wird.

Frühe Modemlösungen waren nicht automatisch selbstwählend. Teilweise wurde die Verbindung über das Telefon aufgebaut und anschließend auf die Datenverbindung umgeschaltet. Wahlfähige Direktmodems machten diesen Vorgang später zum Bestandteil der Softwaresteuerung: Nummer an das Modem senden, wählen lassen, Besetztzeichen erkennen, gegebenenfalls auflegen und erneut versuchen.

Dadurch entstand die bekannte Redial-Praxis. Gerade viel benutzte Mailboxen hatten nur eine begrenzte Zahl von Leitungen. War die Leitung besetzt, musste der nächste Versuch warten. Automatische Wiederwahl war komfortabel, änderte aber nichts an der physischen Realität: Eine einzelne besetzte Telefonleitung blieb besetzt.

RS-232 und die Rechnerseite des Modems

Auf der einen Seite hing das Modem an der Telefonleitung, auf der anderen am Rechner. Dort war lange eine serielle Schnittstelle nach dem Umfeld von RS-232 beziehungsweise verwandten V.24/V.28-Konzepten üblich. Für den Anwender bedeutete das: Neben der Geschwindigkeit auf der Telefonleitung gab es auch eine separate Geschwindigkeit zwischen Rechner und Modem.

Diese beiden Raten mussten nicht identisch sein. Spätestens mit Fehlerkorrektur und Datenkompression konnte es sinnvoll sein, die serielle Verbindung zwischen Rechner und Modem schneller einzustellen als die eigentliche Leitungsrate. Das Modem puffert Daten und verarbeitet sie intern.

Hinzu kamen Parameter wie Datenbits, Parität und Stopbits. Die berühmte Schreibweise 8N1 bedeutet acht Datenbits, keine Parität und ein Stopbit. Andere Dienste oder ältere Systeme konnten andere Einstellungen verlangen.

Falsche Einstellungen führten zu einem besonders typischen Fehlerbild: Die Verbindung stand, aber auf dem Bildschirm erschien nur Zeichensalat. Genau dann war die Versuchung groß, die Telefonleitung zu verdächtigen, obwohl das Problem auf der lokalen seriellen Seite lag.

Terminalprogramme und Einwahlroutinen

Ohne ein brauchbares Terminalprogramm blieb selbst das beste Modem oder Dataphon weit unter Wert. Die Software war die eigentliche Arbeitsoberfläche: Zeichenformat, Geschwindigkeit, Echo, Zeilenende, Mitschrift, Upload/Download, Nummernverwaltung, Redial und nicht selten kleine Skripte oder Makros für immer gleiche Abläufe.

Praktisch bestand eine Einwahlroutine aus mehreren Schichten gleichzeitig: Gegenstelle kennen, richtige Nummer wählen, Geschwindigkeit und Format passend setzen, auf das Antwortverhalten achten, Login-Sequenz durchlaufen und dabei immer mitdenken, ob ein Fehler von der Leitung, dem Modem, dem Gegenüber oder schlicht von der falschen Einstellung kommt.

Hier zeigte sich auch schon ein früher Unterschied zwischen bloßer Nutzung und technischer Haltung. Wer DFÜ nur konsumierte, wartete auf Erfolg. Wer sie verstand, behandelte jede Sitzung wie einen reproduzierbaren Ablauf mit Zuständen, Parametern und Fehlerbildern.

Hayes-AT-Kommandos – als das Modem textgesteuert wurde

Ein entscheidender Komfortschritt war die Steuerung des Modems mit Textkommandos. Der von Hayes populär gemachte AT-Befehlssatz wurde in zahlreichen kompatiblen Modems zum De-facto-Standard. „AT“ steht für attention: Das Modem erkennt daran, dass nun ein Befehl und keine Nutzdaten folgen.

Damit konnte ein Terminalprogramm das Modem initialisieren, eine Nummer wählen, auflegen oder Zustände abfragen. Hersteller ergänzten später eigene Befehle und Register, sodass aus dem einfachen Grundprinzip teilweise umfangreiche Initialisierungsstrings wurden.

Für den Benutzer war das ein großer Unterschied. Das Modem wurde von einem weitgehend eigenständigen Fernmeldegerät zu einem programmierbaren Peripheriegerät des Rechners. Telefonbuch, automatische Wahl und Wiederwahl ließen sich dadurch direkt in die Kommunikationssoftware integrieren.

Das Pfeifen beim Handshake – was dort tatsächlich geschieht

Der klassische Modem-Verbindungsaufbau war hörbar, weil die Geräte zunächst über den Sprachkanal der Telefonleitung miteinander kommunizierten und ihre Betriebsbedingungen festlegten. Antworttöne, Träger, Prüfsignale und Trainingssequenzen dienten dazu, die Gegenstelle zu erkennen und einen gemeinsamen Übertragungsmodus herzustellen.

Bei späteren schnelleren Modems wurde dieser Vorgang komplexer. Die Geräte mussten unter anderem feststellen, welche Verfahren beide Seiten beherrschen und wie gut die aktuelle Leitung ist. Je nach Ergebnis konnte eine niedrigere Datenrate gewählt werden, wenn die theoretisch höchste Geschwindigkeit nicht stabil möglich war.

Das bekannte Kreischen und Pfeifen war deshalb eine Art hörbares Protokoll. Für geübte Nutzer ließ sich zumindest grob erkennen, ob gerade gewählt wurde, eine Gegenstelle antwortete, der Trägeraufbau begann oder der Verbindungsversuch abbrach.

DTR, DCD, RTS/CTS und warum Flow Control wichtig wurde

Eine serielle Modemverbindung besteht nicht nur aus Senden und Empfangen von Nutzdaten. Zusätzliche Steuersignale können dem Rechner und dem Modem mitteilen, ob ein Gerät bereit ist, ob ein Träger anliegt oder ob der Datenfluss vorübergehend gebremst werden muss.

• DTR – Data Terminal Ready: signalisiert auf der Rechnerseite typischerweise, dass das Datenendgerät betriebsbereit ist; Modems konnten auf einen DTR-Abfall je nach Konfiguration mit Auflegen reagieren.
• DCD – Data Carrier Detect: meldet dem Rechner, dass ein Datenträger beziehungsweise eine aktive Modemverbindung erkannt wurde.
• RTS/CTS: Hardware-Flusskontrolle zwischen Rechner und Modem, damit Daten nicht schneller angeliefert werden, als sie verarbeitet beziehungsweise gepuffert werden können.
• XON/XOFF: softwarebasierte Flusskontrolle durch Steuerzeichen im Datenstrom.

Diese Details wurden besonders wichtig, als Modems intern pufferten, Fehlerkorrektur betrieben und Daten komprimierten. Dann konnte der Rechner kurzfristig schneller Daten liefern, als sie über die Telefonleitung abflossen. Ohne funktionierende Flusskontrolle drohten Pufferüberläufe und Datenverlust.

Rauschen, Abbrüche, Neuversuche und die reale Fehlerwelt

Frühe DFÜ war kein sauber entkoppeltes Idealmodell. Sie war voller kleiner und großer Störungen. Leitungsrauschen, instabile Gegenstellen, falsche Pegel, falsch gesetzte Parameter, Nebengeräusche beim Akustikkoppler, Auflegen an anderer Stelle, besetzte Ziele, plötzlich abbrechende Sitzungen – all das gehörte nicht zur Ausnahme, sondern zur normalen Erfahrungswelt.

Gerade das macht diese Zeit technisch interessant. Man lernte früh, Fehler nicht als mystisches Pech zu behandeln, sondern nach Schichten zu unterscheiden: Ist die Telefonseite das Problem? Das Modem? Die Software? Die Gegenstelle? Der Protokollzustand? Oder nur die eigene Hektik beim Start?

• Leitungsrauschen verfälschte Zeichen oder machte Protokolle unruhig.
• Verbindungsabbrüche kosteten nicht nur Zeit, sondern oft auch Geld und Konzentration.
• Falsche Parameter führten zu Zeichensalat, obwohl die Leitung an sich stand.
• Beim Akustikkoppler reichten kleine Störungen der Hörerauflage für echten Ärger.
• Ein Neuversuch war Routine, aber nie gratis.

Das war mühsam, aber nützlich. Man bekam ein realistisches Verhältnis zu Technik. Eine Verbindung galt nicht als selbstverständlich, nur weil man sie wollte. Sie galt als gelungen, wenn sie unter realen Bedingungen stabil genug aufgebaut und gehalten werden konnte.

MNP, V.42 und Fehlerkorrektur – wenn das Modem selbst aufpasst

Bei einfachen frühen Verbindungen musste die Anwendungsebene mit Übertragungsfehlern leben oder sie durch eigene Protokolle erkennen. Spätere Modems konnten einen Teil dieser Aufgabe selbst übernehmen. Fehlerkorrekturverfahren zerlegen Daten in Blöcke, prüfen sie und lassen fehlerhafte Blöcke erneut übertragen.

Bekannt wurden zunächst verschiedene Stufen der Microcom Networking Protocols – MNP. Später standardisierte V.42 Verfahren zur Fehlerkorrektur für Modemverbindungen. Für den Anwender bedeutete das vor allem: Die Verbindung zwischen den Modems konnte zuverlässiger werden, ohne dass jedes Terminalprogramm jedes einzelne Leitungsproblem selbst behandeln musste.

Diese Zuverlässigkeit ist allerdings nicht kostenlos. Prüfinformationen, Blockverwaltung und gegebenenfalls Wiederholungen benötigen Übertragungszeit. Auf einer guten Leitung fällt das kaum negativ auf. Auf einer schlechten Leitung kann die effektive Nutzrate deutlich sinken, während die Verbindung dafür korrekt bleibt.

Modemkompression und V.42bis – warum „effektiv schneller“ möglich war

Neben Fehlerkorrektur kam Datenkompression hinzu. Verfahren wie V.42bis konnten gut komprimierbare Daten vor der Übertragung verkleinern und auf der Gegenseite wiederherstellen. Dadurch konnte der effektive Datendurchsatz für bestimmte Inhalte über der nominellen Leitungsbitrate liegen.

Das funktioniert jedoch nur bei Daten, die überhaupt noch Redundanz enthalten. Bereits komprimierte Archive, viele Bildformate oder andere stark verdichtete Dateien lassen sich kaum weiter verkleinern. In solchen Fällen bringt zusätzliche Modemkompression wenig oder kann durch Verwaltungsaufwand sogar ungünstig sein.

Genau deshalb konnten Werbeaussagen zur „effektiven Geschwindigkeit“ irreführend wirken. Die physische Modemverbindung wurde durch Kompression nicht plötzlich schneller. Es wurden unter günstigen Bedingungen lediglich weniger Bits für denselben ursprünglichen Inhalt über die Leitung geschickt.

XMODEM, YMODEM und ZMODEM – Dateitransfer war ein eigenes Handwerk

Eine Textsitzung und ein zuverlässiger Dateitransfer sind zwei verschiedene Aufgaben. Für Dateien wurden deshalb eigene Übertragungsprotokolle verwendet. Sie strukturierten die Daten in Blöcke, prüften die Übertragung und regelten Wiederholungen.

Bei einer langsamen, gebührenpflichtigen Verbindung war Protokolleffizienz nicht akademisch. Ein unnötig wiederholter Block kostete Zeit. Ein kompletter Neustart nach einem Abbruch konnte besonders bei größeren Dateien frustrierend und teuer sein.

Die eigentliche Mailboxkultur gehört ausführlicher auf mailboxen-bbs.htm. Hier ist entscheidend, dass die Modemtechnik allein noch keinen zuverlässigen Dateiaustausch garantierte. Erst die Kombination aus stabiler Leitung, Modemfehlerkorrektur und einem passenden Transferprotokoll machte größere Übertragungen alltagstauglich.

Von 2400 bit/s bis 56k – die Telefonleitung wurde immer weiter ausgereizt

Mit 2400 bit/s war die Entwicklung keineswegs beendet. 9600 und 14.400 bit/s veränderten den Mailboxalltag deutlich, später folgten 28.800 und 33.600 bit/s. Jede Stufe verlangte ausgefeiltere Modulation, bessere Anpassung an die Leitung und komplexere Signalverarbeitung.

Die sogenannten 56k-Modems markierten schließlich eine besondere Grenze der klassischen Einwahlwelt. Sie nutzten aus, dass ein Teil des Verbindungsweges auf Providerseite bereits digital war. Die volle nominelle Geschwindigkeit war in der Praxis nicht in beide Richtungen symmetrisch erreichbar und hing stark von der Netztopologie und Leitungsqualität ab.

Interessant ist weniger die spätere Maximalzahl als die technische Leistung dahinter: Aus einem ursprünglich für menschliche Sprache gedachten analogen Teilnehmeranschluss wurde über Jahrzehnte immer mehr Datenrate herausgeholt. Das war keine Magie, sondern Signalverarbeitung, Standardisierung und sehr viel Optimierung.

Warum Geduld damals Teil der Technik war

Geduld war in dieser Zeit keine Tugend für Sonntagsreden, sondern ein technischer Arbeitsstoff. Man brauchte sie beim Wählen, beim Warten auf Träger, beim Seitenaufbau, beim Mitschreiben, bei Dateitransfers, bei Fehlern und bei jedem Neuversuch. Wer ungeduldig wurde, machte eher zusätzliche Fehler, als dass er schneller ans Ziel kam.

Das ist im Rückblick wichtiger, als es zunächst klingt. Viele spätere Systeme verdecken ihre innere Arbeit hinter glatten Oberflächen. Frühe DFÜ tat das nicht. Man spürte die Zeit, die ein Protokoll braucht. Man sah, dass Übertragung dauert. Man hörte, dass eine Verbindung ringt. Genau dadurch entstand ein nüchternerer Umgang mit Technik.

In genau diesem Sinn passt die DFÜ-Zeit sauber in die spätere SSLXY-Linie. Sie zwang dazu, Systeme wirklich zu lesen. Nicht nur Ergebnisse, sondern Übergänge, Wartezeiten, Fehlerbilder und innere Zustände.

„Langsamkeit war damals nicht bloß ein Mangel. Sie machte sichtbar, was eine Verbindung wirklich tut.“

Übergang zu BTX, Mailboxen und späteren Shell-Accounts

Technisch war die Modem- und Dataphon-Phase keine Sackgasse, sondern eine Brücke. Wer einmal gelernt hatte, über Leitung, Gegenstelle, Protokoll, Parameter und Fehlerbilder nachzudenken, war für die nächsten Schritte bereits vorbereitet. BTX war eine frühe zentrale Gegenwelt mit Seitenadressierung und klarer Taktung. Mailboxen brachten freie textbasierte Kommunikation und lokale Szenen näher zusammen. Shell-Accounts verschoben die Arbeit dann noch einmal deutlich weiter in Richtung Host, Datei, Kommando und später Web.

Gerade deshalb hängen diese Themen enger zusammen, als es im Rückblick oft erzählt wird. BTX war nicht „das Internet“, Mailboxen auch nicht, und ein Shell-Account ebenfalls nicht. Aber die Denkform wurde von Station zu Station klarer: Einwahl, Gegenstelle, Login, Text, Befehl, Datei, Übertragung, Protokoll.

Rückblickend ist der eigentliche Gewinn dieser Phase nicht, dass man „früh online“ war. Der eigentliche Gewinn war, dass man technische Verbindung nicht als Blackbox hinnahm. Genau daraus wuchs später auch die ruhigere Haltung gegenüber Hosts, CGI, HTML und der ganzen Webarbeit.

Die Funkseite davor steht auf 11-meter-band.htm. Die textbasierte Gegenwelt danach führt weiter auf mailboxen-bbs.htm. Die größere Einordnung der Linie bleibt auf sslxy.

Historische DFÜ heute erhalten

Alte Modems und Akustikkoppler lassen sich heute nicht immer einfach so betreiben wie früher. Die klassische analoge Teilnehmerleitung verschwindet zunehmend aus dem Alltag, moderne Telefonie arbeitet häufig IP-basiert, und Sprachkompression oder digitale Telefonadapter können historische Modemsignale anders behandeln als eine frühere durchgehende analoge Verbindung.

Für die Erhaltung ist deshalb nicht nur das Modem selbst wichtig. Handbücher, Anschlusskabel, Netzteile, serielle Adapter, Initialisierungsstrings und Informationen zu unterstützten Standards gehören genauso dazu. Ein funktionierendes Gerät ohne dokumentierte Schnittstelle kann praktisch schwerer nutzbar sein als ein defektes Gerät mit vollständigen Unterlagen.

• Dokumentation: Modell, Firmwarestand, unterstützte V-Standards und AT-Kommandos festhalten.
• Serielle Seite: Pinbelegung, Kabeltyp und notwendige Handshake-Leitungen dokumentieren.
• Telefonseite: beachten, dass moderne VoIP-Umgebungen historische Modemverfahren nicht immer transparent übertragen.
• Software: Terminalprogramme und passende Konfigurationsdateien sichern.
• Gegenstellen: historische Mailboxen können heute über Emulation, Telnet-Brücken oder private Testaufbauten nachgebildet werden, ohne das ursprüngliche Telefonnetz vollständig rekonstruieren zu müssen.

Für die Technikgeschichte ist das wichtig, weil ein Modem im Regal nur einen Teil der Geschichte erzählt. Die eigentliche Erfahrung entstand erst aus Rechner, serieller Schnittstelle, Modem, Telefonnetz, Gegenstelle und Software. Erst diese Kette erklärt, warum DFÜ damals gleichzeitig faszinierend und manchmal anstrengend war.

„Ein altes Modem bewahrt man nicht nur als Gerät. Man bewahrt eine komplette Verbindungskette.“