NES Game Genie patch issue

[Fuego]

So, I haven't been able to figure this out. I am using Mega Man 1 for the NES and the Game Genie code TAOOYTGA which gives Megaman super high jumps. This works when I put in the code in Nestopia, but I was trying to permanently mod the rom so that I wouldn't have to rely on an emulator's ability to do that. I tried using ucon64 and it seemed to patch the rom, but I still didn't get the high jumps. When I decode the GG code, it says it modifies the hex address at 0x961F to 06. Ucon64 shows this, but when I do the patch it gives me something that says 0x962F. I have also tried patching with the invicibility code (AVVXLPSZ), and it works in Nestopia, but without using Nestopia's GG ability, it almost seems to make Megaman take 2 or 3 times more damage than normal. Am I missing something? Would it be better to just use a hex editor and edit the value directly instead of using ucon64? Is there another patch program that would be better? Sorry for all the questions and thanks for the help!

[Hybrid]

high jump is located at 01562F

invincibility is located at 0161FB

if you were to use a hex editor

[Fuego]

okay, this will probably sound dumb, but how did you come up with that? I am assuming you used some sort of GG decode program. Which one? Thanks again.

[Hybrid]

yeah its called FCEUXDSP :P the best nes emulator out there

[adaml]

Hybrid, do you know what the best emulator is for hacking Sega Master System codes?

Sorry for the off-topic post, but I've been wanting to hack games for the SMS for awhile and have been out of touch since my MEKA playing days.

[ugetab]

Continuing research may be found here:
http://www.gshi.org/wiki/Assembly_Hacking#Master_System

Emukon. It's not as pretty as other debugging emulators, but if you have the skills to get the affected RAM addresses, and the patience to pour through log files, you can use it. I know it's usable, because I used it to hack some Game Gear Game Genie codes. If SMS works the same to any degree, expect a few hassles with learning and logging, but nothing too severe for a decently skilled RAM hacker.

I just noticed that you're probably limited to RAM cheats for SMS.

As far as the actual RAM hacking goes, I just mess around with save states. I can't really give you anything more useful than that, since I always do things like this my own way.

[adaml]

Thanks Ugetab, I'll look into that.

You are right about me being limited to RAM cheats...I am still in rom hacking kindergarten

[Fuego]

Okay, I think I understand how Hybrid got those addresses that were posted, besides using FCEUXDSP. Let me know what you all think and let me know if my logic/understanding is off.

First off, you have two types of GG codes, those with 6 digits and those with 8 digits. Second, there is something called memory mapping. And third, there is decoding what the GG code is saying.

Let's start off with the GG decode. Take my example for Mega Man 1 for the NES. TAOOYTGA Decoded you get 0x161F followed by 0x06 and followed by 0x04. The first four digits are the hex address for the GG code inside the ROM. This is NOT the hex address that will be changed inside the ROM. The second is the value you are changing to at the desired ROM hex address (yet to be determined). The third is the compare value, the value that is currently at the ROM hex address you want (yet to be determined).

Back to memory mapping. I am not an expert, but basically, it refers to the type of processing the game uses. For basic/earlier games, they don't use memory mapping. The first 8 kb of data is the RAM (working memory) and the next 8 kb are for the ROM (asm code). For later games, the code was bigger than 8 kb. So, they put just part of the ROM into RAM. Now, this is a jump, but I think the 6 digit codes are primarily for non-memory mapped games and the 8 digit codes are for the memory mapped games. Why? Because of the second value from the decoded GG code called the compare value. It is because there are multiple chunks of code that can be put into RAM and you need to find the right one.

Back to my code. The first thing to convert the GG hex address into a ROM hex address is to add 0x10 to compensate for the ROM header. This makes it 0x161F + 0x10 = 0x162F. Then, you add 0x8000 to get the address into the ROM area of the ROM (game) file. That gives you 0x162F + 0x8000 = 0x962F. Check the value at that address to see if it matches the compare value (0x04 in this case, the third value decoded). This will normally match for a non-memory mapped game (assumption, not sure yet). If it doesn't match, add 0x2000 to what you have and compare that value. Rinse and repeat until you have a match. In this case, you do this until you find 01562F (thanks to Hybrid and FCEUXDSP).

The problem I was running into understanding was the ucon64 just added 0x8010 (0x8000 + 0x10 for ROM header) and left it at that. It didn't take into account the compare value that is required for memory mapped games, something in which FCEUXDSP does.

Anyways, that is my understanding of how all that works. I really want to understand how this works and I think I do, but please fill in any gaps and correct any false statements. Again, thanks for your help and feedback!

[Whipon]

Estimated Fuego:
Download FCEUX.
Go to Debug => Game Genie Decoder/Encoder...
Under Game Genie Code enter your GG code.
Under the box "Possible Affected Rom File Addresses" you'll see the possible addresses. Usually it only shows only one. This works better with 8 letters GG codes.
Then use a hex editor to edit the rom.
Thats all.

[ugetab]

Actually, even that's basically a crap shoot, because there's no guarantee that the file addresses shown will actually be banked to a position the code can affect. Generally, I find the address, and set execution/read breaks on the data, and when it hits a point that the code is executing code where the suspect byte fits the compare, then I search for a unique set of bytes in the file that identify only locations where that change may fit. Included in my view is whether the last 3 digits of the code match the last 3 digits of the file address(-0x10 to adjust for header) match one-another.

This is the only truly effective way I know to implement Game Genie codes into a ROM file, without inadvertently changing code you don't want changed. Also note that there are sometimes cases where a particular grouping of assembly code is duplicated across more than 1 bank in the same relative position as the other assembly code is at when loaded, and multiple byte changes will be in your best interest in these cases.

[Whipon]

Actually, even that's basically a crap shoot, because there's no guarantee that the file addresses shown will actually be banked to a position the code can affect. Generally, I find the address, and set execution/read breaks on the data, and when it hits a point that the code is executing code where the suspect byte fits the compare, then I search for a unique set of bytes in the file that identify only locations where that change may fit. Included in my view is whether the last 3 digits of the code match the last 3 digits of the file address(-0x10 to adjust for header) match one-another.

This is the only truly effective way I know to implement Game Genie codes into a ROM file, without inadvertently changing code you don't want changed. Also note that there are sometimes cases where a particular grouping of assembly code is duplicated across more than 1 bank in the same relative position as the other assembly code is at when loaded, and multiple byte changes will be in your best interest in these cases.

The method I described works perfectly. Its the method I use everytime to hack my codes directly to the rom. And its easier than the method you described. Try it and you'll see how much time it saves you. In the remote case you get more than one result, you just have to use trial an error until you find the correct one. You just have to alter one byte, so its not a big deal.

[ugetab]

Trial and error works well enough too.

It's just that it's a good idea to not leave in unaffected bytes, and the inexactness of the recoding can have undesirable effects on code execution. I've even seen official GG codes with unreported errors, so I play it safer than necessary in most cases.

[Fuego]

Well, I was doing a couple more codes today and I came across one that had three possibilities. I did the trial and error method like Whipon suggested and it worked out well. I think what you do ugetab, is a level or two higher than just changing a couple of bytes, which is what I do. Your's sounds a lot safer, but a lot more involved, and at least to me, more prone to errors due to ignorance.

In any case, I feel a lot better about doing something like that for nes games. Thanks for the input!