Recreating Namco's IPL Interface after 35 years
by TakuikaNinja
Preface
This is a first-hand recollection of how I reverse-engineered and recreated a proprietary development interface used for Namco’s retail Famicom Disk System (FDS) games.
For technical details, please refer to the following links:
- IPL.MAIN disassembly & interface recreation
- Example program
- NESdev Wiki article
- NESdev Forum discussion
A fake license screen message?
It all started in November of 2023. During a NESdev Discord discussion regarding how unlicensed FDS disks would bypass the license screen, NewRisingSun mentioned the following:
The funniest thing is that licensed Namco FDS games have a kyodaku bypass for some reason. Of course, their kyodaku bypass code checks for the presence of some kind of debug device, and if it’s not attached, just displays the kyodaku screen on its own.
For context, the kyodaku or license screen bypass is a technique associated with disks from unlicensed developers who needed to avoid infringing Nintendo’s trademarks. Basically, one could exploit a flaw in the bootloading logic to make a disk file trigger a Non-Maskable Interrupt (NMI), thus gaining an entrypoint before the license screen check is performed.
Namco is a big outlier, however - they were one of the earliest and most significant third-party developers for the Famicom, going so far as to reverse-engineer the console themselves before negotiating with Nintendo. In contrast to their vast cartridge lineup, Namco only ever released 6 FDS games through the Disk Writer kiosk service, all in 1990. In release order, these are:
- Pac-Man
- Xevious
- Galaga
- Dig Dug
- Galaxian
- Dig Dug II
These are good choices, but one could consider these “too little, too late” for the dying platform. The fact that a licensed developer would bypass, then display a fake license screen anyway is quite odd regardless.
I responded to NewRisingSun’s remark that it probably would have been annoying to sit through the license screen for every debug build. In December 2023, the license screen bypass was brought up again in a discussion regarding the poor accuracy of FDS emulation (which is still an ongoing issue, BTW). I mentioned Namco’s FDS games there and then had a thought: “what kinda (debugging) hardware is it expecting anyway?”
And so began my quest to figure out this mysterious debugging hardware.
Software disassembly & hardware enumeration
I hate to make this anticlimactic but the actual disassembly process was pretty straightforward - even for someone like myself who hadn’t done a full disassembly project before at the time. The program size was only 1.5KiB, of which 189 bytes were zero padding. I used a web-based 6502 disassembler to generate a disassembly I could use as a starting point for analysis. The simple program flow, lack of obfuscation, and heavy use of disk I/O routines from the FDS BIOS ROM made it easy to discern the logic without executing all of the code paths. I found that it had the ability to completely overwrite memory and/or disk contents with newly transferred data from the debugging hardware. After discussing with Fiskbit on Discord, we decided to give it the name “Namco IPL Interface” after seeing the internal disk filename of “IPL.MAIN” and determining that IPL stood for Initial Program Load(er). The term hearkens back to IBM mainframes - the modern term would be “bootloader/bootstrapper”.
Despite the discoveries, I still didn’t fully understand the interactions being made between the program and the hardware. I posted my findings on the NESdev forums to get some ideas from other users. Within 10 days, members had pointed out the most probable hardware setup - a level-shifted RS232 interface connected to another device transmitting Intel HEX payloads at 38400 baud. I used that information to create the NESdev Wiki article for the interface.
Lua recreation & IPL-demo
In July 2024, I shared the initial version of the Lua recreation. At this point, I already owned a Twin Famicom (a combined FC + FDS unit from Sharp) but didn’t have any means of running arbitrary FDS programs, nor the hardware needed to do serial transfers. Because of that, I had to implement the interface in a Lua script in order to test it with an NES emulator first. (Mesen2 in this case) I then made a demo program compatible with the IPL, creatively called IPL-demo. It simply calculates and displays the CRC32 value for the memory region occupied by the IPL program. Come October 2024, and I had managed to improve the Lua script’s performance to bring transfer speeds up to simulated real-time.
In November 2024, I purchased an FDSKey and an adapter cable for my Twin Famicom. This finally let me run arbitrary FDS programs, including those created using the IPL. I immediately put this to good use by (re)creating unofficial FDS ports of various cartridge games, some of which I had seen in Yahoo Auction listings. In particular, BattleCity was ported using the IPL since it was originally published by Namco (and therefore would have been eligible for this method). I’ll post about unofficial disk ports some other time.
Arduino recreation
I put off the hardware recreation for a while due to being unfamiliar with the topic, though I did discover that the IPL could be triggered by shorting two pins on the Famicom’s expansion port. After seeing an Arduino UNO R3 kit on clearance in July 2025, I purchased it on a whim to see if it could be used to recreate the IPL interface. It didn’t take long to find that the Arduino’s SoftwareSerial library conveniently provided an initialisation setting to invert the 5V TTL serial output - exactly what I needed for it to transfer payloads without adding an inverter to the signal path. I used that to construct an interface that would relay payloads from my host machine to the Twin Famicom running the IPL. With that, the Namco IPL Interface was successfully used for the first time in 35 years, by someone other than the original developers.
Closing thoughts
This reverse-engineering project went surprisingly well for the experience level I was at when I started. The hardware recreation especially worried me but the Arduino thankfully made it easy to implement. I’ve since used the Arduino to recreate peripherals such as the Arkanoid paddle and the Coconuts Japan Pachinko controller. (That’ll be a topic for later.)
During the gap between the Lua and Arduino recreations, I encountered a three-part video series by Japanese creator 4ST. He managed to privately interview Haruhisa Udagawa, the Namco engineer primarily responsible for the early Famicom reverse-engineering and game programming:
- Part 1: Early life, arcade reverse-engineering, applying to Namco & reverse-engineering the Famicom, FC Galaxian port development
- Part 2: More FC ports, dev anecdotes, soundchip development (including the N163), FDS hacking
- Part 3: PCE Youkai Douchuki development, scrapped projects, FDS ports, ventures beyond Namco
In parts 2 and 3, Udagawa recalls the time he managed to bypass the FDS license screen, and the fact that he subsequently used it in his final projects before leaving Namco. I would certainly be interested to know how much he was involved with the IPL and its interface.
With all that said, I’m very proud to have documented a small but interesting part of Namco’s FDS development history. I hope this was an interesting read!
tags: Famicom - FDS - Namco - 6502 - assembly - disassembly - Lua - Arduino