The Famicom Network System did not need repairing in the usual sense. The plastic was there. The chips were there. The modem could still make its tones. The awkward problem was that almost everything the object knew how to talk to had disappeared.
In August 2026, Throaty Mumbo showed one of Nintendo’s network adapters exchanging data again after months of work.1 7 This was not the familiar kind of restoration where two capacitors are replaced, a connector is cleaned and the object returns to a shelf looking pleased with itself. Getting a responsive screen required understanding the internal electronics, obtaining a rewritable communications card, improving the test loop, simulating a telephone line, recreating signalling that the old network supplied and eventually writing the other end of the service.
That shift is what makes the project worth studying. Hardware preservation is often described as though keeping the plastic and silicon intact were the hard part. A networked object gives the opposite lesson. Hardware can survive physically while becoming functionally opaque because the environment that made it useful has vanished.
A modem that is almost a second computer
The HVC-050 Network System plugs into the Family Computer’s cartridge connector. NESdev describes it as an adapter for a proprietary dial-up network, sold with a dedicated numeric controller. Commercial communication cards were used for services including banking, stock information, horse-race betting and traditional games such as shogi.2
What looks like a peripheral from the outside is closer to a small computer grafted onto the Famicom.
The RF5C66 provides its own memory mapping, internal RAM, graphics RAM management and access to a Kanji character ROM.2 More importantly, the RF5A18 contains a second processor, called CPU2 in NESdev’s documentation: a 65C02 with an independent clock and its own internal ROM. It handles much of the modem work and exchanges data with the Famicom CPU through bidirectional registers.2
That detail changes the reconstruction problem. If the modem were merely an analogue converter hanging off the main CPU, a few captured bytes might have been enough to build a substitute. Here, a whole layer of behaviour lives in another chip. NESdev documents an internal UART, its status and configuration registers, and transmission modes that include 1,200 bit/s.2
This is dependency hidden inside hardware. Commercial software asks the modem to do something. CPU2 translates that request into operations on the telephone side. The remote network answers according to conventions that are alien to a modern USB test bench. A misunderstanding at any one layer produces the same user-facing symptom: nothing happens.
NESdev’s documentation therefore matters as much as the surviving unit. It collects years of measurements, software observations and reverse engineering around the registers and signals.2 Some fields are still explicitly unknown or theoretical. That is useful honesty. A memory map with several “unknown” entries is more valuable than a retro-computing story that quietly turns every gap into a fact so the paragraph can end neatly.
The first useful replacement was not the server
Before rebuilding a remote service, the experiment needed a fast way to change what ran on the Famicom.
Around 26:33 in the video, a flash card for the Network System finally works with test ROMs.1 Flash-FNS provides that layer: instead of depending entirely on fixed period communication cards, it gives experimenters a practical route for loading software built to answer one technical question at a time.3
That is not merely convenient. In reverse engineering, the speed and quality of the test loop often determine how much of the machine can eventually be understood.
Throaty Mumbo’s account makes the point unusually clearly. At roughly 09:52, he describes months of work that had not yet produced the desired result and points to the accumulated NESdev community work behind the project.1 Later, around 29:57, the problem turns out to be partly methodological: the existing test loop itself was sending the investigation in the wrong direction. The approach changes.1
This may be the most reusable part of the story. When an opaque system refuses to respond, the instinct is to add more analysis: longer captures, more disassembly, more theories. But a slow test that changes several variables at once can generate ambiguity faster than knowledge.
The rewritable card therefore does something deeper than modernising a peripheral. It makes the object experimental again. Instead of interrogating a frozen system only through whichever commercial software happened to survive, the investigator can construct questions for the particular mystery being examined.
It is the same move as adding test points to a machine, writing a minimal failing case for a software library, or building a jig in a workshop. Preservation advances when behaviour can be provoked deliberately, not merely admired.
A phone socket is not the network
Once the software is controllable, another trap appears. Simulating a telephone line is not simply a matter of connecting two modems with a pair of wires.
In the demonstration, Super Mario Club finally talks to a PC at about 33:39.1 The connection still depends on signalling that the hardware expected from NTT’s telephone infrastructure. Between roughly 34:38 and 36:29, the setup uses a relay to reverse line polarity and reproduces a 400 Hz tone sequence.1
SMC-Server’s README describes one part of the issue plainly: the card waits for a polarity reversal used as answer supervision, while the line simulator used for the project does not provide that behaviour on its own. A relay supplies it.4
That distinction rules out an attractive headline: the Famicom Network System has not been demonstrated back on Japan’s public telephone network. The published setup uses a local simulated line. SMB-FCNS says an actual landline is a possible hardware option, but explicitly labels it untested for this proof of concept.5
The distinction sounds pedantic until someone tries to reproduce the work. Serious restoration is not simply a video in which an old screen eventually lights up. It is also an inventory of substitutions.
Here the analogue exchange is simulated. Part of the original answer supervision is reproduced with a relay. Period communication cards can be replaced with modern flash hardware. And the machine at the other end is obviously not a Nintendo server found humming in a forgotten basement.
The original server does not come back
Around 39:17, the project reaches the point most likely to be misreported. The original remote service is gone. The solution was not a rediscovered backup. It was to construct a compatible server from the surviving client’s behaviour and available documentation.1
SMC-Server is admirably blunt about what it is. The repository implements a mock server intended to reproduce enough of Super Mario Club’s protocol and feel for the real cartridge to interact with it. The implementation was derived from reverse engineering the cartridge’s 6502 code, and it distributes no Nintendo code or data.4
The material it serves is not a recovered historical archive. The README warns that the release dates, sales forecasts, review scores and publisher announcements under site/ are invented period-plausible data created to exercise the protocol. It also says much of that mock content is LLM-generated.4
That limitation gives us a useful definition of functional preservation.
At least three different things can be preserved. The first is the physical object: modem, chips, connectors and cards. The second is behaviour: signals, frames and acceptance rules. The third is historical content: what the original service actually transmitted to a particular user at a particular time.
This project recovers a large part of the second layer. It does not claim to have recovered the third.
Keeping those categories separate matters because networked computing makes them easy to blur. When a website disappears, an archive may retain pages. When an 1980s peripheral depended on a proprietary dial-up protocol and a central service, screenshots are nowhere near enough. The conditions that produced those screens have to be reconstructed.
The client becomes documentation for the server
When the server has disappeared, the surviving client can become the best technical document left behind.
That is what SMC-Server exploits. Its code models constraints imposed by the cartridge: framing, validation, content structures and even line-wrapping behaviour. A page that the cartridge would reject can be rejected by the tooling before another call is made.4
The team is therefore doing more than tweaking a fake server until the screen looks convincing. It is extracting an implicit specification from the client.
There is something elegant about the reversal. Closed software built to consume a service becomes, decades later, evidence from which that service can be described.
NESdev acts as a distributed technical memory. Its wiki and forum thread accumulate measurements, disassembly work, bench tests and hypotheses from multiple contributors.2 6 The map is incomplete, but each understood register reduces the amount of magic needed to explain the device.
This kind of documentation is often more useful to preservation than the commercial documentation that originally accompanied a product. A user manual explains how to dial the service. Reverse-engineering notes explain which bit changes when the line answers, which processor sees it and which register carries that state back to the main program.
If a device is expected to remain usable after its maker leaves, the second kind of documentation is what we wish had existed from day one.
Then the network stops needing a server at all
The final experiment pushes the reconstructed system somewhere it was not historically designed to go.
Around 49:50, two Famicoms communicate directly with one another, with no central application server.1 SMB-FCNS modifies Super Mario Bros. to use the Network System for peer-to-peer play. Its README does not present this as a rediscovered Nintendo feature. It calls the project a proof of concept and jokes that there are obviously easier ways to play Super Mario Bros. remotely in 2026.5
Exactly. That is why it is a useful test.
There is a difference between reproducing one demonstration and understanding a system well enough to make it do something that was not part of the original service. Peer-to-peer play does not make the restoration more historically authentic. It demonstrates something more useful: the technical model has become productive.
Once the protocol, modem and communication card are documented well enough, the old hardware stops being only an artefact to imitate. It becomes a platform again.
The flash card makes sense in the same way. It does not erase the original object. It separates two goals. Period cards and software can be retained when historical behaviour is the question. Modern tools can be used when the aim is to understand the machine by asking it new questions.
Documentation becomes part of the machine
A less photogenic consequence appears after the demo is over. The durable result is not only the video. It is the repositories, behavioural models, test tools and explicit statements of what remains unknown. Without those, the next person would have to repeat a large part of the archaeology.
NESdev does something here that displaying the physical peripheral cannot do. It preserves addresses, timing observations, signals, test results and hypotheses that can be challenged by another measurement.2 The server repository does the same at another layer by turning constraints discovered in the cartridge into code that can be read and exercised.4
None of this documentation is final. Unknown registers may become understood when another piece of commercial software is analysed or a better bench test is devised. But the material already changes the nature of the surviving object. A black box tied to dead infrastructure becomes a system with named boundaries and repeatable experiments.
There is a large difference between “we got it working once” and “we can explain to someone else why it works.” The first produces a demonstration. The second begins to produce preservation.
What this restoration actually preserves
By the end of the video, the local setup can run sustained exchanges and modern flash cards have become ordinary components of the test system.1 It would be easy to stop at the satisfying image: a dead technology lives again.
But “works” hides everything that changed.
The telephone network is simulated. The remote service is a reimplementation. Super Mario Club’s historical data was not recovered. A modern card accelerates experimentation. Parts of the hardware remain unknown in NESdev’s documentation. And the published demonstration does not validate operation across the real public telephone network.2 4 5
Those are not defects to apologise for. They are the boundaries that make the result intelligible.
The restoration achieves something more useful than a perfect illusion: an explainable chain. We can follow the path from Famicom software to modem registers, from the UART to a simulated telephone line, from answer signalling to a USB modem, and from the reconstructed protocol to the modern server. We can point to where original behaviour ends and a substitute begins.
That lesson is uncomfortable for many current products. An offline console can often survive in a drawer. A device that depends on an account, API or proprietary server may become a pristine shell in only a few years. Plastic cannot document an HTTP request. A radio chip does not preserve the authentication rules that once lived at the other end.
The Famicom Network System got an unusual second chance because people treated its vanished environment as part of the object.
The most interesting result is therefore not that a service from the late 1980s appears to return on a CRT. It is that part of the chain can now be explained, tested and modified. The modem had survived for decades. What had to be rebuilt was enough of the world around it for the hardware to become understandable again.