Huang Di (NES) mystery - jumping glitch and Powerpak mappers

[RetroProf]

I figure you guys are the experts on this, so I made an account just to ask - hello all!

I've got a weird mystery here and it's been driving me crazy. Does anyone have any information regarding this?

Huang Di: Zhuo Lu Zhi Zhan is an unlicensed NES game developed and published by Asder on 1994. HG101 article on it written by me.

Infamously when using an emulator the internal timing is off and your jumping is infinite.

This RHDN user wanted to make a Game Genie code to fix it.

Playing the original cartridge on a real Famicom fixes this.

In 2012, I bought an NTSC American NES and Powerpak cartridge and confirmed that the game works normally when played on actual hardware.

I bought the cartridge used. I do not remember what version of mappers came pre-installed. I just know they were the original official mappers, and not one of the forks by Loopy or TheFox or the other programmers adding to it. Since then I've updated the Powerpak mappers as revised or modified editions came out and...

At some point the newer sets broke the game again, and the jumping glitch has returned. (Or possibly it's related to a firmware upgrade I did, from 1.00 to 1.11?)

The logical solution then would be to erase the POWERPAK folder container the mappers and revert to an older set. This is where stuff gets weird.

THIS is the page for the Powerpak listing the official mappers. Latest official is 1.34. They also have a legacy set from 1.20. However by playing with the URL address I managed to find 1.00 (direct ZIP download).

None of these correct the problem. I have erased the mapper folder and installed the 1.00 set, and each incremental set above that as listed in the changes TXT. All the way up to the 1.35 beta set, plus Loopy and other contributors additions.

NONE of them replicate the functionality I had in 2012. I am amazed and baffled at the fact I cannot revert to whatever set-up I had back then.

* The NES Powerpak has firmware which can be upgraded
* My ROMs are unchanged (it is not a ROM issue)
* My NES is the same as before, unchanged

The mapper for Huang Di is Mapper 112.

In the Powerpak folder this is the file MAP70 . MAP since the file names convert the mapper number to hexadecimal (112 = 70).

Can someone, anyone, explain any of this? At one point it absolutely worked, and now it doesn't, and unless my cart came with mapper sets earlier than 1.00, none of this makes any sense.

QUESTIONS:
1) Is this a firmware issue? Have I borked my cartridge by upgrading the firmware to 1.11? Can you downgrade the Powerpak firmware? I found the old 1.00 firmware but I fear I might destroy the cartridge downgrading it.

2) Can anyone confirm if an EverDrive N8 Pro runs the game correctly? Might be time to upgrade.

3) If you have a Powerpak, does yours run Huang Di correctly? If so can you please tell me which mapper sets you are using so I can replicate it?

4) Does anyone have any idea which Powerpak files are responsible for this change? I have been replacing the entire Powerpak mapper folder each time, since there are some files like B . MAP and I . MAP and Q . MAP, which I assumed were needed for the cartridge to function? If anyone has any experience with the Powerpak, do I need to replace everything each time I try a new set, or can I just drop a different MAP70 . MAP file in the folder?

5) Does anyone have any idea why or how this is happening? Emulators flat out cannot run it correctly. The original cartridge on Famicom works fine. The ROM on a flashcart used to work, but only with a very specific mapper version. Is the cause of the change in behaviour going to be mapper 112 (ie: MAP70 . MAP) or could there be other causes? Dirty connectors? Different memory card in the cart?

I'm also just really curious as to why the jumping glitch even happens. Can anyone give a technical explanation on the cause?

If anyone wants more information please ask.

Huang Di is one of the absolute best unlicensed games on the NES, and the mystery surrounding this is maddening. I wish I had never updated my mappers folder or firmware, because for a brief time it worked and now I can't go back!

EDIT:
This post apparently explains a bit more:
viewtopic.php?p=178159#p178159

"Huang Di, which expects $100 to be non-zero or else it believes it has debug cheats enabled, giving you moon jump and other great but likely unwanted things"

So in theory one could fix this with a Game Genie code, to force $100 to have a value of 1. Thing is, i don't know what $100 means in hex. Is it literally 0000:FF ?

[creaothceann]

i don't know what $100 means in hex

"$100", "0x100" and "100h" are the exact same thing, they indicate a hexadecimal number, in this case 256.

[Dwedit]

This has nothing to do with Mappers at all, and entirely to do with uninitialized memory.

The game never writes anything to location 0x0100, but is reading that byte back. The value could literally be anything, because initial values of uninitialized 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. So the game is buggy, and you might find a console somewhere where RAM 0x0100 started out as zero on a particular boot-up, and you'll get the jumping glitch on that console.

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 RAM 0x100 as 00. 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.

As for flash cartridges, an earlier version 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.
At no point are mapper files involved at all.

So what code do you change to resolve this?

Code: Select all

>07:D35E: A9 00     LDA #$00
 07:D360: 8D 00 20  STA PPU_CTRL = #$00
 07:D363: 8D 01 20  STA PPU_MASK = #$00

This is redundant code that turns off PPU Rendering and NMIs a second time. This was already done earlier, so the code is unnecessary here. Also the code immediately after this does not depend on the value of A.
So we can change the code to do something else.

Let's change "LDA #$00" to "LDA #$01", then change "STA PPU_MASK" into "STA $0100". This leaves behind a write 01 to PPU_CTRL, but it's okay here, because the game will be changing it again long before it's actually needed.

The sequence of bytes appears in the .NES file at 1D36E (grab your hex editor): "A9 00 8D 00 20 8D 01 20", then you change it to "A9 01 8D 00 20 8D 00 01".
Or if you prefer Game Genie Codes: PASSYLAA + AAVIGLPA + PAVIILAZ

[NewRisingSun]

Apply this IPS patch to the Huang Di ROM file. It will initialize address $0100 so that cheat mode is disabled.

[Dwedit]

The IPS patch does something different than my post, it intercepts the reset vector, and makes three instructions run before the game boots, writing FF to RAM 0x0100. Should work fine as well. Just too many bytes changed to fit within three game genie codes.

[RetroProf]

WOW!

Thank you all for the replies!

I can't believe this, 11 years after discovering the game, and mistakenly thinking it was an emulator timing issue, and then a mapper issue, I now have a thorough understanding of a simple problem, plus at least three solutions to it!

Thank you, sincerely thank you to everyone.

However, now comes an interesting situation. I made an IPS patch earlier based on the directions for hex editing. Actually I made two, the other one based on different directions on another forum:

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

This is different to Dwedit's instructions, so I have two IPS patches now.

My plan was to submit the IPS patches to RHDN and credit the people who did the heavy lifting - such as Dwedit from this forum.

I've not tested NewRisingSun's IPS patch yet. I was busy earlier but planned to return here this evening to post an update, and that's when I saw it.

I will however test it tomorrow. From what I understand, it functions differently to Dwedit's code and the code from another forum. So three IPS patches?

Dwedit - may I have permission to submit your work to the Romhacking database, credited to you?

NewRisingSun - do you want me to include your patch? Or do you want to submit to it yourself? A lot of submissions contain multiple IPS patches for a single game, so I might just try submitting all of them, credited to each person, if you're cool with that.

Ultimately, my only desire here is that more people get to experience this game as it was designed, and thanks to everyone's help, that's now possible, and very easily too!

Those Game genie codes are great as well.

[NewRisingSun]

I am boycotting romhacking.net, so please don't submit mine. Dwedit's patch is more than an adequate substitute.

[RetroProf]

I am boycotting romhacking.net, so please don't submit mine. Dwedit's patch is more than an adequate substitute.

Duly noted - I respect your decision. Thanks for the quick reply.

Out of curiosity, may I ask why?

I like the site for being a central hub, but am not a regular poster. Feel free to message privately if you prefer.

[Dwedit]

I haven't exhaustively proven that function 07:D35E is only called once, but it looks like it is. I only see one reference to that address, and don't see the game trying to execute it more than once. So it should be fine.

Feel free to use my post for submitting a patch.

[TakuikaNinja]

This should probably be documented on the game bugs article in the wiki.

[RetroProf]

Indeed! Fill the Wikis!

Anyway, just uploaded this to RHDN.

Both Dwedit and Cyn credited for their work. Many thanks again!

[RetroProf]

It's up!

https://www.romhacking.net/hacks/7792/

I gave my name as the releaser, and Dwedit and Cyn as hackers, but Dwedit ended up as the front-person.

I personally don't care - the point is, AT LAST! THE GAME CAN BE PLAYED RIGHT!

Let me know if you feel there are mistakes in the Readme.

[aquasnake]

This is not related to hardware, nor to mapper coding. It is related to the initialization iram of the loader. It expects to initialize all 1($FF) at some specific address(es), such as $100 on Huang Di

However, neither emulator nor flash cart can fully emulate the actual iRAM power-up pattern (I believe that the values of this memory after power-up are not random, but a pattern table related to address bits). Initializing to all 0 or all 1 does not cover all games