Filesystem not working on M3, OK on emus

jotd
Posts: 32
Joined: Sun Dec 13, 2009 9:43 pm
Location: France
Contact:

Re: Filesystem not working on M3, OK on emus

Post by jotd » Sat Dec 26, 2009 6:36 pm

vuurrobin wrote:I get the same result here.

but IIRC, no$gba executes the nds file from slot 2, and slot 2 works differently than slot 1 (slot 2 is memory mapped). maybe that is how libfilesystem gets the nds file, because there is only 1 nds file loaded at the memory of slot 2.


is there a way to figure out if an nds file is executed from slot 1 or 2?
You're right, No$GBA must do this, that's the explanation. So you mean that programs from slot 2 can run from ROM (GBA mode) and programs from slot 1 run from RAM + filesystem from cart/SD. Sounds logical.

On my M3 card it's only possible to execute from slot 1 since I don't have the full pack (only the useless "rumble" pack) so I cannot run GBA games or NDS games through slot 2.

So since for example EFS can manage (WarHawk works OK on my M3 and uses EFS), even if I don't like EFS because it's not 100% posix (dir szcan is proprietary for instance), maybe we can hack something to force argv[0] to something correct.

Since main passes **argv, if we replace the pointer of argv[0] by one of our strings it may work for NitroFS right?

StevenH
Posts: 133
Joined: Sun Feb 22, 2009 7:59 pm

Re: Filesystem not working on M3, OK on emus

Post by StevenH » Sat Dec 26, 2009 7:30 pm

Just use the homebrew menu available from the devkitPro svn area on sourceforge. It works on slot-1 cards, and allows you to use nitroFS / libfilesystem perfectly. Don't try and do a dir scan for your nds file since someone may change the file name, infact I have done this for some games / apps as I like to keep things nice and neat on my card, when your forced to keep the file name to what ever the dev wanted it's got nothing to do with the actual game / app it's a PITA!

GNU Tar download Project link

jotd
Posts: 32
Joined: Sun Dec 13, 2009 9:43 pm
Location: France
Contact:

Re: Filesystem not working on M3, OK on emus

Post by jotd » Sat Dec 26, 2009 10:36 pm

StevenH wrote:Just use the homebrew menu available from the devkitPro svn area on sourceforge. It works on slot-1 cards, and allows you to use nitroFS / libfilesystem perfectly. Don't try and do a dir scan for your nds file since someone may change the file name, infact I have done this for some games / apps as I like to keep things nice and neat on my card, when your forced to keep the file name to what ever the dev wanted it's got nothing to do with the actual game / app it's a PITA!

GNU Tar download Project link
Ok to use homebrew menu (BTW any .nds direct download? I can recompile it but ...)

What I could do it 1) scan the card to find my .nds file if argv not avail/nitrofs cannot be initialized. 2) If I find the .nds file, then init nitroFS after having hacked argv[0]. Will try this. ATM I'm distributing my game with .nds file without any files in it + files to put at the root of the card (like Lemmings or Reminiscence) and it works with fatInitDefault.

StevenH
Posts: 133
Joined: Sun Feb 22, 2009 7:59 pm

Re: Filesystem not working on M3, OK on emus

Post by StevenH » Sun Dec 27, 2009 6:33 pm

jotd wrote:Ok to use homebrew menu (BTW any .nds direct download? I can recompile it but ...)

What I could do it 1) scan the card to find my .nds file if argv not avail/nitrofs cannot be initialized. 2) If I find the .nds file, then init nitroFS after having hacked argv[0]. Will try this. ATM I'm distributing my game with .nds file without any files in it + files to put at the root of the card (like Lemmings or Reminiscence) and it works with fatInitDefault.
There's no link to a pre-compiled nds file that I'm aware of. I would seriously rethink your approach as there is no way to confirm the name of the NDS file you are searching for, and when launched from the homebrew menu, the nitroFS init / fat init functions also set the current directory to the directory that your software is in, which means your game uses less space in the root folders (IIRC FAT12/16 only allowed a limited number of entries in the root folder) limited space for file entries.

jotd
Posts: 32
Joined: Sun Dec 13, 2009 9:43 pm
Location: France
Contact:

Re: Filesystem not working on M3, OK on emus

Post by jotd » Sun Dec 27, 2009 8:18 pm

StevenH wrote:
jotd wrote:Ok to use homebrew menu (BTW any .nds direct download? I can recompile it but ...)

What I could do it 1) scan the card to find my .nds file if argv not avail/nitrofs cannot be initialized. 2) If I find the .nds file, then init nitroFS after having hacked argv[0]. Will try this. ATM I'm distributing my game with .nds file without any files in it + files to put at the root of the card (like Lemmings or Reminiscence) and it works with fatInitDefault.
There's no link to a pre-compiled nds file that I'm aware of. I would seriously rethink your approach as there is no way to confirm the name of the NDS file you are searching for, and when launched from the homebrew menu, the nitroFS init / fat init functions also set the current directory to the directory that your software is in, which means your game uses less space in the root folders (IIRC FAT12/16 only allowed a limited number of entries in the root folder) limited space for file entries.
So you mean that if I take WarHawk (using EFS) and that I rename the .nds file, the game won't start then?

StevenH
Posts: 133
Joined: Sun Feb 22, 2009 7:59 pm

Re: Filesystem not working on M3, OK on emus

Post by StevenH » Sun Dec 27, 2009 8:55 pm

jotd wrote:
StevenH wrote:
jotd wrote:Ok to use homebrew menu (BTW any .nds direct download? I can recompile it but ...)

What I could do it 1) scan the card to find my .nds file if argv not avail/nitrofs cannot be initialized. 2) If I find the .nds file, then init nitroFS after having hacked argv[0]. Will try this. ATM I'm distributing my game with .nds file without any files in it + files to put at the root of the card (like Lemmings or Reminiscence) and it works with fatInitDefault.
There's no link to a pre-compiled nds file that I'm aware of. I would seriously rethink your approach as there is no way to confirm the name of the NDS file you are searching for, and when launched from the homebrew menu, the nitroFS init / fat init functions also set the current directory to the directory that your software is in, which means your game uses less space in the root folders (IIRC FAT12/16 only allowed a limited number of entries in the root folder) limited space for file entries.
So you mean that if I take WarHawk (using EFS) and that I rename the .nds file, the game won't start then?
It should not, but since the only way I have of launching homebrew is the homebrew launcher which supplies the argv information, and I think Warhawk uses an advanced scan dir that checks for argv, I can't test it myself.

jotd
Posts: 32
Joined: Sun Dec 13, 2009 9:43 pm
Location: France
Contact:

Re: Filesystem not working on M3, OK on emus

Post by jotd » Sun Dec 27, 2009 9:33 pm

StevenH wrote:
It should not, but since the only way I have of launching homebrew is the homebrew launcher which supplies the argv information, and I think Warhawk uses an advanced scan dir that checks for argv, I can't test it myself.
scanning dirs cannot retrieve argv. Only the launcher (homebrew or the card) can retrieve argv. Scanning dirs can only guess argv. Mmmh by checking .nds file sizes can be an idea. But it requires pre-knowning of the size, and a finished product, or a post-build step to insert the size at the correct location in the code. ok, those are only ideas.

StevenH
Posts: 133
Joined: Sun Feb 22, 2009 7:59 pm

Re: Filesystem not working on M3, OK on emus

Post by StevenH » Sun Dec 27, 2009 9:56 pm

jotd wrote:scanning dirs cannot retrieve argv. Only the launcher (homebrew or the card) can retrieve argv. Scanning dirs can only guess argv. Mmmh by checking .nds file sizes can be an idea. But it requires pre-knowning of the size, and a finished product, or a post-build step to insert the size at the correct location in the code. ok, those are only ideas.
No Advanced Dir Scan means it checks for a pre-existing passed argv, if it exists it uses than instead of scanning. Any way you look at directory scanning for your nds file is a waste of time. No good checking the file sizes, what if there's 2 files with exact same size? Also doing the post-build injection of the file size would not be very effective since you will have to make the injection code work on a moving target since you have no guarantee that the location of the size will be in the same location each time, and I'm not sure how you will work out the location initially.

jotd
Posts: 32
Joined: Sun Dec 13, 2009 9:43 pm
Location: France
Contact:

Re: Filesystem not working on M3, OK on emus

Post by jotd » Sun Dec 27, 2009 10:23 pm

StevenH wrote:
jotd wrote:scanning dirs cannot retrieve argv. Only the launcher (homebrew or the card) can retrieve argv. Scanning dirs can only guess argv. Mmmh by checking .nds file sizes can be an idea. But it requires pre-knowning of the size, and a finished product, or a post-build step to insert the size at the correct location in the code. ok, those are only ideas.
No Advanced Dir Scan means it checks for a pre-existing passed argv, if it exists it uses than instead of scanning. Any way you look at directory scanning for your nds file is a waste of time. No good checking the file sizes, what if there's 2 files with exact same size? Also doing the post-build injection of the file size would not be very effective since you will have to make the injection code work on a moving target since you have no guarantee that the location of the size will be in the same location each time, and I'm not sure how you will work out the location initially.
I've already done this size injection (actually it was a signature injection after a given hex string). But I agree with you that size is not enough, even if this could be completed by contents analysis. But this is going too far. Let's stop this :)

WinterMute
Site Admin
Posts: 1396
Joined: Tue Aug 09, 2005 3:21 am
Location: UK
Contact:

Re: Filesystem not working on M3, OK on emus

Post by WinterMute » Sun Dec 27, 2009 11:15 pm

The homebrew menu is still a bit of a work in progress so we haven't yet been distributing precompiled versions. Ideally we want to be able to replace the menu on any available DS card or at least have a small list of recommended cards where the menu can be replaced. Some cards appear to have their menus encrypted which obviously makes things a little more difficult. Having said that we do have the means to encrypt a menu for R4. The idea of a devkitPro branded card has been suggested but it needs a bit more research.

Scanning the card for a particular file is a bad idea, it can take quite a long time and still has no guarantee of finding the correct file. The only sensible method is for the launcher to support the argv protocol.
Help keep devkitPro toolchains free, Donate today

devkitPro IRC support
Personal Blog

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests