Enable MSU streaming music for Alttp

Are trackerless BitTorrent links ok? That seems the ideal way to distribute these massive packs of PCM audio. No ads, no tricks, and high speed, provided by the community.

The problem is that torrents are connected with all sorts of "unwelcome" data transfers and are based on the number of "seeders", so this will not work here.

But there is no need of finding different ways, since the main files are on DB already and the MSU is a special case. Usual shortcuts connected with romhacking contain much less data.

You can also regard the ASM only as the main data to be downloaded, the media files can be acquired separately by the users. Since with MSU I can add any audio music to the game.

mega.co.nz did not add the ad.fly. If you hover over the link, you can see that the board is actually pointing there, but when I created the post, it was a direct link to mega.co.nz, and if I edit the post, it's still a direct link. If you copy/paste that link, no ad.fly. The ad.fly redirect was created by the forum upon posting.

I think this is more a philosophical question. It is the combination: of course you made a direct link, but when you post it on the forum of any kind, the add will "fall in" because of the combination between the post and upload host.

If you link to megaupload, mega fire, rapid share, it will always add it; if you link to Zebucket, it will not.

How's this for a download link? I still don't like using cloud hosting for file hosting, but Google Drive probably doesn't have bandwidth restrictions like Dropbox...

This shortcut seems beter. Will leave this one.

Puzzledude wrote:

How's this for a download link? I still don't like using cloud hosting for file hosting, but Google Drive probably doesn't have bandwidth restrictions like Dropbox...

This shortcut seems beter. Will leave this one.

Thanks, I'm not trying to break the rules... just trying to find something that works, and Dropbox doesn't work for me.

if you added new sprites to the game, just added new ones, THATS IT, and this would be perfect, I have been wanting a remastered and fresh version of link to the past, and that would do it.

zorazer0 wrote:if you added new sprites to the game, just added new ones, THATS IT, and this would be perfect, I have been wanting a remastered and fresh version of link to the past, and that would do it.

This is easily done by users with just about any graphics-replacement tool available.

Is anybody willing to test some modifications to this patch?  Right now, I'm trying to clean up some of the redundant code, and as I'm still not super familiar with all of the working parts, I may have naively removed some of the code that was implemented to fix one of the specific bugs reported here.  If anybody is willing to test this out for general functionality, as well as testing out the specific bugs that were reported earlier and fixed (Blind, great fairy... ??), I'd really appreciate it.  The patch was created against the unmodified, unheadered, un-expanded ROM.

http://www.bwass.org/bucket/alttp_msu.ips

Also, here's a thought for file uploading.  I see the board supports file attachments for a lot of various file types.  Any chance you could add .ips to the list of allowed file types for attachments? That might work really nicely, especially for WIP threads, so you could attach the .ips directly to a comment where you describe changes made in that particular revision.  If not, you already allow .zip, so I might just zip up my .ips and attach it that way next time...

cannot dl from the link... did you remove all those jsl I suspected not needed?

Forbidden

You don't have permission to access /bucket/alttp_msu.ips on this server.

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

better is to zip the files

That's weird, it downloads just fine for me, it's a direct link...  but yeah, basically I just deleted most of the extra NOPs and the jsl hooks, except for leaving $0AB940->$22EB00, $02FFD0->$22EB90, and $06C621/$06C847->$22EC80.  Like I said, a naive hack job for now, but I ran around for awhile and everything I've tried so far has played (though I'm only halfway through the Tower of Hera), so I'm fully expecting that I broke something in the process.  If not, that alone was a pretty significant code reduction, I may not actually need to do more than that, but next up I do want to find some empty space inside the native ROM to relocate the code so it doesn't have to be expanded (I'll have it easily switchable with a define switch so you can keep the code in the expanded section for compatibility with other hacks).

Edit: I just noticed I made 1 mistake in the .ips I posted above. Try this (and hopefully this link works)

http://www.bwass.org/bucket/alttp_msu.zip

I can't still download it. Well, you can send me the patch to con.@gmx.de I will look through it.

You see, I did immense hacking work with all my patches previously published and therefore all free place in the native rom is gone if this patch shall be compatible with all my other work; which I do, so such a patch would cause Problems by overwriting some crucial data of my other works... but you're free to develop it of course.

All the cleaned code will not have an effect on the current debugged gameplay but it is important for other People trying to hack the msu... so I leave the current patch in the main download as it is, Independent whether your code works or not, but for developers your work truly will be important

Check your permissions and adblocker - I have no difficulty downloading it.

dunno... can you simply send it per mail to me, TR?

Conn, I understand your wishes for this to remain compatible with your other patches. I plan to add the equivalent of an #ifdef switch (can you tell I'm primarily a C++ guy?) which will switch the locations of the code to either fit inside the native ROM or in the expanded section. That way, if, say all I want is MSU-1 + death counter patch, I can do that without expanding the ROM (assuming there's actually enough room in the native ROM for just that, I haven't checked yet). There's a specific reason I want to do that which I mentioned in my PM that I don't necessarily want to announce publicly just yet, but I'll definitely leave a way to easily switch the code locations back into the extended region. Having labels on all of the jsr targets makes that really easy to do.

There's plenty of space in the native Rom which should provide enough space for your hack
03/f8A0-3f/ffff
07/fe80-07/ffff
0d/b1e0-0d/b7ff

But as said, all this space is taken by other code from me, so I have no use for it. In the end I am sure, it won't be a Problem whether the hack is to be applied on a 1MB or 1.5 MB Rom. I think if you simply apply the hack even without expanding the Rom first will still Play it, since lunar.ips automatically expands the Rom (though it is better to use lunarexpand because of the ingame Header adjustments).

Still haven't received your hack...

Sent you the PM. And you're correct about Lunar IPS expanding the ROM if you haven't already (though it only expands it to the end of the actual code). My point is to retain the 8MB file size, because that will make my next project much easier.

Announcement. Due to a lot of work done here, SePH has promoted the users: TheRetromancer, qwertymodo and mwreichelt into the group: Music Artists. Congratulations, you can now see more topics, have more rights etc.

@TR I love watching your Videos, but your 4th has technical Problems at the end... are you going to create further ones?

Mh, for TR Music Artist fits well. For mwreichelt I'd suggest "Rom hackers" as he has nothing to do with Music but published a code which I ported into my hack for sd2snes Support.
For qwertymodo, maybe both fits. He's not as good in asm but makes big Progress. But also he linked to an own made pcm Music package so I dunno.

And me? ^^

mh, neither Music Artist nor romhackers would fit. Maybe we Need a new category "game/bug testers"? Also Tompala and all the others who helped with the PU beta could be added.

Tompala is already a founding member.

Alright Ive renamed founding members into VIP members and moved mwreichelt there and added emuandco!

That should do the trick.

Hey Conn, I've been playing through with the volume and MSU patches and so far everything has been good and complete. The only thing I've noticed with the volume adjustment patch is after picking a destination to fly to with the duck, upon leaving the map, the volume is back up at 100% until I perform another action to reset it (open/close map, enter a house, etc). I guess there's yet another place in the code where volume is set.

Might just be better in the long run to edit the music files themselves. To do it, open the .pcm in a hex editor and copy the loop point at bytes 5-8 and save them somewhere. Now open Audacity and select Import>Raw Data>select your file>Signed 16-bit PCM, Little endian, Stereo, offset 8 bytes, 100%, 44100Hz. Now, select Effect>Amplify, and select your amplification level. You might have to play around a bit to find the right level, but -5.0dB worked for me for the ALBW soundtrack. I'm not sure what level TR's tracks are set to, hence the fact that you'll have to try a level and find out. However, since TR did the work of matching the tracks to each other, once you find a good level, you should be able to just use the same value for all of the tracks. Now, export audio as wav, then use wav2pcm to remove the wav header and replace it with the msu header. Finally, replace bytes 5-8 with the loop point you saved earlier, and you're done... just gotta repeat it 33 more times.

Thx SePH ^^

This is very nice. I want this in my hack!

@donkeykong, thanks for finding this:
116B0B: a9 60 8d 0620 // return from flute map to normal game the 60 now should do the trick.

I updated the volume_decrease ips, so please redownload and reapply that patch from
http://bszelda.zeldalegends.net/stuff/Con/zelda3_msu.zip

Is the Video volume ok? There are no sfx but it might also be necessary to lower the volume Level there as it is as well at full.

Hi, figured I should stop by and say thanks to you all for working on this patch! It's always very exciting to see people doing new and innovative things with the SNES. I was especially impressed that not only audio, but video was added as well.

To cover some earlier points:

If the volume of the pcm is too loud, you can adjust the volume with a hex editor in the rom here.

My understanding was that the cartridge audio pins were mixed after the digital output from the SNES DSP, and thus I mix the raw samples. Yet if the MSU volume is significantly higher under emulation, I can certainly apply an audio adjustment inside the emulator.

Immediate automatic saving cannot be supported for MSU1 games because the MSU1 interface doesn’t support any sort of flow control. Byuu ignored my concerns.

I don't recall this ever coming up, but I would never intentionally ignore ikari's concerns after all the help he's given me (sd2snes, SuperCIC console mod, etc).

In this particular case ... the sd2snes saves your game every few seconds by writing the SRAM contents onto the SD card. What ikari needs is a flow-control that will let the sd2snes disable the MSU1 data/audio access while it writes the SRAM data, and then let the SNES continue.

But this isn't really possible. An audio track basically streams non-stop, and data can potentially stream for up to 10s with a single DMA request in the most pathological case, and the video players are so tight on timing that even a short blocking operation could cause video desync.

So there really was no way around this from the MSU1 design. My idea would be to have the boot loader of the sd2snes copy the SRAM contents to the SD card on the SRAM slot for the last previously played game at startup. This should work so long as ikari's SRAM is connected to his CR2032 battery (which it should be.)

There might be a reason why this is not doable on the sd2snes design, however. But it's true, I certainly didn't design the protocol with a flash cart that copies saves onto the SD card periodically in mind. So, my apologies that this is causing some trouble.

But bsnes 0.75 is much more user-friendly and I guess most People prefer this Emulator (as I do as well), which however does not Support the spc-fallback, thus they have only silence when they warp.

While I certainly don't mind or blame people if they don't like certain changes to my software, it is very annoying when future features have to be ignored due to people sticking with older versions.

I am also currently talking with ikari about a possible audio resume feature, and I suppose people would be similarly worried about that, so ...

We could patch v075 to have the new MSU1 features very easily. The actual MSU1 code is only 4KB, and most of that is boilerplate.

The file naming part though, yeah. I don't see the sd2snes ever gaining a BML parser. So for maximum ease of use, you're going to want to specify the file names the sd2snes expects inside the BML file (and again, if you want to target a four-year old release of bsnes, also include an XML file.)

Longer-term ... something I wanted to do/see happen was have some sort of "msu-tool" program. It'd take an "msu-pack", plus a ROM image (Zelda 3.sfc in this case), and output a folder with the game in whatever format you wanted (sd2snes, bsnes, higan, future emulator that decides to do things differently.)

With the really nice part being that the "msu-pack" could store the video in MKV format, and the audio in MP3 format. Thus making the download drop from 600MB to 40MB per game. The "msu-tool" would decompress, add the loop points, convert the video format, etc. Would lose a bit of quality, but then *most* people are using compressed source video/audio anyway. Just haven't had the time to make it.