Video update

Just read that my Zelda3 video is now mute on sd2snes 1.7 (at least some have these problem while other not)
http://krikzz.com/forum/index.php?topic=5124.75

(at least for some; read this also on RetroDan's youtube channel):

Cjaj Jajcvor 1 Monat (bearbeitet)

Nice, had it on my sd2snes but now in firmware 1.7b the video is now mute due to ikari updating the msu1 to latest higan/bsnes standards. It was working beautifully but Ikari stated that MSU1 was not setting the volume properly so in the latest 1.7b firmware music works but video is now muted due to the volume being set incorrectly before. Ikari said something about the patch needing to be updated because of this. Topic is here the firmware 1.7b release: http://krikzz.com/forum/index.php?topic=5124.0

Ikari wrote:
This change is responsible: https://github.com/mrehkopf/sd2snes/commit/412127ed5f71848490c0ac73486f0348d44ae619

It was made by byuu's request more or less. The purpose is to have bsnes/higan and sd2snes work the same in terms of MSU1. The MSU1 spec states that the volume has to be 0 initially and must be set by software - so the change was a bugfix strictly speaking.

Unfortunately my (very old) demo player - which has been used in a number of places - does not set the volume correctly so it remains silent now. My apologies! I'll prepare an updated version of the player. You can "install" it by just replacing the .sfc files of the MSU1 video demos with it. The Zelda patch would need to integrate the updated player code however.

Since I still have no sd2snes, qwertymodo or anybody with a sd2snes, can you help me out? I also do not know which registers must be set to 0... 2006?... There's also the name select music before (which should work), so do I need to reset the volume registers?

Also I didn't have heard any complains for bszelda, which uses the same video code, ... and it WORKS on firmware 1.7 without issues, as qwertymodo tested... so I am confused (maybe Ikari solved this already in a new firmware without needing me to adjust the patch again?).
Can somebody maybe test my alttp hack (updated with new music settings) whether the video is played correctly?
http://bszelda.zeldalegends.net/stuff/Con/zelda3_msu.zip
(apply both patches alltp_msu1.ips and optional_video.ips on expanded (1.5MB) alttp w/o header)

BSZelda Video test with firmware 1.7

Look at that commit, it's pretty straightforward. He used to initialize $2006 to $FF, now it initializes to $00. All you need to do is set $2006 to $FF in your code before you begin playback.

This is actually how the code is set, in the video playback code I have a LDA #$FF - STA $2005 (well, now that is at LDA #$60 because of the boost but that doesn't matter I think).

It is strange however... one or two people reported this (also on RetroDan's channel). While on Ikari Forum, one reported this mute with zelda3, while other said that my zelda patch fixes the problems in other games (since it sets the volume).

Ah well. If you have the time I'd appreciate a short testing with my new hack (where I set the volume level to 60)

Well, there's your problem. $2005 is the track # MSB. Try sta $2006.

No sorry, just a typo, of course 2006 was meant... I am not that stupid

*bug... short test... *bug

Here's a snipplet of the tracelog:

$23/F5B0 A9 60 LDA #$60 A:0501 X:201F Y:3F80 P:envMxdizC
$23/F5B2 8D 06 20 STA $2006 [$0C:2006] A:0560 X:201F Y:3F80 P:envMxdizC
$23/F5B5 9C 07 20 STZ $2007 [$0C:2007] A:0560 X:201F Y:3F80 P:envMxdizC
$23/F5B8 A9 23 LDA #$23 A:0560 X:201F Y:3F80 P:envMxdizC
$23/F5BA 8D 04 20 STA $2004 [$0C:2004] A:0523 X:201F Y:3F80 P:envMxdizC
$23/F5BD 8D 30 01 STA $0130 [$0C:0130] A:0523 X:201F Y:3F80 P:envMxdizC
$23/F5C0 9C 05 20 STZ $2005 [$0C:2005] A:0523 X:201F Y:3F80 P:envMxdizC
$23/F5C3 2C 00 20 BIT $2000 [$0C:2000] A:0523 X:201F Y:3F80 P:envMxdizC
$23/F5C6 70 FB BVS $FB [$F5C3] A:0523 X:201F Y:3F80 P:envMxdizC
$23/F5C8 A9 01 LDA #$01 A:0523 X:201F Y:3F80 P:envMxdizC
$23/F5CA 8D 07 20 STA $2007 [$0C:2007] A:0501 X:201F Y:3F80 P:envMxdizC
$23/F5CD A9 F1 LDA #$F1 A:0501 X:201F Y:3F80 P:envMxdizC
$23/F5CF 8D 40 21 STA $2140 [$0C:2140] A:05F1 X:201F Y:3F80 P:eNvMxdizC
$23/F5D2 8D 33 01 STA $0133 [$0C:0133] A:05F1 X:201F Y:3F80 P:eNvMxdizC
$23/F5D5 60 RTS A:05F1 X:201F Y:3F80 P:eNvMxdizC

Hmm... weird. I tried it, worked great. Tried it again, muted. It's only in the video playback, the audio soundtrack is fine, both the title screen track and then afterward in-game.

Oh wow, this is getting mysterious. I do not think this is a problem of my patch but of the new firmware. I pointed Ikari here; maybe he is able to source the bug out. My best guess is that a register is not reset if you hit reset button on snes (only on power off). But yes, this is only my best guess.

Thank you for testing

The problems seems to be unrelated to the initial volume register value change, my current guess is it's a kind of race condition because track 0 and 35 are requested in rapid sequence.
The request for track 35 might be lost while the request for track 0 is handled. However so far I haven't been able to reproduce the issue. I guess it depends on SD card speed, further investigation is underway.
Are there any differences in occurrence between firmwares 0.1.7, 0.1.7a and 0.1.7b?
Can you copy any other PCM track to alttp_msu-0.pcm and see if it plays instead?

There is no track 0.  The stz $2005 is just clearing the MSB since it's in 8-bit mode at that point.  I'll look into it more when I get the chance to disassemble it.  For one thing, you're using $0130, $0133, and $2140 in a weird way, but I need to check my notes before I can comment on a better way.

Yes, I use many flags, I must also admit that my coding wasn't very clear (try and error, since it was the first msu patch).

What I can also think (but this is maybe a weird idea). I set a flag for fade out to 7e/e004. This is set whenever you leave a building to the volume level (60)and decremented with each nmi until it gets 0 (so the fade-out lasts 1 second), while it is decremented it saves its value to $2006.
So my suspicion is that the initial ram value is different than zero when switching the snes on (snes9x sets it to 55). Means, maybe this initial value is stored to $2006 with the very first nmi, and this makes problems with your setup, Ikari? I do not know whether it is mandatory that firmware 1.7b starts with 00...

@qwertymodo
There is no track 0 indeed but still the hack requests track 0 (m=0; stz $2004) just before requesting track 35 (m=1; lda #$23; sta $2004; stz $2005).
(By "before" I mean time-wise, not necessarily program counter wise, I'm going to grab that from the logic analyzer if it's of any interest)

@Conn
The volume register contents are applied immediately, it "lives" in the FPGA entirely with no need for interworking with the microcontroller. So it can be clobbered all you like without any adverse effects.

ikari_01 wrote:@qwertymodo
There is no track 0 indeed but still the hack requests track 0 (m=0; stz $2004) just before requesting track 35 (m=1; lda #$23; sta $2004; stz $2005).
(By "before" I mean time-wise, not necessarily program counter wise, I'm going to grab that from the logic analyzer if it's of any interest)

Ah, ok. I was just going off of Conn's code snippet, I haven't had time to disassemble/trace anything else.

Seems like this turns out to be one of such ghost bugs I love. If you cannot reproduce it, Ikari, the only chance might be that qwertymodo tries to find the trigger (soft reset, playing, whatever). If the initial volume set to 0 isn't responsible, it could also have something to do with the msu-boost (unreliable if at the same time a video is streaming or something). I do not know

Conn, do you have the original asm code available, or did you write it all in hex? That would make it a lot easier for me to look into it. If not, I will still take the time to dig into it, this week just hasn't been a good one for that kind of thing (ADHD's a b***h, some days you can keep it together, some days you can't, and trying to get both the motivation to work on something and the focus to actually do it both at the same time is a bit hit or miss).

Unfortunately not. I coded it directly in hex. I recall that I gave you a documentation for your dx project, maybe you find it.

But I almost doubt it has something to do with the code itself but it is more likely that the changes in msu progression by the change from firmware 1.6 to 1.7 has something to do with it. At least nobody had these issues on the older firmware (though a lot of people tried it out), and since its introduction I count (with you, Ikari board and Retromancer's youtube channel) 3 complains. So I would say: save your time to dig in the code and rather try to find the reason (trigger) why it casually works and casually not...
My best guess is that the msu-boost doesn't always like the video stream...

I finally got around to trying with the new version (0x60 volume) of the patch Actually the problem is similar to one that has occurred in the FF3 Dancing Mad MSU1 hack.

The playback control register gets overwritten rapidly. First it seems to be cleared (AFTER the track has been prepared), then written again with the play bit set. This seems to have changed since the former version of the hack that I tried. The current MSU1 implementation handles the first write but misses the second one while handling it. The debug log (v0.1.7b) states:

Code:

Audio requested! Track=35
filename: /msu1/A Link to the Past MSU Audio boost/alttp_msu-35.pcm
loop point: 0 samples
Repeat clear!
PAUSE!

And that's it, so the play command never gets through.
I improved on this since v0.1.7b (expect v0.1.7c in a couple of days). But why is the playback control register cleared first?

EDIT: This is how it looks with the current development head:

Code:

Audio requested! Track=35
filename: /msu1/A Link to the Past MSU Audio boost/alttp_msu-35.pcm
loop point: 0 samples
Repeat clear!
PAUSE!
Repeat clear!
PLAY!

And audio plays. So this should sort itself out with v0.1.7c I guess.

Funny, I just got around to looking into this myself, and came to the same conclusion.  The stz $2007 at $23f5b5 shouldn't be necessary.  You don't need to clear the playback register when you're just switching from one track to the next.  The main time you need to do it is at the end of a fade-out, otherwise the faded out track still keeps playing and then when you go to set the volume register for the next track it'll play a few samples of the previously faded out track before switching, but that should be done in the fading code, not in the track loading code, which would space out the control register writes a lot more than they are here.  If you're just doing a normal track switch, you can just write to $2004.  Now, if you had more than 255 tracks or for whatever other reason $2005 might change, then you might want to do it that way (or more simply, just be sure to always write $2004-2005 with a single 16-bit write), but in this case, you don't have to worry about that.

Anyway... this should do it.

Code:

PC 11F5B5: EA EA EA

Edit: Tested it, 6-7 tries so far and no failures. The original code would fail ~60% of the time. Even with 1.7c improving this behavior, I still think this should be changed. It's simple enough, and I don't see any side effects on hardware or in the latest bsnes-plus (haven't tried higan, or any other versions, but I'm pretty sure that subroutine is only executed for the video playback, so there shouldn't be any effects elsewhere).

Alright, thanks for isolating this bug
I also had fixed this once for the other ingame tracks, and also I set this correctly in the BS Zelda videos, but somehow must have forgotten about the video. Strange is however that this bug was never reported on the old firmware.

Well, I updated my files
http://bszelda.zeldalegends.net/stuff/Con/zelda3_msu.zip

(also all in and wrote SePH a message to do that in Conker as well).

Thanks to all of you