Page 96 of 218

Re: More NSF Requests

Posted: Tue Oct 16, 2012 9:21 am
by locke_gb7
awesome. Say, I noticed that the NSF for Dragon Power is archived the same for both, Dragon Ball - Shen Long no Nazo & Dragon Power. The USA Release Dragon Power has different music from the NSF thats currently there, which is the music from the japanese version.

Is there an NSF out there for the USA release of Dragon Power?

Re: More NSF Requests

Posted: Tue Oct 16, 2012 6:42 pm
by B00daW
Gil-Galad wrote:Here is the archive I made. Feel free to bookmark.

http://gilgalad.arc-nova.org/NSF-Archive/
To make this easier for everyone and take much of the archiving off your hands, this could be hosted by Dropbox, then someone with Apache server running could host the public directory. Dropbox subscriptions could be given to select members that have proven to be able to rip NSFs and update the archive. (Otherwise it access could be given to trusted members.)

However, Gil, thanks for posting your archive as you have it. :)

Re: More NSF Requests

Posted: Sun Nov 04, 2012 4:35 pm
by Eugene.S
Hi, nesdev. Can anyone rip-off the title melody of this pirate dump?

Image

100-in-1 (MG-109) [p1] (!)

Re: More NSF Requests

Posted: Sun Nov 04, 2012 4:45 pm
by Doommaster1994
That screen looks like it's from the 1,000,000 in 1. It may have the same song. That NSF is already ripped.

Re: More NSF Requests

Posted: Sun Nov 04, 2012 4:46 pm
by Eugene.S
No, it has another song.

Unchained melody is here:
9999-in-1 [p1] (!)
Image

10000000-in-1.nsf from GilGalad archive

Re: More NSF Requests

Posted: Sun Nov 04, 2012 6:20 pm
by Doommaster1994
Oh okay. I'm on my phone at the moment so I'm currently unable to listen to it.

Re: More NSF Requests

Posted: Mon Nov 05, 2012 11:15 pm
by rainwarrior
Gil-Galad in your archive "Gyromite (Gyro) (1985)(Nintendo R&D1)(Nintendo).nsf" seems to be an NSF for Stack Up and not Gyromite. (I can't find an NSF called "Stack Up" or "Robot Block" or "Robot Gyro" in the archive.)

Re: More NSF Requests

Posted: Mon Nov 05, 2012 11:28 pm
by Doommaster1994
I noticed there is a missing track in Terminator 2.

Re: More NSF Requests

Posted: Tue Nov 06, 2012 11:47 am
by Eugene.S
Eugene.S wrote:Hi, nesdev. Can anyone rip-off the title melody of this pirate dump?
83-in-1 or 100-in-1

I think it's the "Summer Wine":
http://www.youtube.com/watch?v=mQiDs9tKZv4
http://www.youtube.com/watch?v=ktKoSAEx-yU&feature=plcp

Re: More NSF Requests

Posted: Mon Jan 28, 2013 9:54 pm
by rainwarrior
Sangokushi 2 - Haou no Tairiku

Current rip jams the CPU on most players/emulators. Probably an easy fix. (Old version of NSFPlay where illegal opcodes were NOP seem to play it okay, so is probably just a matter of replacing bad opcode with NOP.)

Fixed: Sangokushi 2 - Haou no Tairiku (1992-06-10)(-)(Namco) Fixed.nsf (attached)
The PLAY address was one byte low.

Re: More NSF Requests

Posted: Mon Jan 28, 2013 10:20 pm
by Doommaster1994
Thanks for the fix! I'll see if I can find out who the composer is.
The only problem is that since this game was developed by TOSE, a company that doesn't believe in game credits, it may be a little difficult.
Also, 720 Degrees plays too fast in most NSF players. Would it be possible for you to fix that one as well? I'd deeply appreciate it.

Re: More NSF Requests

Posted: Sat Feb 02, 2013 9:50 am
by locke_gb7
Hey guys, I need second opinion, the Rip for Baltron, I'm not sure if its playing right or not, the emulator sounds well, how can I say, faster? higher pitch? the rip soudns slowed down, but often my emulators play the stuff too fast and I can't tell which is right, youtube vids also sound like my emulators. Thanks!

Re: More NSF Requests

Posted: Sat Feb 02, 2013 11:41 am
by rainwarrior
Doommaster1994 wrote:720 Degrees plays too fast in most NSF players. Would it be possible for you to fix that one as well? I'd deeply appreciate it.
I can't fix most NSF players. 720 specifies a 30Hz update rate instead of 60hz for some reason. It'll play fine in any NSF player that correctly uses the update rate.

If you think it is worthwhile to convert it to 60hz you can write a little stub for the PLAY code that skips every second update. I will write a guide here, which you can follow along and attempt for yourself.

1. Use FCEUX, put a breakpoint on some RAM address you think might be unused by the NSF. Try $07FF, and break on reads or writes, and play some tracks from the NSF. If it's being used, try another until you find one that isn't ($07FE, etc. refer to a memory map if you need to learn what addresses the RAM uses). When you find one, remember this address (I will refer to it as "variable" below).

2. Find an empty space in the NSF. This is easy because there is no bankswitching-- just stick it on the end of the existing code (at the end of the file).

3. Insert some code that executes the play routine once every second time. This is probably what I'd write:

Code: Select all

    PHA           ; save A register in case it's in use (probably not, but this is safe)
    LDA variable  ; load your variable into A register (will be initialized to 0)
    XOR #1        ; toggle variable
    STA variable  ; store it back to RAM
    BNE skip      ; if variable != 1, skip the play routine
    PLA           ; restore A register
    JMP play      ; execute the play routine
skip:
    PLA           ; restore A register
    RTS           ; return without playing
Note that the value of "play" in this example can be read from the NSF header. (NSFPlay's info page will show you what PLAY is equal to.)

4. Assemble your code (pick your favourite assembler, or use FCEUX's built in assembler, whatever's convenient) and insert it at the end of the NSF. Figure out the starting address of this code (it will be the NSF header's LOAD value + the position of the code in the file after the header). Replace the address in PLAY with the address of your code.

5. Replace the NSF header's NTSC update rate with $4100 (the proper NTSC play rate).

If you need help with any of these steps, you can ask me, but this is basically what I'd do.

Re: More NSF Requests

Posted: Sat Feb 02, 2013 11:48 am
by Doommaster1994
I wanted to cover it on Famitracker (since it was the last game that used that driver by Neil) but when I used NSFImport it played it faster.

Re: More NSF Requests

Posted: Sat Feb 02, 2013 11:48 am
by rainwarrior
locke_gb7 wrote:Hey guys, I need second opinion, the Rip for Baltron, I'm not sure if its playing right or not, the emulator sounds well, how can I say, faster? higher pitch? the rip soudns slowed down, but often my emulators play the stuff too fast and I can't tell which is right, youtube vids also sound like my emulators. Thanks!
Edit: Fixed, see below.

It's not playing at all in FCEUX, Nestopia, VirtuaNES, or NSFPlay.

VirtuaNSF plays it but does not support PAL, so it plays at the NTSC clock and update rates, i.e. pitch raised, faster playback. (The NSF is flagged as PAL, is this correct?)

foo_gep plays it but at the PAL rate, so it plays at the PAL clock and update rates, i.e. pitch lowered, slower playback.

The reason it is not playing in other emulators I am not sure, here are two possible culprits:

1. Uses bankswitching, but specifies 0,0,0,0,0,0,0,0 as bank value (disallowing bank switching-- replace with 0,1,2,3,4,5,6,7 if needed).

2. Non returning INIT. I know foo_gep has a hack to interrupt a non-returning INIT (not sure about VirtuaNSF), but this is against the NSF spec.

Edit: This was indeed the problem, but it was because it was messing with the PPU. See below for a fixed NSF.