nesdev.org

Hello everyone folks

Are a couple of months that i'm working on a hack on Nes [just graphics, sound, colors and a little gameplay but figuring out stuff seeing ram and then appling it to the hex in rom file]. Never used Assembly. Deassembled something and stuff..
Now i'm trying to learn something to get a little further..

Btw,

I was making this hack of Section-z where a boy goes in the space fighting 420 related stuff.
Now i would like that the background tiles palette have this effect

This effects is taken by The Little Mermaid[which uses mapper 2] and section-z use that mapper too.

What ways should i try?
Thank you..

Since you really only need to update 3 PPU addresses, and during V-Blank, you should add to the NMI routine...and have a way to count frames to decide how to index the color array. The game probably already counts frames, look at the RAM and find something that always goes up every frame.

The usual way to patch in some code (without disassembling/reassembling)...is to find some empty space in the ROM, and jsr there, where your new code is and whatever you overwrote with 'jsr address' and then an rts to return.

Should be easy if you know 6502 ASM.

This is a simple palette cycling effect, which is completely unrelated to the mapper. Any game can do this, no matter the mapper.

There's no "standard" way of doing this though... Each game has its own way of handling palettes, so you have to analyze the game you're modifying in order to find out what the best time and place to manipulate the palette is.

It's possible that the game has a copy of the palette in RAM, so it may be possible to rotate it in place with a couple of LDA and STA instructions. The game might also be copying palettes directly from ROM to VRAM, in which case you might either have to store all possible rotations in the ROM or patch the code to work differently. You also have to find if it's possible to trigger a palette update (send the palette bytes to VRAM) or if you'll have to write your own code for this.

Be careful if you have to do your own custom VRAM transfers during vblank, because you might run out of vblank time, which will cause glitches in accurate emulators and the real hardware. If you can use the game's own video update system, that'll be safer.

Should be easy if you know 6502 ASM.

I don't.

I'm trying to learn it in these days, as hard as i can.

dougeff wrote:
The usual way to patch in some code (without disassembling/reassembling)...is to find some empty space in the ROM, and jsr there, where your new code is and whatever you overwrote with 'jsr address' and then an rts to return.

Should be this, right? What should i do now?

This [address 1CB12] should be the related code for the v-blank. In fact if i screw up with that my background changes.

Now as i've assumed i've to write a code that addresses to this address in some blank space into the rom that tells that during vblank that palette should ''cycle''. Right?

Sorry for not being proficient, but this, in fact, is the newbie section. Cheers

I haven't looked at the game code, but a quick glance at the opcodes just before 1cb10...makes me think this is a generic ppu update routine, which is maybe called every frame...loading data from...it looks like $0302,x
And the 88 D0 F6 60, (just after it) makes me think this is a loop that uses Y to count.
88 = DEY
D0 F6 = branch != backwards
60 = RTS, end of subroutine

It looks like you can load the ppu buffer @ 302, and if this really does what I said, it might automatically send the info to the PPU.

I wouldn't patch here.

I would put the JSR to the patch here...
It's the last subroutine during v-blank before the game sets the scroll.
That's offset...0x1c4a0.

Overwrite a new JSR address over this one. And at the end of your subroutine, just add another JSR to the one you replaced. [on second thought, just JMP to that address ($c519) at the end of yours...when that sub-routine terminates, it will return back to the original jsr line +1]

There's plenty of blank space in this bank for putting your patch code. The spot you showed would work fine.

Also, note. RAM addresses 0x47 and 0x48 seem to go up every frame. It might be used to count frames between color changes...since you wouldn't want to change it EVERY frame...maybe every 8 frames (I'm guessing).

lda $47
and #$07
bne somewhere else...skip the code 7 out of 8 frames
code here, do 1 out of 8 frames.