The board was soldered, the chips were flashed, and the FujiNet menu came right up. The trouble started one step later: every time I picked a game to boot, the MSX dropped me onto its own built-in desktop instead of loading it. This is the part where I was most out of my depth, and the part I learned the most from. Not one of the walls turned out to be a fault in anyone's work—and one of the fixes I still can't fully explain.
In Part 1 I covered what this is: a prototype FujiNet board for the MSX—an ESP32-S3 for WiFi and a Raspberry Pi Pico pretending to be a cartridge—that lets a 1986 Panasonic FS-A1 load games over the internet, and how I got pulled into it through the local Atari club. Soldering the board together was the comfortable part. Getting the FS-A1 to actually use it was where I had to slow down, ask a lot of beginner questions, and learn how this little two-chip setup really works. Here's each wall I hit, and what climbing it taught me.
The games that wouldn't launch
Getting to the FujiNet menu was never the problem. Power on, and there it was: WiFi up, the host list, everything. The wall was the very next step. I'd highlight a game, tell it to boot, and instead of the game I'd land on Panasonic's built-in desktop—the little clock-and-calculator suite the FS-A1 starts up with. Every single time. To a beginner that looks exactly like "the cartridge is broken."
I chased a couple of wrong leads first—wondering if it was something about the FS-A1's built-in software, even whether I needed to hold a key down at boot. None of that panned out. What actually got me unstuck was odd enough that I want to describe it plainly rather than dress it up as a rule.
When an update came along, I'd reflash the ESP32 WiFi chip and leave the Pico—the cartridge chip—alone, figuring the WiFi side was the only thing that had changed. That's about when the games started dropping to the desktop. Out of pure stubbornness, I had Claude Code, running in VS Code, walk me back through the entire flashing sequence the exact way it had gone the last time everything worked—and the step that brought the games back was reflashing the Pico, even with the same firmware it already had. Same file, flashed again, and it played.
I can't really explain that, and I'm not going to pretend I can. Reflashing a chip with firmware identical to what's already on it shouldn't change anything, which makes me think the reflash isn't the real fix at all—more likely the Pico just needed a reset, and flashing it happens to reset it on the way through. Somewhere there's probably a simpler move—a button, a flag, a proper sequence—that does the same thing in one step, and I just haven't found it. So take this as a beginner reporting what worked, not a how-to: if your games won't launch after you've touched the WiFi side, try reflashing the Pico and power-cycling. It got me playing. The why I'm happy to leave to the people who actually understand this board.
One genuine bit of MSX lore worth knowing while you're in here: never hold SHIFT at boot. On an MSX, SHIFT at power-on disables disk loading—the exact channel FujiNet uses—so it's an easy way to accidentally block the very thing you're trying to make work.
One wire that isn't optional
A smaller trap, but it fooled me the same way. In normal use, the Pico has to be connected by a short cable to the port marked "To Pico"—that's the link the two chips use to talk to each other. Plugging a chip into the Mac is only for flashing it.
I had a stretch where everything was flashed correctly and it still looked dead, because that chip-to-chip cable was on the wrong port. With the link missing, the FujiNet menu can't reach the WiFi, and to a beginner it looks exactly like a firmware failure. Lesson logged: check the cable before you blame the code.
The microSD card that wasn't my fault (or anyone's, really)
The last holdout was the microSD card slot, which simply never saw a card. Soldering is the one part of all this I'm actually confident about—I've done plenty of it, and I was sure the joints were good, so I never doubted the iron work. What nagged at me was a different mistake, one I'd made earlier: I never tested either board before I soldered them down.
That's my own rule, broken. It's the whole reason I bench-check PlusCart boards before I commit them—catch a problem while it's still easy to fix, before everything's permanent. Here I got excited to see the thing come alive and skipped my own step. Lesson re-learned: test first, solder second, no matter how eager you are.
As it happened, the slot wasn't on me at all. nwah pointed me to the real story: these are inexpensive, off-the-shelf ESP32-S3 boards, and on this batch some of the microSD connections simply weren't wired up at the factory. I can't tell you exactly which one got me—the chip-select line and the card-detect switch both turned up as unconnected suspects—but it was a gap in the board's wiring, not anything I did with an iron. And it wasn't just me: FozzTexx had to add a little jumper to fix seven of these things, and another builder traced the same dead pins on his. I'd gone deliberately budget on this whole build—the cheapest board on offer, bargain microSD cards, eyes wide open—so I had a few low-cost variables to rule out before the real culprit turned up. Buying cheap, I tend to buy in pairs: I'd picked up two ESP32-S3 boards for exactly this kind of situation, and that spare now gives me a way to check whether the same gap is sitting on the second one too. But it wasn't my soldering, my card, or my firmware; it was a rough edge on cheap, mass-produced hardware—the normal texture of tagging along on something still being brought up. And the best part is that it stopped mattering entirely, which is where Part 3 picks up.
What I learned
The theme of this round, looking back, is how much of "debugging" was really just me learning how the machine and the project actually work. The games dropping to the desktop weren't a broken cartridge—reflashing the Pico brought them back, for reasons I still can't fully explain. The dead-looking board was a cable on the wrong port. The SD slot was a shared hardware quirk, not my soldering. Almost nothing here was a fault in someone's work—it was the gap between what the experts know in their bones and what a curious newcomer has to find out the hard way. Closing a little of that gap, out loud, is the whole point. Part 3 is the reward.
Frequently asked
Why do FujiNet games drop to the FS-A1's built-in desktop instead of loading?
On this bench the fix that restored launching was reflashing the Pico (the cartridge chip) and power-cycling, even with the same firmware already on it—the reflash seems to reset the Pico rather than fix a mismatch. Also never hold SHIFT at boot, since that disables the disk-loading path FujiNet uses.
Why would a fully flashed MSX FujiNet board still look dead?
Check the chip-to-chip cable before blaming firmware. The Pico must be connected by its short cable to the port marked "To Pico"; with that link on the wrong port the FujiNet menu can't reach the WiFi and it looks exactly like a firmware failure.
Why doesn't the microSD slot work on some MSX FujiNet boards?
On this batch of inexpensive off-the-shelf ESP32-S3 boards, some microSD connections were never wired at the factory—the chip-select line and card-detect switch both turned up as unconnected suspects. It was a board wiring gap, not a soldering fault; FozzTexx added a jumper to fix seven of them.
Further reading
- Panasonic FS-A1—MSX Wiki—the machine, its built-in software, and boot behavior.
- FujiVersal on GitHub—FozzTexx's Pico firmware that drives the cartridge side of the board.
- FujiNet project home—the wider FujiNet project and community.
0 comments