Thanks in advance,
- 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.
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
Code: Select all
lda #$03 sta $037e ; Execution paused here
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.
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.
$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.
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?
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.
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.dougeff wrote:Palettes are usually stored as a 16 or 32 byte string, that is copied at the start of the level to the PPU.
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.tokumaru wrote: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.
Example: Super Mario Bros. stores its palettes as VRAM update strings, including the 4th bytes.