Le Famicom Network System n’avait pas besoin d’être réparé au sens habituel. Le boîtier était là. Les puces étaient là. Le modem pouvait encore produire ses tonalités. Le problème était plus embarrassant : presque tout ce avec quoi l’objet savait parler avait disparu.
En août 2026, Throaty Mumbo montre un exemplaire de ce périphérique Nintendo reprendre une conversation de données après des mois de travail.1 7 Ce n’est pas le genre de restauration où l’on change deux condensateurs, nettoie un connecteur et remet l’objet sur une étagère avec un air satisfait. Pour arriver à un écran qui répond, il a fallu comprendre l’électronique interne, fabriquer une carte réinscriptible, modifier la boucle de test, simuler une ligne téléphonique, reproduire une séquence de signalisation et finalement écrire l’autre extrémité du réseau.
C’est ce déplacement qui rend le projet intéressant. On parle souvent de préservation du matériel comme si conserver le plastique et le silicium suffisait. Un objet connecté raconte exactement l’inverse. Le matériel peut survivre physiquement tout en devenant fonctionnellement incompréhensible parce que son environnement a disparu.
Un modem qui est presque un deuxième ordinateur
Le Network System, référencé HVC-050, se branche sur le port cartouche de la Family Computer. NESdev le décrit comme un adaptateur destiné à un réseau propriétaire par modem téléphonique, avec un pavé numérique dédié. Les cartes commerciales pouvaient servir à la banque, aux informations boursières, aux paris hippiques ou à des jeux comme le shōgi.2
Ce qui ressemble extérieurement à un accessoire est en réalité une petite machine greffée à la Famicom.
Le circuit RF5C66 gère une cartographie mémoire spécifique, une RAM interne de 8 Kio, de la RAM graphique et l’accès à une ROM de caractères kanji.2 Surtout, le RF5A18 contient un second processeur, appelé CPU2 dans la documentation NESdev : un 65C02 avec sa propre horloge et sa propre ROM interne. C’est lui qui s’occupe d’une grande partie des communications du modem. Il échange avec le processeur principal de la Famicom à travers plusieurs registres bidirectionnels.2
Le détail compte. Si le modem avait été un simple convertisseur analogique accroché derrière le processeur principal, on aurait pu observer quelques octets et écrire vite un substitut. Ici, une couche entière de comportement vit dans une puce séparée. NESdev documente même l’UART interne, ses registres de configuration et des modes de transmission qui incluent 1 200 bit/s.2
C’est une forme de dépendance encapsulée. Le logiciel commercial demande quelque chose au modem. CPU2 traduit cette demande en opérations sur la ligne. Le réseau distant répond selon des conventions de téléphonie aujourd’hui étrangères à un banc de test USB. Une panne de compréhension à n’importe quel étage produit la même chose à l’écran : rien.
La documentation NESdev est donc aussi importante que le matériel. Elle rassemble des années d’observations sur les registres, les signaux et les comportements des logiciels commerciaux.2 Certaines parties restent explicitement inconnues ou théoriques. C’est sain. Une carte mémoire pleine de cases « unknown » vaut mieux qu’une histoire rétrotech où chaque mystère est transformé en certitude pour que le paragraphe tombe bien.
Le premier outil utile n’était pas le serveur
Avant de refaire un service distant, il fallait pouvoir faire varier rapidement ce qui tourne sur la Famicom.
Dans la vidéo, une étape décisive arrive vers 26 min 33 : une carte flash pour le Network System fonctionne enfin avec plusieurs ROM de test.1 Le projet Flash-FNS sert précisément à cette couche : remplacer la rigidité d’une carte d’époque par un support sur lequel on peut charger du logiciel expérimental.3
Ce n’est pas un détail de confort. En reverse engineering, la vitesse de la boucle de test décide souvent de ce qu’on finit par comprendre.
Le parcours de Throaty Mumbo le montre assez brutalement. Vers 9 min 52, il revient sur plusieurs mois de travail sans résultat concluant et sur l’aide accumulée par la communauté NESdev.1 Puis, autour de 29 min 57, il identifie un problème plus méthodologique que matériel : sa boucle de test elle-même l’amenait dans la mauvaise direction. Il change d’approche.1
C’est probablement la partie la plus transférable du projet. Quand un système opaque ne répond pas, l’envie naturelle est d’ajouter de l’analyse : davantage de captures, davantage de désassemblage, davantage d’hypothèses. Mais si le test prend trop longtemps ou mélange plusieurs variables, on accumule surtout des ambiguïtés plus vite.
La carte réinscriptible fait alors quelque chose de plus profond que « moderniser » un périphérique. Elle rend l’objet expérimental. Au lieu d’interroger un système figé uniquement avec les logiciels qui nous restent, on peut fabriquer des questions adaptées au mystère du moment.
C’est le même geste que poser des points de mesure sur une machine, écrire un test minimal pour une bibliothèque ou fabriquer un gabarit dans un atelier. La préservation avance lorsque l’on peut provoquer le comportement, pas seulement le regarder.
La prise téléphonique n’est pas le réseau
Une fois le logiciel contrôlable, il reste un autre piège : simuler une ligne téléphonique ne consiste pas seulement à relier deux modems avec deux fils.
Dans la démonstration, Super Mario Club finit par parler à un PC autour de 33 min 39.1 Mais la connexion demande encore de reproduire une signalisation que le matériel attendait du réseau NTT. Entre 34 min 38 et 36 min 29, Throaty Mumbo montre notamment l’usage d’un relais pour inverser la polarité de la ligne ainsi qu’une séquence de tonalité à 400 Hz.1
Le README de SMC-Server explique le problème de manière très concrète : la carte attend une inversion de polarité utilisée comme supervision de réponse, et le simulateur de ligne employé ne la fournit pas directement. Le banc ajoute donc un relais pour la produire.4
Cette nuance interdit une formule tentante : le Famicom Network System n’a pas été « remis sur le réseau téléphonique japonais ». La démonstration publiée fonctionne sur une ligne locale simulée. Le dépôt SMB-FCNS mentionne bien qu’une vraie ligne fixe pourrait théoriquement être utilisée, mais la marque explicitement comme non testée dans ce contexte.5
La distinction paraît tatillonne jusqu’au moment où l’on essaie de reproduire l’expérience. Une restauration sérieuse n’est pas seulement une vidéo où l’écran finit par afficher quelque chose. C’est aussi la liste précise de ce qui a été substitué au système d’origine.
Ici, l’échange analogique est simulé. Une partie de la supervision téléphonique est reproduite par un relais. Les cartes de communication d’origine peuvent être remplacées par des cartes flash modernes. Et l’ordinateur distant n’est évidemment pas un serveur Nintendo réveillé dans un sous-sol.
Le serveur original ne revient pas
Vers 39 min 17, la démonstration arrive au point le plus facile à mal raconter. Le service original est mort. La réponse n’a pas été de retrouver une sauvegarde secrète, mais d’en reconstruire une version compatible à partir de ce que le client attend et de la documentation disponible.1
Le dépôt SMC-Server est exceptionnellement clair là-dessus. Il fournit un serveur factice destiné à reproduire le comportement et l’apparence générale nécessaires au logiciel Super Mario Club. Le protocole a été dérivé par analyse du code 6502 de la carte. Aucun code Nintendo n’est distribué.4
Mais le contenu servi n’est pas une archive historique. Le README prévient que les dates, classements de ventes, notes et annonces dans le répertoire site/ sont inventés, avec une plausibilité d’époque destinée à exercer le protocole. Une partie de ce contenu a même été générée par LLM.4
C’est une limite, mais c’est aussi une excellente définition de la préservation fonctionnelle.
On peut préserver au moins trois choses différentes. La première est l’objet physique : le modem, les circuits, les cartes. La deuxième est le comportement : les signaux, les trames, les règles d’acceptation. La troisième est le contenu historique : ce que le service envoyait réellement à telle date, à tel client.
Ce projet récupère beaucoup de la deuxième couche. Il ne prétend pas récupérer la troisième.
Cette séparation est précieuse parce qu’Internet a rendu les trois faciles à confondre. Lorsqu’un service web disparaît, on peut parfois archiver des pages. Lorsqu’un périphérique des années 1980 dépendait d’un protocole téléphonique propriétaire et d’un serveur central, conserver des captures d’écran ne suffit pas. Il faut reconstruire les conditions qui faisaient naître ces écrans.
Le client devient la documentation du serveur
Quand le serveur a disparu, le logiciel client devient parfois le meilleur document qui reste.
C’est exactement ce qu’exploite SMC-Server. Le code contient un modèle des contraintes imposées par la carte : format des trames, contrôles d’acceptation, construction des pages, règles de retour à la ligne. Le serveur peut même refuser au chargement une page que la carte rejetterait, ce qui permet de tester la structure avant de redialer.4
Autrement dit, l’équipe n’a pas seulement écrit un faux serveur jusqu’à obtenir un écran joli. Elle a progressivement extrait une spécification implicite du client.
C’est un renversement assez beau. Un logiciel fermé conçu pour consommer un service devient, des décennies plus tard, le témoin technique qui permet de décrire ce service.
La communauté NESdev joue ici le rôle de mémoire distribuée. Le wiki et le fil de forum accumulent mesures, désassemblages, essais sur banc et hypothèses depuis plusieurs années.2 6 Tout n’est pas résolu. Mais chaque registre compris réduit la quantité de magie nécessaire pour expliquer la machine.
Ce genre de documentation a une valeur étrange : elle est souvent plus utile aujourd’hui que la documentation commerciale d’époque. Un manuel utilisateur dit comment appeler le service. Une page de reverse engineering dit quel bit change quand la ligne répond, quel processeur l’observe et quel registre transmet l’état au programme principal.
Pour garder un objet utilisable après la disparition de son fabricant, c’est souvent cette deuxième documentation qu’il fallait avoir depuis le début.
Puis le réseau cesse même d’avoir besoin d’un serveur
La dernière expérience déplace encore le projet.
Autour de 49 min 50, deux Famicom communiquent directement l’une avec l’autre, sans serveur central.1 Le dépôt SMB-FCNS modifie Super Mario Bros. pour exploiter le Network System en pair-à-pair. Son README ne prétend pas que c’est une fonction historique cachée : c’est un proof of concept contemporain, volontairement absurde au regard des moyens beaucoup plus simples de jouer en réseau en 2026.5
Justement. C’est le bon test.
Il existe une différence entre reproduire une démonstration et posséder suffisamment le modèle pour faire quelque chose que le système original n’avait pas prévu. Le pair-à-pair ne rend pas la reconstruction plus historiquement fidèle. Il fait mieux : il montre que la compréhension technique est devenue productive.
Une fois le protocole, le modem et les cartes assez documentés, le matériel ancien cesse d’être uniquement un artefact à imiter. Il redevient une plateforme.
C’est aussi là que la carte flash moderne prend tout son sens. Elle n’efface pas l’authenticité du système. Elle sépare deux objectifs. Pour étudier le comportement original, on conserve les cartes et logiciels d’époque. Pour comprendre la machine, on lui donne aussi des outils qui n’existaient pas alors.
La documentation devient elle aussi une pièce de la machine
Une conséquence moins spectaculaire apparaît une fois la démonstration terminée : le résultat durable n’est pas seulement la vidéo. Ce sont les dépôts, les schémas de comportement, les outils de test et les limites écrites noir sur blanc. Sans eux, la prochaine personne devrait recommencer une partie de l’archéologie.
Le wiki NESdev fait ici quelque chose qu’un musée ne peut pas faire seul. Il ne montre pas seulement à quoi ressemble le périphérique. Il conserve des adresses mémoire, des chronologies de signaux, des hypothèses réfutables et des observations parfois contradictoires.2 Le dépôt du serveur fait pareil à un autre étage : il transforme les contraintes découvertes dans la carte en code que l’on peut relire, modifier et tester.4
Cette documentation n’est évidemment pas définitive. Certaines cases resteront peut-être inconnues jusqu’à ce qu’un nouveau banc de mesure ou un autre logiciel commercial révèle un comportement. Mais elle change déjà la nature de l’objet. Un périphérique opaque dépendant d’une infrastructure morte devient un système dont plusieurs frontières sont nommées.
Il y a une différence importante entre « nous avons réussi à le faire marcher une fois » et « nous pouvons expliquer à quelqu’un d’autre pourquoi cela marche ». La première phrase produit une démonstration. La seconde commence à produire une préservation.
Ce que cette restauration conserve vraiment
À 53 minutes, la démonstration tourne localement sans incident majeur visible et les cartes flash font désormais partie de l’installation.1 On pourrait s’arrêter à l’image : une technologie morte fonctionne de nouveau.
Mais « fonctionne » cache tout ce qui a changé.
Le réseau téléphonique est simulé. Le service distant est une réimplémentation. Les données de Super Mario Club ne sont pas récupérées. Une carte moderne facilite l’expérimentation. Certaines zones des puces restent inconnues dans la documentation NESdev. Et la validation publiée ne couvre pas le réseau téléphonique public réel.2 4 5
Ce ne sont pas des défauts à excuser. Ce sont les limites qui rendent le résultat intelligible.
La restauration atteint quelque chose de plus utile qu’une illusion parfaite : une chaîne explicable. On peut suivre le trajet depuis le programme Famicom jusqu’aux registres du modem, de l’UART à la ligne, de la signalisation au modem USB, puis du protocole reconstitué au serveur moderne. On peut identifier où l’original s’arrête et où le substitut commence.
C’est une leçon assez dure pour beaucoup d’objets contemporains. Une console hors ligne peut souvent survivre dans un tiroir. Un appareil dépendant d’un compte, d’une API ou d’un serveur propriétaire peut devenir une coque impeccable en quelques années. Le plastique ne sait pas documenter une requête HTTP. Une puce radio ne conserve pas les règles d’authentification de l’autre côté.
Le Famicom Network System a eu une chance inhabituelle : des gens ont accepté de traiter son environnement disparu comme une partie de l’objet.
Le plus beau résultat n’est donc pas qu’un service de 1988 semble revenir à l’écran. C’est qu’on peut maintenant expliquer, tester et modifier une partie de la chaîne qui le faisait exister. Le modem avait survécu depuis longtemps. Il a fallu reconstruire autour de lui assez de monde pour qu’il redevienne compréhensible.