Banner
The Base Rom Level Design Contest has begun! Visit its contest subforum to learn more!
Views: 771,432,201
Time:
13 users online: 7 Up, Daizo Dee Von, Dark4ssass1n, DPBOX,  FPzero,  fsvgm777, GatoSlashFish, Kusamochi, ReaLifePlumber, Shook50, Slash Chen, Ultima, Yung Gotenks - Guests: 55 - Bots: 215Users: 40,525 (1,859 active)
Latest: XCB
Tip: Do you want to create custom blocks, but have little to no experience with ASM? Use Kipernal's Blockreator!Not logged in.
Super Mario World MSU1 hack
Forum Index - SMW Hacking - Works in Progress - Super Mario World MSU1 hack
Pages: « 1 2 3 »
Alright, Ikari_01 gave me a hint so I was able to fix this sd2snes loop bug.

The new file is already uploaded:
Edit: Seems like the nice Forum Moderators removed my Submission without giving reasons after 2 months of queue status. I'm not interested to resubmit it here again, so please download it only from the following permalink:


http://bszelda.zeldalegends.net/stuff/Con/smw_msu1.zip

Edit:
Unfortunately, Ikaris_01 found 2 further bugs:
- a Jingle went mute after dying
- when pausing the msu forwarded in the Background

both is now fixed when redownloading/reapplying:
http://bszelda.zeldalegends.net/stuff/Con/smw_msu1.zip
Everything that got removed from the site has removal logs. They're on the forum after "Site Suggestions & Bugs". I did even send you a PM with the link to the removal log, but you didn't read. Here are the reasons.

--------------------
GitHub - Twitter - YouTube - Blog - SnesLab Discord
Ah thank you. This was my fault, as I'm quite new here and didn't look for PM:s. I do not know yet whether I will resubmit it or just leave the extern permalink for People that dare playing the "poorly coded and dangerous code" :) which however was tested on different sides and works nevertheless perfect and now flawlessly.

I have Major real live issues and also zelda3 requests, so I do not know if I will have time to rewrite the code. Furthermore, the feedback on this hack is in common not very high (feels not very much appreciated by the community), so I have not many reasons in spending more time in it (also, the code's functionality is, as said, at 100% as it is now. Of course there's always space for beauty improvements and make it compatible with LM (if it isn't already) by relocating it (but this is a thing of time/effort and also appreciation).

My code is source-free so if somebody else thinks a msu-1 hack is a must-have for smwcentral and wants to address your critique and resubmits it again, please feel free to do this.

Your critique:

1. The code can only be hooked during nmi since the value on $1dfb is given to $2142 here.
The Video was taken from the previous Version.
In the latest Version I published 2 days ago (sd2snes fix) the black bar is solved through bit$2000-bvs end (and not bvs Loop (forced the code to stay in nmi until stream is finished causing the bar). This new code "bvs end" will make data Streaming in the Background while the routines continue and the msu will be played in a later Frame when the stream is finished... so you will not have a black bar anymore.

2. I do not know the Rom well. What's the difference between freespace and unused space? Expanded area?

3. You're right, I was lazy here ^^'.

additional 1.
Byuu's policies change often. I consider v.70 the easiest Emulator for msu-1 (Plays Header/not-headerd, smc/sfc, xml, pcm in the rom's folder), but I also included a tutorial and bml for higan (for those who want to go this way). Byuu promised me to make the spc-fallback code also for bsnes v.70 if he has time. Nevertheless, Kiddo will make pcm for all the sfx used (game-over and such), so People, using his package will have full msu Support.

additional 2: no, bsnes v70 has a higher volume Level than sd2snes. But I will ask Ikari whether $2006-80 is good for sd2snes playing

additional 3: hard to implement...

additional 4: never heard about this, sorry.
Hi there. I've been messing around with the MSU-1 patch, and despite its issues, it's a really nice patch that would be a shame for it to go to waste. I'd be willing to help fix some of its flaws, as I've got some ASM knowledge, and I have an SD2SNES, so I can test it out on that in addition to BSNES V070.

Anyway, I'm going to respond to a few things that you said in your previous post while I'm here.

1. Just because SMW loads the value of $1DFB into $2142 during NMI doesn't mean that you necessarily have to hijack that part for your patch to work. As long as $1DFB/$2142 keeps its value, you can hijack some other part of the ROM for your patch to work, as long as it's somewhere where it can be read every frame. Plus, given how inefficient the code is for determining what songs to loop and what music bank to use when loading songs, your code is wasting a lot of time in NMI, which is what is causing the screen flickering and the black bars. Even if you optimized the code, you're still wasting NMI time, as the NMI shouldn't be used for anything aside from VRAM related stuff (I could be wrong about that, though. If I am, someone correct me, please).

Since I'm using AddmusicK in my hack, which NOPs out that area your patch hijacks, I put the hijack to the MSU-1 code inside of AddmusicK's patch.asm file right before it jumps back to the start of the main game loop, and it works without any of the issues that Vitor Vilela described in the removal log. For SMW hacks that don't use AddmusicK, you could put a JML at $008075 to the MSU-1 code, then at the end of your code, store a zero to $10, then JML to $00806B and it should work fine. For hacks that use AddmusicK, the hijack could go here in patch.asm:

Code
End:	
	CLI
	PLB
	PLP

	JSL $04EF40		; JSL to MSU-1 code

	JML $00806B		; Return.  TODO: Detect if the ROM is using the Wait Replace patch.



2. The expanded area is the area in the ROM beyond the first 512 KB when SMW is expanded. Specifically, ROM banks 0-F are within the first 512 KB, so you'll want your patch to point to a ROM bank after that.

3. The code for deciding whether a track should loop can either be shrunken down into either way that Vitor Vilela suggested or you could alternately set it so that every track loops, but the loop point for the songs that aren't meant to loop simply loop in a completely silent part of the music file. As for the code for checking the song bank, that code can be shrunken down in the same way that the other code could be shrunken down. In addition, none of that code is necessary if AddmusicK has been used on the ROM, so you could add a define and some code for asar/xkas that stops that code from being inserted if the user sets the define to a certain value.


Additional 1: It'd be nice if you could find a way to force non-MSU-1 songs to play for certain song numbers that the user can define regardless of whether or not an MSU-1 song is playing. This could have some useful applications, where besides having the normal music play in case there is no MSU-1 song to take its place, more creative SMW hackers that don't mind that this will only work in BSNES/SD2SNES could use the MSU-1 audio and the SPC7000 music in conjunction in interesting ways (for example, instead of music, the MSU-1 could be used to play custom sound effects, like voice clips, if the MSU-1 uses a different RAM address than $1DFB to determine what to play, though as these sound effects are technically music, only one can play at a time. Meanwhile, the SPC7000 is handling the music and the other sound effects).

Additional 2: One idea to solve the volume issue is if you were to use an unused RAM address that never gets cleared, you could hijack some code during the start up of SMW, and have it check to see if the player is holding select or some other button, and if they are, load a certain value to the unused RAM address. Then, when the MSU-1 is switching songs, it will add the value of the unused address to the value from a 256 byte table indexed with the value of $1DFB (though there should be some code that will prevent the value from overflowing) so that the songs will be louder until SMW is reset. This might not be the most elegant solution to this, but it would be one way to fix the volume issue between BSNES V070 and SD2SNES by giving the player the option to make the songs louder if they're playing on SD2SNES. Plus, as a bonus, that table I mentioned earlier would give the user the ability to customize the volume of each song so that the volume of every song used is consistent without having to modify the .pcm files.

Additional 4: AddmusicK does have a few incompatibilities with this patch, so it'd be great to fix these considering that a lot of people play hacks in ZSNES and SNES9x and addmusicK is currently the primary tool used to insert custom music in SMW. It'd be a good idea for anyone using the MSU-1 patch to include non MSU-1 custom music in their hack in case the people playing the hack aren't using BSNES/SD2SNES, so making this patch work with AddmusicK would be a good idea



In addition, as a bit of feedback, you should probably include some information about the XML file that comes with the patch, as that file can cause glitches if the defines in that file don't match up with the ones the ROM uses. For example, in the file, you have the SRAM size parameter set to 2000 and the map address set to 70:0000-1fff. That's fine if the SMW hack has 8 KB of SRAM or less, but what if it actually uses 16 KB or more like mine does? BSNES will assume that the ROM has 8 KB of SRAM regardless of how much it's actually set to use, and if you have something that uses SRAM address beyond that 8 KB like the VWF dialogues patch, which uses a little over 32 KB of SRAM for its functions, then this is going to cause problems. Likewise, under the ROM tag, you have the banks set to 00-6f:8000, which will also cause problems if someone puts ROM data in banks 70-7D like I did in my hack. Plus, this would likely cause even more problems for anyone using SA-1 in addition to this patch. I think this is something you should probably mention in the .doc file you included.

--------------------
My Hacks:
Mario's Strange Quest V1.6
Yoshi's Inside Story (on hold)
Yoshi's Strange Quest V1.3 / V1.3.1 Beta 4.6 / Latest Test Build (Mario & Yoshi's Strange Quests)

Other stuff:
My WIP SMW/SMAS+W disassembly
Yoshifanatic's Discord Server: A place for fans of my stuff and/or Yoshi to chat with others.
The current patch is 100% functional on sd2snes/higan with native SMW (tested by Ikari and EmuandCo). That is what I wanted to accomplish.

But I completely understand that the community here has different Claims on how a patch should work and be compatible with your other hacks (nmi time, free space etc.). So I appreciate very much your offer to advance it and make it smwcentral compatible.

Best of luck and thanks for your help! :) :)
Originally posted by Con
The current patch is 100% functional on sd2snes/higan with native SMW (tested by Ikari and EmuandCo). That is what I wanted to accomplish.

But I completely understand that the community here has different Claims on how a patch should work and be compatible with your other hacks (nmi time, free space etc.). So I appreciate very much your offer to advance it and make it smwcentral compatible.

Best of luck and thanks for your help! :) :)



I can see what you mean, and that's fine. However, as you found out, SMWCentral has a few standards for anything submitted to the main sections. While your MSU-1 patch may have worked fine for you for what you were trying to do with it, the patch had a few major issues that would have made it less useful for anyone that wanted to use your patch in their hack or would cause problems. This patch has a lot of potential and it'd be a shame for it to go to waste due to those issues, so that's why I wanted to help out with it.

Anyway, sorry it took so long, but I finally got around to working on fixing up your MSU-1 patch as I said I was going to a while ago.

MSU-1 V1.1 Beta

Here's what I've done so far:

- Moved the hijack location from the NMI routine to within the main game loop, as the original location could potentially cause problems as Vitor Vilela mentioned in the removal log.

- Rewrote the code in the patch to make it more efficient, as the original patch was very inefficient.

- Added a table that lets the user define what songs loop and what the volume of those songs are.

- Commented all the code, so the user knows what everything is doing.

- Made the patch compatible with Asar.

- Made the patch use freespace instead of unused space within the first 512 KB.

- Added a define that allows the user to change the RAM address used to control what MSU-1 song to play. If this is changed, then the MSU-1 and the SPC700 can be used in conjunction which can open up some interesting possibilities if you write custom code that will determine what to load in the address you picked. Ex. You could use the MSU-1 for voice clips during gameplay while the SPC700 plays music and sound effects like normal.

- Added a define that prevents some code from being inserted if the user is planning on using AddmusicK in addition to this patch. However, in order for this patch to fully work, this must be combined with AddmusicK's patch.asm file like so:

Code
End:	
	CLI
	PLB
	PLP

	JSL MSU1

	JML $00806B		; Return.  TODO: Detect if the ROM is using the Wait Replace patch.

.....

pushpc

incsrc "SongSampleList.asm"

MusicPtrs:
SamplePtrs:
SampleLoopPtrs:
UploadSPCEngine:
UploadSPCData:
UploadSPCDataDynamic:
MSU1:

pullpc


And the patch has to be put in the same folder as patch.asm so that it can be inserted when the user uses AddmusicK. I haven't fully tested this out yet, but I do know that that hijack location works as that's where I put the MSU-1 hijack in my own hack.

- Changed one of the defines in the .XML file, since if the user is using the MSU-1 patch and they put ROM data in banks 70-7D, then glitches would occur when the MSU-1 is enabled in BSNES.


Despite all the improvements, there are still some things that I want to do before this can be submitted to the patch section again, such as rewriting the readme to make it more useful to anyone that wants to the use the patch and fixing a few bugs that popped up (MSU-1 music doesn't play during the credits and loading a saved game causes the SPC700 to play music while the MSU-1 is playing music).

Let me know what you (or anyone else who has been viewing this thread) think of the updated MSU-1 patch.

--------------------
My Hacks:
Mario's Strange Quest V1.6
Yoshi's Inside Story (on hold)
Yoshi's Strange Quest V1.3 / V1.3.1 Beta 4.6 / Latest Test Build (Mario & Yoshi's Strange Quests)

Other stuff:
My WIP SMW/SMAS+W disassembly
Yoshifanatic's Discord Server: A place for fans of my stuff and/or Yoshi to chat with others.
You're awesome, looks much better now. I hope your code will boost your projects. Don't forget to credit yourself in the descriptions!

I'm still quite busy with real life issues and Zelda/bszelda projects so I cannot test your hack...

only thing I noticed:
Code
MSULoop:
	LDA $2000		;\ Wait for the MSU-1 to be ready
	BIT $2000		;|
	BVS MSULoop		;/ if not ready, loop


You should enable an unused ram address here, like I did in my version. It happens on sd2snes that if it stays too long in that loop bugs may be caused. A serious bug caused by this were the black bar (but since your code isn't executed in nmi this isn't a problem) but also the wrong value was stored to $2007; so non-looping tracks were looped. So better is you enable a free ram as msu-busy flag.

Code
LDA #$01   ;set "MSU1 busy pending" flag
STA $1e00
...
checkmsuready:
LDA $1e00     ;check "MSU1 busy pending" flag
BNE checkmsuready
....
BIT $2000 
BVS end       ; if not ready wait for next frame
STZ $1DFB     ; clear new track flag, so code isn't executed anymore
STZ $1E00     ; clear msu-busy flag
end:
RTL
Originally posted by Con
You're awesome, looks much better now. I hope your code will boost your projects. Don't forget to credit yourself in the descriptions!

I'm still quite busy with real life issues and Zelda/bszelda projects so I cannot test your hack...

only thing I noticed:
Code
MSULoop:
	LDA $2000		;\ Wait for the MSU-1 to be ready
	BIT $2000		;|
	BVS MSULoop		;/ if not ready, loop


You should enable an unused ram address here, like I did in my version. It happens on sd2snes that if it stays too long in that loop bugs may be caused. A serious bug caused by this were the black bar (but since your code isn't executed in nmi this isn't a problem) but also the wrong value was stored to $2007; so non-looping tracks were looped. So better is you enable a free ram as msu-busy flag.

Code
LDA #$01   ;set "MSU1 busy pending" flag
STA $1e00
...
checkmsuready:
LDA $1e00     ;check "MSU1 busy pending" flag
BNE checkmsuready
....
BIT $2000 
BVS end       ; if not ready wait for next frame
STZ $1DFB     ; clear new track flag, so code isn't executed anymore
STZ $1E00     ; clear msu-busy flag
end:
RTL


You're welcome. :)

Anyway, I've finished doing the rest of the things I was planning on doing for the non-AddmusicK version of this patch, which I'm going to link to here:

MSU-1 V1.1


I fixed the bugs I mentioned, which were easy to fix (all I had to do was NOP out the STZ $1DFB in the NMI routine so that $1DFB always keeps its value unless the music is set to change which allows the MSU-1 to change songs no matter when the music changes). I also rewrote the readme to better explain some things for people that want to use this patch and I made it into a .txt file so that anyone who doesn't have Microsoft Word can open it. I tested it in BSNES 0.70 already and it works fine and I'll be testing it out on my SD2SNES on Thursday when I'm back home. I may have missed something though, so it'd be good if either you (if you find the time to do it) or someone else test out the updated patch.

Also, I was going to make this AddmusicK compatible, but when I tried to do that, I ran into a few problems that I currently have no idea how to work around (at least when it comes to using the MSU-1 for music while the SPC700 doesn't play music. If I don't touch $1DFB, I put a JSL to the location of where the MSU-1 routine was inserted in the location mentioned in my above post, and I instead use another RAM address to determine what the MSU-1 should play, then I can get the MSU-1 to play sound effects without issue).


As for the code you posted, I'm not sure if that will be necessary now. I'm 99% sure that the black bars were a result of the code originally being in the NMI routine, and I'm not sure if that loop is necessary since the CPU can't reach this loop unless bit 7 of $2000 is already set which is what the branch command is looking for, unless there is something I'm not getting).

As for the random values being loaded into $2007, I know why that was happening. That's because the data bank wasn't getting changed when the CPU would jump to the MSU-1 code, so the tables in the patch would pull data from bank $00 instead of from the bank where the MSU-1 code was. This bit of code fixes that:

Code
PHB
PHK
PLB
...


This would explain why you had a long series of branch commands instead of a table for determining what songs to loop and what music bank a given song uses, since I'm guessing you tried to use a table only to find out that it was behaving randomly. I encountered this problem when I tried to update this patch and it wasn't until I traced the MSU-1 code in a debugger that I found out what was going on. Before yesterday, I didn't know what that bit of code I posted did, but now I know. XD

--------------------
My Hacks:
Mario's Strange Quest V1.6
Yoshi's Inside Story (on hold)
Yoshi's Strange Quest V1.3 / V1.3.1 Beta 4.6 / Latest Test Build (Mario & Yoshi's Strange Quests)

Other stuff:
My WIP SMW/SMAS+W disassembly
Yoshifanatic's Discord Server: A place for fans of my stuff and/or Yoshi to chat with others.
I see what I can do to test your patch :)
I cannot tell anything about the code (though it really Looks very clean!) - issues might be found through playtests, where I hope I find some time soon. I unfortunately have no sd2snes and I hope the $2007 issue will not occur!

What you may also want to include is a higan instruction. For msu-1 Emulation this Emulator is best (alone given the spc-fallback), but it is for advanced users unfortunately.
Here's my msu-file for bszelda:
http://bszelda.zeldalegends.net/zips/m1_msu.zip
You find in the tutorial a description how to use higan (copy, adapt and paste it if you like) and in the bsens_higan compatibility subfolder a bml

I'd send you the bml but it is generated by higan and I do not know the size of the expanded Rom. I think this Information is crucial for higan and is different for all Projects you run here I assume.

The only part which must be added to the bml is this (after it has been created by higan:

Code
  msu1
    rom name=smw_msu1.msu size=0x0000
    map id=io address=00-3f,80-bf:2000-2007
    
    track number=1 name=smw_msu1-1.pcm
    track number=2 name=smw_msu1-2.pcm
    track number=3 name=smw_msu1-3.pcm
    ...
    ...



The track names are necessary if you like to avoid the user having to rename them (e.g., if you take Kiddo's package). Otherwise the user has to Label them track-1.pcm, track-2.pcm, etc.
Pages: « 1 2 3 »
Forum Index - SMW Hacking - Works in Progress - Super Mario World MSU1 hack

The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.

Copyright © 2005 - 2019 - SMW Central
Legal Information - Privacy Policy - Link To Us


Total queries: 9

Menu

Follow Us On

  • YouTube
  • Twitch
  • Twitter

Affiliates

  • Talkhaus
  • SMBX Community
  • GTx0
  • Super Luigi Bros
  • ROMhacking.net
  • MFGG
  • Gaming Reinvented