12

The Supercard is a flash cart for the Game Boy advance which can play ROMs and other files off of assorted flash memory. I recently found my Supercard SD and Superkey for NDS, which acts as a Passcard/Nopass device (allow DS and ROMs to boot from the GBA slot). I also remember that in order to run any ROMs from the Supercard on the DS itself, you needed to "patch" them with a special tool made by Supercard. It looked something like this:

Supercard Software v2.44

This software is no longer supported by the manufacturer, and only worked on Windows.

My Question

What exactly did this "patching" utility do to the GBA and DS ROM files? Why was it necessary to "patch" the ROM images before running them on the actual hardware from the Supercard?

My end goal is to create a new Mac/Linux tools that does the patching for me so I don't need to run this software via Wine or VM.

Improve this question
4
  • To anyone who believes this question is out of scope, please head to meta: Are questions about the Supercard (CF/SD/Lite/Rumble) for GBA and NDS on-topic?.
    – JAL
    Nov 16, 2016 at 3:46
  • 1
    For homebrew software, there is dlditool, which can be run on your PC, or even on your DS on DSLinux.
    – ninjalj
    Nov 17, 2016 at 0:55
  • @ninjalj I don't believe they serve the same role as dlditool, which simply adds in support for various storage interfaces for the different cards.
    – forest
    Sep 15, 2018 at 2:01
  • 2
    @JAL Did you ever happen to create the Mac/Linux tool?
    – forest
    Mar 30, 2019 at 1:54

2 Answers 2

Reset to default
16

The GBA's memory controller can be configured using WAITCNT, an MMIO port at 0x04000204, to use slow or fast timing when accessing the Game Pak slot. The BIOS boots up in slow mode, in case Nintendo would release games on slow ROM. But Nintendo ended up releasing all games on fast ROM, and when a game starts, it writes a value to WAITCNT to enable fast access.

The SuperCard is made to be cheap, not fast. When you start a game, the firmware copies it from the SD card to 32 MiB of DRAM that can't keep up with fast access. If you start a game, it will crash soon after the WAITCNT write because the memory can't get the data lines to settle by the time the GBA's memory controller in fast ROM mode expects them to have settled. So the patch removes the write to WAITCNT, keeping the system in slow mode and thus within the RAM's spec. It's not necessary for homebrew games that do not write to WAITCNT or for "multiboot" game demos smaller than 256 KiB that load entirely into the GBA's RAM.

A patch can do other things.

  • Changing the save method: GBA games can save to an 8-bit SRAM, a serial EEPROM, or a parallel flash. SuperCard hardware supports only SRAM. A patch changes the game to use SRAM.
  • Save to SD card: The SuperCard's SRAM is volatile memory and will lose data if the system is powered off longer than the capacitor can continue to supply current. Normally, after saving the game, the user needs to quickly power cycle the GBA and restart the menu to copy the SRAM back to the SD card. The patch does the copying within the game under certain conditions.
  • Patching DS games: When used in SLOT-2 of a suitably modded Nintendo DS, SuperCard can play DS games. But if they're bigger than a couple MB, they will need to load data from the Game Card in SLOT-1 during play. (The N64 and DS cartridge interfaces behave more like a CF or SD card than like traditional ROM.) Patching redirects these accesses to SLOT-2.
Improve this answer
5
  • Why did the SuperCard not apply this patch on-the-fly when loading the game?
    – forest
    Sep 15, 2018 at 2:07
  • @forest I don't know for sure. Presumably it'd increase loading time, or specific ROMs needing special handling would need to be looked up in a database that has to be stored somewhere.
    – Damian Yerrick
    Sep 15, 2018 at 2:48
  • That makes sense. I know that it would automatically DLDI patch ROMs, at least.
    – forest
    Sep 15, 2018 at 2:49
  • 1
    @forest - the SuperCard doesn't see the actual code executed, just the image. What happens when the byte sequence occurs e.g. in a random data structure somewhere? Or doesn't occur at all, as can happen with e.g. self-modifying code? (And making this more difficult: it's memory-mapped. There's no convenient WRITE_IO(WAITCNT, val) instruction.)
    – TLW
    Jan 31, 2022 at 3:52
  • 1
    @TLW For DLDI patching at least, it's certainly possible for it to accidentally patch the wrong location because of bad luck, at least if my memory is correct. I think there are a few different levels which determine just how aggressive its search and function hooking is. But the chances are still low enough that on-the-fly patching is not too risky.
    – forest
    Mar 11, 2022 at 22:23
2

I don't know if this applies to this card in particular, but in all likelihood, one of the things the patch program does is to patch in custom save game functionality so that the ROMs can write to the flashcard rather than expecting their own flash memory to be present. Later cards were sophisticated enough to do this patching on-the-fly. I'd recommend if you want specifics to compare the output of the patcher to the input in a hex editor.

(My view is that the Nintendo DS is possibly not retro since you can still buy brand new games for it, albeit I don't believe they're actually being made any more. The GBA certainly is retro though.)

Improve this answer
2
  • 1
    Great first post! I hadn't considered patching the save mechanism to write to the GBA flash cart itself. Also, I invite you to post the second part of your answer on my linked meta question to discuss the scope of the Nintendo DS on Retrocomputing.
    – JAL
    Nov 16, 2016 at 14:38
  • 1
    Since the Supercard SD was a Slot 2 cart, I guess it also patches accesses to Slot 1 to redirect it to the SCSD.
    – ninjalj
    Nov 17, 2016 at 0:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.