Sd2snes china version mean bin download

byuu wrote:You are much better at documentation, whereas I usually just rely on source code to document how things work.

Whew, thanks for the flowers : - ) okay, then I am trying to take your source code apart... and write some notes/questions.
One small warning: I've looked at some old bsnes source that I had laying around, so some details might be different in your current source. The msu file I had was dated 25 Jun 2012 (but the source package also included emulator.hpp with date 10 Aug 2012).

Reset - most eye-catching is this: but there's also this: I am not sure how that two part are executed in order, and how often (only on coldboot, or also on warmboot). But I guess they are executed shortly after each other as ordered above.
So for example, volume would become ZERO, and busy flags would become FALSE automatically after reset, right?

Floating Point Unit Is that really a floating point division by 255? That's something cannot be reasonably implemented in hardware (nor in emulators). Integer multiply and shift right 8 steps should do the same thing, and it'd be common to skip the calculation for max volume (ie. let "*255 shr 8" act is if it were "*256 shr 8")

Data Address - the basic idea here is to write 4 bytes to set the 32bit address, with the seek occuring on 4th write. There are some corner cases on "what happens when doing data reads after writing less than 4 address bytes" (which, one shouldn't ever do that). When implementing it same way as in your source code, it should act as so:
The Address Register gets incremented on each data read (so, when initializing address.lsb to zero, one should not expect it to stay at that value) (just mentioning in case somebody has all data stored on 256-byte boundaries, and thinks that it would be faster to rewrite only the upper 3 address bytes).
The filepointer (in the OS) also gets incremented on each data read (so it does usually increment in sync with the incrementing Address Register). The corner case is when somebody changes only the Address Register LSBs: Then Address Register and filepointer will have different values, with reads being done in respect to filepointer... unless you are loading/saving a snapshot: that would reinitialize the filepointer (and make it same as the Address Register value).

Play and Repeat Flags these flags exist in both Status and Control register. From the docs it wasn't quite clear to me if they have different meanings. But from the source code: Status.Play/Repeat values are identical to Control.Play/Repeat values. Aside from writing to control register, they are also manipulated automatically upon some events:
Reset: Play=0, Repeat=0
Selecting a new Track: Play=0, Repeat=0
Reaching end of Track: If Repeat=0 then Play=0
If "file not open": Play=0 (that case... appears to be same or similar the track not found error)

Busy Flags easiest case would be to have them set to 0=Ready all the time (assuming that either the hardware fast enough, or simply pausing the emulation when it isn't). If that works well, then I'll just do it that way. Looks as if you have implemented it as so, too (aside from busy bits being initiallly/temporarily set on reset).
Btw. worst case for audio seek that I could think of is this: Running the .sfc file from a compressed .zip or .7z file (which also contains compressed tracks). I'll probably not implement that case as it's slightly more difficult to decompress multiple files (and supporting that isn't needed for normal single-file SNES rom-images).
But if were supported, in a on-the-fly fashion (=decompressing a new track when needed) then it may cause huge 'seek' times.
For .7z files it may take several minutes (as it would need to decompress all preceeding files in the .7z archive).
For .zip files it may take a few seconds (as it would only need to skip the preceeding files in the .zip archive).