gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > libfat and swapping between microSD adapters and Game Cards?

#121256 - tepples - Sat Mar 10, 2007 8:45 pm

I'm planning to make a trainer for a DS game. First off: it does not involve ROM dumping, but it does involve save dumping from an authentic DS Game Card. The intended use case is the following:
  1. Load program and datafiles from microSD card in SLOT-1
  2. Player ejects microSD adapter from SLOT-1
  3. Player inserts Game Card
  4. Program reads 256 KiB serial flash
  5. Player ejects Game Card
  6. Player reinserts microSD adapter in SLOT-1
  7. Portions of savegame data are written to microSD card

What's the cleanest way to use libfat to cleanly shut down the card and bring it back up? Here's what I'm thinking about so far:
Code:
// Untested, possibly pseudocode

unsigned char savegameData[256*1024];

void checkForDSDump() {
  fatUnmount(PI_DEFAULT);
  alert2Opts("Please remove the flash card and insert your "
             "Game Card.",
             "OK", "Cancel");
  dumpFlashUsingCardme(savegameData);
  alert2Opts("Please remove the Game Card and insert your "
             "flash card.",
             "OK", "Cancel");
  fatRemount(PI_DEFAULT);
}

But fatRemount() does not exist in .../libnds/include/fat.h, and
fatMountNormalInterface() does not take PI_DEFAULT.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#121263 - Lick - Sat Mar 10, 2007 9:28 pm

fatInitDefault()?
_________________
http://licklick.wordpress.com

#121264 - tepples - Sat Mar 10, 2007 9:30 pm

But doesn't calling fatInitDefault() again leak the cache memory? Or does fatUnmount() free it?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#121271 - Ryan FB - Sat Mar 10, 2007 11:58 pm

This won't work easily on the two Slot-1 flashcarts/adapters I've tried it on. The DS-X causes my DS to reset when it's inserted back in, and the R4 depends on the DS BIOS startup procedure to init it correctly (meaning you'll have to find a way to emulate this before you can init FAT on it after reinserting it with your program running).

#121277 - chishm - Sun Mar 11, 2007 1:21 am

Your code is almost correct, but since you only want/need to unmount and remount the Slot-1 interface, use PI_SLOT_1.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

#121280 - tepples - Sun Mar 11, 2007 2:04 am

Is there a way for the code to tell which slot is the default? Or should code just probe SLOT-1 and SLOT-2? Is there full documentation for libfat that addresses these issues?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#121284 - chishm - Sun Mar 11, 2007 4:05 am

Slot-1 is the prefered default. If no card is inserted in Slot-1, then Slot-2 is set as the default. There isn't a function to tell which is set as the default, but if fat1:/. can't be opened for diretory listing while fat2:/. can, then it is safe to assume that Slot-2 is the default.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

#121288 - tepples - Sun Mar 11, 2007 7:29 am

When remounting with fatMountNormalInterface(PI_SLOT_1, cacheSize), which cacheSize should I use? Or (per Ryan FB's concern) should I just expect SLOT-1 users not to be able to swap cards?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#121308 - chishm - Sun Mar 11, 2007 12:39 pm

Default cache size is 8 for the DS. You may indeed run into trouble when trying to re-init the slot-1 cards, though. The only solution would be initializing the card as the BIOS does it, but there's no public code to do that.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

#121310 - Lick - Sun Mar 11, 2007 12:58 pm

Slot-1 cards will give you a header and the startup binaries form both ARM7 and ARM9. Once you have received them, the device put itself in a different state (referred to as 'second state'). We have no idea how to put them back in the original state through software commands, the only method known is to re-insert the card.

The problem with homebrew Slot-1 devices is that you don't know what the ARM7 startup binary does. The ARM9 probably puts itself in a PassMe loop, but the ARM7 might execute some fatal card commands to put the device into a third state, one that has access to the media-storage. (Ryan FB kind of confirmed this for R4?)

Perhaps there is no third state, in that case, you only need to read out the header and startup binaries so the card put itself into the second state. After that, you may hope that libfat initializes.

To my knowledge this is exactly what the DS BIOS does:
1) Read header from card.
2) Store parts of header in 0x27FFE00 (Main RAM).
3) Read binaries from card. Decrypt, decompress and execute.
_________________
http://licklick.wordpress.com

#121316 - chishm - Sun Mar 11, 2007 2:29 pm

Lick wrote:
To my knowledge this is exactly what the DS BIOS does:
1) Read header from card.
2) Store parts of header in 0x27FFE00 (Main RAM).
3) Read binaries from card. Decrypt, decompress and execute.

Yeah, I know that bit already, it's used by Nitro Hax :-p
It adds around 8 extra KiB to get all that, though, and I'm not sure it's worth it.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

#121387 - HyperHacker - Mon Mar 12, 2007 3:18 am

Lick wrote:
The problem with homebrew Slot-1 devices is that you don't know what the ARM7 startup binary does.

Why not? Can you not dump it and find out?
_________________
I'm a PSP hacker now, but I still <3 DS.

#121448 - Lick - Mon Mar 12, 2007 3:00 pm

There is exactly one guy who will spend many days and eventually do that, the person is probably..



You.
_________________
http://licklick.wordpress.com

#121489 - tepples - Mon Mar 12, 2007 7:03 pm

chishm wrote:
Lick wrote:
To my knowledge this is exactly what the DS BIOS does:
1) Read header from card.
2) Store parts of header in 0x27FFE00 (Main RAM).
3) Read binaries from card. Decrypt, decompress and execute.

Yeah, I know that bit already, it's used by Nitro Hax :-p
It adds around 8 extra KiB to get all that, though, and I'm not sure it's worth it.

How much space is available in the R4DS DLDI driver? Can't a DLDI be up to 32 KiB, with most drivers not using even half of that?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#121504 - Lick - Mon Mar 12, 2007 7:25 pm

It's rather a standard procedure for all Slot-1 devices, shouldn't it therefore be in libfat? (Or not, considering what you can do with the code.)
_________________
http://licklick.wordpress.com

#121519 - HyperHacker - Mon Mar 12, 2007 10:03 pm

Lick wrote:
There is exactly one guy who will spend many days and eventually do that, the person is probably..



You.

I don't have a slot-1 device.
_________________
I'm a PSP hacker now, but I still <3 DS.

#121538 - tepples - Tue Mar 13, 2007 12:12 am

Besides, only chishm knows how to dump devices that look like DS Game Cards, and he's not telling for fear that the pirates will learn.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#121554 - Ryan FB - Tue Mar 13, 2007 3:10 am

tepples wrote:
Besides, only chishm knows how to dump devices that look like DS Game Cards, and he's not telling for fear that the pirates will learn.

I haven't tried it myself yet, but it seems like all the information necessary to do this is available on GBATEK.

#121612 - Lick - Tue Mar 13, 2007 2:55 pm

It's not THAT hard to dump. -_- Disassembling the dump is what's hard.
_________________
http://licklick.wordpress.com

#122267 - cory1492 - Sun Mar 18, 2007 7:03 am

How about this... a little more end user complicated but it could (maybe) be made faster than soft reset for all slot 1 cards.
1. Load program and data files from microSD card in SLOT-1
2. Player ejects microSD adapter from SLOT-1
3. Player inserts Game Card
4. Program reads and compresses 256 KiB serial flash (not always 256)
5. Player ejects Game Card
6. Player reinserts microSD adapter in SLOT-1
7. Compressed flash data is written to adapter's save chip, along with some type of flag to tell the app to write the save out with perhaps a file name, user prompted to shut down and reboot.
8. next program boot, the data on the save chip is converted to a regular save file, and intermediately stored however the adapter normally stores it's save chip data.

Of course, this assumes a couple things. Save chip being the ident factor for which microSD adapter was reinserted, save chip being available on reinsert... I only know for shure at this point MK5 (and likely all the other similar cards) ID as a 2mbit save chip using cardme.

Also provides the benefit of having access to the DS game's clean header (nearly, there seem to be a couple that don't using the stuff in libnds) every time to make a sensible file name from.