Enable MSU streaming music for Alttp

Full success. I disabled several different soundtracks, and the .spc played perfectly alongside .pcm audio. I tried overworld, dungeon, and SFX files, and they all played seamlessly and without incident.

I will continue playing through the game to verify all audio tracks, but if there are no more glitches, I'm prepared to call this patch 98% done. If you can ever manage to get rid of that black flicker when playing .pcm tracks and figure a way to implement a more advanced audio loop method, this will be the best Zelda hack ever made.

The only thing I can think of to improve it beyond this is to expand the ROM to a much larger size (like 6MB), move your audio code to the end of it, and change your pointers so that ANY Zelda 3 hack (like Parallel Worlds or The Goddess of Wisdom) of a smaller size can have this patch applied to them without messing up.

Awesome!
I think I cannot do anything about the flickering. This is a Hardware Problem and it has its limitations. I think Ikari isn't able to improve this as well, as I understood his post msu-data Transfer is only possible during vblank.

The patch is rather small it is 11/6880-11/6e00... I wonder if PW/GoW has data there?

I call it so far 100% at least what I can do. The master sword bug and the flickering must be solved by sd2snes Software I think (if possible).

I deleted the v9 in link above and updated since verified the official link:

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

I sent you a Version for PU per mail, SePH!

The only thing I can think of to improve it beyond this is to expand the ROM to a much larger size (like 6MB), move your audio code to the end of it, and change your pointers so that ANY Zelda 3 hack (like Parallel Worlds or The Goddess of Wisdom) of a smaller size can have this patch applied to them without messing up.

That's not a wise thing to do. You need to keep it on 4MB at max to be fully compatible to all systems. It will require custom mapping above this number.

If you want this on PW and GoW and any other Z3 hack, this Asm needs to be adopted pointer wise. The best way would be to change it from 116880-116DFF (current main code location) to 216880-216DFF, which is 1MB further. Could also be in the 150000-200000 section, so that the rom would then have 2MB.

By the way, I tested this and there seem to be 46 pointers in the code. That's a lot. Must be one complex code.

------------

I wonder if PW/GoW has data there?

I've also checked PW and GoW. This section 116880-116DFF is actually empty in both games. The question remains if the pointer-code is in place. Since this is music code and I haven't changed anything music-wise in GoW; this patch should work with GoW also. Not sure about PW, since this rom tends to have everything different than other Z3 hacks. And you would need to remove the header first on PW, obviously.

Conn wrote:Awesome!
I think I cannot do anything about the flickering. This is a Hardware Problem and it has its limitations. I think Ikari isn't able to improve this as well, as I understood his post msu-data Transfer is only possible during vblank.

The patch is rather small it is 11/6880-11/6e00... I wonder if PW/GoW has data there?

I call it so far 100% at least what I can do. The master sword bug and the flickering must be solved by sd2snes Software I think (if possible).

I deleted the v9 in link above and updated since verified the official link:

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

For me, the Master Sword 'bug' doesn't exist. I still think that emuandco has done something fundamentally incorrect with his music files, like using the letter 'O' instead of the number '0' or something.

So what it sounds like you're saying is that the MSU-1 architecture REQUIRES vblank before it can start playback. If I understand this correctly, that strikes me as a problem with the MSU-1 specification itself, which means that we'd have to get byuu to change how the MSU-1 handles data loading.

...any volunteers up for telling byuu that his baby isn't perfect and needs a change? Anyone at all...?

I've also checked PW and GoW. This section 116880-116DFF is actually empty in both games. The question remains if the pointer-code is in place. Since this is music code and I haven't changed anything music-wise in GoW; this patch should work with GoW also. Not sure about PW, since this rom tends to have everything different than other Z3 hacks. And you would need to remove the header first on PW, obviously..

In this case my hack is 100% compatible to These games, somebody may simply test ^^^

So what it sounds like you're saying is that the MSU-1 architecture REQUIRES vblank before it can start playback. If I understand this correctly, that strikes me as a problem with the MSU-1 specification itself, which means that we'd have to get byuu to change how the MSU-1 handles data loading.

...any volunteers up for telling byuu that his baby isn't perfect and needs a change? Anyone at all...?.

Sorry, you got me wrong. But I can also be completely wrong.
There's nothing problematic with byuu's bsnes, youu will not see flickering since the msu-1 data stream will not require the wait Loop.
In real Hardware (sd2snes) - this is different. And as I understood Ikari the msu data on RH can only be transferred during vblank. This is a Hardware and no Software Problem and can't be fixed.
However (unrelated) I wonder why the master sword works for you and not EmuandCo... maybe you have a more updated Software on your sd2snes?

Conn wrote:In real Hardware (sd2snes) - this is different. And as I understood Ikari the msu data on RH can only be transferred during vblank. This is a Hardware and no Software Problem and can't be fixed.
However (unrelated) I wonder why the master sword works for you and not EmuandCo... maybe you have a more updated Software on your sd2snes?

So it actually has to do with how the SNES itself handles data presented by the SD2SNES, not the SD2SNES by itself? I think I see.

Well, I'm using the newest SD2SNES firmware, which was released yesterday (0.1.7 preview 3), but before that, I was using 0.1.7 preview 2, which didn't have any problems either. I couldn't begin to understand what's going on with emuandco's music.

Yes -This is how I understood the comment by Ikari you posted.

Sorry but that’s lazy programming on the hack side Wink It doesn’t have anything to do with audio looping, what he is referring to is the SNES CPU loop that waits for the sd2snes to open the audio file and fill the playback buffers. bsnes just STOPS SNES emulation while preparing the audio file which is obviously something the sd2snes cannot do. I don’t know why it is necessary to blank the screen while waiting for the MSU to respond. It might be a better choice to implement a per-frame state based polling if forced blanking is a must during the ISR.

Anyways, I ported the code to bszelda is somebody is interested... but not yet tested:
http://z9.invisionfree.com/bszelda/index.php?showtopic=1504&st=0&#last

I wonder - is it at all possible to use common audio for MSU-1 Zelda hacks? It seems so wasteful to have ROM-specific .pcm files for all these different hacks - it would be so much cleaner if you could have all the Zelda 3 hacks in the same directory, have all the audio files be named something like 'msu_zelda3-1.pcm' and so on. As it is, my audio files take up 589MB on my SD card, and basically replicating the same files with different names would get very wasteful very quickly.

Only those who have a sd2snes can answer your question. As far I understand though, all tracks must be named with your Rom Name. Means you can simply rename your hack and that's it. However, you will loose your srm Progression.
But SD Cards, do not cost anything anymore. Why don't you simply buy a Card for every hack :p

I just traced the start Screen flickering. It seems to be sprite related, e.g., when the flute bird is on the Screen and you press start it flickers very much. I also was able to trace the ram address, in case of the bird it is 7e/0c4e:27
Resetting it to 00 will make the flickering vanish, unfortunately also the bird, so I'd Label this bug for now as not-fixable. This however is Little only so I tend to say "so what".

Well, the flickering only really occurs in the overscan area anyway, so it's a bug, sure, but decidedly harmless.

As to buying SD cards, yeah, I COULD, but I'm less interested in a 'workaround' and more interested in an elegant solution. It just irritates me as an engineer to basically copypaste the same data over and over just to make 2MB of ROM select it.

I use 0.1.7 Preview 3, too. And you can try my music, if you want. As I said, I use the Original ones as base, then copy ZREO in it and after that the K.Kondo tracks. That collection has NO duplicate tracks for castle/Master Sword at least. Will try again later at home. But that will still take a while. I have a schooling later till 9:30 PM

It would be so much cleaner if you could have all the Zelda 3 hacks in the same directory, have all the audio files be named something like 'msu_zelda3-1.pcm' and so on.

Yes, however this is not happening. As far as I know Bsnes is specifically programed to have one folder per one game, and everything in it has to have the same name but different file extensions. It is because of that, that the external files can be loaded at all, like Xml mapper and obviosuly all the individual tracks, which makes Msu possible. I guess it is the same with sd2snes.

It just irritates me as an engineer to basically copypaste the same data over and over just to make 2MB of ROM select it.

That's the irony of it. 2MB of base to select hundreds of MB additional data (just for the sound).

One bug found. In Dark World Dungeon 4 (In Kakariko Village), the Boss Music does not play when the battle with Blind the Thief begins. I didn't check the map during the battle, but I bet that either the volume is set to zero, because the .spc file didn't play either, or there is a missing 'start playback' due to the fact that unlike most other boss rooms, the battle with Blind does not begin as soon as you enter the room.

Fixed this:
http://bszelda.zeldalegends.net/stuff/Con/zelda3_msu.zip

(sent updated pu Version to SePH)

I fixed the flickering bug:
https://www.zeldix.net/t385-original-alttp-bug-fixes

Wrt the discussion of inefficient .pcm storage, unless we get some way to navigate the filesystem on the sd2snes from within a ROM, I don't think there necessarily is an elegant solution. Though, as it stands you at least have the ability to customize the soundtracks for each hack.

mwreichelt wrote:Wrt the discussion of inefficient .pcm storage, unless we get some way to navigate the filesystem on the sd2snes from within a ROM, I don't think there necessarily is an elegant solution. Though, as it stands you at least have the ability to customize the soundtracks for each hack.

The question that is in my mind is, when the MSU-1 looks for the .pcm audio, how does it know what filenames to use?

In the case of alttp_msu.sfc, does it look for 'alttp_msu-X.pcm' because it's using the filename of the ROM itself, or because it's told to look for a specific string? IE, could 'alttp_msu.sfc' be told to look for files named 'MSUZelda-X.pcm', or is it locked to the ROM filename?

The question that is in my mind is, when the MSU-1 looks for the .pcm audio, how does it know what filenames to use?

I suspect it  is based off the name of the folder; failing that that, the .msu file. To be honest though, I have no idea.

Welcome here mwreichelt

I updated with the blind bug fix if you do not know yet, will post on your Forum as well.
Any more bugs found? Or can we eventually open a beer?

As for the flicking fix I also posted. I dunno whether it covers all. But try it. Call a bird, Transport and press select (Major flickering), press start while the bird is on Screen and it will flicker as well - both will be fixed by applying the hack.
But I really can't know whether all flickering issues are solved by this, so some more testing would be required.

The 'flickering' fix does not seem to work on real hardware. The flickering is still there. I'm going through the game to find any more potential bugs - I need to beat Blind again to make sure.

ok... mmh, can you check the flute? When you Transport and press select after deported (best while the bird is on Screen) there is Major flickering.
If you still have flicker at this place, there might be again some Problems with your Rom (then maybe also the blind bug fix will not take effect).
If you Encounter more flickering let me know how and where you Encounter, and maybe check with snes9x or zsnes.

Edit: oh, due to the limited bsnes debug Feature, I can only fix flicker occuring in snes9x. The posted patch so far fixes only the flute flicker. As said, describe where else and how flicker occur in snes9x and I try to fix then ^^

Yeah, I've tried the flute flicker - it doesn't work. The flicker is identical to the flicker on the 'Start Screen', in placement on the screen, in size (3 horizontal pixel lines), and in frequency of the flicker.

The Blind fix works great. And boy, do I hate that fight.

how straange... well, on Emulators this fix works.

Cool ^^ so I wait for the green light to post the patch :p

Well, snes9x is not a terribly accurate emulator.

Conn wrote:Fixed this:
http://bszelda.zeldalegends.net/stuff/Con/zelda3_msu.zip

(sent updated pu Version to SePH)

I fixed the flickering bug:
https://www.zeldix.net/t385-original-alttp-bug-fixes

Just wanted to make sure, but I should be applying all the patches from this post, right?

I've played around with it for ~30 minutes now, just wandering around and then playing the beginning of the game up through arriving at Kakariko. It's everything I always wanted my patch to be! The only bug I noticed was the flickering which, as mentioned previously, is very noticible and happens every time a .pcm starts to play. For me at least, it takes up the whole screen, but it seems like Retromancer only gets a small flicker of a few rows of pixels? I'm currently on a slightly older version of the firmware than he is, so that might also be the problem. I'll continue to poke at it, but I'm sure the flickering is surmountable.

Just finished the game. I applied all the bugfix patches, and all the ones I was able to test worked fine (aside from the flickering).

After the fix with Blind, I didn't knowingly encounter a single bug. I'm going to restart the game from the beginning and do another complete playthrough, just to make sure (and I'm going to do my best to do things out of order), but I think that we have a final product here!

@mwreichelt - you misunderstand - there are two separate 'flickering' issues I discuss. The 'flash of black' across the whole screen when a new track begins is endemic to the SNES itself, and apparently cannot be corrected at a software level (I would LOVE to be proven wrong, though). The 'top-of-the-screen' flickering occurs in a very few situations: On the inventory screen, after pressing 'SELECT' to "Save and Quit" or "Continue", and a very few rare instances aside from that.