You'd need to know ASM and find a routine that writes to VRAM. Use a tracing emulator and trace when the address of the data you need is changed.
NES games write the 2-byte VRAM address to $2006 (first the high byte, then the low byte) and then write data to $2007.

If you're looking to manipulate what the pattern tables are loaded for mega man, the data is stored for each level individually.  There's a table for Fireman's stage at $3C10 (you can add $4000 to get the other stages).  From my editor source, here's a rough guide to the data:

  Format is as follows:

  Byte #00 - Number of Entries

  Entries are three bytes in size.

  Entry Byte #00 - Memory Address (Multiply by 1000)
  Entry Byte #01 - Number of PPU Rows
  Entry Byte #02 - Bank ?

Does the update need to happen instantly? Would a slight pause still work? If it's something you can switch back and forth to, maybe you could put the megaman sprite in "transition" mode (like when you pause and unpause the game), until the graphics are updated - then transition back into the standing frame, etc.

That many tiles is definately too much.  Way too much to accomplish in one VBlank.  The NES just isn't fast enough.

You'll notice, however, that many of those tiles are identical.  You could get away with trimming that (for example...that whole last row is the same for both except for the last tile).  That way rather than trying to update one huge block, you'd be updating several smaller blocks (which could be done a bit faster if it removes enough tiles).


I don't think anything super-fancy is required to make this work.  Since the game is already set up so that you have to go in and out of the pause menu to change graphics, the game is already paused when you need to make the swap.  All you'll have to do is stop the pause menu from exiting for a few frames (maybe 8 or so -- enough to get the drawing done... but the end user would hardly notice a 8-frame pause at all.. I mean that's only like 0.13 seconds)

I would probably approach this with the following:

1)  Find the code that triggers when the user exits the pause menu (preferably the code before the weapon select window is erased).  This code probably sets some flag in RAM that gets checked in the game's NMI code.  When the game sees that the flag is set, it will start erasing the weapon select screen in VBlank (it won't start erasing it in the routine you're looking for, simply because this routine probably won't be run in VBlank, where all drawing needs to be done).  Your first edit would be to stop the game from setting this paticular flag, and have it set your own custom flag instead.

2)  In the NMI routine (which is called at the start of every VBlank), check for your custom flag being set.  If it's set start replacing a small chunk of tiles at a time.  You have $800 bytes there (less if you trim duplicates).  Maybe copy over $100 bytes a frame.  You can do this by having a counter increment every NMI and copying a different chunk based on the value of said counter.

3)  After you've copied over all of it, set the game's normal flag to erase the weapon screen.  If all goes according to plan, the new graphics will be swapped in, and the game's original code will kick in, erase the weapon screen, and the program will continue as normal.


If $100 bytes is too much to get done in VBlank (I think it'll be fine... but you never know), you can reduce the number... but you'll have to pause for more frames.  The way you can tell if it's too much is there will be on-screen graphics corruption and/or the scroll will get all screwed up.