Are there any complete MSU1 specs? And what does MSU stand for? Mass Storage Unit? Movie Sound Upgrade? Media Something Unnamed?
The best (inofficial) specs I could find are here http://helmet.kafuka.org/msu1.htm - that page does also have a (broken) link to official specs: http://byuu.org/msu1/ and it does have links to several forum threads (which I haven't check if they contain additional specs or scratch notes).
And there are two implemention notes on http://sd2snes.de/blog/ and some notes about transfer rates here: viewtopic.php?p=124578#p124578
EDIT: For transfer rate: byuu said "Needs to be fast enough to read 3.58Mbyte/s" - that isn't possible, or is it?
Fastest way I could think of would be DMA at 2.68Mbyte/s (assuming that the SNES doesn't contain any nasty feature that prevents using port 2000h-2007h for DMA).
Next fastest would be polling by software, which would be 0.51Mbyte/s (when using a 3-cycle load opcode and a 4-cycle store opcode at 3.58MHz).
For the seek times: I understand thdm as so: The audio/data seek busy status flags need to be checked only on initial seeks (when setting a new data address, or when selecting a new track). And there after, programmers can simply expect that data and audio arrives fast enough (even if the hardware is organized in sectors, possibly stored on a fragment filesystem, and possibly sharing the same memory chip for data and audio).
For hardware devrs that would mean that they must use hardware that is fast enough, and do suitable read-ahead caching on sequentially accessed memory chips. And when sharing the same media: give priority to data reads (and drop audio reads in case transfer is slowed down too much by slow SD cards, by read-retries, by filesystem fragmentation).
For "gamename-#.pcm" audio track filenames, I've looked at the Super Road Blaster binary at http://www.dforce3000.de/ it does 122 audio tracks, judging from their filenames, the "#" is supposed to be a unsigned decimal number in range 0..65535, without leading zeroes, ie. "0..9" for first 10 tracks, "10..99" for next 90 tracks, "100..999" for next 900 tracks, and so on.
The "gamename.xml" file - I hope that it's optional to interprete that file. I would prefer to detect MSU1 by presence of the "gamename.msu" data file, and expect the "gamename.sfc" file to contain a valid SNES header at FFxxh (with info about lorom/hirom/sram/etc). One fun caution: d4s does also has a "gamename.sfc" folder, which shouldn't be confused with the "gamename.sfc" file.
The best (inofficial) specs I could find are here http://helmet.kafuka.org/msu1.htm - that page does also have a (broken) link to official specs: http://byuu.org/msu1/ and it does have links to several forum threads (which I haven't check if they contain additional specs or scratch notes).
And there are two implemention notes on http://sd2snes.de/blog/ and some notes about transfer rates here: viewtopic.php?p=124578#p124578
EDIT: For transfer rate: byuu said "Needs to be fast enough to read 3.58Mbyte/s" - that isn't possible, or is it?
Fastest way I could think of would be DMA at 2.68Mbyte/s (assuming that the SNES doesn't contain any nasty feature that prevents using port 2000h-2007h for DMA).
Next fastest would be polling by software, which would be 0.51Mbyte/s (when using a 3-cycle load opcode and a 4-cycle store opcode at 3.58MHz).
For the seek times: I understand thdm as so: The audio/data seek busy status flags need to be checked only on initial seeks (when setting a new data address, or when selecting a new track). And there after, programmers can simply expect that data and audio arrives fast enough (even if the hardware is organized in sectors, possibly stored on a fragment filesystem, and possibly sharing the same memory chip for data and audio).
For hardware devrs that would mean that they must use hardware that is fast enough, and do suitable read-ahead caching on sequentially accessed memory chips. And when sharing the same media: give priority to data reads (and drop audio reads in case transfer is slowed down too much by slow SD cards, by read-retries, by filesystem fragmentation).
For "gamename-#.pcm" audio track filenames, I've looked at the Super Road Blaster binary at http://www.dforce3000.de/ it does 122 audio tracks, judging from their filenames, the "#" is supposed to be a unsigned decimal number in range 0..65535, without leading zeroes, ie. "0..9" for first 10 tracks, "10..99" for next 90 tracks, "100..999" for next 900 tracks, and so on.
The "gamename.xml" file - I hope that it's optional to interprete that file. I would prefer to detect MSU1 by presence of the "gamename.msu" data file, and expect the "gamename.sfc" file to contain a valid SNES header at FFxxh (with info about lorom/hirom/sram/etc). One fun caution: d4s does also has a "gamename.sfc" folder, which shouldn't be confused with the "gamename.sfc" file.