Wie man Dateien von einem 30 Jahre alten Laptop kopiert
(unterminated.com)- Kurze Audioaufnahmen auf einem Apple PowerBook Duo 280c von 1994 mussten erhalten werden, aber Audioausgang, Diskette, Netzwerk und Disk-Adapter waren allesamt unbrauchbar, sodass sich die Faxübertragung als Umweg anbot
- Mit dem Hex-Editor von ResEdit wurde die Audiodatei als hexadezimaler Text geöffnet, in Microsoft Word eingefügt und dann über die Faxfunktion im Druckdialog gesendet
- Der Empfang übernahm ein ThinkPad T60 mit installiertem Windows XP, eingebautem Modem und Fax-App; statt die beiden Laptops direkt per Telefonleitung zu verbinden, war eine Telefonleitungs-Simulationsschaltung auf Basis einer 9V-Batterie nötig
- Der Versuch, die TIF-Faxbilder per OCR zurückzuverwandeln, hinterließ wegen Verwechslungen wie 0/C, 9/4 und 0/D sowie Auslassungs- und Einfügefehlern Knistern und Pop-Geräusche im Audio
- Am Ende wurde mit FaxToBinary ein eigenes Werkzeug gebaut, das das Raster einer Monospace-Schrift direkt analysierte und Zeichenmuster manuell anlernte, um eine mit dem Original bytegenau übereinstimmende Audiodatei wiederherzustellen
Blockierte Kopierwege
- Das Zielgerät war ein PowerBook Duo 280c von 1994, auf dessen internem Speicher sich einige kurze Audioaufnahmen befanden, die erhalten werden sollten
- Glücklicherweise bootete der Laptop noch, die Festplatte lief nach einem leichten Klopfen wieder an, und die Audiodateien ließen sich über den internen Lautsprecher abspielen
- Die üblichen Kopiermethoden fielen nacheinander aus
- Es gab keine Audiobuchse, wodurch eine analoge Kopie in guter Qualität schwierig war
- Die interne Festplatte nutzte SCSI mit einem ungewöhnlichen Stecker, und es war unklar, ob ein modernes System das alte HFS-Dateisystem ohne Weiteres lesen könnte
- Beim Anschließen des externen Diskettenlaufwerks funktionierte der Computer nicht mehr, und die Ursache ließ sich nicht klären
- Es gab zwar einen AppleTalk-Port und eine Telefonbuchse, aber keine installierte Netzwerksoftware
- HTTP wurde erst 1996 standardisiert, und auf dem Laptop war auch keine damalige Einwahlsoftware vorhanden
- Übrig blieben jedoch ein Wählprogramm und Faxsoftware, wodurch das Modem als Umweg nutzbar wurde
Eine Datei in ein Faxdokument verwandeln
- Auf dem Laptop war neben einigen Spielen auch der Ressourcen-Editor ResEdit installiert, dessen Hex-Editor den Rohinhalt von Dateien in Hexdarstellung anzeigen konnte
- ResEdit unterstützte jedoch keine Ausgabefunktion, daher musste der Hex-Text in eine andere App übertragen werden
- Die Beispiel-Audiodatei war 37.928 Byte groß, und da jedes Byte als zweistelliger Hexwert dargestellt wird, war die Textrepräsentation doppelt so lang
- Wegen Begrenzungen bei der auf einmal verarbeitbaren Größe wurde die Datei in Teilen kopiert; verwendet wurden Einheiten von 12.288 Byte, also 0x3000, weil sich diese Offsets gut merken ließen
- Der per Zwischenablage kopierte Hex-Text ließ sich direkt in ein Microsoft-Word-Dokument einfügen, und Word bot die benötigte Ausgabefunktion
- Alle Dateien waren kleiner als 100 KB, und die Geschwindigkeit des manuellen Kopierens per Zwischenablage von ResEdit nach Word wurde auf durchschnittlich etwa 316 Byte/s geschätzt
Eine simulierte Telefonleitung zwischen zwei Laptops bauen
- Der Empfangsrechner war ein ThinkPad T60 mit eingebautem Einwahlmodem, und die Fax-App von Windows XP konnte eingehende Faxe als mehrseitige TIF-Bilder speichern
- Der direkte Anschluss der beiden Laptops mit einem Telefonkabel scheiterte
- Das PowerBook wählte zwar, aber das ThinkPad nahm nicht ab
- Auch die Option „Ignore Dial Tone“ half nicht
- Die vom echten Festnetz bereitgestellte Spannung war für den Betrieb des Modems wichtig; gelöst wurde das Problem mit einer Schaltung zur Simulation einer Telefonleitung
- Diese Schaltung ließ sich aus gängigen Elektronikbauteilen und einer 9V-Batterie aufbauen und stellte zwischen den beiden Laptops eine simulierte Telefonleitung bereit
- Für die Faxübertragung war aufgrund von FCC-Vorgaben ein Deckblatt erforderlich; nach dem Hinzufügen des Deckblatts lief die Übertragung an
- Anfangs wurde nach dem Rastern eine Übertragungszeit von 24 Minuten geschätzt, doch durch kleinere Schrift ließ sich das auf 6 Seiten und 7 Minuten verkürzen; das Fax wurde mit 14400 bps auf dem ThinkPad empfangen
Mit OCR bleiben Fehler zurück
- Das vom ThinkPad empfangene Fax lag als TIF-Bild vor, und zur Rückwandlung in eine Binärdatei wurde zunächst eine PDF-Konvertierung mit anschließendem OCR versucht
- Das Faxbild schien für OCR günstig zu sein
- Der Text war computergeneriert und damit in Ausrichtung und Form konsistent
- Es kamen nur 16 Zeichen vor, nämlich 0-9 und A-F
- Verwendet wurde mit Courier eine verbreitete Monospace-Schrift
- Das per OCR erkannte Ergebnis ließ sich markieren, in einen Hex-Editor kopieren und als Binärdatei speichern
- Audacity erkannte das Audioformat der resultierenden Datei als unsigned 8-bit PCM, little-endian, 22050Hz, mono, und zeigte auch eine Wellenform an
- Die Wiedergabe war größtenteils in Ordnung, aber plötzliche Einbrüche in der Wellenform waren als Knistern oder Pop-Geräusche hörbar, verursacht durch OCR-Transkriptionsfehler
- Weder mit verschiedenen OCR-Programmen noch durch Schriftgrößen- oder Schriftartwechsel ließ sich eine Genauigkeit von 100 % erreichen
- 0 und C, 9 und 4 sowie 0 und D wurden verwechselt
- Teilweise fehlten Zeichen oder es wurden zusätzliche eingefügt
Bytegenaue Wiederherstellung mit FaxToBinary
- Da der Text im Faxbild in einer Monospace-Schrift erzeugt worden war, ließ sich das ganze Dokument als Zeichenraster mit gleichmäßigen Abständen behandeln
- Wenn Startpunkt, Zeichenoffset und Zeilenabstand korrekt ausgerichtet waren, konnte jedes Zeichen einzeln erfasst und analysiert werden
- Das selbst entwickelte Werkzeug zeigte links eine Vorschau, um zu prüfen, ob Größen- und Offset-Parameter passten; solange beim Verschieben über Zeichen oder Zeilen kein Drift auftrat, konnte die Verarbeitung beginnen
- Die Zeichenerkennung arbeitete mit einem einfachen manuellen Anlernverfahren
- Bei jedem erstmals gesehenen einzigartigen Muster gab der Nutzer an, welches Zeichen es darstellte
- Traf das Tool später auf ein gleich aussehendes Zeichen, wurde die frühere Zuordnung wiederverwendet
- Der Quellcode des Werkzeugs ist als FaxToBinary.zip verfügbar
- Nach etwas manuellem Anlernen gab das Tool die Datei aus; das Audio ließ sich ohne Pop-Geräusche sauber abspielen und war eine mit dem Original bytegenau übereinstimmende Kopie
- Nach der Dateiwiederherstellung lief auf dem PowerBook auch DOOM
2 Kommentare
Nur ein Gedanke.
Meinungen auf Hacker News
Beim OCR von Hex-Dumps aus alten Computermagazinen hatte ich ein ähnliches Problem und habe es gelöst, indem ich ein Tool gebaut habe, das die OCR-Ergebnisse überprüft.
Gibt man das OCR-Ergebnis ein und teilt die Zahlen auf, zeigt es die aus dem Original ausgeschnittenen Zeichen nach Klassen gruppiert an; mit bloßem Auge findet man dann schnell Fehlklassifizierungen wie eine „3“ in der „8“-Gruppe.
https://blog.qiqitori.com/2023/03/ocring-hex-dumps-or-other-...
https://blog.qiqitori.com/2023/03/ai-day-in-retroland-prolog...
Ich habe zwei verwandte Beiträge geschrieben, und das Tool ist in den Beiträgen ebenfalls verlinkt. Allerdings ist die Benutzbarkeit des Tools nur ein ganz kleines bisschen besser als die von sendmail.
Ich weiß nicht, ob es auf dem alten Apple-Notebook eine Programmierumgebung oder etwas Ähnliches wie Microsoft Word aus jener Zeit gab, aber vermutlich hätte es auch ohne Hardware-Hacking eine bessere Methode gegeben.
Die bessere Methode wäre wohl gewesen, statt über den Modem-Port ein Fax zu senden, den seriellen Port zu verwenden. Seriell-USB-Adapter sind leicht zu bekommen.
Im Grunde würde man in einem zweiten Durchlauf Ausreißer in jeder Zeichengruppe finden, sie vorläufig in eine andere Gruppe umklassifizieren und die Änderung beibehalten, wenn sich die Ähnlichkeitswerte der beteiligten Gruppen verbessern; das wiederholt man, bis es keine weitere Verbesserung mehr gibt.
Man könnte zum Beispiel die „3, die den anderen 3en am wenigsten ähnelt“ finden, sie vorläufig zu den „8“ legen und die Änderung beibehalten, wenn sich die Werte dafür, „wie ähnlich sich die 3-Schnipsel untereinander sind“ und „wie ähnlich sich die 8-Schnipsel untereinander sind“, verbessern.
Wenn im Dokument allerdings mehrere Schriften gemischt sind, kann das nach hinten losgehen, etwa indem „3“-Zeichen aus verschiedenen Schriften zusammengeworfen werden und so der Gruppen-Ähnlichkeitswert leidet.
Hatte dieses Notebook nicht einen seriellen (COM-)Port? Damals war das fast universell, und laut dieser Seite [1] hatte es zwei davon.
Mit Zmodem wäre das einfach zu lösen gewesen, und Terminal-Software scheint es auch schon gegeben zu haben.
[1] https://everymac.com/systems/apple/powerbook_duo/specs/mac_p...
Allerdings braucht man auf der PowerBook-Seite irgendetwas, das seriell empfangen kann. ClarisWorks konnte das definitiv, und es ist sehr wahrscheinlich, dass Office dieselbe Funktion „Dokument empfangen“ hatte.
Oder man könnte über den seriellen Port „drucken“ und die serielle Ausgabe mitschneiden. Das ist faktisch eine einseitige Textübertragung, reicht aber für das, was der Autor vorhatte.
Trotzdem ist die Methode, es per Fax zu senden und per OCR zu erfassen, ziemlich cool.
Ich erinnere mich nicht daran, dass auf dem Notebook eine Terminal-App installiert war, aber vielleicht habe ich auch nicht gründlich genug gesucht.
Zuerst dachte ich, er würde den Bildschirm des alten Notebooks fotografieren und dann OCR darauf anwenden, aber die tatsächliche Methode war viel unterhaltsamer.
Trotzdem wäre es vielleicht schneller gewesen, eine große Schrift zu wählen und 24 Minuten für die Übertragung aufzuwenden. Die aktualisierte OCR-Software zu schreiben hat wahrscheinlich länger als 24 Minuten gedauert.
Aber dann wäre es nicht lustig gewesen.
Im Artikel habe ich es der Kürze halber weggelassen, aber tatsächlich habe ich verschiedene Schriftarten und Schriftgrößen jeweils seitenweise getestet und manuell geprüft; große Verbesserungen gab es nicht.
[0] https://social.immibis.com/notice/AeWSRvyKlhBB2hANoe
Als ich jung war, musste ich einmal von einem CP/M-Desktop eine dBase-2-Datenbank auf einen tragbaren MS-DOS-PC herüberholen.
Ich richtete ein serielles Kabel ein, startete PROCOMM auf dem PC, stellte beide Ports auf 9600/n/8/1, druckte aus dBase 2 heraus und ließ PROCOMM die Sitzung in eine Datei mitschreiben.
Wenn es lief, ohne zu lange anzuhalten, um auf die Diskette zu schreiben, gingen Zeichen verloren, also regelte ich den Fluss auf der CP/M-Seite mit ctrl-s/q.
Damals schien noch niemand herausgefunden zu haben, wie man so etwas auf diese Weise macht.
Wenn allerdings ein Modem installiert war, hätte es meiner Erinnerung nach auch Terminal-Software geben müssen.
AppleTalk kommt der richtigen Antwort nahe. Die Treiber waren integriert, und Apple hat die Kompatibilität über lange Zeit gut gepflegt.
Ich hatte ein ähnliches Problem beim Übertragen von Dateien zwischen einem IIGS und moderner Hardware. Floppy-Emulatoren, SCSI und rohes Seriell sind zwar möglich, aber wenn man einen Mac dazwischenschaltet, der sowohl AppleTalk als auch Ethernet hat, kann man ganze Dateihierarchien per Drag-and-drop zwischen dem AppleTalk-basierten Zielgerät und einer Freigabe wie SMB verschieben – das ist simpel.
Auch SCSI lässt sich in der Regel leicht adaptieren, wenn man den Laufwerksanschluss und den Typ kennt und bereit ist, ein paar Adapter in Reihe zu schalten. Ich meine, 2,5-Zoll-SCSI-Laufwerke hatten Anschlüsse aus der SCA-Familie, und solange man die Regeln für Single-Ended/Differential einhält, gibt es SCSI-Adapter, mit denen sich fast alles miteinander verbinden lässt.
Das Problem ist eher, ein OS oder Tool zu finden, das alte Mac-Dateisysteme lesen kann; mit einem der Utilities, die Raw-Images lesen, hätte man vermutlich Disk-Images lesen und schreiben können.
Vermutlich wäre es ziemlich einfach gewesen, sie woanders anzuschließen und die Daten zu kopieren. Ich arbeite an einem Ort, an dem wir regelmäßig mit über 30 Jahre alter Hardware auf diese Weise umgehen; entscheidend ist, den Rahmen „Softwarelösung“ zu verlassen.
Das ist kein Softwareproblem, sondern erfordert meist eine andere Art von Fachwissen.
Bei der SCSI-Umsetzung hatte ich denselben Gedanken, und der Autor sagte zwar, er sei nicht sicher, ob er ein HFS-Volume lesen könne, aber Linux hat schon seit Jahrzehnten HFS-Treiber.
In diesem Fall handelt es sich um ein PowerBook Duo mit SCSI-Festplatte, daher braucht man ein Gerät wie ein Duo Dock[2], einen HDI-30-Adapter[3] und eine Kombination aus Kabeln, Konvertern und Controllern, um ein paralleles SCSI-Gerät an ein modernes System anzuschließen.
Für Geräte mit PCI-Express-Slot oder Thunderbolt-PCI-Express-Gehäuse würde ich einen LSI Logic Ultra320-Adapter empfehlen, den man bei eBay für unter 50 Dollar bekommt. Treiber für macOS, Linux und Windows sind leicht zu finden.
Wenn alles vorbereitet ist, verbindet man die Macs per SCSI-Kabel, hält beim Starten des PowerBook die Taste T gedrückt, um in den Target Disk Mode zu wechseln, und antwortet unbedingt mit Nein, wenn das OS fragt, ob eine nicht lesbare Festplatte formatiert werden soll.
Für den Zugriff auf das HFS-Dateisystem scheint mir unter macOS der vollständigste und einfachste Weg zu sein: ein Raw-Disk-Image erstellen, es sichern, dann Mac OS 9 in qemu installieren, das Image einbinden, HFS mit Alsoft PlusMaker in-place zu HFS+ konvertieren und anschließend das Image im aktuellen macOS mounten.
Als Bonus bekommt man damit auch ein emuliertes Mac-OS-9-System, auf dem sich die meisten Apps von der ursprünglichen PowerBook-Festplatte ausführen lassen.
[1] https://developer.apple.com/library/archive/technotes/tn/tn1...
[2] https://en.wikipedia.org/wiki/PowerBook_Duo#Docking_stations
[3] https://www.amazon.com/dp/B0081SAIS2/
[4] https://www.broadcom.com/support/download-search?pg=Legacy+P...
[5] https://wiki.qemu.org/Documentation/GuestOperatingSystems/Ma...
[6] https://www.macintoshrepository.org/19-plusoptimizer-plusmak...
[7] https://www.macintoshrepository.org/809-stuffit-deluxe-1-5-x...
[8] https://www.macintoshrepository.org/1724-toast-5-titanium
Das fühlt sich wie eine praktische Prüfung in Informationstheorie an, und das gefällt mir
„Übertragen Sie eine 32.000-Byte-Datei über einen Kanal Ihrer Wahl. Alle Kanäle sind auf die eine oder andere Weise schlecht. Sie haben ein Smartphone, einen seriellen Port und einen Computer. Auf dem Computer gibt es keinen Compiler, aber Sie können beliebige Grundfunktionen nutzen. Lösungen, die mehr Eingabe-Bytes benötigen als die zu übertragende Datei, etwa Skripte, scheiden aus. Es gibt kein Zeitlimit, aber die schnellste Lösung gewinnt. Los.“
Bei einem alten Mac hätte ich es vielleicht nicht besser gemacht als der Autor. Wenn man jedoch visuell ähnliche Zeichen wie 3 und 8 durch sehr gut unterscheidbare Zeichen ersetzen könnte, etwa 8→Z, reizt einen schon die Idee, dass es am schnellsten sein könnte, den Bildschirm mit dem Smartphone zu filmen und per OCR auszulesen
In System 7 gab es meines Wissens AppleScript, also wäre vielleicht ein sed-ähnlicher Ersetzungsschritt möglich gewesen
hfsprogs installieren, das Laufwerk mounten und die benötigten Dateien herausziehen – fertig
Der proprietäre Anschluss könnte ein Problem sein, sodass ein Workaround wie spontanes Löten nötig wäre, aber zum Glück funktionieren alte Geräte damit oft ziemlich gut
Ehrlich gesagt ist das der Vorteil von Hardware-Leuten
Deshalb würde ich vermutlich nach einer Kodierung suchen, bei der Fehler extrem selten werden. Wenn man das gesamte Laufwerk des Notebooks dumpen müsste, fände ich es besser, das Notebook einmal eine Woche lang laufen zu lassen, als eine schnellere, aber fehleranfällige Methode zu verwenden
Grob gerechnet sind 320 MB in einer Woche etwa 530 Byte pro Sekunde. Wenn man den Bildschirm mit 4 Hz anzeigt und per Smartphone aufnimmt, kann man annehmen, dass es keine ausgelassenen Frames oder seltsamen Artefakte gibt; das wären ungefähr 135 Byte pro Frame, also 1080 Bit
Teilt man ein 8,4-Zoll-Display mit 640×480 in Quadrate von 16×16 Pixeln auf, entstehen etwa 1000 Felder von rund 0,5 cm Größe. Wenn jedes Feld 0,25 Sekunden lang schwarz oder weiß angezeigt wird, sollten Kamera-Artefakte die Daten kaum beeinflussen, und man liegt ziemlich genau bei der benötigten Bandbreite
Da keine Zeichen per OCR erkannt werden müssen, würden die oben genannten Probleme geringer, aber zuerst müsste man dieses Programm in die Maschine bekommen
Die Stelle, an der es hieß, die interne Festplatte sei SCSI mit einem ungewöhnlichen Stecker und daher schwer zu adaptieren, war eigentlich ein Fall, in dem man einfach den SCSI-Bus hätte verwenden können
SCSI ist ein Bus-Mastering-Protokoll, bei dem mehrere Master denselben Bus teilen können; man kann also zwei Computer gleichzeitig an denselben SCSI-Bus hängen und gemeinsam auf das Plattengerät zugreifen. Dem gleichzeitigen Schreiben auf ein Dateisystem sollte man nicht vertrauen, aber die ganze damalige Festplatte ist heute nur noch eine große Datei, die man einfach komplett dumpen kann
Inkonsistenzen eines geöffneten Dateisystems wären ungefähr auf dem Niveau einer Crash-Recovery, und lange gespeicherte Dateien wären vermutlich nicht betroffen gewesen
Auch das alte HFS hätte sich dank der Vorzüge des Open-Source-/New-Jersey-Stils unter Linux sehr leicht per Loopback mounten lassen
Ich habe noch immer das komplette Disk-Image eines alten Mac SE20 von 1988 und mounte es gelegentlich. Auch das habe ich über den SCSI-Bus herausgezogen. Die 20 stand, glaube ich, für die MHz des 68020-Prozessors, aber zufällig hatte er auch eine 20-MB-Festplatte, und der SE30 im Jahr darauf war ähnlich
Der Teil mit der Fax-Software erinnert mich an eine Idee, die ich früher nur im Kopf hatte und nie umgesetzt habe. Wenn man auf ein Fax-Deckblatt so etwas wie einen großen QR-Code packte, der das .DOC-Format des Dokuments kodiert, könnte man es auch mit einem normalen Faxgerät senden; wenn der Empfänger ein Computermodem wäre, könnte er das Dokument im Originalformat empfangen und den Rest der Faxübertragung per Handshake abbrechen
Das wäre wohl ein sanfter Weg gewesen, über die alte Faxtechnik hinwegzukommen
Vor ein paar Jahren habe ich ziemlich viel Zeit damit verbracht, Dateien zwischen einem Macintosh Plus und einem modernen Computer hin- und herzuschieben
Damals habe ich zwei 100-MB-ZIP-Laufwerke verwendet, eines mit SCSI für den Mac Plus und eines mit USB für den modernen Computer, und später dann eine serielle Verbindung mit Terminal-Software [1]
Heute gibt es mit BlueSCSI[2] eine bessere und günstigere Option. Das ist ein SCSI-HDD-Emulator, der auf einer SD-Karte gespeicherte .img-Dateien als HDD-Disk mounten kann und außerdem CD- und Netzwerkkarten-Emulation unterstützt
Nachdem man Dateien auf ein solches virtuelles Laufwerk kopiert hat, kann man sie auf einem modernen Gerät mit einem HFS-Browser oder Emulator extrahieren
[1] https://blog.rekawek.eu/2016/12/08/mac-plus#hard-drive
[2] https://bluescsi.com/
Das war ein wirklich spannender Artikel und für mein begrenztes Computerwissen viel zu kompliziert.
Irgendwann um 1993–1994 herum hatte ich, wenn ich die Reihenfolge mit anderen Ereignissen richtig rekonstruiere, die Gelegenheit, einen nicht bootenden IBM-Laptop zu „reparieren“. Er war dick, schwer und groß, aber der Bildschirm war nur etwa so groß wie eine 3,5-Zoll-Diskette.
Ich habe so einen Laptop weder auf Fotos noch sonst irgendwo gesehen, daher vermute ich, dass er schon für damalige Verhältnisse ein älteres Gerät war. Falls jemand weiß, was das war, würde ich gern ein Foto sehen.
Ein etwas aus der Zeit gefallener, nerdiger Onkel aus der Nachbarschaft, so eine Art Mentor, gab ihn mir zum Reparieren, und ich stellte ihn ein paar Tage lang stolz auf meinen Schreibtisch. Wahrscheinlich habe ich ihn auf eine dämliche, simple Weise repariert, indem ich die AUTOEXEC.BAT geändert und WordStar geladen habe. Gebraucht wurde auch nur WordStar unter DOS, nicht einmal Windows 3.x.
Sehr wahrscheinlich stammte der Laptop von christlichen Missionaren, die die örtliche Kirche in meiner Heimatstadt besucht hatten.
Ich habe noch eine andere Computer-Reparaturgeschichte, aber die Details muss ich erst wieder zusammensuchen. Es ging darum, in einer Militärbaracke in den Bergen zu schlafen, beim Wasserlassen von bewaffneten Wachen begleitet zu werden und auf dem Heimweg eine schwangere Frau in einem Krankenwagen zu versorgen. Diese „Mission“ war mit einem Freund aus Kindertagen aus der Nachbarschaft, aber er ist inzwischen verstorben, und der anachronistische Onkel ebenfalls. Das hängt nicht miteinander zusammen.
Allerdings dürfte dessen Bildschirm etwas größer als eine 3,5-Zoll-Diskette gewesen sein, und er hatte keine 3,5-Zoll-Laufwerke, sondern unterstützte nur 5,25 Zoll. Der Osborne 1 und tragbare Computer aus den frühen 80ern hatten kleinere Bildschirme, liefen aber wohl nicht unter DOS.
Ein weiterer Kandidat wäre der PC Convertible: https://en.wikipedia.org/wiki/IBM_PC_Convertible
Wenn es „Fax-Software“ gab, gab es mit ziemlicher Sicherheit auch einen Terminal-Emulator, und man hätte Dateien mit etwas wie ZMODEM übertragen können, ohne sie zu beschädigen.
Das zu lesen war schmerzhaft, als würde man jemandem zusehen, der statt eines Präzisionsschraubendrehers ein Buttermesser benutzt.