I'd like to add some new functionality to Ninja Gaiden (NES). I've searched the documents section and this forum. I have read Disch's document on memory mapping, which I presume I'll need to do, but I haven't found anything regarding a basic insertion of new code.

The 'Select' button is often unused in normal NES gameplay. Let's say I want to make it so that when you push select, your jump height is doubled on your next jump. After that jump, the jump height is reset to normal. I suspect I need to add instructions for the following:

• 'Listen' for the select key, which is currently not used for anything
• Set a byte in memory that indicates whether select key has been pressed since last player jump
• Inside the player jumping subroutine, check the status of the 'select key pressed' byte, and set the jump height accordingly. Then clear the 'select key pressed' byte.
  

So, I need to find space in the ROM to add these new instructions, add pointers (JMP or JSR) to the new space I am using, and make sure they either exist on a page currently in memory, or that I load the page they are on before trying to access them. Can someone point me to some documents to help me, or provide an example? It could be something simple like adding 100 points to the score when select is pressed. If it helps at all, the jump height in Ninja Gaiden is at 0x01EBA4 and is 37 by default. The score is in $0060.

Another thing that may help is that I already need to obliterate the stuff that happens when pausing and unpausing, in this and probably subsequent ROMs that I hack. So that gives me some space to use that is always available during regular gameplay, although I admit it is not pretty.

I'd also like some help on listening for more complex button combinations, such as simultaneous keypresses (select + start gives you a powerup) or button sequences where there is a limited time to execute the sequence (e.g., A-B-B-A pressed during 1 second adds a life). How can I find the main subroutine that is constantly checking for buttons? Is there a usual location for it? I see a few values in the CPU being set to precise values while I press buttons, but putting read breakpoints on them leads to a constant series of rapid snaps at different locations.



Thanks.

How about Up and Jump to make a higher jump?  I know the select button is unused, but since Up is also not used while walking except for subweapons, it would fit perfectly into the controls.  I don't know anything about the Ninja Gaiden rom, but I did do somthing a little while back in Megaman 4 where I made it so you can press up and B to shoot a fully charged mega buster shot.  What I do is I find where the jump routine is called, then I add a JSR to free space.  You will overwrite bytes, so you need to include them after at some point. Basically what you want to do is first make a check to see if the Up button is held.  If it's true, keep going.  If it's false, regular jump value is used.  Then you re-define the new jump value after A is pressed.  Of course this is assuming you know how the jump mechanics work.  Some games have different ways of coding jumps than others.  Doing a Select powerup requires at least one free byte in ram.  Basically, you need to insert this routine somewhere where it will read button commands.  It obviously must be somewhere within the main program for the Ryu sprite.  You define that the select button has been pressed, and if it has, then a check is made to see if the ram slot is empty or not.  If it's not, then it moves on.  If so, do an INC for either Zero Page or Absolute(depends on where the byte is).  Now, in the jump call routine, it can check for that one address and branch off as desired.  If the value is detected, then load the new jump value.  When the actual jump button is pressed, that value is always erased.  The only stipulation is that there has to be some space left in the main PRG bank, or know what bank is also loaded while you are jumping.

It's the last bank that's fixed, right? Anyways, I overwrote the FFs at 0x1ff20 with no apparent ill effects. I'd say the end of the bank is your best bet for unused memory.

That's why I pointed out data between 0x1C000 and 0x1FFFF, this is the last (i.e. presumably fixed) PRG bank.

Hmmm... When I insert my code at 0x01FF20, it causes a freeze immediately after returning from execution. Looking at the registers, stack and processor status flags, everything is the same as when my subroutine is called as when it is bypassed. Somehow I'm violating something important and killing the game (graphics get scrambled, music freezes on current sound, I can still move my garbled sprite, but it's slow and there are no enemies, etc.). Comparing stack traces of the clean and hacked ROM, the clean ROM appears to do a bunch of "redundant" writes just before the point where the game crashes in the hacked ROM, which seems strange to me. Why would it do this after reading that Select was pressed, when the Select button is 100% unused in the game?
Clean ROM executes this set of writes at the point shortly before the hacked ROM crashes, whereas the hacked ROM does not:

Looking at Disch's document about Mapper 1, I'm seeing the same thing, but I don't understand why the redundant writes are necessary...

Anyway, it may be that my subroutine is writing to memory values it really shouldn't be, or maybe preventing a bank switch that needs to happen. I was not rigorous enough to make sure I tested under exactly the same conditions between the clean and hacked ROMs, so the bank switch might even be irrelevant. I'll try a more precise test, and I'll try rewriting my subroutine if necessary.

Those five writes in a row are for MMC1 bank-switching. The bank number is specified by writing it to a certain address (or range of addresses). With MMC1 the bank number is transmitted serially, i.e. one bit at a time. There are five bits. Each write to $FFFF (actually $E000-$FFFF) sends the lowest bit of the value "stored" to the MMC controller.

So the simplest way to do it is store the bank number in the accumulator, and write five times to the same address, with a bit shift (LSR) between each write to cycle through the bits.

It seems so simple...

Here is where I insert my jump to subroutine for checking the select key:

Here's my subroutine. It is intended to function this way: Push select once, and the player gets the shuriken powerup (throwing star). Press select again and the player gets the windmill star powerup. Press select again and the player gets the fireball powerup. Press select again, and the cycle starts over with the shuriken powerup, and so on.

$C9 is the address that holds the powerup value. #81 = shuriken, #82 = windmill and #80 = fireball.

$FF10 (0x01FF20) is where I store a counter variable to watch how many times Select is pushed.
The subroutine:

This code executes as expected and returns without any apparent problems, but a few hundred lines after it executes, the game freezes as described above.

If you really want to have a crack at it, try the patch here. Push select at any time and see for yourself. To see what should ideally happen, whack the first lantern on the building and pick up the shuriken powerup.

You can also use $6000-7FFF (cart RAM), but it's probably better to only use those if the game is already using it.