[DANGER X]

Is there anyone who knows how to hack nes music.I want to swap some sounds betwen two roms,Any ideas...

[snarfblam]

With the possible exception of two games that use the same sound engine (presumably, Metroid and Kid Icarus would use the same sound engine since they're based on the same game engine), NES games each have their own unique sound programming. Generally, you can't just copy sounds from one to the other. You would need to dissect the sound engines of both and figure out how they work so you can tell how, if it's possible at all, you can accomplish the same thing in both engines. That means you would probably need a pretty good handle on assembly as well as NES sound hardware.

[FAST6191]

It works much the same as anywhere else in that you figure out the formats and either change the donor file to match the accepting game's format or change the accepting game's code to run the donor's music. Unlike some later systems there is no universal or near universal NES format save for the fact that on the NES, it not being the most powerful system, things tended to be kept close to the underlying hardware. I have not pulled enough apart from the sound perspective to guess properly at it but developers vary when it comes to keeping things at more a more data like level (what you hope for for this) and a more coding/instruction type level.

Another trouble you may face is the hardware can change between games (see discussions of mappers) so you may well end up in the situation of the game you are wishing to transfer from had more music processing capability by virtue of the cart itself having onboard chips to help it ( http://wiki.nesdev.com/w/index.php/VRC6_audio is a nice example). This then leaves you in the extremely unenviable task of changing the mapper and most of the time that is considered the hardest/most tedious thing you can do in NES hacking.

[DANGER X]

Well,i was thinking if i found the music data in hex editor i would be able to change it but i don't know how to find it.Any ideas...

[FAST6191]

Changing music and injecting music from another game are two quite different hacks on the NES. Later consoles are a different matter but they are not the NES.

"if... hex editor"
You can change anything in a hex editor, it is just very annoying for a lot of types of hack, this included.

Finding the music will vary depending upon the game's method of making it. If it is just piping data into the sound chips then so be it, if it is using code to trigger events based on in game actions and has things within the code itself then it can get tricky.
Either way though the name for the technique is the same and that is "tracing". For most things like music and video the consoles will have a set place in memory that handles it, with a debugging emulator you get to watch these points for things that fiddle with the areas and then the emulator will halt and tell you what fiddled with the point in question (this is known as setting a breakpoint). This might not lead directly back to the ROM but work backwards from there (tracing if you will) and you will find the object of your desire.

There are other methods but ROM level music hacking on early consoles will almost certainly require ASM skills so I am not sure teaching you about corruption, elimination, fingerprinting and whatever else will help you that much here. Such techniques are extremely useful on post 16 bit consoles but not so much before them.

[optomon]

A good start would be to open the NSF files in a hex editor. Find the section(s) of code in the rom that matches the code in the NSF in a hex editor, and there's your music/sound for the game.

But from there, yeah, basically what these guys said. Get an emulator with a built in debugger and watch the code in a memory viewer while playing an NSF. Check for pointer values in that appear in the memory viewer, that could usually is a good way to find locations of specific music data in the game.

[Morinis]

A good start would be to open the NSF files in a hex editor. Find the section(s) of code in the rom that matches the code in the NSF in a hex editor, and there's your music/sound for the game.

But from there, yeah, basically what these guys said. Get an emulator with a built in debugger and watch the code in a memory viewer while playing an NSF. Check for pointer values in that appear in the memory viewer, that could usually is a good way to find locations of specific music data in the game.

Please pardon me on 'jumping' into this conversation for I have questions relating to this answer as I too am trying to understand the whole NES music hacking business.


First question.  Say that when an individual finds all of this information and edits that info with the NSF and Hex Editor and wants to put it back in to the desired ROM but finds that the info is either shorter or longer than the original info, how can one shorten or expand that location?  This question just flew out from my mind for I have no clue if that is a factor or not.

Second question.  Now that I am understanding mappers a little more, how can one put new music into different sections into a game like for example Simon's Quest, replacing Bloody Tears in most sections to play something different along with the mansions?  Will the mapper be able to do such a thing or will it need to be entirely reprogrammed into that particular section?



For these questions of mine I am currently working on a Dracula's Curse and Simon's Quest hack (heavily inspired by your old Castlevania II hack) aside from other projects.  I'm a mediocre graphic editor like the next chap but since I lost my partner 2 years ago that knew everything about hex editing AND music editing, I've been trying to pick up everything myself since then to the best I can.  I just found out that this website existed not too long ago so trying to play 'catch-up' on information that I need lol!

[FAST6191]

Please pardon me on 'jumping' into this conversation for I have questions relating to this answer as I too am trying to understand the whole NES music hacking business.


First question.  Say that when an individual finds all of this information and edits that info with the NSF and Hex Editor and wants to put it back in to the desired ROM but finds that the info is either shorter or longer than the original info, how can one shorten or expand that location?  This question just flew out from my mind for I have no clue if that is a factor or not.

Second question.  Now that I am understanding mappers a little more, how can one put new music into different sections into a game like for example Simon's Quest, replacing Bloody Tears in most sections to play something different along with the mansions?  Will the mapper be able to do such a thing or will it need to be entirely reprogrammed into that particular section?



For these questions of mine I am currently working on a Dracula's Curse and Simon's Quest hack (heavily inspired by your old Castlevania II hack) aside from other projects.  I'm a mediocre graphic editor like the next chap but since I lost my partner 2 years ago that knew everything about hex editing AND music editing, I've been trying to pick up everything myself since then to the best I can.  I just found out that this website existed not too long ago so trying to play 'catch-up' on information that I need lol!

An NSF is almost like a cut down ROM image and the player is a cut down emulator. Going back to games is odd but that is not quite what you asked.
Expanding data... varies as much as the format underpinning it.
The game could have a hardcoded value in an instruction or something directly related to it.
The game could reference a value elsewhere in the binary or data itself and load accordingly. Though the other is technically a pointer this is what most people are thinking of when they speak of them.
The game could check every instruction to see if the song has ended or when a section loops a counter is increased and that counter is checked every run through where is might branch/stop otherwise. This is typically in games that have a full audio format to play with (the NES did see things like it but it could also be low level code that causes music as game musicians back then were often programmers of equal skill to the actual programmers).
The game could do something else entirely, typically it is one of the first three with the "check all the time" method being highly discouraged.

Each of those has various quirks when it comes to working with them but if you understand how the one you are using works it is fairly obvious how to make it longer (assuming the storage you have can handle the increased space which is not a given on the NES). Shorter is often far easier to handle (especially if it is cases two and three on the list above), the only thing I will say is make sure all that follows it (effectively you then have blank/wasted space) is where it originally was (if something is 8 bytes shorter I had better not see something that was at 40A hex now at 402 hex).

New music for a section.
Depending upon the game this is less of a music hack and more of an assembly hack or possibly a level hack if you are really lucky.
Typically when you load a new level the game will do something like
Get all sprites for this area and stick them in memory
Get level layout and stick it in memory
Generate first screen for new level and stick it in memory
Call track ? and set it to play.

You can have loading screens, that order is not fixed in the slightest, single screen vs scrolling level vs level that can scroll backwards and more all come into play but that is the basic overview.
You then get to find the "call track ?" and change it to "call track new_hacked_one" instead. This may be easier said than done (if a game only uses a 4 bit value for the audio tracks and already has 16 tracks you either get to nuke a track, rewrite the handler there or do something exotic*) or it may be a trivial single number change (assuming your new track injected OK). There is a reason most audio hacks tend to replace existing tracks though.

*the list of exotic things you can do gets very long and is worthy of a thread of its own and arguably is relevant here but I will largely forgo it as it does not serve much purpose. Still if I want to add a new track could I not put two end to end but at the and of the first one make it loop back around to the start and thus ignore the rest. However I would also do the same with the second and somehow force the starting point in the game to be at the start of the second track.

You can also have incidental music ( http://www.youtube.com/watch?v=9Yw5jkAHgME being one of the more noted examples) and things like sword swings, enemy hits and such like will almost certainly be these but if the game is programmed halfway competently this should not pose a problem.

[Morinis]

My curiosity is satisfied!  Thank you for providing me information once more!

I got a long, tedious process ahead of me...once or when I make the jump to get ready to attempt music hacking LOL!

[DANGER X]

Ok.

[NinjaDude,RomHAXX0r]

I also wonder how to inject NSF files into Mega Man 2 that I made with Famitracker.

[Bisqwit]

I also wonder how to inject NSF files into Mega Man 2 that I made with Famitracker.

You cannot (barring extraordinary effort*). You can, however, rewrite your song to work with the format that the game already uses.

You can find a commented disassembly of Mega Man 2's music engine here: http://bisqwit.iki.fi/jutut/megamansource/mm2music.txt
Here are some relevant bits for you:
The entire music engine encompasses bank 12 of the ROM. Each bank is 0x4000 bytes long, and the .nes file has a 0x10 bytes long header. This means that it begins from ROM file offset 12*0x4000+0x10 which is 0x30010, and ends at offset 0x34010. Any addresses listed in this post starting from the next paragraph will be referring to data inside that section, e.g. address 0x8123 would be 0x30010 + 0x8123 − 0x8000 in the file, which is 0x30133. Address X is ROM file offset 0x30010 + X − 0x8000. The 0x8000 is there because the cartridge maps any ROM data into the 8000-FFFF space rather than 0000-FFFF. You therefore have to subtract the 0x8000 to get the actual data offset.

The list of songs can be found at address 0x8A50. Each song is a word-size pointer to the song data. For example, the pointer for song 2 (Crashman's song) reads as 0x90C8.

Within that address -- 0x90C8 for Crashman -- you will find the song's header. The song's header begins with byte $0F, followed by five pointers. The four first pointers are points to the song's data for each of the four channels. The fifth pointer refers to the list of vibrato controls used for this song.
In case of Crashman, these five pointers read as: 0x90D3, 0x9270, 0x9391, 0x9430, and 0x947F. If any of these pointers reads as 0, then that channel is not used by the song.

Therefore, the song data for channel 0 (first square wave channel) is at 0x90D3; the song data for channel 1 (second square wave channel) is at 0x9270, song data for channel 2 (triangle) is at 0x9391, song data for channel 3 (noise) is at 0x9430, and the vibrato control data is at 0x947F.

The song channel data is a stream of events.
The following commands are defined:

• Two-byte encoding $00 n.  Song speed is set as n frames per tick.
• Two-byte encoding $01 n. Adjusts vibrato parameters by n. Affects all following notes.
• Two-byte encoding $02 n. Selects duty cycle settings. Valid values for n: $00,$40,$80,$C0. Only applicable for squarewave channels.
• Two-byte encoding $03 n. Selects volume and envelope settings. Value n is passed directly to the soundchip; see APU documentation for details. Affects all following notes.
• Two-byte encoding $05 n. Sets note base to n. Value n is added to the note index for any notes (excluding pauses) played on this channel from now.
• One-byte encoding $06.     Dotted note: The next note will be played 50% longer than otherwise, i.e. 3/2 of its stated duration.
• Three-byte encoding $07 n m. Sets volume curve settings. Byte n controls the attack, and byte m controls the decay. Affects all following notes.
• Two-byte encoding $08 n. Select vibrato entry n from the vibrato table referred to by the song header. Affects all following notes
• One-byte encoding $09. Ends the track. Can be omitted if the track ends in an infinite loop instead.
• Four-byte encoding $04 n w. Ends a loop. If n=0, loop is infinite. Otherwise the marked section plays for n+1 times. w is a 16-bit pointer to the beginning of the loop. Finite loops cannot be nested.
• One-byte encoding $20+n. Note delay (n=0-7): Delays the next note by n ticks, without affecting its overall timing. (I.e. plays silence for the first n ticks of the note.)
• One-byte encoding $30.     Triplet: The next note will be played at 2/3 of its stated duration.
• One-byte encoding: m*0x20 + n. Play note (m=2..7). If n=0, plays pause. Otherwise plays note n (note base is added to n). The lowest note that can be played is C-0 (n+base=0). Note or pause length is 2^m−1 ticks, possibly altered by the triplet / dotted modifiers. The next event will be read only after this note/pause is done playing.
  

All songs in Mega Man 2 must adhere to this format.

For example, Crashman song channel 0 begins with:  00 06 03 3C 07 8A 10 02 40 05 17 88 A0 85 A6 87..
Which translates to:
  Set speed 06;
  Set volume and env as $3C
  Set volume curve as $8A,$10
  Set dutycycle as $40
  Set note base offset as $17 (decimal 23, which is 1*12+11)
  Play note 8 (+23 = 31, which is G-2) for 8 ticks
  Pause for 16 ticks
  Play note 5 (+23 = 28, which is E-2) for 8 ticks
  Play note 6 (+23 = 29, which is F-2) for 16 ticks
  Play note 7 (+23 = 30, which is F#2) for 8 ticks

If all of this flew straight above your head without being intercepted, you will first need to learn the basics of hexadecimal numbers, hex-editing, and pointers, before you can move on.

(Now this is the level of documentation I would hope to get for Simon's Quest sound engine...)

P.S. Mega Man 1 follows this exactly same format, but the location is bank 4, and the first $1000 bytes of that bank are occupied by ending data. The song table is at 0x9A60. There are some other Capcom games that also use this engine, but I don't remember which ones they are. Megaman 3-6 use a different engine.

*) The NSF files generated by Famitracker are holistic systems that take up as much space as a small game. You can't just insert an entire game into another game.