Incorrect track loading loop causes faulty "bad track" errors. Was: Glitchy playback on SD2SNES

[Dan Yetman]

I've played up to the second save point (in Narshe Caves), and MSU-1 playback on the SD2SNES is spotty. I'm playing on an SD2SNES with firmware 0.1.7p4, on an NTSC Model 1 SNES (I have an NTSC mini, and about eight different NTSC-J Super Famicom motherboard revisions I can test, though).

The opening theme never plays the .PCM version, and there seems to be some trouble particularly when switching from SFX tracks (such as the blowing wind in Narshe and on the intro precipice) and .PCM tracks.

To wit: Sometimes, battles will play the .PCM music, and sometimes they will play .SPC tracks. In addition, occasionally neither track will play and there will be either silence or a buzzing noise from the MSU-1 (which resolves itself whenever a new audio track loads, which in this instance is invariably a .PCM.

After the battle, the victory music always seems to be the .PCM, after which, upon returning to the field, the field music will play the .PCM reliably.

Loading a saved game produces NO music in the field until a new track is loaded, either by moving to a new area, or by entering a battle.

It's very difficult to debug on the SD2SNES (in addition, I am not the world's greatest coder), but what appears to be happening is that the "Play .PCM if found" routine is somehow taking too long to check if a .PCM is found, but not on a truly consistent basis. The game then defaults to .SPC. The buzzing is likely caused by confusion between switching back and forth between .SPC and .PCM files - I've seen it happen on occasion with other patches (MMX MSU-1, but it was fixed in the last revision).

I'm using a class 10 card with an average seek time of under .7ms, and a peak seek time of just a hair over 1ms, so I don't believe my SD card is the issue.

[Dylan Morrison]

Interesting... I think your guess is correct, in that it has something to do with the missing track check routine. I'll give it another look and see if I'm doing something stupid there.

If you can, please check to make sure these bugs don't happen in Higan (they don't for me), so that we can make sure we're not dealing with some other issue. If you don't want to run the install again, the manifest.bml for higan is in the installer's archive (it's a 7-zip self extractor).

[Dan Yetman]

Will do, and I'll report back on it later.

[Dylan Morrison]

Hmm... curiouser and curiouser. I just checked my ASM and the bit where it waits for the MSU to load a track and then report bad track if it can't load it or good track if it can, runs indefinitely until it gets either a yay or nay from the MSU-1. So the amount of time it takes to check for a valid .PCM shouldn't matter at all. I might have you test the experimental branch patch and see if this has something to do with the memory addresses I'm using for currently-playing-track checking, which I changed in the experimental branch.

[Dylan Morrison]

Okay, I'm just throwing shit at the wall to see what sticks here, since I don't have access to an SD2SNES or any way to look at the RAM of your console to see what's happening, but a potential fix was just committed to the experimental branch. Said fix doesn't break anything on my copy (a good sign, I guess?) but god knows what will happen on the SD2SNES. If the game locks up completely, tell me, as this is a sign it's getting caught in a busyloop of asking the MSU-1 to play and it not indicating that it is playing.

Also, for the opening, is it playing absolute silence, or is it playing the SPC music? If it's playing the SPC music that's really interesting... Please make sure you have PCMs ff3-2 through ff3-4.

Anyway, there's an IPS patch in the experimental branch under the patch directory. This goes against an unmodified, unheadered copy of FF3 US v1.0. Try this, and report back to me your results.

If you're technically inclined and want to know, the fix is essentially that I'm now, instead of immediately silencing the SPC and returning, checking to see if the track is playing or the MSU is busy first. If it's playing, we proceed as normal. If it's busy, we wait. If it's neither, I raise an error flag in RAM (something I don't know if you can check on the SD2SNES), then check if the MSU is reporting bad track. If it is (which should be impossible at this point in the code) I raise another error flag and start all over. If it isn't, I repeat the play command to the MSU-1 and go back to waiting (thus the potential infinite loop and lockup).

Potential fix is in commit 4e337eb

Also, I'm upgrading this issue to Critical as it's really important that things work as identically as possible on the SD2SNES and on emulators.

[Dylan Morrison]

Something occurred to me regarding trying to debug on the SD2SNES. If checking for known or suspected failure states, I could change Terra's name. That'd be an easy way to flag an error in a way that'd be immediately visible. If the potential fix from above doesn't work this may be worth trying.

[Dan Yetman]

Well, it doesn't fix the issue. Not really. In a weird sort of fashion, it does 'improve' it, I suppose. The title theme was .SPC, but the intro cutscene was .PCM, until the wind SFX cut it off. At that point, I didn't hear .PCM music until the battle with the two guards and two mammoths just outside the entrance to the mine, and only then with the Victory Fanfare. It then went back to .SPC. It took a few battles inside the mine before I got another Victory .PCM, after which I got .PCM Mine music, and everything started to work as it was supposed to. I have just used the first save point, so I don't know about further, but that's how things are.

The improvement is that I have yet to hear any of that godawful buzzing when a bad MSU-1 seek occurs, but I wouldn't say that was a huge step. Currently, whether it plays .SPC or .PCM on the SD2SNES seems almost completely random, and I am uncertain as to why. My best guess is that there is some variable in the game that is causing the MSUExists check to fail on many of its calls.

Also, I'm not a great coder, but I did notice something that struck me as a little weird:

.DEFINE MSUDSeek     $2000

This not only looks like a typo (What is MSUDSeek?), but why is it assigned to $2000, when MSUStatus is ALSO assigned to $2000? I am not an ASM coder, being only modestly able in VB.NET, but it looks to me as if two different registers are being assigned to the same address. Is this right?

[Dylan Morrison]

That's not a bug. MSUDSeek stands for MSU Data seek. When writing to that address, it's for seeking in a data stream (like for playing an FMV) on the MSU. When reading that address, it's a status flag.

Also, in ASM you don't assign anything. Those are just the equivalent of #defines. As in, shorthands.

There are no variables, there's no telling things where to be, they just are where they are. The MSU is always at $2000-$2007, and the read registers are always different from the write registers.

[Dylan Morrison]

http://helmet.kafuka.org/msu1.htm

[Dylan Morrison]

As far as the MSUExists check failing, that should be impossible. This is checked directly against the MSU registers themselves, and the variable written to, in the experimental patch, is unused by any game code.

Just for the sake of arguement however, I'm going to create a version of the patch that checks directly against the MSU-1 registers for its existence every time, instead of saving its existence to a variable in RAM.

[Dylan Morrison]

Done. The version as of commit a0d9360 should be foolproof against any MSUExists check failures.

[Dylan Morrison]

I've also sent ikari (the developer of the SD2SNES) an email asking for input on any quirks of the SD2SNES that I should be watchful of.

[Dan Yetman]

Newest experimental is still sporadic on playback. I've noticed that the Opening crawl never plays. Ever. Tried it on several different systems, with no luck.

When I get the .PCM to play (which is random), it is almost always with a victory fanfare, and very nearly always the first battle in the mine. If I step back outside into Narshe with .PCM playback, I get the buzz indicating a problem with playback, and once I go back into the mine, it plays .SPC again until something like a battle occurs.

Something is either not right with the .SPC/.PCM takeover code, or something about the way FFVI calls music is very different. Are you ABSOLUTELY SURE that all the areas of RAM you have allocated are unused?

EDIT: The new method to hold onto the last .PCM played on save load works beautifully. If I save when the .pcm is playing, reset or restart and load that file, it plays the .pcm off the bat.

[Dan Yetman]

It's probably a longshot, but you might also try getting Conn (Konrad Staudt) from the bszelda forums involved. He was the main coder on the MSU-1 Zelda projects.

[Dylan Morrison]

Played the game for four hours with bsnes-plus's memory editor open, from the opening onwards, with those memory addresses. All bytes remained at 0x55 which is what the CPU wipes all RAM to on boot. Also took an SRM from the end of the game and watched the RAM values of the game. As sure as I can be without playing the entire game through in one marathon play session.

[Dylan Morrison]

ikari wants me to send him the patch so that he can run it through a debugger. Let's consider this bug on hold until I get his feedback.

[Dan Yetman]

Glad to have ikari on board! I'll start testing in higan now

[Dylan Morrison]

I'm going to wait until after he gives his take on it before trying this out, but I just had a stroke of inspiration regarding a potential fix, given what ikari said to me in the email.

He said nothing should be the problem as long as I'm testing the MSU-1's audio busy and error status flags, but he said them in that specific order. I'm checking them in the reverse order (error flag first and then busy flag). Which got me to thinking, if the track error flag is somehow lingering from a previous track, that could cause a false positive on "track bad" before the MSU is finished loading the track. Which could explain at the very list your intro problem: FF3 firsts asks to load a nonexistant "track 0" (silence) and then track 2 (the first part of the opening).

This would explain things working fine on higan and breaking on the SD2SNES because, for me at least, load times on higan are practically instant. Whereas the SD2SNES is likely limited by the SNES's clock rate, and by the SD card's speeds. Even .7ms is forever from the point of view of single 65816 processor instructions.

[Dylan Morrison]

Actually, while we're waiting on ikari's input, can you try one more patch for me on the SD2SNES? This latest commit, e78864e, I made a change based on the assumptions made above. Basically, it now loops around waiting for Busy to clear before checking for badtrack.

[Dan Yetman]

That's taken care of so many of the issues! I'm only just starting the playtesting, but all .PCMs have played thus far, and the only issue is a brief buzzing between the point where I started a new game and when the Intro music started to play.

I will report more on this later, but this simple fix seems to have addressed the main issue rather nicely. Bravo!

EDIT: I can quite happily confirm that, with an hour's worth of play time into the game, this simple reorganization of the busy/error flags has resolved the problem. Naturally, I will perform more exhaustive testing (I am dreading the Opera Sequence and the final battle with Kefka in particular), but this is sufficient progress to close this issue until further notice. There still remain a very few minor issues (mostly relating to fade-in/out of tracks and a pair of minor graphical glitches), but nothing catastrophic.

[Dylan Morrison]

I'm going to close this particular bug as resolved then. Any further issues can go in their own reports. Glad we nailed this one down.

[Dylan Morrison]

Resolved in commit e78864e

[Dylan Morrison]

FWIW, after a bit of a... kerfuffle involving my git client going all wonky and the master and experimental branches getting mixed up, I've fixed it by reworking what each branch is. Now "stable" is the alpha code as given in the installer I sent out, and "experimental" is what I am up to the minute directly working on. "master" is to be considered now a midline, the code that I have done at least preliminary testing and checking on to make sure it's working, and the code I'm most likely to ask someone to try out. This is relevant to this bug as the bugfix for this is the current "master" branch. Therefore anyone testing for the SD2SNES is likely to be asked to apply the "master" branch IPS file.