NSF - Revision history

MathUser at 18:53, 9 November 2008

2008-11-09T18:53:28Z

← Older revision		Revision as of 18:53, 9 November 2008
Line 197:		Line 197:
	Open any regular game rom, open the hex viewer, then open the NSF file you want with the Hex viewer open. Run another copy of FCEUXDSP, and load the rom of the game you're working on an NSF of. In the game window, open it's hex-editor window too. In the emulator with the game running, get some music going, and click-drag downward from 0x200 until you have 0x700 bytes selected, and copy the information to the clipboard. This skips 0x100, where the stack is stored. In the NSF-emulating window's hex editor, paste the info at 0x200, and see if the NSF plays the music correctly. If it does, you can narrow down the amount of info copied selectively, until you get the bit of information it needs to play, and find what routine needs to be adding this info to RAM. Some fixes can consist of a single byte of difference in RAM between the original, and the repaired version of an NSF. Note that this will require that the right banks be loaded, or it will fail outright. An inaccurate Play address can also result in a lack of sound.		Open any regular game rom, open the hex viewer, then open the NSF file you want with the Hex viewer open. Run another copy of FCEUXDSP, and load the rom of the game you're working on an NSF of. In the game window, open it's hex-editor window too. In the emulator with the game running, get some music going, and click-drag downward from 0x200 until you have 0x700 bytes selected, and copy the information to the clipboard. This skips 0x100, where the stack is stored. In the NSF-emulating window's hex editor, paste the info at 0x200, and see if the NSF plays the music correctly. If it does, you can narrow down the amount of info copied selectively, until you get the bit of information it needs to play, and find what routine needs to be adding this info to RAM. Some fixes can consist of a single byte of difference in RAM between the original, and the repaired version of an NSF. Note that this will require that the right banks be loaded, or it will fail outright. An inaccurate Play address can also result in a lack of sound.

	[[Category:~~GSHI pages~~]]		[[Category:Hacking and Game Info]]

MathUser at 13:51, 17 October 2008

2008-10-17T13:51:20Z

← Older revision		Revision as of 13:51, 17 October 2008
Line 196:		Line 196:

	Open any regular game rom, open the hex viewer, then open the NSF file you want with the Hex viewer open. Run another copy of FCEUXDSP, and load the rom of the game you're working on an NSF of. In the game window, open it's hex-editor window too. In the emulator with the game running, get some music going, and click-drag downward from 0x200 until you have 0x700 bytes selected, and copy the information to the clipboard. This skips 0x100, where the stack is stored. In the NSF-emulating window's hex editor, paste the info at 0x200, and see if the NSF plays the music correctly. If it does, you can narrow down the amount of info copied selectively, until you get the bit of information it needs to play, and find what routine needs to be adding this info to RAM. Some fixes can consist of a single byte of difference in RAM between the original, and the repaired version of an NSF. Note that this will require that the right banks be loaded, or it will fail outright. An inaccurate Play address can also result in a lack of sound.		Open any regular game rom, open the hex viewer, then open the NSF file you want with the Hex viewer open. Run another copy of FCEUXDSP, and load the rom of the game you're working on an NSF of. In the game window, open it's hex-editor window too. In the emulator with the game running, get some music going, and click-drag downward from 0x200 until you have 0x700 bytes selected, and copy the information to the clipboard. This skips 0x100, where the stack is stored. In the NSF-emulating window's hex editor, paste the info at 0x200, and see if the NSF plays the music correctly. If it does, you can narrow down the amount of info copied selectively, until you get the bit of information it needs to play, and find what routine needs to be adding this info to RAM. Some fixes can consist of a single byte of difference in RAM between the original, and the repaired version of an NSF. Note that this will require that the right banks be loaded, or it will fail outright. An inaccurate Play address can also result in a lack of sound.

			[[Category:GSHI pages]]

Ugetab at 05:28, 20 July 2007

2007-07-20T05:28:01Z

← Older revision		Revision as of 05:28, 20 July 2007
Line 47:		Line 47:
	If offsets 0070h to 0077h have 00h in them, then bankswitching is not used. If one or more bytes are something other than 00h then bankswitching is used. If bankswitching is used then the load address is still used, but you now use (ADDRESS AND 0FFFh) to determine where on the first bank to load the data.		If offsets 0070h to 0077h have 00h in them, then bankswitching is not used. If one or more bytes are something other than 00h then bankswitching is used. If bankswitching is used then the load address is still used, but you now use (ADDRESS AND 0FFFh) to determine where on the first bank to load the data.

	Each bank is 4K in size, and that means there are 8 of them for the		Each bank is 1K in size, and that means there are 8 of them for the
	entire 08000h-0ffffh range in the 6502's address space. You determine where in memory the data goes by setting bytes 070h thru 077h in the file. These determine the inital bank values that will be used, and hence where the data will be loaded into the address space.		entire 08000h-0ffffh range in the 6502's address space. You determine where in memory the data goes by setting bytes 070h thru 077h in the file. These determine the inital bank values that will be used, and hence where the data will be loaded into the address space.

Line 61:		Line 61:
	Since 0070h-0077h are something other than 00h, then we know that this tune uses bankswitching. The load address for the data is specified as 08000h. We take this AND 0fffh and get 0000h, so we will load data in at byte 0 of bank 0, since data is loaded into the banks sequentially starting from bank 0 up until the music data is fully loaded.		Since 0070h-0077h are something other than 00h, then we know that this tune uses bankswitching. The load address for the data is specified as 08000h. We take this AND 0fffh and get 0000h, so we will load data in at byte 0 of bank 0, since data is loaded into the banks sequentially starting from bank 0 up until the music data is fully loaded.

	Metroid has 6 4K banks in it, numbered 0 through 5. The 6502's address space has 8 4K bankswitchable blocks on it, starting at 08000h-08fffh, 09000h-09fffh, 0a000h-0afffh ... 0f000h-0ffffh. In the Metroid NSF header, all banks start out loaded with the 6th 4K bank of data, which is 5. Each one of these is 4K in size, and the current bank is controlled by writes to 05ff8h thru 05fffh, one byte per bank. So, 05ff8h controls the 08000h-08fffh range, 05ff9h controls the 09000h-09fffh range, etc. up to 05fffh which controls the 0f000h-0ffffh range. When the song is loaded into RAM, it is loaded into the banks and not the 6502's address space. Once this is done, then the bank control registers are written to set up the inital bank values. To do this, the value at 0070h in the file is written to 05ff8h, 0071h is written to 05ff9h, etc. all the way to 0077h is written to 05fffh.		Metroid has 6 1K banks in it, numbered 0 through 5. The 6502's address space has 8 1K bankswitchable blocks on it, starting at 08000h-08fffh, 09000h-09fffh, 0a000h-0afffh ... 0f000h-0ffffh. In the Metroid NSF header, all banks start out loaded with the 6th 1K bank of data, which is 5. Each one of these is 1K in size, and the current bank is controlled by writes to 05ff8h thru 05fffh, one byte per bank. So, 05ff8h controls the 08000h-08fffh range, 05ff9h controls the 09000h-09fffh range, etc. up to 05fffh which controls the 0f000h-0ffffh range. When the song is loaded into RAM, it is loaded into the banks and not the 6502's address space. Once this is done, then the bank control registers are written to set up the inital bank values. To do this, the value at 0070h in the file is written to 05ff8h, 0071h is written to 05ff9h, etc. all the way to 0077h is written to 05fffh.
	This is should be done before every call to the init routine.		This is should be done before every call to the init routine.

Ugetab at 02:22, 17 July 2007

2007-07-17T02:22:35Z

← Older revision		Revision as of 02:22, 17 July 2007
Line 6:		Line 6:


			(The following is a modified version of the text on the nesdev.parodius.org wiki)
	== Header Overview ==		== Header Overview ==

Line 13:		Line 14:
	0005 1 BYTE Version number (currently 01h)		0005 1 BYTE Version number (currently 01h)
	0006 1 BYTE Total songs (1=1 song, 2=2 songs, etc)		0006 1 BYTE Total songs (1=1 song, 2=2 songs, etc)
	0007 1 BYTE Starting song (1= 1st song, 2=2nd song, etc)		0007 1 BYTE Starting song (1=1st song, 2=2nd song, etc)
	0008 2 WORD (lo/hi) load address of data (8000-FFFF)		0008 2 WORD (lo/hi) load address of data (8000-FFFF)
	000a 2 WORD (lo/hi) init address of data (8000-FFFF)		000a 2 WORD (lo/hi) init address of data (8000-FFFF)
Line 39:		Line 40:
	0080 nnn ---- The music program/data follows		0080 nnn ---- The music program/data follows

	This may look somewhat familiar; if so that's because this is somewhat ~~sorta~~ of based on the PSID file format for C64 music/sound.		This may look somewhat familiar; if so that's because this is somewhat sort of based on the PSID file format for C64 music/sound.


Line 60:		Line 61:
	Since 0070h-0077h are something other than 00h, then we know that this tune uses bankswitching. The load address for the data is specified as 08000h. We take this AND 0fffh and get 0000h, so we will load data in at byte 0 of bank 0, since data is loaded into the banks sequentially starting from bank 0 up until the music data is fully loaded.		Since 0070h-0077h are something other than 00h, then we know that this tune uses bankswitching. The load address for the data is specified as 08000h. We take this AND 0fffh and get 0000h, so we will load data in at byte 0 of bank 0, since data is loaded into the banks sequentially starting from bank 0 up until the music data is fully loaded.

	Metroid has 6 4K banks in it, numbered 0 through 5. The 6502's address space has 8 4K bankswitchable blocks on it, starting at 08000h-08fffh, 09000h-09fffh, 0a000h-0afffh ... 0f000h-0ffffh. Each one of these is 4K in size, and the current bank is controlled by writes to 05ff8h thru 05fffh, one byte per bank. So, 05ff8h controls the 08000h-08fffh range, 05ff9h controls the 09000h-09fffh range, etc. up to 05fffh which controls the 0f000h-0ffffh range. When the song is loaded into RAM, it is loaded into the banks and not the 6502's address space. Once this is done, then the bank control registers are written to set up the inital bank values. To do this, the value at 0070h in the file is written to 05ff8h, 0071h		Metroid has 6 4K banks in it, numbered 0 through 5. The 6502's address space has 8 4K bankswitchable blocks on it, starting at 08000h-08fffh, 09000h-09fffh, 0a000h-0afffh ... 0f000h-0ffffh. In the Metroid NSF header, all banks start out loaded with the 6th 4K bank of data, which is 5. Each one of these is 4K in size, and the current bank is controlled by writes to 05ff8h thru 05fffh, one byte per bank. So, 05ff8h controls the 08000h-08fffh range, 05ff9h controls the 09000h-09fffh range, etc. up to 05fffh which controls the 0f000h-0ffffh range. When the song is loaded into RAM, it is loaded into the banks and not the 6502's address space. Once this is done, then the bank control registers are written to set up the inital bank values. To do this, the value at 0070h in the file is written to 05ff8h, 0071h is written to 05ff9h, etc. all the way to 0077h is written to 05fffh.
	is written to 05ff9h, etc. all the way to 0077h is written to 05fffh.
	This is should be done before every call to the init routine.		This is should be done before every call to the init routine.

Line 84:		Line 84:
	per second is determined by offsets 006eh and 006fh in the file.		per second is determined by offsets 006eh and 006fh in the file.
	These bytes denote the speed of playback in 1/1000000ths of a second.		These bytes denote the speed of playback in 1/1000000ths of a second.
	For the "usual" 60Hz playback rate, set this to 411ah.		For the "usual" 60Hz playback rate, set this to 411ah.

	To generate a differing playback rate, use this formula:		To generate a differing playback rate, use this formula:
Line 126:		Line 126:

	== Properly Playing a Tune ==		== Properly Playing a Tune ==
			Call the play address of the music at periodic intervals determined by the speed words. Which word to use is determined by which mode you are in- PAL or NTSC.

	~~Call the play address of the music at periodic intervals determined by~~ the ~~speed words. Which word to use is determined by which mode you are in- PAL or NTSC~~.		== Changes Since This Guide Was Written ==
			Some players no longer use the playback rate bytes.

	== Adding DPCM ==		== Adding DPCM ==
Line 177:		Line 179:
	# There should be 8K of RAM present at 6000-7FFFh. MMC5 tunes need RAM at 5C00-5FF7 to emulate its EXRAM. 8000-FFFF should be read-only (not writable) after a tune has loaded. The only time this area should be writable is if an FDS tune is being played.		# There should be 8K of RAM present at 6000-7FFFh. MMC5 tunes need RAM at 5C00-5FF7 to emulate its EXRAM. 8000-FFFF should be read-only (not writable) after a tune has loaded. The only time this area should be writable is if an FDS tune is being played.
	# Do not assume the state of anything on entry to the init routine except A and X. Y can be anything, as can the flags.		# Do not assume the state of anything on entry to the init routine except A and X. Y can be anything, as can the flags.
	# Do not assume the state of anything on entry to the play routine either. Flags, X, A, and Y could be at any state. I've fixed about 10 tunes because of this problem and the problem, above.		# Do not assume the state of anything on entry to the play routine either. Flags, X, A, and Y could be at any state. I've fixed about 10 tunes because of this problem and the problem above.
	# The stack sits at 1FFh and grows down. Make sure the tune does not attempt to use ~~1F0h~~-1FFh for variables. (Armed Dragon Villigust did and I had to relocate its RAM usage to 2xx)		# The stack sits at 1FFh and grows down to 100h. Make sure the tune does not attempt to use 1E0h-1FFh for variables. (Armed Dragon Villigust did and I had to relocate its RAM usage to 2xx) Tunes that do use this area are likely relying on direct lookup of stack values. Games that do this need to be debugged to find the location that pushes or writes this information.
	# Variables should sit in the 0000h-07FFh area only. If the tune writes outside this range, say 1400h this is bad and should be relocated. (Terminator 3 did this and I relocated it to 04xx).		# Variables should sit in the 0000h-07FFh area only. If the tune writes outside this range, say 1400h this is bad and should be relocated. (Terminator 3 did this and I relocated it to 04xx). Note that most recent players also support RAM at 6000h-7FFFh.
			# Some games require A/X/Y to be 'cleaned' before running some code. This can be required during the Init routine, or before the Play address is run. In one case, all the songs in an NSF wouldn't loop because the Y register wasn't zeroed in the init routine.

	== Using FCEUXDSP ==		== Using FCEUXDSP ==
Line 188:		Line 191:
	Breaking on writes to $4000 - $400F will usually show you part of the Play routine. Using the 'Step Out' option tends to help show the entry point into the routine.		Breaking on writes to $4000 - $400F will usually show you part of the Play routine. Using the 'Step Out' option tends to help show the entry point into the routine.

	Discovering what part of memory changes to choose the next note is helpful in figuring out where the music init is. Breaking on writes to these addresses helps find the Song Init coding, either by visually ~~disecting~~ the code, or by using Step Out to try to find a place to breakpoint, and change the A/X/Y registers, in hopes of choosing a different song, which will confirm that it's a Song Init routine.		Discovering what part of memory changes to choose the next note is helpful in figuring out where the music init is. Breaking on writes to these addresses helps find the Song Init coding, either by visually dissecting the code, or by using Step Out to try to find a place to breakpoint, and change the A/X/Y registers, in hopes of choosing a different song, which will confirm that it's a Song Init routine.

	If you load an NSF, you can use the debugger to check for errors without much difficulty. You can also use a trick for debugging that lets you use verified Game memory to test the NSF for correct music information, and Play routine...		If you load an NSF, you can use the debugger to check for errors without much difficulty. You can also use a trick for debugging that lets you use verified Game memory to test the NSF for correct music information, and Play routine...

	Open a regular game rom, ~~and~~ open the hex viewer, then open the NSF file you want with the Hex viewer open. Run another copy of FCEUXDSP, and load the rom of the game you're working on an NSF of. In the ~~other copy~~, open it's hex-editor window too. In the emulator with the game running, get some music going, and click-drag downward from 0x200 until you have 0x700 bytes selected, and copy the information to the clipboard. This skips 0x100, where the stack is stored. In the NSF-emulating window's hex editor, paste the info at 0x200, and see if the NSF plays the music correctly. If it does, you can narrow down the amount of info copied selectively, until you get the bit of information it needs to play, and find what routine needs to be adding this info to RAM. Some ~~fixed~~ can consist of a single byte of difference in RAM between the original, and the repaired version of an NSF.		Open any regular game rom, open the hex viewer, then open the NSF file you want with the Hex viewer open. Run another copy of FCEUXDSP, and load the rom of the game you're working on an NSF of. In the game window, open it's hex-editor window too. In the emulator with the game running, get some music going, and click-drag downward from 0x200 until you have 0x700 bytes selected, and copy the information to the clipboard. This skips 0x100, where the stack is stored. In the NSF-emulating window's hex editor, paste the info at 0x200, and see if the NSF plays the music correctly. If it does, you can narrow down the amount of info copied selectively, until you get the bit of information it needs to play, and find what routine needs to be adding this info to RAM. Some fixes can consist of a single byte of difference in RAM between the original, and the repaired version of an NSF. Note that this will require that the right banks be loaded, or it will fail outright. An inaccurate Play address can also result in a lack of sound.

Ugetab at 05:29, 12 December 2006

2006-12-12T05:29:01Z

New page

The basic idea is one rips the music/sound code from an NES game and prepends a small header to the data.

A program of some form (6502/sound emulator) then takes the data and loads it into the proper place into the 6502's address space, then inits and plays the tune.

Many of the same methods used for finding cheat codes are compatible with finding sound information. The extra work of getting the right code into the right place and setting up the header is the primary difference between ripping and cheat making.

== Header Overview ==

offset # of bytes Function
----------------------------
0000 5 STRING "NESM",01Ah ; denotes an NES sound format file
0005 1 BYTE Version number (currently 01h)
0006 1 BYTE Total songs (1=1 song, 2=2 songs, etc)
0007 1 BYTE Starting song (1= 1st song, 2=2nd song, etc)
0008 2 WORD (lo/hi) load address of data (8000-FFFF)
000a 2 WORD (lo/hi) init address of data (8000-FFFF)
000c 2 WORD (lo/hi) play address of data (8000-FFFF)
000e 32 STRING The name of the song, null terminated
002e 32 STRING The artist, if known, null terminated
004e 32 STRING The Copyright holder, null terminated
006e 2 WORD (lo/hi) speed, in 1/1000000th sec ticks, NTSC (see text)
0070 8 BYTE Bankswitch Init Values (see text, and FDS section)
0078 2 WORD (lo/hi) speed, in 1/1000000th sec ticks, PAL (see text)
007a 1 BYTE PAL/NTSC bits:
bit 0: if clear, this is an NTSC tune
bit 0: if set, this is a PAL tune
bit 1: if set, this is a dual PAL/NTSC tune
bits 2-7: not used. they *must* be 0
007b 1 BYTE Extra Sound Chip Support
bit 0: if set, this song uses VRCVI
bit 1: if set, this song uses VRCVII
bit 2: if set, this song uses FDS Sound
bit 3: if set, this song uses MMC5 audio
bit 4: if set, this song uses Namco 106
bit 5: if set, this song uses Sunsoft FME-07
bits 6,7: future expansion: they *must* be 0
007c 4 ---- 4 extra bytes for expansion (must be 00h)
0080 nnn ---- The music program/data follows

This may look somewhat familiar; if so that's because this is somewhat sorta of based on the PSID file format for C64 music/sound.

== Loading a tune into RAM ==

If offsets 0070h to 0077h have 00h in them, then bankswitching is *not* used. If one or more bytes are something other than 00h then bankswitching is used. If bankswitching is used then the load address is still used, but you now use (ADDRESS AND 0FFFh) to determine where on the first bank to load the data.

Each bank is 4K in size, and that means there are 8 of them for the
entire 08000h-0ffffh range in the 6502's address space. You determine where in memory the data goes by setting bytes 070h thru 077h in the file. These determine the inital bank values that will be used, and hence where the data will be loaded into the address space.

Here's an example:

METROID.NSF will be used for the following explaination.

The file is set up like so: (starting at 070h in the file)

0070: 05 05 05 05 05 05 05 05 - 00 00 00 00 00 00 00 00
0080: ... music data goes here...

Since 0070h-0077h are something other than 00h, then we know that this tune uses bankswitching. The load address for the data is specified as 08000h. We take this AND 0fffh and get 0000h, so we will load data in at byte 0 of bank 0, since data is loaded into the banks sequentially starting from bank 0 up until the music data is fully loaded.

Metroid has 6 4K banks in it, numbered 0 through 5. The 6502's address space has 8 4K bankswitchable blocks on it, starting at 08000h-08fffh, 09000h-09fffh, 0a000h-0afffh ... 0f000h-0ffffh. Each one of these is 4K in size, and the current bank is controlled by writes to 05ff8h thru 05fffh, one byte per bank. So, 05ff8h controls the 08000h-08fffh range, 05ff9h controls the 09000h-09fffh range, etc. up to 05fffh which controls the 0f000h-0ffffh range. When the song is loaded into RAM, it is loaded into the banks and not the 6502's address space. Once this is done, then the bank control registers are written to set up the inital bank values. To do this, the value at 0070h in the file is written to 05ff8h, 0071h
is written to 05ff9h, etc. all the way to 0077h is written to 05fffh.
This is should be done before every call to the init routine.

If the tune was not bankswitched, then it is simply loaded in at the
specified load address, until EOF

== Initalizing a tune ==

This is pretty simple. Load the desired song # into the accumulator,
minus 1 and set the X register to specify PAL (X=1) or NTSC (X=0).
If this is a single standard tune (i.e. PAL *or* NTSC but not both)
then the X register contents should not matter. Once the song # and
optional PAL/NTSC standard are loaded, simply call the INIT address.
Once init is done, it should perform an RTS.

== Playing a tune ==

Once the tune has been initalized, it can now be played. To do this,
simply call the play address several times a second. How many times
per second is determined by offsets 006eh and 006fh in the file.
These bytes denote the speed of playback in 1/1000000ths of a second.
For the "usual" 60Hz playback rate, set this to 411ah.

To generate a differing playback rate, use this formula:

1000000
PBRATE= ---------
speed

Where PBRATE is the value you stick into 006e/006fh in the file, and
speed is the desired speed in hertz.

== Properly Loading a Tune ==

* If the tune is bankswitched, go to #3.

* Load the data into the 6502's address space starting at the specified load address. Go to #4.

* Load the data into a RAM area, starting at (start_address AND 0fffh).

* Tune load is done.

== Properly Initializing a Tune ==

* Clear all RAM at 0000h-07ffh.

* Clear all RAM at 6000h-7fffh.

* Init the sound registers by writing 00h to 04000-0400Fh, 10h to 4010h, and 00h to 4011h-4013h.

* Set volume register 04015h to 00fh.

* If this is a banked tune, load the bank values from the header into 5ff8-5fffh.

* Set the accumulator and X registers for the desired song.

* Call the music init routine.

== Properly Playing a Tune ==

Call the play address of the music at periodic intervals determined by the speed words. Which word to use is determined by which mode you are in- PAL or NTSC.

== Adding DPCM ==
There is a large section on how to deal with DPCM samples in the [http://www.zophar.net/tech/files/NESAudioRipping.TXT NES Music Ripping Guide], but the basic information on DPCM is that writes to $4012 and $4013 access sample data stored at and between $c000 and $ffff.

Writes to $4012 determine the location of the sample data. The value written to $4012, multiplied by 0040h, plus 0c000h, is the point in ROM space the sample starts.

Writes to $4013 determine the length of the sample data. The value written to $4013, multiplied by 0010h, plus 1, is the length of the sample data.

If 00h is written to $4012 and $4013, the sample would be located at $c000, and would be 1 byte in length. If 0080h is written to $4012 and $4013, the sample would be located at $e000, and would be 0x801 bytes in length.

DPCM samples can be attached to an NSF by either relocating the neccesary data, or by including the banks with the DPCM data in the NSF. Relocating the data correctly will often lead to a smaller file size, but including the original data in it's original location is usually easier to do.

== Sound Chip Support ==
Byte 007bh of the file stores the sound chip flags. If a particular flag is set, those sound registers should be enabled. If the flag is clear, then those registers should be disabled. All I/O registers within 8000-FFFF are ''write only'' and must not disrupt music code that happens to be stored there.

=== VRCVI ===
* Uses registers 9000-9002, A000-A002, and B000-B002, write only. See [[VRC6 Audio]] for more information.
* Note: The A0 and A1 lines are flipped on a few games! If you rip the music and it sounds all funny, flip around the xxx1 and xxx2 register pairs. (i.e. 9001 and 9002) 9000 and 9003 can be left untouched. I decided to do this since it would make things easier all around, and this means you only will have to change the music code in a very few places (6). Esper2 and Madara will need this change, while Castlevania 3j will not for instance.

=== VRCVII ===
* Uses registers 9010 and 9030, write only. See [[VRC7 Audio]] for more information.

=== FDS Sound ===
* Uses registers from 4040 through 4092. See [[FDS Audio]] for more information.

Notes:
* 6000-DFFF is assumed to be RAM, since 6000-DFFF is RAM on the FDS. E000-FFFF is usually not included in FDS games because it is the BIOS ROM. However, it can be used on FDS rips to help the ripper (for modified play/init addresses).
* Bankswitching operates slightly different on FDS tunes. 5FF6 and 5FF7 control the banks 6000-6FFF and 7000-7FFF respectively. NSF header offsets 76h and 77h correspond to *both* 6000-7FFF *AND* E000-FFFF. Keep this in mind!

=== MMC5 Sound ===
* Uses registers 5000-5015, write only as well as 5205 and 5206, and 5C00-5FF5. see [[MMC5 Audio]] for more information.

Notes:
* 5205 and 5206 are a hardware 8*8 multiplier. The idea being you write your two bytes to be multiplied into 5205 and 5206 and after doing so, you read the result back out.
* 5C00-5FF5 should be RAM to emulate EXRAM while in MMC5 mode.

=== Namco 106 Sound ===
* Uses registers 4800 and F800. See [[Namco 106 Audio]] for more information.

=== Sunsoft FME-07 Sound ===
* Uses registers C000 and E000. See [[Sunsoft Audio]] for more information.

== Caveats ==
# The starting song number and maximum song numbers start counting at 1, while the init address of the tune starts counting at 0. To "fix", simply pass the desired song number minus 1 to the init routine.
# The NTSC speed word is used *only* for NTSC tunes, or dual PAL/NTSC tunes. The PAL speed word is used *only* for PAL tunes, or dual PAL/NTSC tunes.
# The length of the text in the name, artist, and copyright fields must be 31 characters or less! There has to be at least a single NULL byte (00h) after the text, between fields.
# If a field is not known (name, artist, copyright) then the field must contain the string "<?>" (without quotes).
# There should be 8K of RAM present at 6000-7FFFh. MMC5 tunes need RAM at 5C00-5FF7 to emulate its EXRAM. 8000-FFFF should be read-only (not writable) after a tune has loaded. The only time this area should be writable is if an FDS tune is being played.
# Do not assume the state of *anything* on entry to the init routine except A and X. Y can be anything, as can the flags.
# Do not assume the state of *anything* on entry to the play routine either. Flags, X, A, and Y could be at any state. I've fixed about 10 tunes because of this problem and the problem, above.
# The stack sits at 1FFh and grows down. Make sure the tune does not attempt to use 1F0h-1FFh for variables. (Armed Dragon Villigust did and I had to relocate its RAM usage to 2xx)
# Variables should sit in the 0000h-07FFh area *only*. If the tune writes outside this range, say 1400h this is bad and should be relocated. (Terminator 3 did this and I relocated it to 04xx).

== Using FCEUXDSP ==
Ripping can be made much easier by using this relatively new NES debugging emulator.

By breakpointing writes to $4015, then resetting the game, you can often find the part of code that initializes the sound registers(Sound Init), and see if it's doing anything unusual at that point.

Breaking on writes to $4000 - $400F will usually show you part of the Play routine. Using the 'Step Out' option tends to help show the entry point into the routine.

Discovering what part of memory changes to choose the next note is helpful in figuring out where the music init is. Breaking on writes to these addresses helps find the Song Init coding, either by visually disecting the code, or by using Step Out to try to find a place to breakpoint, and change the A/X/Y registers, in hopes of choosing a different song, which will confirm that it's a Song Init routine.

If you load an NSF, you can use the debugger to check for errors without much difficulty. You can also use a trick for debugging that lets you use verified Game memory to test the NSF for correct music information, and Play routine...

Open a regular game rom, and open the hex viewer, then open the NSF file you want with the Hex viewer open. Run another copy of FCEUXDSP, and load the rom of the game you're working on an NSF of. In the other copy, open it's hex-editor window too. In the emulator with the game running, get some music going, and click-drag downward from 0x200 until you have 0x700 bytes selected, and copy the information to the clipboard. This skips 0x100, where the stack is stored. In the NSF-emulating window's hex editor, paste the info at 0x200, and see if the NSF plays the music correctly. If it does, you can narrow down the amount of info copied selectively, until you get the bit of information it needs to play, and find what routine needs to be adding this info to RAM. Some fixed can consist of a single byte of difference in RAM between the original, and the repaired version of an NSF.