Hacking Trying to make the Supercard suck less...

[admin]

Intro

If you've been looking for a GBA flashcart recently, you'll probably be aware of the fact that the functional cheap flashcarts of old like the EZ Flash IV just aren't around any more. There are high end carts which are better like the Everdrive GBA and EZ Flash Omega Definitive Edition, but they'll easily set you back some £80-£90. On the other hand, it's easy to find cheap listings for this little guy.

This seems to be a clone of the Supercard Mini SD, albeit with the obsolete and obscure Mini SD slot replaced by a micro SD slot instead (interestingly, the shell still has a mini-SD sized hole). You can grab it for about £20 and it's widely available on eBay or Aliexpress. I already have a few good GBA flashcarts but I wanted to buy one of these to find out just how capable it really was. As it turns out, this cart suffers a lot of heavy limitations.

• The cart uses slow SDRAM, meaning GBA games must be patched to prevent reducing wait games which introduces lags and slowdowns in some games.
• The patching above requires the use of external client software. I had some problems using this due seemingly to DPI scaling cropping parts of the UI. The client also needs to perform SRAM patching for many games to save.
• You can somewhat mitigate the slowdown by using prefetch patching, but that's another tool you have to use.
• The cart does not support SDHC, so you're limited to only 2GB Micro SD cards or less.
• Unlike most flashcarts, SRAM is not automatically copied to the SD card on reboot. You have to copy it ingame with a patch and a key combo, or by selecting the save file in the file browser after rebooting.

Some of these limitations are hardware-based, but others are due to poor software.

• The client software seems unnecessary. The EZ Flash IV 2.0 firmware update added the ability for the cart itself to perform SRAM patching. Maybe a firmware update could add this and also waitstate/prefetch patching, removing the need for client software.
• The EZ Flash IV 2.0 also added SDHC support. Based on the open source DLDI drivers available, it looks like the SD card is mainly software driven - so maybe it's possible here to patch in SDHC support?
• Automatically copying SRAM on reboot is an obvious and easy thing to fix.

With that all in mind, I decided it'd be an interesting venture to see whether I could get an alternative firmware booting on the Supercard and then how far it would be possible to push it. Spoiler alert for those who aren't interested in reading the whole thing - I wasn't able to get very far.

Accessing flash
At this point, I didn't have any real clue what sort of hardware is in the Supercard. Unlike say the EZ Flash Omega/Definitive Edition, there's no documentation out there and only a few code samples. Fortunately I was able to find a few existing tools for flashing a Supercard SD. Those are flashmp and scflash_sd. Source wasn't available for these tools but I was able to understand just enough of the assembly to figure out how to access the internal flash chip which stores the firmware. With that I was able to find out the size of the flash at 512KB, dump its contents on the latest 1.85 firmware (sc.zip), and write a small NDS program which can flash an alternative firmware to it (sckill.zip).

Writing something bootable

With that out of the way it was time. I noticed when trying to dump the supercard's firmware that the full firmware chip isn't readable unless some magic pokes are done, or else only the top ~0x400 bytes or so. A normally built GBA homebrew wouldn't run unless that space were unlocked, so I needed to write a quick bootloader which would enable this before handing control over to whatever GBA multiboot or NDS binary you wanted to run. This has been attached as scfw.zip. Combining it with the Hello World example included with devkitARM, I was finally able to get my Supercard to boot to something other than the official firmware.

Reading the SD card

At this point I wanted to be able to get filesystem access. I just want to be read out any file from the SD card, without caring much about how it's done for the time being. libgba provides a few different builtin drivers for libfat to use, but even though _io_scsd is present, this seems to be incompatible with the cartridges I have.

// Include known io-interfaces:
#include "io_mpcf.h"
#include "io_m3cf.h"
#include "io_sccf.h"
#include "io_scsd.h"
#include "io_m3sd.h"

static const DISC_INTERFACE* discInterfaces[] = {
    &_io_mpcf, &_io_m3cf, &_io_sccf, &_io_scsd, &_io_m3sd
};

const DISC_INTERFACE* discGetInterface (void)
{
    int i;

    for (i = 0; i < (sizeof(discInterfaces) / sizeof(DISC_INTERFACE*)); i++) {
        if (discInterfaces[i]->startup()) {
            return discInterfaces[i];
        }
    }
    return NULL;
}

So I changed tack and decided I'd see if I can get NDS mode software to read the SD card. Rather than relying on static drivers, the default libfat uses DLDI instead. Chishm's old webpage still seems to be up with a few options, but these drivers are also mirrored on github.

Chishm's driver which seems to be the same one from libgba always failed to init, but the alternative driver from Moonshell seemed to work! I patched nds-hb-menu and launched it through the official Supercard firmware and was able to see the SD card contents just fine.

But look again at that comment on the alternative driver - "Must be booted from Supercard firmware." I had hoped it'd work regardless, but after flashing the Supercard with this version of nds-hb-menu...

Drat! And this is where things are currently stuck. I have no idea what magic the Supercard firmware performs which makes this driver able to work. I could try to dig into the official firmware a little more, but that sort of reverse engineering is a little daunting! Anyway, I'm glad I was able to make it this far, maybe I'll figure it out in the future but for now this is where things stand.