Super Mario World MSU+

This will not work

Code:


MSUReady:
   LDA $2000                        ;\
   AND #$40                        ;| If not ready, loop
   BNE MSUReady


try to set the free ram and let the game continue to the next frame. I had several problems when not making it this way; e.g., game crashed, track didn't loop, black bar, etc,.

Read this topic:
https://www.zeldix.net/t649-top-gear-2-snes-msu1-hack
I explained the problem with this loop in detail in the middle of the thread

Oh my, I didn't realize the SDCard speed could affect the data streaming, well then, sorry rom hackers, one more freeram will be taken.

Done.

http://1drv.ms/1L4aE0G

All files are updated, this time I tested all the .BPS patches in both emulators and SD2SNES to make sure the music works as intended.

The ASM source code now includes the MSU-1 busy pending flag, however, the code related to it will only assembler if !Emulator is set to !False, this was done because the busy flag screws up the music reproduction (it cuts off a piece of the song at the start), so I decided to preserve the old code only to emulators.

Colines wrote:Done.

http://1drv.ms/1L4aE0G

All files are updated, this time I tested all the .BPS patches in both emulators and SD2SNES to make sure the music works as intended.

The ASM source code now includes the MSU-1 busy pending flag, however, the code related to it will only assembler if !Emulator is set to !True, this was done because the busy flag screws up the music reproduction (it cuts off a piece of the song at the start), so I decided to preserve the old code only to emulators.

Everything works great thank you so much!

The ASM source code now includes the MSU-1 busy pending flag, however, the code related to it will only assembler if !Emulator is set to !True, this was done because the busy flag screws up the music reproduction (it cuts off a piece of the song at the start), so I decided to preserve the old code only to emulators.

I wonder how this could possibly happen, I mean it's just 2 or 3 opcodes more and the emulator will not stuck there.

Anyways, awesome

GinBunBun wrote:Everything works great thank you so much!

No, no, no.
Thank YOU very much.

Due to your feedback, I will never commit again the mistake of not testing my BPS patches ;D

Conn wrote:I wonder how this could possibly happen, I mean it's just 2 or 3 opcodes more and the emulator will not stuck there.

Oh, I didn't mean the code crashed the game or something like that. It's just the audio player which doesn't work properly at the first seconds of level tracks.

If you play the SD2SNES patch in a more accurate emulator (bsnes plus or higan), you will see what I'm talking about.

Actually, while setting up the busy flag, I figured out that some of the flaws I accuse your native patch has is indeed because of the busy flag, but these flaws only show up on emulators. higan doesn't emulate the hardware limitation of the data streaming speed in SDCards (it seems like byuu really thought someone would do a cartridge capable to support the 4GB of extra data), so while the busy flag maintain compability with RH, as you said, in emulators the music data streams immediately, but since $2007 and $2006 are only set in the next frame (and before that, need to wait the overflow flag), the music plays a few seconds in mute even if the Audio Control port isn't set, to fix that I would need to set more custom flags to determine if the music is playing or not (just like you did in F-Zero).

Ah ok... I don't know if I have this problem in my patch since I hook inside the nmi routine, which is called 60 times per second.

If your routine is called only every 3 seconds or whatever, there is surely some mute between 2004 and 2007.

Conn wrote:I don't know if I have this problem in my patch

Unfortunately, your patch has this problem, however you can't hear the mute (oh, irony xp) because bsnes 0.70 doesn't seem to emulate properly this condition, play in bsnes plus or higan and you will see ;D

Conn wrote:If your routine is called only every 3 seconds or whatever, there is surely some mute between 2004 and 2007.

I hijacked the main loop, which is called in every frame of the game, so that would be 1/30th of a second.

But that doesn't make difference, the mute seems to last the same in both of our patches

mh, I don't think that this all is the reason for the delay. If I make a STZ $2007, the msu pauses until I play it again with setting #$01 or #$03 to this address (and then it plays from where I paused it).

What I think: when you introduce a new track, you do not pause the track (it still has $2007 set with 01 or 03 from the previous track), so the new track already starts playing without having the data streamed.

What you could/should try is, when loading the new track to 2004 also clear 2007 (set it to zero with stz), means

Code:


; lda track index
STA $2004
STZ $2007


When the new track is ready (overflow cleared, 2007 gets a value again)

Conn wrote:What I think: when you introduce a new track, you do not pause the track (it still has $2007 set with 01 or 03 from the previous track), so the new track already starts playing without having the data streamed.

You sir, deserve a gold bar

I already had fixed that by doing what you said, but I still wasn't understanding what was going on since no matter what, I supposedly coded the audio to stop by always STZ'n out the Audio Control port ($2007), so I shouldn't have to STZ $2007 right after loading a track to $2004.

But thanks to you, I could see I made another probie mistake:

Code:

Go:
STZ !FreeRAM3
STZ $2006

This is the end of the THEFade routine, as you can see, I naively STZ'd $2006 instead of $2007.

Well, live and learn.

Conn at F-Zero topic wrote:Such hacking is always problematic and bug affectiveas you see    but smw was way worse.

Sorry if I brought up bad memories xp

Great that it works the question bugging me now is whether I should also update my hacks (I have no sd2snes and thus cannot test anything rh related), but you've told me that this problem also occurs in my hacks.
Would it work with my suggested STZ $2007 before STA $2004? I have no fade out (only in ALTTP) so your report is a bit cryptic to me ^^

Conn wrote:Would it work with my suggested STZ $2007 before STA $2004? I have no fade out (only in ALTTP) so your report is a bit cryptic to me ^^

Yes, that would definitely fix the problem too.

But looking into your code, I can see the problem of your patch is exactly the same as mine:

Code:

CMP #$80
BEQ playspc
.............
playspc:
STZ $2006  <----------------------
LDA $1DFB  
STA $2142  
STA $1DFF  
STZ $1DFB
RTL

When the game requests the SPC music to be stopped, you intercept the command to redirect it so the MSU-1 audio be stopped too.

However, you STZ'd $2006 just like me xp
As we all know, this only mutes the audio, rather than stopping it for good.

So instead of adding three more bytes to your code, you will just want to change that piece of code to:

Code:

playspc:
STZ $2007  
LDA $1DFB  
STA $2142  
STA $1DFF  
STZ $1DFB
RTL

YES!

I present you guys, the new feature for version 1.5 of Super Mario World MSU-1(+)



Now, the overworld is capable of playing multiple songs on main map, and to make things better, it's fully customizable for the end user! (Go to 1:15)

As soon as I get done with other minor stuff, I will be releasing it for beta testing and I will update the readme with instructions of how it works.

Excellent! I think its a pretty incredible feature to have and I think that the smw community hasn't grasped how significant this actually is yet.

The potential for msu1 for mario hacks is really high. You could make a totally different game using smw as a base from the typical mario games and given how power music is you could really turn heads when someone hears some really epic soundtrack coming from an snes.

Oh wow... after you've finished bszelda you really should do other hacks (dkc1,3, street fighter...)

Public release, there you go!

http://1drv.ms/1L4aE0G

Download the BPS patches again and apply one of them to a clean rom!

I had some problems to make it work with the SA-1 chip, but I solved it by getting rid of the Busy flag, still, the busy flag settings will assembler if the rom is detected not being SA-1 type.

You need to download the folder "OW Music" in the link provided and mix its content to your PCM set if you don't want the SPC fallback be activated.

I would have organized the PCM files in a better way, but I'm too busy working on others projects right now! So this is going to be done later ;D

Erockbrox wrote:Excellent! I think its a pretty incredible feature to have and I think that the smw community hasn't grasped how significant this actually is yet.

The potential for msu1 for mario hacks is really high. You could make a totally different game using smw as a base from the typical mario games and given how power music is you could really turn heads when someone hears some really epic soundtrack coming from an snes.

You are absolutely damn right. I have no idea what happens to people over there, I'm not underrating the power the SPC engine has, but they think the SNES should not be appreciated if he goes beyond from what Nintendo presented.

Seriously, they are cave men. Trying to understand the anti-MSU thing is like to try to prove God's existence.

Conn wrote:Oh wow... after you've finished bszelda you really should do other hacks (dkc1,3, street fighter...)

I surely will!!! All the ASM I've been doing so far was for educational purposes, when I past this phase, my MSU-1 reign will begin.

I surely will!!! Smile All the ASM I've been doing so far was for educational purposes, when I past this phase, my MSU-1 reign will begin. Very Happy

*lol, in this case DarkShock and I can eventually retire