DLDI-patching for GBA, Supercard access

Discussion in 'GBA - Hardware, Devices and Utilities' started by DSLSC, Sep 3, 2013.

  1. DSLSC
    OP

    DSLSC Member

    Newcomer
    28
    3
    Aug 27, 2013
    United States
    Hello everyone. I would like to be able to write GBA binaries with read/write access to an SD card inserted in a SuperCard Mini SD. However, the only example I have at the moment is DevKitPro "biosdumper" example (using libfat), which fails, "FAT initialization failed." (If I quickly remove the card when starting the example, it takes a very long time to fail.) For some reason, the Supercard software's built-in patcher, and the Win32 GUI patcher on Chism's DLDI page both FAIL on GBA binaries. Is something going wrong here? (By the way, it seems that DLDIWiki is gone.)
    If I understand correctly, libfat is for both GBA and NDS, and Chism's DLDI page lists the Supercard as being R/W supported in libfat. (Read-only in gba_nds_fat.) I know that the SD card can be accessed (GBA Movie Player, gamesaves), but...

    Does anyone have a working GBA binary that can read and write to a DLDI device? Source code would also be appreciated. I should also note that my computer is stuck with Windoze 8, which may be part (or all) of the problem. Any suggestions?
     
  2. FAST6191

    FAST6191 Techromancer

    pip Reporter
    23,838
    9,723
    Nov 21, 2005
    United Kingdom
    GBA Game Save Backup Utility from http://chishm.drunkencoders.com/SendSave/index.html is about the only example of a GBA program using DLDI I know of. Everything else I have seen that attempts some form of flash memory access is device specific stuff like those you mentioned.

    Likewise some of the DLDI patches may have been compiled for the DS ARM9 memory setup -- years back there was a wavelet based video program known as DSvideo that needed to recompile them for ARM7 (sadly the site has long since vanished and I do not have many of recompiled patches). The differences between ARM9 and 7 are not so much and I very much doubt it uses the extra instructions but who knows. There may also be calls for on cart functionality (some carts used their CPLD/FPGA innards to boost CRC speeds which should be used when writing).

    Still I grabbed the save tool I linked at the start and used the command line patcher from the non wiki DLDI page (the command is "dlditool.exe scsd.dldi cart_save.gba") and it apparently worked. I lack a SCSD device to test it out (and the cart swapping nature of that program can trouble things) and I do not have my DS or GBA with me right now to otherwise try to confirm things.
     
  3. DSLSC
    OP

    DSLSC Member

    Newcomer
    28
    3
    Aug 27, 2013
    United States
    That program works perfectly. (Now I need the source...;).) The Win32-GUI patcher worked just fine, but I tried an unpatched version on my Supercard SD Mini...and it worked perfectly. (Supercard software "Patch" column was still "Fail.") Just what is required to make a DLDI-compatible GBA project in devKitPro? I'm assuming that a DLDI file needs included in the project, thus providing a patching "header"? I have downloaded the SCSD.DLDI's source code, and it looks like hardware-level access of a memory device. It seems to me that libfat wouldn't work at all without a DLDI file. But then why doesn't devKitPro complain about a missing file?

    P.S. I've spent a couple of months writing a fully integrated BASIC and ASM IDE for the GBA in 100% ARM ASM, and it works pretty good. Called "bASMic", I am hoping to add DLDI support for true file load/save (rather than using only gamesave...which does have its place, though.) In the past few days, I added PS/2 keyboard support, which makes typing a lot easier and faster. If you think there might be interest in such a program here, I'd gladly post it. NOTE: I designed it for the purpose of easy hardware interfacing to the link port. (Electronics hobbyists, anyone?) It has rudimentary graphics support (line, pixel, rectangle, ellipse, etc.) Math, strings, port interfacing, etc. all supported, functioning. Interrupts seem slightly buggy, but they're not easy to support! Admittedly, I posted it on GBADev awhile back, but never heard anything.
     
  4. FAST6191

    FAST6191 Techromancer

    pip Reporter
    23,838
    9,723
    Nov 21, 2005
    United Kingdom
    Other than the occasional recompile and whatever I have done in ROM hacking I have not developed anything for the DS/GBA so I have never really had cause to get far into libfat/DLDI and I was not exaggerating when I said that was the only GBA DLDI program I know of*. I did have a look for the source of the other program on the page but did not get anything interesting as far as use of libfat/DLDI goes. I could sit here discussing possibilities of why it might not work (it could be anything from it was broken in a devkitpro revision, and DKP does change radically between revisions, and as nobody does GBA DLDI then nobody caught it right through to the DLDI patch being used being broken as far as the GBA side of things goes -- there have been various issues over the years with memory limits and more). Likewise the DLDI patches are typically just the read/write routines as the DLDI libraries want them (the whole idea was as new flash carts were coming out every week or so, read/write libraries were not typically that forthcoming from flash cart makers, read/write libraries often tended to fight with those from other developers if you tried to merge them together and all the old homebrew would then have to be recompiled for the new carts was to make the libraries generic and well have a dynamically linked device interface), I guess you could try http://chishm.drunkencoders.com/gba_nds_fat/ as the basis for something and it does seem to have read support for the SCSD, bonus is there seemed to be a DLDI backport for gba_nds_fat in case you do write yourself into a corner.

    *GBA homebrew did stick around quite a bit into the DS era, even to the point where we were all using NAND/removable based GBA slot cards and would be DS coders were told to learn the GBA first so I am not sure why more was never made.

    By all means post any homebrew like that you make up (about the only things we ignore are horribly racist/offensive stuff and recompilations of SDK/tutorial demos), how much discussion it generates seems to vary wildly (and if I am to be the one doing the predicting then unpredictably as well, give or take the obvious ones like an attempt to remake a java or flash interpreter even if it is a small subset of the general runtime) but such things are certainly welcome.

    The keyboard stuff. I saw the old GBA keyboard stuff ( http://www.brolinembedded.se/projects/keyboard/ ) and stuff like is described in http://reinerziegler.de/GBA/gba.htm but I did not expect to see much otherwise, consider me curious.
     
  5. DanTheManMS

    DanTheManMS aka Ricochet Otter

    Member
    4,330
    107
    Jun 2, 2007
    United States
    Georgia
    Ohhhdamn, I don't think I'm gonna be able to link you to the forum thread where it originated because the PocketHeaven forum suffered severe data loss, but I know that Dwedit managed to get a single version of PocketNES working with DLDI access, and it worked on my Supercard miniSD. I don't think he ever released the source though as it was abandoned. You could contact him on the PocketHeaven forums and see if he'll share it with you. In the meantime, here's the binary: https://dl.dropboxusercontent.com/u/59972490/vidjeogames/pocketnes_m3_test.z7 (it's a 7zip archive, dunno why the file extension is z7). I don't think saving was ever supported, though maybe it could read existing save files? Not sure, it's been a while.

    As FAST6191 said, the other major one would be chishm's SRAM dumper program called cart_save, which I verified does work:



    Part of the problem is that adding DLDI to your project automatically took up at least 32 KB of RAM. On the DS with its 4 MB of RAM this wasn't a problem, but on the GBA that amounted to 1/8 of its total 256 KB of RAM. Plus, GBA development had pretty much stagnated by the time gba_ds_fat finally evolved into the DLDI-capable libfat that very few program ever tried it. FAST6191 and I here have come up with a grand total of 2, and I highly doubt anyone else did.

    Much more common in the GBA era was GBFS, made by Tepples. Gives you FAT-like filesystem abilities within the GBA rom itself, even if you do have to rebuild the ROM to make changes. The base for that would be at http://pineight.com/gba/#gbfs but for a really good example of how it would be used in practice check out his GSM Player program, especially the go.bat file - http://pineight.com/gba/gsm/ (convert your mp3 files to *.wav format first so the sox.exe program can convert them).
     
  6. DanTheManMS

    DanTheManMS aka Ricochet Otter

    Member
    4,330
    107
    Jun 2, 2007
    United States
    Georgia
    Consider me curious as well. Up until right now I have never known another person to actually know about that "Keyboard Advance" project link, seems like a blast from the past to see it again. Somewhat related is the SNES-to-GBA cable I was never able to make because none of my GBA link cables had all 6 necessary pins (apparently only 4 pins are needed for basic link transfers so most cables went cheap and didn't include the others, surprisingly even the official GBA-to-Gamecube cable doesn't have all 6). I even got the patcher program to make that SNES controller adapter work on commercial roms and not just the specially-patched version of SNES Advance, all for naught. If you can find any use for that, I think I still have those binaries on my hard drive somewhere...

    EDIT: Found these binaries all in the same spot, probably related:
    https://dl.dropboxusercontent.com/u/59972490/vidjeogames/snesadvance_snespad.zip -- I think this was the version of SNES Advance with support for the SNES controller
    https://dl.dropboxusercontent.com/u/59972490/vidjeogames/snesadvancegbaccelerator.zip -- it was in the same folder but was more for the GBAccelerator hardware mod. Not quite so relevant.
    https://dl.dropboxusercontent.com/u/59972490/vidjeogames/snesgbapatcher.zip -- this patches commercial roms to respond to the SNES controller coming in over the link port.

    EDIT 2: I'm sorry to hear that you had a bad reception at the GBAdev forums. Those forums were the highlight of the GBA and DS homebrew development scenes back in the day, but as soon as the DSi launched the overall activity kinda started slowing down, all the way down to the deadness it is now. Quite a shame, really.
     
  7. DSLSC
    OP

    DSLSC Member

    Newcomer
    28
    3
    Aug 27, 2013
    United States
    Actually, as a matter of fact, bASMic's helpfile is compressed with ApLib (50% compression rate, and the decompression code is very short in ASM.) Thanks to Dwedit on GBADev, I have the ASM decompression source for Aplib from guess what: PocketNES! I have the source code for that entire project.
    Secondly, bASMic's filehandling (on cartridge gamesave FLASH/SRAM) is based on GBFS. Sure, putting files in a binary is certainly useable for reading data, but for writing a 1GB file to a SD Card? Nope.

    I've also heard that Pogoshell is an advanced GBA file handler for such things. However, it is not DLDI-compatible, and provides a perfectly black screen on the GBA and VisualBoyAdvance.

    Yes, Chism's SRAM dumper does work perfectly on my Supercard. Source, anybody?

    On to the PS/2 keyboard thing. Just connect a keyboard to the GBA's link port (keyboard CLK->GBA SC, keyboard DAT->GBA SI, keyboard VCC->GBA 3.3v, GND->GND), enable it on bASMic, and chances are high that it will work. For the purpose of minimizing CPU overhead, I am using the link port in shift-clock mode. (By the way, it appears that both shift-clock and I/O port mode appear to be simultaneously useable.) Well, the keyboard transmits a start bit, 8 bits of data, a parity bit and a stop bit. The GBA's shift-clock link port only reads 8 bits before stopping. OK, so we got the start bit, and seven data bits. As it turns out, then only F5 and F7 have the same scan code...all the other keys are useable! In bASMic, I have the link port interrupt process the keyboard data, and then delay for the remaining bits to be ignored. (I should probably make "smart" code to physically watch the bits go by.) All regular keyboards I tested worked fine. USB keyboards (with a PS/2 converter) don't work at all. Super-specialized PS/2 keyboards may not work.
     
  8. FAST6191

    FAST6191 Techromancer

    pip Reporter
    23,838
    9,723
    Nov 21, 2005
    United Kingdom