View unanswered posts | View active topics It is currently Fri Jun 22, 2018 8:40 am



Reply to topic  [ 28 posts ]  Go to page Previous  1, 2, 3  Next
 Filesystem not working on M3, OK on emus 
Author Message

Joined: Sun Dec 13, 2009 9:43 pm
Posts: 32
Location: France
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?


Sat Dec 26, 2009 6:36 pm
Profile WWW

Joined: Sun Feb 22, 2009 7:59 pm
Posts: 133
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


Sat Dec 26, 2009 7:30 pm
Profile

Joined: Sun Dec 13, 2009 9:43 pm
Posts: 32
Location: France
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.


Sat Dec 26, 2009 10:36 pm
Profile WWW

Joined: Sun Feb 22, 2009 7:59 pm
Posts: 133
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.


Sun Dec 27, 2009 6:33 pm
Profile

Joined: Sun Dec 13, 2009 9:43 pm
Posts: 32
Location: France
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?


Sun Dec 27, 2009 8:18 pm
Profile WWW

Joined: Sun Feb 22, 2009 7:59 pm
Posts: 133
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.


Sun Dec 27, 2009 8:55 pm
Profile

Joined: Sun Dec 13, 2009 9:43 pm
Posts: 32
Location: France
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.


Sun Dec 27, 2009 9:33 pm
Profile WWW

Joined: Sun Feb 22, 2009 7:59 pm
Posts: 133
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.


Sun Dec 27, 2009 9:56 pm
Profile

Joined: Sun Dec 13, 2009 9:43 pm
Posts: 32
Location: France
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 :)


Sun Dec 27, 2009 10:23 pm
Profile WWW
Site Admin

Joined: Tue Aug 09, 2005 3:21 am
Posts: 1268
Location: UK
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


Sun Dec 27, 2009 11:15 pm
Profile ICQ WWW
Display posts from previous:  Sort by  
Reply to topic   [ 28 posts ]  Go to page Previous  1, 2, 3  Next

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
  Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.
Get devkitPro at SourceForge.net. Fast, secure and Free Open Source software downloads