#178029 - WriteASM - Mon Aug 05, 2013 4:01 pm
Am looking at a Supercard Mini SD adapter for GBA/DS devving, but have a question. Does anyone know whether the SD card can be accessed from the GBA? I know that the Supercard supports gamesave, but that's only ~64K, which doesn't count for me.
It would be fun to make an audio recorder--connect a codec chip to the link port, and there's the SD card adapter in the slot.
#178030 - Dwedit - Wed Aug 07, 2013 2:31 pm
Yes it can be accessed from the GBA. Libfat should work with it.
Libfat was originally written for the GBA and the GBA Movie Player, then it expanded to the NDS and other cards, and later to the Gamecube/Wii.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#178031 - WriteASM - Wed Aug 07, 2013 4:31 pm
Thanks for the reply. I had figured that if the card had software for video and audio playback, there had to be a means of accessing the data on the card! Will do.
_________________
"Finally, brethren, whatever is true, whatever is honorable, whatever is right, whatever is pure, whatever is lovely, whatever is of good repute, if there is any excellence and if anything worthy of praise, dwell on these things." (Philippians 4:8)
#178056 - WriteASM - Sat Aug 24, 2013 2:26 pm
OK, now I have a Supercard Mini SD. It works pretty good, but the DevKitPro "biosdumper" example does not work. I tried the Win32 GUI "DLDI patcher", and it says that the binary does not have a DLDI section.
I did find the libfat source, and would like to port it to ASM for my projects (retaining DLDI-patching ability), which would probably help data transfer speed. That is, only if it works!
An ASM port would probably help the binary's size as well: the very simple "BiosDumper" binary is 90KB (and my far more complicated 100% ASM "bASMic" is 46K.) Looking at the DLDI source for the Supercard SD, it appears that the Supercard only provides direct access to the SD card. In other words, does libfat have to know the SD communication protocol? Or is that the responsibility of the DLDI file?
For some reason, the "GBA Movie Player" (Filmplay.gba) doesn't work correctly on the GBA--videos are a garbled diagonal-sliding mess that doesn't resemble the input at all. (The audio is correct, although very low quality.) Perhaps "GBA Movie Player Movie Converter 1.3" isn't compatible with "GBA Movie Player 1.3"? Or is something else wrong?
One last thing: I'm not sure how this affects compatibility, but the Supercard's gamesave memory area doesn't appear to behave like a FLASH chip or an SRAM chip. It acts more like an SRAM chip...but then refuses writes. Any suggestions?
_________________
"Finally, brethren, whatever is true, whatever is honorable, whatever is right, whatever is pure, whatever is lovely, whatever is of good repute, if there is any excellence and if anything worthy of praise, dwell on these things." (Philippians 4:8)
#178057 - Dwedit - Sat Aug 24, 2013 6:22 pm
Supercard has non-battery backed SRAM, so you need to power off then quickly power on again to get it to save.
Data transfer speed isn't limited by how fast the code is, it's limited by the card reading hardware. There is additional latency when it has to wait for the device to become ready, and then there are necessary time delays added to reads and writes.
If you need something lighter than libfat, you can use the previous versions of the filesystem, they're called GBA_NDS_FAT. I once had to heavily reduce the stack usage of the driver, and moved some sector-sized arrays into statically allocated memory instead of stack ram.
Only problem is that GBA_NDS_FAT sometimes has filesystem corruption problems, libfat got all the bugfixes since to fix them.
There's also the really old version of the filesystem called GBAMP_CF that was intended solely for the original GBA Movie Player.
And yes, the DLDI driver is responsible for containing all the code to read and write sectors from the disk. This was done so that card manufacturers could provide a driver and existing homebrew would work.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#178058 - WriteASM - Sun Aug 25, 2013 1:31 pm
Thanks, Dwedit. Yes, I am aware that the Supercard needs a power cycle to get to the menu to save the data. I was just about to list the source code I was using to save data, and...bummer, my bad! Using the wrong register for the address won't exactly get the desired result :-).
I'm not sure if this means anything, but most of the Supercard software export settings have to be disabled to make anything function, including the GBA Movie Player.
It seems that all of the DLDI patching utilities are for Nintendo DS binaries. The Supercard software has an automatic Patch, but that always comes up "Fail." I would note that I got stuck with Windoze 8 (regular), which is pretty bad with compatibility. Too many "permissions."
Do you know of any GBA binaries that write to a memory card with DLDI? (Source code would be appreciated as well.) As I mentioned the DevKitPro BIOSDumper example doesn't work.
Hmm...transfer speed not limited by code...? If the code has to wait for each SD command to finish, then the delay between each command is, well, code-based: the faster the commands come, the higher the data rate. Of course, the CLK rate also determines the data speed. A good PC card reader can get 10MBytes/sec in/out from an SD card, requiring a clock rate of 100MHz or higher! I doubt the Supercard provides a clock rate that high.
P.S. Discovered that the link port's shift-clock serial mode can be used while the link port is set to GPIO mode...just as long as the required pins are inputs. Surprise!
_________________
"Finally, brethren, whatever is true, whatever is honorable, whatever is right, whatever is pure, whatever is lovely, whatever is of good repute, if there is any excellence and if anything worthy of praise, dwell on these things." (Philippians 4:8)