Nice, it can cause trouble on sd2snes since
STZ $2006
Is below sta $2004
But we'll see

Sorry for the confusion in pw, the current v4 has 2 asm files inside and I checked the wrong.

Conn wrote:Nice, it can cause trouble on sd2snes since
STZ $2006
Is below sta $2004
But we'll see...

So, is the Kawa document wrong? I followed the instructions where it has STZ $2005/06 after STA$ 2004. Or maybe, I read it wrong?
Just want to make sure. Been doing it this way for all my previous hacks.

Sent from Topic'it App

Hmm, help me out here, Conn. If STZ $2006 effectively mutes the MSU1 audio. Later on in the code, I have:

loopTitle:
BIT $2000
BVS loopTitle ; track not ready
LDA #$FF ; max volume
STA $2006

LDA #$FF and STA $2006 would restore max volume, right? So, my question, is STZ $2006 redundant? I'm trying to remember why I had it this way. I might have done this to avoid a sudden jerk switch between tracks (if my memory serves me correctly).

The bit $2000 loop is only needed for sd2snes, as real hardware needs a time to load a newly introduced track. On emulator you.have it immediately loaded.
If you look.into the pw threads you see a buzz bug solved after shifting it. I think this was caused because real hardware is not so fast writing to registers. So if you introduce a new theme with 2004 and then mute the audio, sd2snes plays the new track while loading, resulting in a buzz. If you mute it before 2004, the buzz gets muted and problem solved. You need in any case mute the current track with stz $2006 before loading a new track, otherwise it will play the unfinished loaded track (buzzes, but only sd2snes since on emulator, as said, you have it immediately loaded)
After loading it (after the bit $2000 loop) you need of course to unmute again with writing ff to 2006.

Btw, do you think my solution for track 8 may.work with pilotwings?
https://www.zeldix.net/t1569-pilotwings
(It's not adjusted to your new code, just a technical idea to compare the counter 00-ff to be 08 and only then store it to 2004).

Last edited by Conn on Sun 31 Dec 2017 - 11:42; edited 1 time in total

As Conn pointed out, we've been doing this way because it takes a little for the next track to load, if not STZ'ing either $2006 or $2007(assuming you set this every time a new track is loaded), the previous track will play for a fraction of seconds before the purposed one does.

I particularly choose to clear $2007, since that frees the SD2SNES streaming buffer

Ok, this is good to know. I appreciate the input, gentlemen. I will make these corrections (including my previous hacks).

Conn wrote:Btw, do you think my solution for track 8 may.work with pilotwings?

My apologies, I forgot to mention in my previous post that I tried to use a CMP #$08 to isolate that value from the loop but had the same issue. Even tried using X and Y for compares to the same effect.

I see, can you post here or per mail a savestate before that problematic track load routine is executed (preferably Geiger but also bsnes+ will work), I try then what I can do  at when I'm back Home at Thursday

Stz $2007 should actually also work but it doesn't for some reasons, at least we had a problem with zelda3: if you write to 2007 shortly behind each other, like stz $2007, bit $2000... lda #$03 sta $2007, the engine doesn't make it right and bugs. So we needed to do it via mute on $2006 though 2007 indeed would be better.

Edit:
Btw, since this adventure island game isn't snes9x compatible, checking briefly the code, the only problem I see is the ram addressing:
STA $0001C0
Should be either
Sta $01c0
Or
Sta $7e01c0

Another problem could be that you hook in 8-bit but you need the high byte and switch to 16 bit with rep #$20
It is possible that snes9x zeroes the high byte in 8bit mode, so it's not accessible anymore. Ah well,I can also check Thursday

Conn wrote:It is possible that snes9x zeroes the high byte in 8bit mode, so it's not accessible anymore.

I'm betting that this may be the issue as changing the STA $0001C0/C1  to STA $01C0/C1 had no effect (same crash at game intro).
Or I could just rewrite the code and move the MSB (high byte) values into LSB (low byte) and stick to 8-bit mode A.

Just as a point of clarification, writing anything to $2005 (including a 16-bit write to $2004, but almost all of the code I've seen is in 8-bit mode) will stop playback of the current track and start loading the track stored in $2004-5. An 8-bit write to $2004 will not do this. Because of this, in 8-bit mode you always need to write $2004 before $2005. It also means you don't need to mute the audio register if you're just loading a new track, because playback is already stopped. As soon as $2005 is written, the audio busy flag in $2000 gets set, so you need to check the busy flag. Once the busy flag clears, then either the track missing flag is set or else the track is loaded and you can start it by writing to $2007.

So, changing tracks should look like this:

Write $2004
Write $2005

(Track stops)

Read $2000 until busy flag clears
Check track missing flag (busy clear and missing set should be atomic so you shouldn't have to read $2000 an extra time but you can anyway)

Write $2007 (or SPC fallback)

The msu code portion is in 8-bit mode, Qwerty. I just use 16-bit A as a quick way to setup the track number in RAM (taking only the high byte portion, rather than resorting to wasted code doing multiple ANDs/ORs/ROL/SHR, etc trickery for each track). Once the data is passed to RAM for later retrieval, I change A back to 8-bit and resume game as normal.

I do appreciate everyone's input on how to properly play msu tracks. Thank you for the extra information.

Conn, I really believe that Snes9x is not the problem. Somehow, this game wants LDA #$01 (or between 00-1A, though these do no provide perfect spc mute). Anything else, will freeze the game at the 'game intro'. I'm using this part of the code as a way to mute the spc audio. I might have to find an alternative way to mute the spc in order for Snes9x to work.

Last edited by pepillopev on Mon 1 Jan 2018 - 0:08; edited 1 time in total

Yes muting spc is always difficult. There are 3 options:
- you have a mute track (e.g. zelda 3)
- you ignore the routine for spc playing (castlevania 4)
-you mute in the apu (dkc)

Last option is the last chance I use if other options fail, since the sfx get slightly different, and the game can only played as msu after patching (you can thus renounce on the lda $2002, cmp #$53).

If you indeed need an apu mute, I can try to find it for you when back.

Conn wrote:If you indeed need an apu mute, I can try to find it for you when back.

Kurrono, has an alternate mute method that can be attempted. I am waiting for his source code to study it. If his method works, I will let you know.

Kurrono never sent his asm for me to analyze, so, I tinkered a little more and found out that, indeed, Snes9x was picky, but only before the game intro started. It was expecting 01 to be written to $2140, otherwise, black screen at game intro.

I used a creative CMP to give Snes9x what it wanted and it worked. After that, Snes9x is happy with any other valid mute value on $2140 for the rest of the game.
To make things short, Snes9x is now compatible. I played it from beginning to end without any problems. Same goes for Bsnes073+3a.

Kurrono did report 'buzzing' noises after START is pressed during game intro. This was with the old code. I did change my code a bunch from the last version; not sure if he tested it on his sd2snes.

pepillopev wrote:Kurrono did report 'buzzing' noises after START is pressed during game intro. This was with the old code. I did change my code a bunch from the last version; not sure if he tested it on his sd2snes.

Kurrono has confirmed that the 'after game intro buzzing' issue is partially gone with the latest patch. So, still need some work. Arg!

Hehe hardly a patch works on the first shot. But real.hardware stuff.is guessing since there is no debugger
I'm curious to.see what is revealed once the sma and dkc3 pcm are released so people can testplay.
Btw, are you able to provide the pw savestate before track 8 so I can check?

My suspicion:
STZ $2007
STA $2004
STZ $2005

Try stz $2006 instead $2007 here. As said, in zelda3 I also tried with 2007, but that bugged, so I only use 2006 when introducing a new track...

Conn wrote:Btw, are you able to provide the pw savestate before track 8...

Conn, I emailed you all the relevant pilot wings files (including bsnes073+3a save state at helicopter landing before characters board it). At this time, Pilotwings does not work properly with Snes9x Geiger (seems like DSP1B issues). Bsnes is the only way, Kurrono and I have been able to trace code.

Got it, thanks a lot, will try to debug on Thursday

Dump Geiger, it's buggy, it's abandoned, and it doesn't have half the features of bsnes-plus, which is actively developed, and the author is pretty responsive to feature requests. Also, it's based on an old version of Snes9x with a lot of accuracy issues. There really isn't any reason to keep it around.

Any chance that a Rewind Feature could be added? It helps a lot when testing games without resorting to cheats. I like play testing via regular game play to make sure every possible thing is covered. For now, I use your Snes9x build for this feature alone when testing.

@qwerty, yes I know. It's just I'm very used to Geiger and thus tracing takes much less time for me.
The trace logs are more lucid in Geiger:
Like
You have paragraphs at a jsl
Banks are separated with a /
If there are branches in bsnes it shows beq $1234 (only the destination), in Geiger beq $04 [xx/1234] the bytes branched, then the destination.

I have no tracelog to compare at my mobile, so this is out of my memory. Most is maybe I'm used to Geiger trace logs, but it's for me definitely harder to dig through bsnes traces. But possible, I can handle both. Also I can trace msu bugs with tricks quite good in Geiger, but sometimes bsnes is indispensable. So I'm more than grateful having this debugger as well of course.

Conn wrote:Stz $2007 should actually also work but it doesn't for some reasons, at least we had a problem with zelda3: if you write to 2007 shortly behind each other, like stz $2007, bit $2000... lda #$03 sta $2007, the engine doesn't make it right and bugs. So we needed to do it via mute on $2006 though 2007 indeed would be better.

qwertymodo wrote:Just as a point of clarification, writing anything to $2005 (including a 16-bit write to $2004, but almost all of the code I've seen is in 8-bit mode) will stop playback of the current track and start loading the track stored in $2004-5.

Hm... That's interesting.

After some investigation and analyzing a few source codes (smw plus and native, qwertymodo's MSU-1 disassembly), the MSU-1 audio indeed stops after setting the Track registers. My OW Music patch exclusively makes use of this feature to deal with the real-time song changes.

Any piece of music that you can hear out of place before the right one, is because of an oversight made on the written code.

Everytime a song is supposed to stop, you should ideally clear the Audio Control port ($2007), be it a fade out or a sudden halt.

We had figured this out a long time ago, but it was eventually forgotten
https://board.byuu.org/viewtopic.php?f=8&t=1020#p23584

Conn wrote:It's just I'm very used to Geiger and thus tracing takes much less time for me.

No problem at all with that ;D
As long you keep working nicely and at your best, retiring it does not apply in this case, you're experienced enough to know what works for you or not. ^.^

For the newcomers arising, best is to use modern tools with better support. Geiger is from a far time in the past where there wasn't too much to work with, it had its time but as of now, it has been obsoleted by the advancements in the hacking scene.

@colines you must not forget that sd2snes is different from emulator, at least it solved a buzz bug in pw to move stz $2006 on top of writing to 2004/5

https://www.zeldix.net/t1569-pilotwings

Making msu1 stuff work on emulator is not that difficult, but to have it work on sd2snes as well is difficult (pev currently is in a try&error phase sending stuff to kurrono for super adventure island).
Loading and clearing the buffer on rh needs time, so emulator is much more tolerant, therefore you need to mute audio with stz $2006 on sd2snes before introducing a new track (can't say whether  stz $2007 has the same, better or worse effect). This is not.needed on emulator, as qwerty pointed out, writing to $2005 stops the track... But not fast enough for sd2snes.

I have my routines sd2snes compatible with this Stz $2006 on top of writing to 2004/5 and a nmi hook (to avoid flickering), and go well with it so far... I make no experiments here anymore