NSF from other game works OK. Self-created doesn't

NSF from other game works OK. Self-created doesn't
by Sivak on 2008-01-21 (#30297)

OK. I've talked about this a few times in an IRC room and such, but I'll go full-detail here:

I've been using an NSF made with Famitracker in my game and whenever I perform a routine that is supposed to hold the BG in place, it can cause flickering on the screen similar to when I wasn't waiting for a vblank when switching screens. It ONLY happens if I make that call. I do have music playing in some parts where I don't make the call and the only animation that takes place are palette changes to fade in and such.

Now, I used the Clu Clu Land NSF just to play around with and it not only works without fail or bugs, but much to my surprise, the SOUND EFFECTS also work AND they don't interrupt the music (the sound channels are briefly used, but the looping music keeps going).

So I'm thinking there's something about the load addresses possibly or that NSF is optimized in some way. Clu Clu's addresses are around the $F--- range while the Famitracker ones are in the A to B range.

So, any thoughts on if my guesses are accurate?

by blargg on 2008-01-21 (#30299)

I bet you're calling the NSF's play routine at the beginning of your NMI, or (ack!) doing your graphics processing outside NMI and calling the NSF in NMI. This means that when the NSF takes a long time to process, you have less time until the end of vblank. The commercial game's music engine is probably more optimized, eliminating the problem in another way.

by Sivak on 2008-01-21 (#30300)

The NSF is called at the very end of the NMI right after all graphical and game calls are made. After the controller is read too, actually. It's the very last thing.

I've also tried Balloon Fight's NSF, but that one causes the same problems, so something about Clu Clu Land's is favored.

The reason I picked these games is their NSFs are small.

by tepples on 2008-01-21 (#30302)

Do you know exactly which RAM locations these NSFs are using as their temporary or persistent scratchpad?

by Sivak on 2008-01-21 (#30303)

tepples wrote:
Do you know exactly which RAM locations these NSFs are using as their temporary or persistent scratchpad?

No sir, I don't.

by No Carrier on 2008-01-22 (#30315)

Sivak wrote:
tepples wrote:
Do you know exactly which RAM locations these NSFs are using as their temporary or persistent scratchpad?

No sir, I don't.

I thought this might be the problem when I first read the message. I had similar problems when coding, using an old Donkey Kong NSF for testing, and then one that a friend made using Famitracker. When I get a chance, I can list the "safe places" that I used in RAM that weren't touched by FamiTracker. Maybe you can post what RAM you're using for different parts of your code.

Good luck.

by Sivak on 2008-01-22 (#30321)

My variables are all defined in zero page. Zero page is holding 87 spaces worth of memory and I have it starting at $0018 because Famitracker NSFs use the first few bytes of zero page. I originally had it at $0080, but that doesn't do anything to fix the problem either.

I have my sprite DMA on $0400 since $0200 is also used by Famitracker.

Having either of these values starting at the addresses I mentioned above will cause the game not to even run or have weirder things happen.

The NSF itself has its load address at $AD5E and it's the only thing in my $A000 bank.

That's pretty much it for memory use. Unless some part of zero page is being used, I don't know.

Glitches ONLY occur if I do a background hold too.

by Dwedit on 2008-01-22 (#30323)

Just watch the NSF player in action with a memory viewer. That tells you what memory addresses it uses.

by Sivak on 2008-01-25 (#30375)

I've figured it all out. Apparently the NSF init routine needs to be at the end of the NMI. I was having this trigger mid-way during some game calls. What I'm basically doing now is using a variable and comparing it at the end of the NMI. If it's not $FF, then it uses whatever number is in there as the music track of the NSF and plays it. It then changes it back to $FF so it obviously doesn't init many times.

I guess command order did matter in this case! Heh.