flashcard-bootstrap
The DS scene may be well over 15 years old, but DS flash cartridges, to this day, makes up an integral part of it. However, during these trying times and the waning popularity, do we know everything about them? The hundreds or so cartridges that have been, and still are, being mass-produced?
flashcard-bootstrap: what is it?
A major portion of my research, development and documentation has been a tool called flashcard-bootstrap.
What does it do? Simple, it is designed to replace these flash cartridges’ typically proprietary menu. It will load a /boot.nds on the SD card and install the necessary cartridge drivers (known as DLDI, dynamically linked device interface), allowing the end user to comfortably load any homebrew application of their choice.
The current state of things
Of course, simply compiling flashcard-bootstrap and bundling the driver is not enough. Many flashcarts are designed differently, and have a few “limitations”, so to speak. These limitations, in a non-exhaustive list, range from:
- Poor implementation of the bootloader stored in the cartridge flash.
- For easier software updates, often the cartridge flash contains just enough to load the menu from the SD card, which has different file names depending on the cartridge. (hereon “boot file”)
- A proper implementation would check the target application’s header, to see where the executable binaries are to be loaded in memory.
- Some implementations, unfortunately, hardcode these addresses, leaving it to the developer of the target application to fix it themselves…
- The boot file may be a custom file format.
- The M3 DS Real, and its descendant “clones”, use the “DSBooter” file format, which differs from a usual NDS ROM format.
- Some older original R4-based clones would store patches to the original R4’s kernel to add functionality.
- The bootloader may contain integrity checks on the boot file.
- This may be live integrity checks, encryption, etc.
- A combination of the above…
Freedom of choice
Today, we are leaning towards free-and-open-source solutions more than ever in our community, and these flashcarts are everything but.
For some people, the manufacturer-provided software (hereon “kernel”) is more than enough; it can load their games, homebrew applications, and more or less doesn’t break functionality.
But the idea of free software is the freedom to use, study, share and modify; some users may simply not like how the provided kernel looks and performs, some may have a bias against piracy (which these carts were created specifically for), and some just want a new coat of paint.
Where flashcard-bootstrap falls in this
Enter flashcard-bootstrap. The project was inspired by devkitPro’s NDS Homebrew Menu and TWiLight Menu++, and heavily based on the former’s source code. devkitPro does support a handful of flashcarts via their own research, but that wasn’t enough for me. I wanted to expand on it, document more cartridges, make it accessible for more people who may have, ah, obscure carts.
flashcard-bootstrap loads a homebrew on the SD card named /boot.nds and sets up all the hardware abstractions needed for it to work, allowing users to simply download any homebrew application from the Internet (or making one themselves), renaming it, and Bob’s your uncle.
It provides, to an end user the freedom to use whichever software they want without dealing with a proprietary loader interface, and, to a homebrew developer, a unified experience across as many different cartridges out there, making it “just work” on as much hardware as possible.
Taking Homebrew Menu’s BootStrap code, I decided to tweak a few configurations to adapt to the “limitations” of various flash cartridges as shown in the above list. Many of these were a simple task of adjusting the memory addresses to what the bootloaders expect, and it worked, just like that.
Some were not as simple, however.
Hacky solutions: if it works it works
Example 1: GMP-Z003
Take, for instance, the M3i Zero (GMP-Z003) flashcart.
The boot file is SYSTEM/_M3_MENU.DAT. Unfortunately, it matched no file formats, and was heavily encrypted.
However, upon diff-ing behaviours of every kernel version released by the M3 Adapter team, I found a debug string printed to the screen when there was no other files, which showed… yet another file path?
From there it was a matter of repacking flashcard-bootstrap into the DSBooter file format and utilizing the kernel’s boot file as a Stage 1 launcher, which would launch flashcard-bootstrap, giving me the freedom once again.
Example 2: The bomb that doesn’t really do much, but annoys you to no end
Another example are “timebomb” carts.
These are known for having a date checker in the kernel, and, if the current date was later than the one hardcoded, the kernel would abort.
The boot file, unfortunately, has integrity checks all over the place, but a famed developer from the heyday of DS homebrew, Xenon++, came in clutch with a script to bypass it, which, with some help, I then rewrote it to Python. And off we are to the races again.
This post is just a snippet of the supported flashcarts, in simplified detail. You can always refer to the developer notes to see more in-depth detail on what I have uncovered thus far.
We’re still a long ways from having a fully-free flashcart (or maybe we aren’t?), but my hopes for this project is that it helps someone get started with it.