nesdev.com

Gents Im a coding noob so please bear with me. Im trying to permanently change the hex code that controls the number of continues you are given after death in a NES game (Im trying to make the game more difficult with no continues) through FCEUX. I know my address and the proper value to change, but I am unable to save said change once the emulator shuts off. Would I break the PPU and bypass the continue screen entirely? And how can I save those changes to a .rom file? What would my best options be and how would I go about doing so?

Thanks in advance,
Jason

Just to help us understand your problem: Is the address you have found a RAM address ($0000-$07FF or $6000-$7FFF) or a ROM address ($8000 or higher)?

• If it is a RAM address, the problem is that the program is overwriting it every time a game starts. Find the ROM address that initializes it.
• If it is a ROM address, the problem is that you have modified a copy of the ROM file loaded into the emulator but haven't written the modified ROM file back to disk under a new name so that you can prepare an IPS.

the address is 037E : 01 : --
RAM issue. I can get this to function as a cheat or if I freeze it (same thing). But Id really like this (no continues) to become a permanent part of the .rom file

Set a write breakpoint on $037E to see if you can find the piece of code in ROM that initially sets the continue count. Once the debugger stops, the piece of code will probably look a little like this:



Change that $03 to a $01, and you have a ROM cheat that you can use instead of the RAM cheat.

Just to clarify, the PPU probably has nothing to do with this. It's generally only used to display things.

_________________
http://nesrocks.com/blog/superpitfall30th/

Still having trouble finding the right 037E to edit. 05 is the number of continues. When i set it to 01, which is what I want, it behaves like a cheat that doesnt overwrite the .rom. I know this is a lot of trial and error so thanks for your support!

You're changing RAM, and RAM is volatile. Once the console is turned off, *poof* everything in RAM is gone. You have to look in the ROM, where the game program is, searching for the code that initializes that RAM location and change THAT, so that the variable is consistently initialized to the value you want every time.

This is why you need breakpoints. A breakpoint on wires to an address will pause the emulation every time the program tries to write to that address, and then you can look at the disassembly and see the code that's initializing/modifying the variable, and that coffee is what you have to change to make the modification permanent.

Well, it looks like you've set a breakpoint for 37E.

Now, reset the game, and play it till it writes to 37E. When it breaks, right click on the debugger in the gray blank area to the left of the disassembly, to the line just before the write to 37E. It should open the hex editor in view=ROM, to the exact location you want.

That's what you edit. Then in the hex editor, save ROM as...new file.

_________________
nesdoug.com -- blog/tutorial on programming for the NES

Im almost there. Only now Im kind of stuck on what hex value to edit!

I'm going to guess you got this breakpoint just after using a continue. Now you have found a line that says "decrease address $37E by 1". You know this address is the number of continues, so if you want infinite continues you replace that instruction with something meaningless. For example: "EAEAEA". Write EA EA EA on ROM bytes located at 0x1C54B, 0x1C54C and 0x1C54D, replacing previous bytes CE 7E 03. And just to make sure, you also have to replace the following two bytes with "EA EA" because once you get "#FF" continues and gain an extra one in gameplay (if it is possible), you'll loop the number to #00 continues and this BEQ will branch to gameover.

$EA is a "NOP" instruction. It does nothing, but costs 2 cycles to execute. It is no problem to use it in this case, you're going to use 6 cycles in total which will not make a difference.
The reason you need to replace the bytes instead of deleting them is that the ROM code is address dependant, and removing the bytes would shift all addresses in the ROM from that point forward.

If you do not want infinite continues and want to change the amount of continues a player is given, you need to keep the breakpoint and reset the game and start a new game. It will probably break right during reset because that address is being filled with "00" just like many other addresses upon initialization by the game's code (many games do this). No problem, hit "run". The moment you find a line that says "STA $37E" and "A" has a value different than zero, that is probably the line that sets the starting amount of continues. Then you go a few lines up and see which line stores that value to A in the first place. Then you edit that single byte containing that value. This moment will probably happen once you start a new game.

_________________
http://nesrocks.com/blog/superpitfall30th/

Thanks you guys rock! I figured it out! that did it had to set it at the start of the game rather than the actual continue point!

Now about that PPU edit lol. So there are 2 points it the game the beginning and end which have an animated graphic. how would I go about changing the color of the sprites when I cant edit them manually through the hex ROM?

Actually, changing palette colors is one of the easiest things to change.

Palettes are usually stored as a 16 or 32 byte string, that is copied at the start of the level to the PPU.

Open the PPU viewer, write down the hex values of the colors at the bottom. Now search the ROM for that exact sequence of hex values. Edit it. Save.

Alternatively, you could open the hex editor to view=PPU, and scroll down to 3f10-3f1f for the Sprite palette (then search the ROM for those numbers).

Edit, I've seen at least 1 game that used "out of range" (higher than $3f) values to write to the palette. The PPU viewer (I think) will only show the 0-3f value, making it hard to find in the ROM. The game will disregard the upper 2 bits.

_________________
nesdoug.com -- blog/tutorial on programming for the NES

Really? I know many homebrew games do it that way because most tutorials do it, but I'm not so sure about games from back in the day.

Strings of 16 or 32 bytes of palette data, as commonly found in homebrew games/demos, contain values that end up not being displayed due to mirroring and/or transparency (the PPU will only use 25 colors out of 32), so it'd be a bit wasteful to store palettes that way. Not to mention that lots of games mix and match sub-palettes depending on what's on the screen, and in this case it makes even less sense to store the whole thing as single block.

I haven't hacked many games, but in the few I did (e.g. SMB), it was easy to search for sub-palettes in groups of 3 colors. With strings this short, there might be some false positives, so be careful if multiple instances of the same 3-byte sequence are found, as most likely only one of them is the palette data you're looking for.

Yes, I've seen 4-byte palette data in many old NES games. You can optimize for space as 3-byte palettes, but there's a bunch of reasons that can make the 4th byte convenient or useful to store anyway.

Example: Super Mario Bros. stores its palettes as VRAM update strings, including the 4th bytes.

I've found the proper patterns in the hex rom data and made the corresponding changes that I wanted, but they dont reflect in the intro or end sequence (which are both animated). Ive made other in-game color edits with no issue.