devkitPro

WinterMute wrote: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.

A homebrew system compatible with R4/M3/others would be excellent. But that's a bit of work I suppose since there are quite a lot of various cards to support. A devkitpro card would be awesome. But we're talking big bucks here, and possible problems with Nintendo, etc... (except if your card can only run homebrew, in which case it won't sell as well...). Good luck with that anyway.

Isn't there some hope that the M3 (the one I have) passes the correct argv in some update. Maybe that's the case now, I haven't installed the latest system yet.

I still fail to undestand how for instance EFS works. I don't like EFS that much compared to nitroFS (first because I could not make it work, and also because of proprietary dirscans), but that's the only embedded filesystem I saw working on my M3 from slot 1.

I just ran into the same problem. So, while looking for a solution I ended up here.
I just downloaded and tested the HBMenu, and it works great !
But I still miss some features from the R4 firmware. So I tried one thing : I put back the R4 firmware and the HBMenu in a folder. Then I launched the HBMenu from the R4 firmware, and it worked ! BUT it couldn't launch my .nds
I suppose that's because the R4 firmware doesn't give the argv to the HBMenu, so it can't pass it to the homebrew .nds...

It would be just great if there was a workaround and that HBMenu could be used that way !

flure wrote:I just ran into the same problem. So, while looking for a solution I ended up here.
I just downloaded and tested the HBMenu, and it works great !
But I still miss some features from the R4 firmware. So I tried one thing : I put back the R4 firmware and the HBMenu in a folder. Then I launched the HBMenu from the R4 firmware, and it worked ! BUT it couldn't launch my .nds
I suppose that's because the R4 firmware doesn't give the argv to the HBMenu, so it can't pass it to the homebrew .nds...

It would be just great if there was a workaround and that HBMenu could be used that way !

And what part of the R4 firmware is missing from the HBMenu? it does everything that the R4 Menu does - launches homebrew, only better. The only option I ran on my old R4 was the moonshell launcher, but that was showing it's age when I had an R4. Also the current implemented HBMenu is getting a face lift at some point to make it look nicer.

Well, the real reason I'd like my homebrew to work on any linker menu is that I'm making NDS demos, and if I want them to be widely watched, I can't force people to change their menu. If they'd like to run cracked games, it's their problem...

By the way, I've thought about a way of making libfilesystem work on any menu without the need of argv, maybe it could work, but I'm really not sure if it's possible, so let me know what you think about it.
The algo is based on the scanning of the subdirectories to find the NDS file, so it may be long. Here it is :

1) on compile time put in the root of the nitrofs directory a simple text file with the compile date and other infos if needed. This text has just to be uniquely identifiable. Also put in the executable, at the same time, the same info using the -D flag.
2) on execution, supply the expected nds file name to nitroFSInit
3) first try to find the nds file from this file name.
4) if the nds file is found, try to init the filesystem and open the text file.
5) Compare its contents with what is expected.
6) If they're equal, we're done ! If not, scan all the directories and try from 3) for each nds file found

What do you think about it ? I believe it should work, though it could make loading times grow with the number of nds files in the card...
I'm not sure I'm skilled enough to make it, but I will try it if nobody does it.

flure wrote:Well, the real reason I'd like my homebrew to work on any linker menu is that I'm making NDS demos, and if I want them to be widely watched, I can't force people to change their menu. If they'd like to run cracked games, it's their problem...

By the way, I've thought about a way of making libfilesystem work on any menu without the need of argv, maybe it could work, but I'm really not sure if it's possible, so let me know what you think about it.
The algo is based on the scanning of the subdirectories to find the NDS file, so it may be long. Here it is :

1) on compile time put in the root of the nitrofs directory a simple text file with the compile date and other infos if needed. This text has just to be uniquely identifiable. Also put in the executable, at the same time, the same info using the -D flag.
2) on execution, supply the expected nds file name to nitroFSInit

How without argv support you don't know what the .nds file name is going to be, and I've got a feeling your next step will be a "Scan the SD card for the nds file".

flure wrote: 3) first try to find the nds file from this file name.
4) if the nds file is found, try to init the filesystem and open the text file.
5) Compare its contents with what is expected.
6) If they're equal, we're done ! If not, scan all the directories and try from 3) for each nds file found

FFS this is WHY we need to get ARGV support on ALL launchers, and it's starting to get on some of the more widely used, homebrew friendly ones. For the ones that are not HB friendly there's the HBMenu option. What you have described is not a good idea as it involved what every EFS user does right now - searching though the SD card for the nds file, I'm sorry but this is not what you should be doing. If you start doing this then the cart makers will not support the ARGV protocols, then you'll have people complaining that their latest HB does not work on cart XYZ, who's dev turn around and say well it's not our fault, it's the HB coders fault, speak to them.

The argv protocol (which also adds the option to exit from your apps to the boot launcher for your card BTW) is the only way we should be using libFilesystem, if someone is trying to view your demo's on a non-argv cart point them at the hbmenu page on devkitPro.org and tell them to point the cart maker there as well. The EU can get a temp fix to run HB until the cart maker pulls it's socks up and gets on board the argv protocol train.

flure wrote: What do you think about it ? I believe it should work, though it could make loading times grow with the number of nds files in the card...
I'm not sure I'm skilled enough to make it, but I will try it if nobody does it.

Please don't bother it's this kind of attitude that we need to get out of the HB scene as it's counter productive for you health.

What happens if the date time is corrupt? This is why HBMenu exists, this is why we need to pressurise the cart makers to include argv support - hell it's been in the toolchain for well over a year now and it's only JUST getting implemented in a couple of cards now, more pressure faster uptake...

A little history:

EFS was created from a fork of libFilesystem and it added the ability to write data back to the NDS file, great in principle, but what happens when you upgrade your nds file? you loose your save data. EFS works like you sugested, but as you pointed out at the end, it increases the loading time of your app expotentially as you have, in the worst case, to scan every .nds file twice in your SD card to find your game's nds file. HBMenu on the other hand just puts the location into memory and the start code just sets a couple of pointers and libFilesystem works fine. Also what happens in the future if there's a change to the way that the files are stored in the NDS file? or if the date time stamp your looking for is corrupt?

How without argv support you don't know what the .nds file name is going to be, and I've got a feeling your next step will be a "Scan the SD card for the nds file".

Sorry, I forgot one thing. The NDS filename has to be passed on compile time as well with the -D flag.

I'm not sure if I understood you very well, or if it's me who didn't explain my idea correctly. The idea is to try to find, in every nds file, a special text file which contains some unique text to identify the file we're looking at. The same idea as a CRC, but easier I guess.

FFS this is WHY we need to get ARGV support on ALL launchers, and it's starting to get on some of the more widely used, homebrew friendly ones. For the ones that are not HB friendly there's the HBMenu option. What you have described is not a good idea as it involved what every EFS user does right now - searching though the SD card for the nds file, I'm sorry but this is not what you should be doing. If you start doing this then the cart makers will not support the ARGV protocols, then you'll have people complaining that their latest HB does not work on cart XYZ, who's dev turn around and say well it's not our fault, it's the HB coders fault, speak to them.

I totally agree with you, I'm just looking for an alternative. It's just that I hate forcing people to do anything, even if I know they're wrong. And people who have an old linker with no updates in 2 years, so no argv possibility (R4 for example) might like an alternative.

flure wrote:

How without argv support you don't know what the .nds file name is going to be, and I've got a feeling your next step will be a "Scan the SD card for the nds file".

Sorry, I forgot one thing. The NDS filename has to be passed on compile time as well with the -D flag.

I'm not sure if I understood you very well, or if it's me who didn't explain my idea correctly. The idea is to try to find, in every nds file, a special text file which contains some unique text to identify the file we're looking at. The same idea as a CRC, but easier I guess.

FFS this is WHY we need to get ARGV support on ALL launchers, and it's starting to get on some of the more widely used, homebrew friendly ones. For the ones that are not HB friendly there's the HBMenu option. What you have described is not a good idea as it involved what every EFS user does right now - searching though the SD card for the nds file, I'm sorry but this is not what you should be doing. If you start doing this then the cart makers will not support the ARGV protocols, then you'll have people complaining that their latest HB does not work on cart XYZ, who's dev turn around and say well it's not our fault, it's the HB coders fault, speak to them.

I totally agree with you, I'm just looking for an alternative. It's just that I hate forcing people to do anything, even if I know they're wrong. And people who have an old linker with no updates in 2 years, so no argv possibility (R4 for example) might like an alternative.

Like the HBMenu????

HBMenu works on all cards, and the following cards that I'm aware of since I own them, as the default boot launcher:

R4
R4i SDHC (thanks to fincs hard work it works on a few of the R4i's)
EzFlash Vi

There also a couple of extra boot loaders in the HBMenu zip file for other carts as well..

It's already been explained in several places why argv is the only reasonable solution, attempting to do anything else is shortsighted and causes problems for homebrew devs. There are far too many card variations to support them all in every homebrew application which is why we created protocols which all cards can use. The single best thing that everyone can do for the homebrew scene is to use these protocols and tell users why your apps don't work on their cards. Ultimately it would be much better if there were fewer but higher quality cards.

The reason hbmenu can't be launched from the R4 menu is because their DLDI has been compiled with arm9 specific instructions. See http://wiki.devkitpro.org/index.php/Homebrew_Menu