I've been trying to restore the cross on the church in the opening and ending cutscenes of Bomberman II for the NES, but I can't find them anywhere in the ROM data.
Is anyone out there able to help me with this?
I've been trying to restore the cross on the church in the opening and ending cutscenes of Bomberman II for the NES, but I can't find them anywhere in the ROM data.
Is anyone out there able to help me with this?
I cant give any advice for how to do this on the nes but I can tell you what I do when I run into these situations on the snes.
Usually when you cant find the graphics in the rom then the graphics are compressed. What I do is find where the graphics are in vram
and then I will trace the code backwards to see how it got into vram. Once I figure out how it got into vram then Ill be able to read
the asm that is doing the decompression and I document everything about the decompression so I will fully understand the format.
Once the compression format is fully understood then I would write a compressor to compress the edited graphics. Seems like the
process should be similar for the nes.
Now if you are doing something like restoring graphics that were in a Japanese game and taken out in say a north american version
of the same game then all you would need to do is find the compressed graphics data and transfer it from
one rom to the other.
slidelljohn wrote: ↑Mon Oct 14, 2024 3:56 amI cant give any advice for how to do this on the nes but I can tell you what I do when I run into these situations on the snes.
Usually when you cant find the graphics in the rom then the graphics are compressed. What I do is find where the graphics are in vram
and then I will trace the code backwards to see how it got into vram. Once I figure out how it got into vram then Ill be able to read
the asm that is doing the decompression and I document everything about the decompression so I will fully understand the format.
Once the compression format is fully understood then I would write a compressor to compress the edited graphics. Seems like the
process should be similar for the nes.Now if you are doing something like restoring graphics that were in a Japanese game and taken out in say a north american version
of the same game then all you would need to do is find the compressed graphics data and transfer it from
one rom to the other.
The graphics I need are already there, they have been removed from screen but they are still present in the ROM.
Is it the screens layer data that you are looking for?
Do you see the cross on the left? That's what I'm trying to put it back where it originally was. I've got to find where it's stored in the Japanese version first, and see if I can re-insert that graphic in the cutscene.
"but I can't find them anywhere in the ROM data"
"The graphics I need are already there"
"I've got to find where it's stored in the Japanese version first"
You have me very confused and I'm very good at hacking the snes.
It sounds like you might be looking for the data that makes the layers for the screen if the graphics are in the rom.
Do you know how to use a debugger and view the layers/vram/sprites/rom/ram?
slidelljohn wrote: ↑Wed Oct 16, 2024 6:44 amIt sounds like you might be looking for the data that makes the layers for the screen if the graphics are in the rom.
Do you know how to use a debugger and view the layers/vram/sprites/rom/ram?
I often use FCEUX's PPU Viewer option to view sprites in a graphic bank, but that's all I can really do.
Check out the romhacking section for the 7th saga topic that I made and look at pic #3. That is Mesen 2 and I think it also works for the nes.
If you open up fceux's name table viewer while the game's running you can see the layout of the background, the Tile ID's and I believe the ppu address it's being written to. I believe this is called tile attribute data, though I could be wrong on the terminology (I've been reading a lot of technical stuff lately and it's kinda all flowing together in my head at the moment)
If the game's background data is uncompressed (usually the case for games with few backgrounds, like Dr Mario or maybe Donkey Kong) you can just plug some of the Tile IDs together in the hex editor's "Find" option and track down the spot in rom pretty quickly.
If it's compressed (likely the case as I imagine Bomberman has a lot of backgrounds) you'll need to do some debugging.
I still suck at that, but if you look at the japanese version's opening cutscene with the name table viewer going you should be able to move your cursor over the cross graphics, which will show the ppu addresses that they're being written to.
From there you should be able to set a write breakpoint (I think that's the one?) to those addresses and start working your way to where the game's writing the data from. Then it should be as simple as opening the us rom, going to the addresses you find from the other version, and plugging in the values from the japanese version.
Hope this is helpful in some way!
Ok so in fceux, open the jpn version, open up the nametable viewer and hover the top left tile of the cross.
The PPU Address is 0x211c, the tile is 0x60.
Using the debugger, set a breakpoint for 211c, write, ppu mem. Add a condition A==#60.
Reset the game (still need to unpause after the reset too), it will stop when that tile is written to the PPU. Sometimes this is it, you can see right where it stops where it's grabbing data from. This game needs more.
You can see where it stops with the line above here:
Code: Select all
07:C5D3: BD 00 06 LDA $0600,X @ $0689 = #$60
>07:C5D6: 8D 07 20 STA PPU_DATA = #$00
So we see it's getting the tile from 0x689, which is just memory so it's processing it from somewhere else. So we set another breakpoint on 0689, write, CPU mem this time, condition A==#60.
Reset/unpause the game and when it stops we see this:
Code: Select all
07:C6B5: AD B1 04 LDA $04B1 = #$60
07:C6B8: E8 INX
>07:C6B9: 9D 00 06 STA $0600,X @ $0689 = #$30
We see a few lines above that it's getting the tile from 0x4b1, still not the rom.
Set another breakpoint for 04b1, write, CPU mem, condition A==#60
Reset/unpause and when it stops we have this:
Code: Select all
04:B890: B1 24 LDA ($24),Y @ $996B = #$60
>04:B892: 8D B1 04 STA $04B1 = #$00
Now we see it's grabbing that tile from 0x996b. You can put that in the "Seek To" field and it will still be in the correct bank so we can see the rom address. Ignore the asm here, we know it's actually data.
Code: Select all
04:996B: 60 RTS -----------------------------------------
04:996C: 61 62 ADC ($62,X) @ $0000 = #$47
04:996E: 63 UNDEFINED
04:996F: 00 BRK
04:9970: 67 UNDEFINED
04:9971: 00 BRK
04:9972: 6B UNDEFINED
04:9973: 68 PLA
04:9974: 69 6C ADC #$6C
04:9976: 6D 6A 00 ADC $006A = #$00
04:9979: 6E 00 00 ROR $0000 = #$47
04:997C: 70 00 BVS $997E
04:997E: 74 UNDEFINED
04:997F: 71 72 ADC ($72),Y @ $0000 = #$47
04:9981: 75 76 ADC $76,X @ $007A = #$00
04:9983: 73 UNDEFINED
04:9984: 00 BRK
Hovering the first line we see the rom offset is 0x1197b. That's the file offset where the top left part of the cross is.
You can do this for the USA rom now with the top of the church and find the area close to where it would be. I can tell you they didn't just blank out the cross, it's removed, so you have to figure it out and find some space, but this should help.
EDIT: code tags