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 > How to detect DLDI patching ?

#149325 - PypeBros - Fri Jan 18, 2008 1:51 pm

I am trying to load a .nds from another .nds file, reusing the chism stub and some code from DSChannels. As far as i can tell, there is no way to work around the need for a "card.dldi" file stored at a well-known location on the media card, right ?

the .nds to be loaded comes from a network download, so i'd rather avoid to require pre-patching of the file and would like the patch to be applied "live" at run-time. Still, i'd like to allow users who don't need a .dldi patch (e.g. because they have a linker directly supported by libfat) to work without it, which means i need a way to detect whether the driver the libfat is using right now comes from a patch or is a "native" part of the libfat.

Any clue on how i should proceed ?
(i was thinking of comparing the address of the driver's readblock funtion with the end of compile-time size of the binary, but i fear that'd be a too hackish way to proceed)...

Thanks in advance.
_________________
SEDS: Sprite Edition on DS :: modplayer

#149333 - Lick - Fri Jan 18, 2008 3:58 pm

If the .nds is loaded from network, couldn't you tell the file server to patch it with the device's DLDI patch before sending it?

Also, how can the receiving.nds not be DLDI patched if it needs to write a downloaded.nds? Or is the downloaded.nds only in memory?
_________________
http://licklick.wordpress.com

#149337 - PypeBros - Fri Jan 18, 2008 5:33 pm

Lick wrote:
If the .nds is loaded from network, couldn't you tell the file server to patch it with the device's DLDI patch before sending it?

That would require the DS to identify the device type, send it to the server, have some sort of .cgi script to perform the patching and host .dldi patches altogether with the offered .nds ... i have to admit i'd prefer an alternate solution ...

Quote:

Also, how can the receiving.nds not be DLDI patched if it needs to write a downloaded.nds? Or is the downloaded.nds only in memory?

Well, i might have receiving.nds not to be patched (and downloaded needing no patching), or i might have receiving.nds patched (either by the user or by the linker). What i'd like to avoid is requiring the user to have card.dldi when the linker needs no patching.

I tried something like
Code:

 if (fat && fat->disc &&
      fat->disc->fn_readSectors>(void*)&__text_end) {
    char* name=(char*)&(fat->disc->ioType);
    iprintf("detected a DLDI driver in use for %c%c%c%c\n",
       name[0],name[1],name[2],name[3]);
    return true;
  }

assuming that the code for DLDI "readSectors" would be appended after the normal .text section, but it doesn't seem to work properly. (e.g. it always thing there is a built-in driver)

edit: i'm using a Supercard SD (slot 2) for testing. Could it be that the libfat prefers its internal driver to the DLDI one ? Even after i applied dlditool ?
_________________
SEDS: Sprite Edition on DS :: modplayer

#149340 - olimar - Fri Jan 18, 2008 6:27 pm



Last edited by olimar on Wed Aug 20, 2008 10:53 pm; edited 1 time in total

#149382 - PypeBros - Sat Jan 19, 2008 12:35 pm

i'm not sure to understand what you suggest, olimar. A built-in driver for SCSD, for instance, define its feature as
Code:

 FEATURE_MEDIUM_CANREAD | FEATURE_MEDIUM_CANWRITE | FEATURE_SLOT_GBA,


and despite it's not a DLDI plugin, it would be considered as "DLDI driver" by your test.


???
_________________
SEDS: Sprite Edition on DS :: modplayer

#149431 - olimar - Sun Jan 20, 2008 12:46 am



Last edited by olimar on Wed Aug 20, 2008 10:53 pm; edited 1 time in total

#149438 - Bloodypriest - Sun Jan 20, 2008 1:46 am

Not sure if it's gonna be easy or not but can't you just memcpy the DLDI driver from your master.nds to your slave.nds*.

From what I can tell, you are already able to apply a DLDI patch at runtime, except you do it from a card.dldi file. So why not locate the current DLDI driver in memory instead?

* Sorry if I changed the names but I thought it would be clearer that way which was which.

#149455 - PypeBros - Sun Jan 20, 2008 12:11 pm

olimar wrote:

Maybe this?
Code:
if (fat && fat->disc && *(((u32*)fat->disc)-0x18)==0xBF8DA5ED) {
    //DLDI driver in use
}

This is checking whether there is a DLDI header *before* the io_interface description, isn't it ?
Hmm ... That might work (unless the magic number is erased by the libfat on init, but i guess libfat won't mess with such things).

Quote:

Not sure if it's gonna be easy or not but can't you just memcpy the DLDI driver from your master.nds to your slave.nds*.

From what I can tell, you are already able to apply a DLDI patch at runtime, except you do it from a card.dldi file. So why not locate the current DLDI driver in memory instead?

I haven't investigated this so far. Clearly it could be done if DLDI drivers were just "appended" to a .nds binary, but they are also patched, to fit their new location. Whether it can be "detached" or not has never been tried afaik, and the loader i'm using does not seem to provide that.
_________________
SEDS: Sprite Edition on DS :: modplayer

#149465 - Lick - Sun Jan 20, 2008 3:15 pm

Chishm has already proven that it works. His VRAM boot stub gets patched before it's executed. There's hackery involved so check its source.
_________________
http://licklick.wordpress.com

#149510 - PypeBros - Mon Jan 21, 2008 10:24 am

Lick wrote:
Chishm has already proven that it works. His VRAM boot stub gets patched before it's executed. There's hackery involved so check its source.

thanks. I'll google that.
_________________
SEDS: Sprite Edition on DS :: modplayer