Have you played the unlicensed Taiwanese game Huang Di: Zhuo Lu Zhi Zhan on Famicom / NES? If you have, you already know about the weird "infinite jumping glitch" where your character flies around if the jump button is held. It removes any challenge and breaks the game. Well, the problem has been fixed and I'm going to explain how I did it. If you just want the patch without the story, scroll to the bottom.
If you've not played Huang Di (the full title of which translates as Yellow Emperor: Battle of Zhuolu), then you should. It's one of the absolute all-time best unlicensed games for the system. There are a lot of interesting unlicensed games available, such as the Resident Evil and Final Fantasy VII demakes, but Huang Di is unique because it's not based on another game, but rather the real-life mythical sovereign that is the Yellow Emperor.
It therefore features all sorts of cool set-pieces and monsters based on ancient legend, backed by some great music. It's also a very challenging action platformer when played correctly – the various "speedruns" you can see online are quite amusing, since they've obviously playing the bugged version. I first wrote about Huang Di for Retro Gamer many years ago (that screenshot is doctored to show more enemies than normal), and then again for Hardcore Gaming 101. In fact, I love it so much that I was determined to find a way to play it as intended. But first, some background...
Back in 2012 when writing the HG101 article there was a discussion as to whether this was actually a bug or intentional. Given the in-game cinemas show the main character flying around on a sword, one reader hypothesized that perhaps you're meant to fly. Various emulators reproduced the problem, and it was only after reader Ghegs tracked down an original Famicom cartridge that was it proven not to occur on real hardware. Simple then, it's obviously just an emulator glitch that doesn't occur on real hardware. Once we had cycle-accurate NES emulators, it would probably go away, similar to how emulators couldn't display the shadow in Air Strike Patrol on SNES until we had HIGAN.
I then purchased a NES PowerPak flash cartridge to play the game on my original NTSC toaster NES without this glitch (in 60Hz!). Huang Di worked correctly. However, sometime between 2012 and now, various new mapper sets were updated as they became available, culminating in 1.35b, plus Loopy's extra mappers, plus TheFox's power mappers, plus some other miscellaneous additions. (I also thought maybe I'd upgraded the firmware, but this turned out not to be the case.) Anyway, after various file updates, the game broke again. The same glitch of infinite flight.
Well, simple solution, right? Just erase the memory card and reinstall the older mappers. First was the immediately previous folder of mappers, since I always kept a backup in case something went wrong. No good. NES PowerPak maker RetroUSB still has available older legacy mappers for v1.20, but after playing around with the URL link, I managed to access their hidden archive of v1.00. Several hours later, after multiple erasures and reinstalls, and Huang Di still didn't work correctly.
Do you ever have a situation where you think you remember something one way, but then the evidence proves it's the other way, so you just assume you remembered wrong? I was starting to think maybe Huang Di never worked on the PowerPak, and I just imagined it... Except no, I posted online about it working, so the memory was real.
Hours were spent researching the problem. Huang Di uses INES Mapper 112, the name of which is converted to hexadecimal for PowerPak's menu folder, and is named MAP70.MAP – however, every single mapper release for the PowerPak produced the same problem. Maybe it was the firmware at fault? But how, and why? Had I updated it? Is it even possible to downgrade cartridge firmware, or would this brick it?
RetroUSB was duly contacted, and they explained:
"The actual firmware on the cart is not user updatable. There is nothing you did to reprogram the PowerPak itself. The only thing I can think of is you had an alternate mapper file, there was some sort of modification to the mapper file, or you were using an alternate ROM that had a modification."
The solution seemed so tantalisingly close. Perhaps one of the hackers on either Romhacking or NESDev may have an idea? Forum user Rainwarrior on NESDev, back in 2016, actually posted information that would lead us to the answer. He posted an excerpt from someone's commentary on NES emulator FCEUX. The emulator, when started, initialises the RAM to a string of 00 and FF. It basically wipes the RAM clean. Someone worked out that Huang Di expects the RAM at address 0x0100 to return a non-zero number. If the number is zero it defaults into debug mode – presumably so the developers could test it more easily.
It turns out the infinite jumping glitch is not really a glitch; it's an intentional debug mode that is being triggered by accident. But how to fix it on the PowerPak? I asked again about the mappers.
NESDev user Dwedit explained in detail:
"This has nothing to do with mappers at all, and entirely to do with uninitialised memory. The game never writes anything to location 0100, but is reading that byte back. The value could literally be anything, because initial values of uninitialised RAM are based on environmental factors such as static charge and ambient temperature, previous values of the memory, and just how that memory cell happens to be constructed. In order to have things be nice and deterministic, emulators will clear the system RAM to known initial values. FCEUX repeats a pattern of 00 00 00 00 FF FF FF FF that leaves the RAM at 0100 as having a value of 00."
Well, all we needed then was to make sure the RAM at 0100 is not zero. My initial hope was a Game Genie code. The device functioned by changing variables in-game, and the PowerPak had built-in Game Genie functionality, so... easy, right? One just needed to figure out the code using one of several utilities. Except this was not possible, as pointed out by Cyneprepou4uk on RHDN: "It's a RAM address at 0100. Game Genie doesn't modify RAM directly. Emulator cheats do."
Cue more research, and... that's absolutely correct, Game Genie can only write to addresses at 8000 and above. There is no way to use a Game Genie to change that initial RAM value. For that, you need to use an emulator, which allows direct manipulation. Still, this did yield one breakthrough. Loading up an NES emulator and putting the following in as a cheat:
30000100 0001 Adr:0x0100 val:1
This completely fixes the problem. By forcibly writing a value of 1 to that specific address, the debug mode is disabled as intended. So why on earth did the PowerPak suddenly stop working?
Dwedit suggested that:
"A flash cartridge may contain code to clear memory as well. This game is programmed to fill 0000-00FF, and 0200-07FF with 00 bytes at boot time, but it does not fill page 0100-01FF. They skipped clearing that page because they were using a subroutine to clear the RAM, and didn't want to clobber the return address. An earlier version of the flash cartridge may have left behind leftover RAM contents from the menu system at the time the game booted. A different version of the menu may have cleared the RAM instead, or left behind different memory values."
Well, if the cartridge was resetting the RAM, and Game Genie couldn't access the RAM, did that mean the only way to play the game was emulation in conjunction with the above emulator cheat code? Thankfully, both Cyneprepou4uk and Dwedit responded with code to hack into the game's ROM using a HEX editor. Interestingly, they each provided an entirely different solution, but both of them work:
Cyneprepou4uk:
At 0x1D391 replace 8D 0F 01 with 20 A3 F7
At 0x1F7B3 replace 00 00 00 00 00 00 00 00 00 with 8D 0F 01 A9 FF 8D 00 01 60
Dwedit:
At 0x1D36E replace A9 00 8D 00 20 8D 01 20 with A9 01 8D 00 20 8D 00 01
After using a HEX editor to hack a clean ROM, using one of the above options, it was easy then to use LunarIPS to compare the hacked ROM to an unedited one and create an IPS patch for legal distribution. The patch even works with the fan-translation of Huang Di!
Both forum users gave permission for the patches to be uploaded, which you can now find here. At last, whatever your means of playing Huang Di, it can be played as intended. In fairness, some emulators correct for this, but not all.
Dwedit and Cyneprepou4uk also provided Game Genie codes if you're unable to patch. The technical explanation of how these work, given the earlier RAM explanation, is too complex to summarise. Just make sure to type all three in:
PASSYLAA
AAVIGLPA
PAVIILAZ
For me, the fascinating part of all this is even though the very first Famicom / NES hardware variation came out nearly 40 years ago (July 1983), we are still discovering things. A decade ago, this curious but wonderful unlicensed game was thought to have a glitch. It turned out simply to be a debug mode activating due to the RAM starting at zero. This itself leads to other interesting points, like the fact Metroid uses the initial RAM in its RNG – so is resetting the RAM to zero in an emulator truly accurate when on original hardware, this is not the case?
Regardless of the minutia of this technical rabbit hole, please enjoy the patches I created with the help of Cyneprepou4uk and Dwedit. (Oh, and can someone tell the speedrunners they're playing it wrong and all their times are void unless they play with debug mode off?)