+  RHDN Forum Archive
|-+  Romhacking
| |-+  ROM Hacking Discussion
| | |-+  Finding song pointers (NES)
Pages: [1]
Author Topic: Finding song pointers (NES)  (Read 2 times)
PolishedTurd
Guest
« on: March 14, 2009, 01:10:21 pm »
What is the best approach for finding the pointers to the background music in a NES game? All I want to do at this point is make the music for level 3 play for level 1, level 2 for level 5, etc. Sound effect swapping might be fun too, but I'd be happy to get the music going at this point.

I've found where each of the tracks is being updated as the song plays. It is fun to watch the values change in hex in perfect synch with the music, or corrupt some values and throw the drums out of synch or break the bassline. But I can't figure out how to find what address holds the pointer to those tracks, or what subroutine changes the song pointer. I've been as clever as I can be. At this point, I need some help with my ROM sleuthing skills, or maybe just some supplemental background knowledge about NES ROMs.

Does someone know offhand what range of addresses to watch? I could probably also use more guidance with the trace logger and debugger (what is symbolic debugging and how/when should I use it?). The game I'm working on is Ninja Gaiden.


I'm new to ROM hacking but not new to programming. So far, using just the documents on this site, I've swapped some colors, changed bad guy health, altered the "pause" subroutine to load an item in your inventory, edited some text, etc. So kudos all around, but especially to the NES people here.  Smiley I've been using FCEUXD SP 1.07 (a fantastic piece of work) and have at least some working knowledge of all of its Tools except the name table viewer. I've looked up as much as I can find here about music, but much of it is game-specific and does not describe the process of discovery.

Thanks for your help.
Sliver X
Guest
« Reply #1 on: March 14, 2009, 01:38:42 pm »
How I Did It

You can use assembly to trace such things, but with FCEUXD it's typically fastest to use the Code Data Logger:



I loaded Ninja Gaiden, started the logger and let the intro play (Since it starts a song, and the title screen is silent). Then I started the game, and as soon as stage 1 loaded I paused it. This will have caused reads to at least three pointers (Intro Song, Stage Start Song, Stage 1's Song), so now that we've logged that it's time to open the game in the hex editor edit - Change the hex editor from RAM to ROM. Blue means data, Gold is code and Green means bytes are used as both. We're looking for blue, and probably three or so 2-byte pointers:



This looks like a good candidate. To test it, I'll copy a pair and paste it over another.



Remember, you can always undo by using CTRL-Z (And FCEUXD has a BIG undo buffer). So now I reset the game, and see if the intro song, stage start song or Stage 1's song are changed.

Sure enough, when the intro loads, it plays the stage start song. This is our song index. It seems to start at C78F and end at C820. I determined this by copy/pasting other pointers into the Intro's and seeing if a song played.

Music data itself seems to follow, possibly starting at C83B.

This is a good way to track down such things quickly for the NES. It took me 10 times as long to type this post up as it did to do the actual hacking.  Wink
« Last Edit: March 14, 2009, 01:48:30 pm by Sliver X »
PolishedTurd
Guest
« Reply #2 on: March 15, 2009, 08:19:12 am »
Ah, thank you very much. I have now mapped all the sound effects and music for the game, and swapped the songs I wanted to.

It remains a bit of a mystery why you suspected the area around C790 as the culprit, even before you started corrupting. Is there any way to make the hex editor update its color coding in real time as the code/data logger runs? It would help me to see what ROM data is being accessed or executed among all the other hex, at the same time as it is being identified as data or code. I tried closing the hex editor before a new song was loaded, then immediately reopening it after the song was loaded, but that's too hacky to be practical.

This saved me several (more) hours of frustration. Thanks again.
Sliver X
Guest
« Reply #3 on: March 15, 2009, 07:45:22 pm »
Quote
It remains a bit of a mystery why you suspected the area around C790 as the culprit, even before you started corrupting.

Simply because I saw three byte pairs near each other, and this was what I was initially looking for.

 'Twas a lucky first time guess. When you work with hex a lot, you start to get the feel for things like this: It's hard to explain.

Quote
Is there any way to make the hex editor update its color coding in real time as the code/data logger runs?

Unfortunately, no.
Pages: [1]  


Powered by SMF 1.1.4 | SMF © 2006-2007, Simple Machines LLC