Hey there!
I've been running Nes2Nsf and all I get are a bunch of (between 1/7) files that always are 17KB in size, 2:02 each tune, and 130:08 in total lenght - of utter silence.
What am I doing wrong?
I've left all configs 'as is', as most tutorials pointed...
I didn't even know it was possible to automate NSF ripping...
Found the tool @
http://www.zophar.net/utilities/rippers/nes2nsf.html
It's the same thing this guy had:
http://oldforum.fobby.net/cgi-bin/ultim ... 8;t=000473
I guess NES2NSF ain't checking the correct directions, but I've run it with a dozen ROMs and all give the same results.
I've been trying the different options, all to no avail. Just in case anyone feels inspired to check the NSFs resultant from the Rom I'm running and maybe fix'em, here they are:
http://rapidshare.com/files/222640410/S ... d.rar.html
The purpose of this program is make ripping nsfs easier by splitting into chunks. 1942 can only be ripped with it.
That is correct. NES2NSF splits a ROM into banks.
By using the INI file, you can specify what size banks you want. For example, 4K, 8K, 16K, and even 32K. You can also specify the detection method based on writes to $4015. STA $4015, STY $4015, STX $4015. You can also specify if you wish to append a header to each file, or no header for each file. The default header is set to $8000/$8003/$8000.
You can easily rip a lot of Capcom and Sunsoft games this way. However, I still recommend a detailed examination of the file ripped in such a way, not to mention tune arrangement.
According to the readme, something to the effect of. NES2NSF is a compilation utility used to aid the ripper.
Also note that I have noticed a problem with this utility when trying to extract 8K banks from a ROM. So, I usually only use it with 16K and 32K output banks.
Thanks for all that info! Reading the docs I saw pretty much all that, yet your explanation has helped me understand the stuff I read a bit more.
But still don't understand 99%
How do I know which specifications to use for a specific game...?
I'm referring to SF4 by Gouder:
http://www.rom-world.com/file.php?id=20398
http://romhustler.net/rom/nes/1324/street-fighter-4
Lasombra_Demon wrote:
Thanks for all that info! Reading the docs I saw pretty much all that, yet your explanation has helped me understand the stuff I read a bit more.
But still don't understand 99%
How do I know which specifications to use for a specific game...?
I don't quite understand what you mean by specifications to use for a certain game.
I do suggest that you figure out what the mapper of the game is and do some real time debugging in an emulator to get a feel for the game. Not to mention using some of the methods I explained in my document, along with what Kingshriek and UGETAB has stated in older posts for ripping.
Chris Covell also has a ripping document, which was the first one.
Gil-Galad wrote:
figure out what the mapper of the game is
How can I do that?
Sorry for total noobness. I've started reading some of the guides, and I'm trying to learn assembly and hex...
Lasombra_Demon wrote:
Gil-Galad wrote:
figure out what the mapper of the game is
How can I do that?
The header of a ROM in iNES format tells what mapper it uses.
Thanks for the tip.
Taken from VmprHntrD's tutorial.
Quote:
(Bytes 4->8-15 Can BE MODIFIED!)
4 = PRG (Hex number depends on size of PRG file)-/-- (See Sect. 4)
5 = CHR (Hex number depends on size of CHR file)/
6 = Mapper 0-15/ V or H Mirroring, Battery, 4 Screen VRAM, Trainer Switches
Also is used as the "Ones" place holder digit for the extended iNES Header
format. (See Sect. 2)
7 = Mappers 16-?, the extended iNES Header format "Tens" place holder digit.
Again (See Sect. 2 for details on how this is set up.)
I see what you mean, but what info of all this is relevant here? How do I config NES2NSF with this info?
Using FCEU and other versions such as FCEUX can tell you what the mapper of the game is, using a NES header header can also tell you, also a hex editor. The reason why you want to know what the mapper is so that you can know what the bank size select that is loaded into memory. For example, MMC1 or mapper 1 uses 16K sized banks. MMC3 uses 8K banks. You can also pick apart a ROM and section it off into banks if you need to. Also, examining the code to see how and where the banks are loaded by number according to the mapper.
(Edited from MMC4 to MMC3. MMC4 also uses 8KB banks as tepples stated)
I'll try to break this down into a few steps for you. It's by no means a definitive list. Also, you'll need to figure out your own way for ripping like we have.
1.) Find out the mapper controller of the game and banksize select.
2.) Use an emulator such as FCEUXDSP (Use UGETAB's version for additional NSF features).
3.) In the debugger, set a write breakpoint for the sound registers $4000 - $4004. This will tell you where the bulk of the sound code is. Keep hitting run to see where the snaps are.
4.) Right after a sound write, set a read breakpoint $8000 - $FFF9. Hit this a couple of times. This is to locate your sequence data. Make sure you have the right area in memory.
5.) Make sure you take note of these and write them down on Notepad or something.
6.) For example, a lot of Capcom games will have their code in the $8000 - $9000 range. The data in the $8000 - $BFFF range.
7.)Use FCEU MOD to dump the memory area, $8000 - $FFFF. This is only a base for testing. Prepend a NSF header on it and set the addressses on it. This is not your final product. This is just to get a working beta.
8.) Find your play address by setting writes to $4000 - $4004 once again. Find the NMI address by looking at the vector table in $FFFA - $FFFF range, look at all the interrupts here.
9.) Look for a call that jumps to the sound code area. JSR $xxxx for example. This is usually the easiest to find and is almost always in the NMI code. Sometimes the play call is in the IRQ, or completely outside of the NMI. You'll have to track them down.
10.) Set the play address in the header once you think you've found it. Examine the play code as well.
11.) Now, for the hardest part, that's tracking the init code. Reset the game and set a write breakpoint for $4015. Keep track of areas that write to this register and write them down. You can have anywhere from 1-5 or more areas that write to this register, or only in the play code. If you examined the play code, you should be able to deduce where the init entry is located at. Once you have figured it out, you'll have to write some code and set the header accordingly.
12.) Reset the game and set a write for $4017. Note what is written to this register. Set and reset the write breakpoint during times of the tune playing. Usually you'll want to use the first write. LDA $80 STA $4017 is often common. Use what's in the game. Sometimes a game doesn't write at all, which is rare.
Once again, read the docs that are out there. I can't really guide you step by step on this. This is the basic methods and I'm sure that others can expand on it. You need to somehow get a grasp on it and put the extra effort in there.
If you don't get a rip, don't let that discourage you. The list is growing thin as the harder ones are left. Some of them would be too difficult for a begginner to rip, unless you learn fast.
Gil-Galad wrote:
For example, MMC1 or mapper 1 uses 16K sized banks. MMC4 uses 8K banks.
Since when? I thought MMC4 (Fire Emblem, Famicom Wars) was the 16 KiB bank version of MMC2 (Punch-Out!!), which does use 8 KiB banks. Did you mean "MMC3 (mapper 4)", which also uses 8 KiB banks?
tepples wrote:
Gil-Galad wrote:
For example, MMC1 or mapper 1 uses 16K sized banks. MMC4 uses 8K banks.
Since when? I thought MMC4 (Fire Emblem, Famicom Wars) was the 16 KiB bank version of MMC2 (Punch-Out!!), which does use 8 KiB banks. Did you mean "MMC3 (mapper 4)", which also uses 8 KiB banks?
Correction: MMC3. It was a typo. Thanks for the correction.