Enable MSU streaming music for Alttp

Anyone who has downloaded any version of my audio pack previous to right now (12:00 am, 10/23/14) should re-download it once more - I had to correct the 2nd Ending volume.

Hello

TheRetromancer wrote:Okay, using this with SD2SNES is super easy.

I made a custom folder in the main directory called 'MSU Zelda'.  In this folder, you'll need to have your expanded, patched Zelda ROM, and you should rename it to 'alttp_smu.sfc'.  In this same directory, you'll need the 'alttp_msu.msu' file and the 'alltp_msu.xml'.

Actually the xml file isn't even required, the sd2snes enables MSU1 when a <romname>.msu file is present. Likewise it will ignore any bml file - the audiotracks are always expected to be named <romname>-<number>.pcm.

@Conn: Thank you for your effort! I presume the flickering appears because the loop waiting for the MSU1 audio busy bit to clear is wasting too much raster time? I know nothing about the technical details of your hack OR ALttP but if the waiting loop is inside the NMI routine, consider placing it outside so at least you don't run into VRAM/OAM/forced blanking issues.
If that's not an option, maybe you could just check the busy flag once per frame, enabling playback if it clears, otherwise doing nothing. You'd probably need a byte of RAM to keep track of the player state then.

@qwertymodo:
many thanks; I put your text and bml (without the track list) into a subfolder of the patch "higan_only".

@EmuandCo
I remember I looked at LB's DKC2 asm and found a mistake. If you post it again, I can check it again.

@Ikari:
This is unfortunately not possible from the coding side... mwreichelt's attempt was to use a single global code to handle the msu - whenever a track was stored to $2140. but it was very Buggy
My (more successful) approach was to play msu whenever a track was stored to the Music control $012c. This has the Advantage that the other addresses that are involved in Music, $0130-$0134 are handled automatically by the code, which is not the case when using the global hook at the store $2140.
So in Zelda3 it seems like no way leads around to make a hook for each theme loaded. Unfortunately, as each store to the Music control $012c is at a different Location, the conditions are different for each theme (nmi etc...); therefore you have flicker on some tracks while not on others.
The Problem is that each store to the Music control happens only one time. involving a ram Byte to check at a later time whether the Overflow flag is clear to stream Music might do the Job but appears to be very complicated... and again with uncertain outcome.
I might have an idea, but dunno whether it will work. It's about time and effort and I don't know how much I want to spend more on this hack.

I see... unfortunately it cannot be solved from the sd2snes side as it is "natural" behavior and the reason the busy flag exists at all. The hardware needs some amount of time to open the audio file and fill the playback buffer.
On the contrary, bsnes just halts emulation until it has opened the audio file, so there is no delay perceived by the SNES program. Maybe it would be wise for bsnes/higan to introduce a ~50ms delay before clearing the busy flag to be closer to reality.

If the track number is always logically stored in $012c, there should be some other routine that picks up the value and actually changes the track accordingly. Kind of "between" $012c (written in many places) and $2140 (maybe used for other purposes at times, like sound effects). This might actually be what you are referring to in your last paragraph. That is probably the most promising location to hook into... but I won't babble on about that since I know nothing about the internals of ALTTP

Well, there is a good (and probably the only Chance) that I fixed it:
http://bszelda.zeldalegends.net/stuff/Con/msu1_sd2snesfix_try.ips

The difference is that I made the bit$2000-bvs$fb Loop (check for Overflow clear) when it is naturally cleared in the game. The address where it is checked is read every Frame. Dunno whether it works though, Needs to be carefully tested in sd2snes.

Unfortunately, none of the MSU audio plays on this newest patch.  Whenever a track should be loaded, there's a brief noise like it's trying to start playback, but it doesn't actually play.

This noise is most significant when using the flute to warp to another area.

That's... unfortunate but not yet all is lost . maybe there's a last Chance; with making the bvs Loop at a place with Little negative effect.

Here I'd Need your advice, Ikaris. What is best to check to execute the bvs Loop? Like checking nmi, vblank or whatever and if conditions are best, execute the Loop.
Can you maybe give me the asm of what to check and at which condition to run?

Helpfull would be something like this (e.g., vblank check if this has something to do with it):

vblankcheck:
LDA $4212
AND #$80
BNE noloop ; if in vblank state, don't execute Loop

overflowloop:
Bit $2000
BVS overflowloop ; Loop that cause flicker when execute at wrong conditions

noloop:
; here the Routine continues until the next Frame to check the conditions

Normally the flow would be like:

Code:

REP #$20      ; 16-bit accumulator
LDA #trackno
STA $2004
SEP #$20      ; 8-bit accumulator
busyloop:
BIT $2000     ; copy $2000.7 to N flag, $2000.6 to V flag
BVS busyloop  ; loop until $2000.6 is 0 (audio busy bit is cleared)
LDA #$03      ; Play audio, repeat=on
STA $2007     ; start playback


EDIT: Oops, sorry, I misread... I thought you had posted actual code at first, sorry. I'm going to post another snippet as a proposal.

Yes, that's similar to the code how I have it, and it is of course only executed when a new track is requested.

I only Need a condition to check where it is best to execute the busyloop, like when nmi is or vblank is or is not not or whatsoever causes less flickering. And therefore I'd Need the best condition to execute the Loop.

My vblank Loop was only to Show you an example of a condition I request from you; it is of course not part of the code

edit: ah saw you edited and got me right

Here's my proposal for "lazy" busy checking. All you need is a byte of RAM and some routine that is periodically called for checking the busy flag. Consumes virtually no time because there are no waiting loops at all.

Code:

; needs one byte of temp RAM

; ====== at init ======
LDA #$00       ; clear internal playback status
STA @$7FFFE0   ; don't know if this address is free ;-)

; ====== at the playback hook (wherever it may be) ======
; 8-bit accumulator is assumed
LDA #trackno   ; (assuming the track number is 8-bits)
STA $2004      ; set track number low byte
STZ $2005      ; set track number high byte (0)
               ; and trigger track request; busy flag goes high
LDA #$01       ; some internal status value
STA @$7FFFE0   ; save internal status as "audio request pending"

; ====== somewhere else, e.g. NMI routine ======
; needs to be called periodically
LDA @$7FFFE0   ; load internal playback status flag
BEQ nowait     ; if no pending request, do nothing

msu_pending:
BIT $2000      ; else: check busy flag
BVS nowait     ; if still busy, check again next frame

msu_ready:
LDA #$00
STA @$7FFFE0   ; clear internal playback pending flag
LDA #$03       ; set playback attributes: PLAY + REPEAT
STA $2007      ; finally start playback

nowait:
JMP @back_to_game

Already had this Byte at $0129 (free ram); only needed to know when it is best to execute the msu-pending to not cause much flickering

ok...I try to shift my code into the nmi Routine.

OK. And no looping on the BIT/BVS The check will repeat itself in due time when it's called in the NMI.

ok... check this out :-/

http://bszelda.zeldalegends.net/stuff/Con/msu1_sd2snesfix_try2.ips

HUGE improvement! Now there is just a very brief 1- or 2- pixel horizontal line in the middle of the screen that flickers upon playback, as opposed to a full screen flicker! Still noticeable, but hardly anywhere near as irritating! There is a slight 'click' sound, though, right before the track plays.

This is...an unbelievable step forward.

err, how can you test this all in 3 minutes?! Incredible!

I think the rest Little flicker can't be anything done about... I'll do a short check what may cause the click, if you like you can test some "sensitive places" like digging game or such...

I hope I can get around to testing this myself soon.

First bug has appeared.  When in a Mysterious Pond location or the Pond of Happiness, the music that plays when the Great Fairy appears is the 'cave' music, not the 'Fairy' music.

I'm going to double-check my .pcm to make sure I didn't accidentally mis-name one of them, but be aware.

And I'm on vacation today, and playing SNES is how I relax.  My PC and entertainment center are less than eight feet apart.

Digging game audio works fine.

EDIT: In fact, it seems that everything except for that weird 'Fairy Pond' music bug, everything is just about perfect. I wonder if there's any way to relocate that 'flicker' to the very top of the screen? It would be even less noticeable than it is now. If we could reliably fold that into the 'overscan' area, I'd call this patch the Ultimate MSU-1 Zelda experience.

ok here's the fairy Pond fixed Version; I also tried to do something about the click but dunno whether this helps.

http://bszelda.zeldalegends.net/stuff/Con/msu1_sd2snesfix_try3.ips

No, there's almost nothing to do with the rest flickering, pls try to live with it

I can live with the flickering, considering that it's literally 1/80th the size of the original flicker. 8)

The music glitch is fixed, but the 'pop' sound still remains. I'm totally okay with calling this as perfect as it could possibly be. Conn, you and ikari_01 astound me. Also, many thanks to mwreichelt, without whom this would not be possible.

EDIT: *sigh* Another music bug. Now, dropping into Ganon's room causes the normal 'boss' music to play (track 21), where it SHOULD be the 'face-to-face + Ganon's theme' (track 30).

I'll take care of it. Could you briefly check this?
http://bszelda.zeldalegends.net/stuff/Con/msu1_sd2snesfix_try4.ips

if the Music will click?

It doesn't 'click', but when it loads new music, the old music stays onscreen a fraction longer (it doesn't really fade-out), and then rapidly increases in volume. Essentially, the 'click' is still there, it's just replaced by a burst of music. This only occurs when going from inside <-> outside (both directions), or transitioning between two overworld locations where the music changes (DW Kakariko<->DW Skull Woods).

I'm uploading a youtube video to showcase this.

At first glance, this appears to be working in conjunction with Parallel Worlds, but I'll have to play through the whole thing to verify... either way, I'm really happy about it

ok, I just wanted to ensure whether it is a spc or a msu Problem, therefore I didn't mute it in that try. But if the click is still there it is a weird spc Problem.

So where does the click occur? Only when transitioning Screens or also leaving a house?

It occurs in both instances. My Youtube video isn't able to showcase this bug - it's too fast/quiet to pick it up.

Well, no worries. Nothing I can do about anyways... so we Need to live woth the click


Ganon should be fixed
http://bszelda.zeldalegends.net/stuff/Con/msu1_sd2snesfix_try5.ips

Can you make a more or less thoroughly test whether more unexpected bugs occur