Comment copier des fichiers depuis un ordinateur portable vieux de 30 ans
(unterminated.com)- Il fallait préserver de courts enregistrements audio restés sur un PowerBook Duo 280c de 1994, mais la sortie audio, la disquette, le réseau et l’adaptateur de disque étaient tous inutilisables, si bien que l’envoi par fax est devenu la solution de contournement
- Avec l’éditeur hexadécimal de ResEdit, le fichier audio a été ouvert sous forme de texte hexadécimal, collé dans Microsoft Word, puis envoyé via la fonction fax de la boîte de dialogue d’impression
- La réception a été assurée par le modem intégré et l’application de fax d’un ThinkPad T60 sous Windows XP, et au lieu de relier directement les deux portables par une ligne téléphonique, il a fallu un circuit simulateur de ligne basé sur une pile 9V
- La méthode consistant à reconvertir les images de fax TIF par OCR laissait dans l’audio des craquements et pops à cause de confusions 0/C, 9/4, 0/D ainsi que d’erreurs d’omission et d’insertion
- Au final, un outil FaxToBinary a été créé pour analyser directement la grille de caractères à chasse fixe et apprendre manuellement les motifs, ce qui a permis de restaurer un fichier audio identique à l’original octet par octet
Des voies de copie toutes bloquées
- L’appareil concerné était un PowerBook Duo 280c de 1994, qui contenait quelques courts enregistrements audio à préserver
- Heureusement, l’ordinateur portable démarrait encore, le disque dur se remettait à tourner après une légère tape, et les fichiers audio pouvaient être lus via le haut-parleur interne
- Les méthodes de copie habituelles se sont révélées bloquées l’une après l’autre
- Il n’y avait pas de prise audio, ce qui rendait difficile une copie analogique de bonne qualité
- Le disque dur interne utilisait du SCSI avec un connecteur inhabituel, et il n’était pas certain qu’un système moderne puisse lire facilement l’ancien système de fichiers HFS
- Quand on branchait le lecteur de disquettes externe, l’ordinateur ne fonctionnait plus, sans qu’il soit possible d’en trouver la cause
- Il y avait bien un port AppleTalk et une prise téléphonique, mais aucun logiciel réseau n’était installé
- HTTP n’a été standardisé qu’en 1996, et ce portable ne disposait pas non plus d’un logiciel de connexion commutée qui aurait pu être utilisé à l’époque
- En revanche, il restait un composeur téléphonique et un logiciel de fax, ce qui a rendu possible un détour via le modem
Transformer le fichier en document faxable
- Le portable avait ResEdit, un éditeur de ressources installé avec quelques jeux, et son éditeur hexadécimal permettait d’afficher le contenu brut d’un fichier en hexadécimal
- ResEdit ne prenait pas en charge l’export, il fallait donc transférer le texte hexadécimal vers une autre application
- Le fichier audio d’exemple faisait 37 928 octets et, chaque octet étant représenté par deux caractères hexadécimaux, sa forme texte était deux fois plus longue
- Comme la taille manipulable d’un coup était limitée, le fichier a été copié par morceaux de 12288 octets, soit des blocs de 0x3000, plus simples à repérer par offset
- Le texte hexadécimal copié via le presse-papiers pouvait être collé tel quel dans un document Microsoft Word, qui offrait lui une fonction d’impression
- Tous les fichiers faisaient moins de 100 Ko, et la vitesse moyenne estimée de cette copie manuelle du presse-papiers entre ResEdit et Word était d’environ 316 octets/s
Créer une fausse ligne téléphonique entre deux portables
- L’ordinateur de réception était un ThinkPad T60 avec modem RTC intégré, et l’application de fax de Windows XP pouvait enregistrer les fax entrants sous forme d’images TIF multipages
- Le branchement direct des deux portables par un câble téléphonique a échoué
- Le PowerBook composait bien le numéro, mais le ThinkPad ne décrochait pas
- L’option « Ignore Dial Tone » n’a pas aidé
- La tension fournie par un vrai réseau téléphonique filaire était essentielle au fonctionnement des modems, et le problème a été résolu avec un circuit simulateur de ligne téléphonique
- Ce circuit pouvait être construit avec des composants électroniques courants et une pile 9V, afin de fournir une ligne téléphonique simulée entre les deux portables
- La transmission fax nécessitait, pour des raisons réglementaires de la FCC, une page de garde, et l’envoi a pu commencer après son ajout
- Au départ, une fois rastérisé, l’envoi était estimé à 24 minutes, mais en réduisant la taille de police, il est passé à 6 pages et 7 minutes, le fax étant reçu sur le ThinkPad à 14400 bps
Les erreurs persistantes de l’OCR
- Le fax reçu par le ThinkPad était une image TIF, et pour la reconvertir en fichier binaire, la première tentative a consisté à passer par un PDF et de l’OCR
- L’image du fax semblait favorable à l’OCR
- Le texte était généré par ordinateur, donc aligné et de forme régulière
- Les caractères utilisés n’étaient que 16 types : 0-9 et A-F
- La police utilisée était Courier, une police à chasse fixe très répandue
- Une fois le texte extrait par OCR, il était possible de le sélectionner, de le copier dans un éditeur hexadécimal et de l’enregistrer en fichier binaire
- Audacity a identifié le format audio du fichier obtenu comme de l’unsigned 8-bit PCM, little-endian, 22050Hz, mono, et a pu en afficher la forme d’onde
- À l’écoute, le résultat était globalement correct, mais des creux brusques dans la forme d’onde se traduisaient par des craquements ou des pops dus aux erreurs de transcription de l’OCR
- Même en essayant plusieurs logiciels d’OCR, différentes tailles de police et d’autres polices, il n’a pas été possible d’atteindre 100 % de précision
- Confusions entre 0 et C, 9 et 4, 0 et D
- Omission de caractères ou insertion de nouveaux caractères
Restauration octet par octet avec FaxToBinary
- Comme le texte de l’image fax avait été produit avec une police à chasse fixe, le document entier pouvait être traité comme une grille régulière de caractères
- Une fois le point de départ, les offsets de caractères et l’espacement entre les lignes correctement ajustés, chaque caractère pouvait être capturé et analysé individuellement
- L’outil maison affichait un aperçu à gauche pour vérifier que les paramètres de taille et d’offset étaient corrects, et le traitement pouvait commencer tant qu’aucune dérive n’apparaissait lorsqu’on se déplaçait entre les caractères ou les lignes
- La reconnaissance des caractères fonctionnait selon un apprentissage manuel très simple
- À chaque nouveau motif unique rencontré, l’utilisateur indiquait de quel caractère il s’agissait
- Lorsqu’un caractère de même forme réapparaissait ensuite, l’outil réutilisait la réponse mémorisée
- Le code source de l’outil est fourni dans FaxToBinary.zip
- Après un peu d’apprentissage manuel, l’outil a produit le fichier, l’audio se lisait sans pops et la copie correspondait à l’original octet par octet
- Une fois les fichiers récupérés, DOOM tournait aussi sur ce PowerBook
2 commentaires
Juste une réflexion.
ihexousrecordfournissent une somme de contrôle.zmodem.Commentaires sur Hacker News
J’ai rencontré un problème similaire en passant à l’OCR des dumps hexadécimaux d’anciens magazines informatiques, et je l’ai résolu en créant un outil pour vérifier le résultat de l’OCR.
Quand on lui fournit le résultat de l’OCR et qu’il découpe les chiffres, il affiche les caractères découpés dans l’original par catégorie, ce qui permet à un humain de repérer rapidement à l’œil les erreurs de classement, comme un « 3 » rangé dans le groupe des « 8 ».
https://blog.qiqitori.com/2023/03/ocring-hex-dumps-or-other-...
https://blog.qiqitori.com/2023/03/ai-day-in-retroland-prolog...
J’ai écrit deux articles à ce sujet, et l’outil est également lié dans l’article. Cela dit, son ergonomie n’est qu’à peine meilleure que celle de sendmail.
Je ne sais pas s’il existait un environnement de programmation ou quelque chose ressemblant au Microsoft Word de l’époque sur les vieux portables Apple, mais il devait y avoir une meilleure méthode sans bidouillage matériel.
Une meilleure méthode aurait sans doute été d’utiliser le port série plutôt que d’envoyer un fax via le port modem. Les adaptateurs série-USB se trouvent facilement.
En gros, lors d’une deuxième passe, on repère les valeurs aberrantes dans chaque groupe de caractères, on les reclasse temporairement dans un autre groupe, puis on conserve le changement si le score de similarité des groupes concernés s’améliore, et on répète jusqu’à ce qu’il n’y ait plus d’amélioration.
Par exemple, on pourrait trouver le « 3 qui ressemble le moins aux autres 3 » et le placer temporairement dans les « 8 » ; si les scores « à quel point les morceaux de 3 se ressemblent entre eux » et « à quel point les morceaux de 8 se ressemblent entre eux » s’améliorent, on conserve ce changement.
En revanche, si le document mélange plusieurs polices, cela peut avoir l’effet inverse, par exemple en regroupant des « 3 » de polices différentes et en dégradant le score de similarité du groupe.
Ce portable n’avait-il pas un port série (COM) ? C’était quasiment universel à l’époque, et d’après ce site [1], il en avait deux.
Avec Zmodem, cela aurait été simple à résoudre, et il me semble qu’il y avait déjà un logiciel de terminal.
[1] https://everymac.com/systems/apple/powerbook_duo/specs/mac_p...
Il faut toutefois quelque chose côté PowerBook qui puisse recevoir en série. ClarisWorks le permettait certainement, et il est très probable qu’Office ait eu la même fonction de « réception de document ».
Sinon, on peut aussi « imprimer » vers le port série et capturer la sortie série. C’est essentiellement un transfert de texte à sens unique, mais c’est suffisant pour ce que l’auteur voulait faire.
Cela dit, la méthode qui consiste à envoyer un fax puis à faire de l’OCR est plutôt géniale.
Je ne me souviens pas qu’une appli de terminal ait été installée sur le portable, mais je n’ai peut-être pas cherché assez sérieusement.
Au début, je pensais qu’il allait photographier l’écran du vieux portable puis faire de l’OCR, mais la méthode réelle était bien plus amusante.
Cela dit, il aurait peut-être été plus rapide d’utiliser une grande police et de consacrer 24 minutes au transfert. Écrire le logiciel d’OCR mis à jour a probablement pris plus de 24 minutes.
Mais ça aurait été moins drôle.
Je l’ai omis dans l’article pour rester concis, mais en réalité j’ai testé plusieurs polices et tailles de caractères, page par page, avec vérification manuelle, et il n’y a pas eu d’amélioration notable.
[0] https://social.immibis.com/notice/AeWSRvyKlhBB2hANoe
Quand j’étais jeune, j’ai dû extraire une base de données dBase 2 d’un ordinateur de bureau CP/M vers un PC portable MS-DOS.
J’ai configuré un câble série, lancé PROCOMM sur le PC, réglé les ports des deux côtés en 9600/n/8/1, puis lancé une impression depuis dBase 2 pendant que PROCOMM enregistrait la session dans un fichier.
Si je laissais tourner trop longtemps sans pause pour écrire sur la disquette, des caractères étaient perdus ; j’ai donc contrôlé le flux côté CP/M avec ctrl-s/q.
À l’époque, il me semble que personne n’avait encore trouvé comment faire de cette manière.
Cela dit, si un modem était installé, il devait aussi y avoir un logiciel de terminal, dans mon souvenir.
AppleTalk est probablement la bonne réponse. Les pilotes sont intégrés et Apple a longtemps bien maintenu la compatibilité.
J’ai rencontré un problème similaire en transférant des fichiers entre un IIGS et du matériel moderne : les émulateurs de disquettes, SCSI et le série brut sont possibles, mais avec un Mac servant d’intermédiaire et disposant à la fois d’AppleTalk et d’Ethernet, on peut simplement déplacer par glisser-déposer toute l’arborescence de fichiers entre l’appareil cible basé sur AppleTalk et un partage de type SMB.
SCSI est aussi généralement assez facile à convertir, à condition de connaître le connecteur et le type du disque, et d’être prêt à chaîner quelques adaptateurs. De mémoire, les disques SCSI 2,5 pouces utilisaient un connecteur de la famille SCA, et tant qu’on respecte les règles terminaison simple/différentiel, il existe des adaptateurs SCSI pour relier presque n’importe quoi.
Le problème est de trouver un OS ou des outils capables de lire l’ancien système de fichiers Mac, mais il me semble qu’on pouvait lire et écrire des images disque avec l’un des utilitaires lisant les images brutes.
Il est probable que le brancher ailleurs pour copier les données aurait été assez simple. Je travaille dans un endroit où l’on manipule souvent de cette façon du matériel vieux de plus de 30 ans, et l’essentiel est de sortir du cadre d’une solution logicielle.
Ce n’est pas un problème logiciel ; dans la plupart des cas, cela demande un autre type d’expertise.
J’ai eu la même idée pour la conversion SCSI, et l’auteur disait ne pas être sûr de pouvoir lire un volume HFS, mais Linux dispose déjà d’un pilote HFS depuis des décennies.
Dans ce cas, puisqu’il s’agit d’un PowerBook Duo et d’un disque SCSI, il faut un appareil comme un Duo Dock[2], un adaptateur de conversion HDI-30[3], ainsi qu’une combinaison de câbles, convertisseurs et contrôleurs pour relier un périphérique SCSI parallèle à un système moderne.
Pour une machine disposant d’un slot PCI Express ou d’un boîtier PCI Express Thunderbolt, je recommande un adaptateur LSI Logic Ultra320, disponible sur eBay pour moins de 50 dollars. Les pilotes pour macOS, Linux et Windows se trouvent facilement.
Une fois prêt, il suffit de relier les Mac avec un câble SCSI, d’appuyer sur T pendant le démarrage du PowerBook pour entrer en mode disque cible, puis de répondre impérativement non si l’OS demande s’il faut formater le disque qu’il ne sait pas lire.
Pour accéder au système de fichiers HFS, la méthode la plus complète et la plus simple semble être, sous macOS, de créer une image disque brute, de la sauvegarder, puis d’installer Mac OS 9 dans qemu, d’y attacher l’image, de convertir HFS en HFS+ sur place avec Alsoft PlusMaker, puis de monter l’image dans macOS actuel.
En bonus, on obtient aussi un système Mac OS 9 émulé sur un Mac moderne, capable d’exécuter la plupart des apps du disque dur PowerBook d’origine.
[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
J’aime bien, on dirait une vraie épreuve de théorie de l’information en conditions réelles
« Transmettez un fichier de 32 000 octets par le canal de votre choix. Tous les canaux sont mauvais d’une manière ou d’une autre. Vous avez un smartphone, un port série et un ordinateur. L’ordinateur n’a pas de compilateur, mais vous pouvez utiliser n’importe quelle fonction de base. Les solutions qui nécessitent plus d’octets en entrée que le fichier à transmettre, par exemple un script, sont éliminées. Il n’y a pas de limite de temps, mais la solution la plus rapide gagne. Départ. »
Avec un vieux Mac, je ne sais pas si j’aurais fait mieux que l’auteur. Cela dit, s’il est possible de remplacer des caractères visuellement proches, comme 3 et 8, par des caractères très distincts, par exemple 8→Z, on est tenté de se dire que filmer l’écran au smartphone et faire de l’OCR pourrait être la méthode la plus rapide
Il me semble que System 7 avait AppleScript, donc une étape de substitution façon sed aurait peut-être été possible
Installer hfsprogs, monter le disque et récupérer les fichiers nécessaires, et c’est terminé
Le connecteur propriétaire pourrait poser problème et nécessiter un contournement du type soudure improvisée, mais heureusement le vieux matériel fonctionne souvent assez bien même avec ce genre de bricolage
Honnêtement, c’est l’avantage des gens côté matériel
Je chercherais donc un encodage qui rende les erreurs extrêmement rares. S’il fallait dumper tout le disque du portable, je préférerais laisser l’ordinateur allumé une semaine une seule fois plutôt qu’utiliser une méthode plus rapide mais sujette aux erreurs
À la louche, envoyer 320 Mo en une semaine fait 530 octets par seconde. Si l’écran est rafraîchi à 4 Hz et filmé au smartphone, on peut supposer qu’il n’y aura pas de frames manquantes ni d’artefacts étranges, ce qui donne environ 135 octets par frame, soit 1080 bits
En divisant un écran 8,4 pouces 640×480 en carrés de 16×16 pixels, on obtient environ 1000 cases d’environ 0,5 cm. Si chaque case est affichée en noir ou blanc pendant 0,25 seconde, les artefacts de la caméra n’affecteraient pas beaucoup les données et on serait presque à la bande passante nécessaire
Comme on ne fait pas d’OCR de caractères, cela réduirait les problèmes évoqués plus haut, mais il faut d’abord réussir à mettre ce programme dans la machine
Le passage disant que le disque dur interne était en SCSI avec un connecteur étrange, donc difficile à adapter, indiquait en fait une piste : utiliser le bus SCSI
SCSI est un protocole de bus mastering où plusieurs maîtres peuvent partager le bus, donc on peut brancher deux ordinateurs en même temps sur le même bus SCSI et accéder ensemble au périphérique disque. Il ne faut pas faire confiance à l’écriture simultanée sur le système de fichiers, mais un disque entier de l’époque n’est aujourd’hui qu’un gros fichier, donc il suffit de le dumper en entier
Les incohérences d’un système de fichiers ouvert seraient du même ordre qu’une récupération après crash et n’auraient probablement pas affecté les fichiers stockés depuis longtemps
Même l’ancien HFS aurait été très facile à monter en loopback sous Linux, grâce aux avantages du style open source/New Jersey
J’ai encore l’image disque complète d’un vieux Mac SE20 de 1988, et je la monte de temps en temps. Je l’avais aussi récupérée via le bus SCSI. Je crois que le 20 désignait les MHz du processeur 68020, mais par coïncidence il avait aussi un disque de 20 Mo, et le SE30 de l’année suivante était similaire
La partie utilisant un logiciel de fax me rappelle une idée à laquelle j’avais pensé autrefois sans jamais la mettre en œuvre. En mettant sur la page de garde d’un fax quelque chose comme un grand QR code encodant le format .DOC du document, on aurait pu l’envoyer même avec un fax classique ; si le destinataire était un modem d’ordinateur, il aurait pu recevoir le document dans son format d’origine puis interrompre le reste de la transmission fax par handshake
Cela aurait pu être une manière en douceur de dépasser l’ancienne technologie du fax
Il y a quelques années, j’ai passé pas mal de temps à essayer d’échanger des fichiers entre un Macintosh Plus et un ordinateur moderne
À l’époque, j’utilisais deux lecteurs ZIP 100 Mo, l’un en SCSI pour le Mac Plus et l’autre en USB pour l’ordinateur moderne, puis plus tard une connexion par port série avec un logiciel de terminal [1]
Aujourd’hui, il existe une option meilleure et moins chère : BlueSCSI[2]. C’est un émulateur de disque dur SCSI qui permet de monter des fichiers .img stockés sur une carte SD comme des disques HDD, et qui prend aussi en charge l’émulation de CD et de carte réseau
Une fois les fichiers copiés sur ce type de disque virtuel, on peut les extraire sur une machine moderne avec un explorateur HFS ou un émulateur
[1] https://blog.rekawek.eu/2016/12/08/mac-plus#hard-drive
[2] https://bluescsi.com/
C’était un article vraiment passionnant, et bien trop complexe pour mes connaissances limitées en informatique.
Vers 1993-1994, si je me fie à l’ordre des autres événements, j’ai eu l’occasion de « réparer » un ordinateur portable IBM qui ne démarrait pas. Il était épais, lourd et volumineux, mais son écran avait à peu près la taille d’une disquette 3,5 pouces.
Je n’ai jamais vu un portable comme celui-là, ni en photo ni ailleurs, donc j’imagine qu’il était déjà ancien même pour l’époque. Si quelqu’un sait de quoi il s’agissait, j’aimerais bien voir une photo.
Un oncle du quartier, un geek dépassé par son époque et une sorte de mentor, me l’avait donné pour que j’essaie de le réparer, et je l’ai gardé quelques jours sur mon bureau pour m’en vanter. Je crois l’avoir réparé avec une méthode bête et simple, probablement en modifiant AUTOEXEC.BAT et en chargeant WordStar. Tout ce dont il avait besoin, c’était WordStar sous DOS, même pas Windows 3.x.
Il y a de fortes chances que ce portable ait été donné par des missionnaires chrétiens qui rendaient visite à l’église locale de ma ville natale.
J’ai aussi une autre histoire de réparation d’ordinateur, mais il faudrait que je me rappelle les détails pour l’écrire. Il y était question de dormir dans une caserne militaire en montagne, d’avoir un garde armé pour aller uriner, puis de rentrer en accompagnant une femme enceinte en ambulance. Cette « mission », je l’avais faite avec un ami d’enfance du voisinage, mais il est décédé depuis, tout comme cet oncle anachronique. Les deux choses n’ont pas de rapport.
Cela dit, son écran devait être un peu plus grand qu’une disquette 3,5 pouces, et il ne prenait pas en charge les disquettes 3,5 pouces, seulement les 5,25 pouces. L’Osborne 1 et d’autres ordinateurs portables du début des années 80 avaient des écrans plus petits, mais ils ne faisaient probablement pas tourner DOS.
Un autre candidat serait le PC Convertible : https://en.wikipedia.org/wiki/IBM_PC_Convertible
S’il y avait un « logiciel de fax », il y avait presque certainement aussi un émulateur de terminal, et il aurait été possible d’envoyer les fichiers sans les corrompre avec quelque chose comme ZMODEM.
C’était pénible à lire, comme regarder quelqu’un utiliser un couteau à beurre à la place d’un tournevis de précision.