hello
is it possible to add the ds homebrewmenu thats in the devkitPro repository as an library in devkitPro? there are some people out there that wants to create there own menu, and having a library to boot nds files is easier than downloading a separate project which doesn't uses the default makefile or arm7 binary. it should also be easier to update, both on your side as on the users side.
homebrewmenu as library
Re: homebrewmenu as library
fwiw I'm currently working on an NDS bootloader program derived from the homebrewmenu sources. It will include a feature equivalent to linux's grub's 'bootonce' feature, which may prove sufficient for your needs. When I originally suggested to WinterMute I believe, that runNdsFile be used to implement exec() in libnds, the idea was cast asside as useless.
Re: homebrewmenu as library
well, my main problem is that it needs an custom arm7 binary (and makefile). so unless it works with the default one, it probably wont be of much use to me.
from what I saw, exec is a family of functions, which does seem overkill to me.
from what I saw, exec is a family of functions, which does seem overkill to me.
-
- Site Admin
- Posts: 1986
- Joined: Tue Aug 09, 2005 3:21 am
- Location: UK
- Contact:
Re: homebrewmenu as library
Considering that the sole reason for executing another nds file is to create a launcher menu it's difficult to see any reason to provide the functionality as a library. The Homebrew Menu was open sourced under the GPL to allow others to contribute to making a better and hopefully universal menu rather than supporting many competing menus.
Re: homebrewmenu as library
my main reason to do this is so I can use it in my library without having multiple arm7 cores. providing it as an officiel library makes it more populair to use than other alternatives, which probably don't work as well (doesn't support command line arguments).
and there are more reasons to boot nds files than just a loader menu. 1 way to use it is to let a program execute the menu after its done, with having the path to the menu provided with the command line arguments. an other is dividing the work between files, like having an level creator in 1 file and the engine in the other. and I'm pretty sure that other people can think of more reasons.
and if they do want to create a loader program, I'm sure they want to create it just like any other program (I know I would). that way, they can use there own templates and makefiles without having to set up everything like libraries, (conversion) programs (like grit) ect.
about having 1 universal menu, it sounds real nice in theory, but I doubt it works in practice. different people just want different menu's. some wants 1 list of all the programs to choose from, the other wants to create a lot of folders. one person wants to just play games and programs, and an other person wants to have alot of other stuff, like reading *.txt files and viewing images. one wants to customise it with skins and sounds, and other doesn't want those skins and sound files on there sd card.
looking at the main arm7 file, I doubt that it would be hard to do. the only custom thing it does is executing runNdsLoaderCheck(); 60 times per second:
so it doesn't really do anything different than the default arm7 binary until the arm9 sets a byte to a specific value. I'm pretty sure that instead of (or besides) setting a value, you could use the fifo to tell the arm7 to execute it, avoiding the need to execute it every vblank.
and there are more reasons to boot nds files than just a loader menu. 1 way to use it is to let a program execute the menu after its done, with having the path to the menu provided with the command line arguments. an other is dividing the work between files, like having an level creator in 1 file and the engine in the other. and I'm pretty sure that other people can think of more reasons.
and if they do want to create a loader program, I'm sure they want to create it just like any other program (I know I would). that way, they can use there own templates and makefiles without having to set up everything like libraries, (conversion) programs (like grit) ect.
about having 1 universal menu, it sounds real nice in theory, but I doubt it works in practice. different people just want different menu's. some wants 1 list of all the programs to choose from, the other wants to create a lot of folders. one person wants to just play games and programs, and an other person wants to have alot of other stuff, like reading *.txt files and viewing images. one wants to customise it with skins and sounds, and other doesn't want those skins and sound files on there sd card.
looking at the main arm7 file, I doubt that it would be hard to do. the only custom thing it does is executing runNdsLoaderCheck(); 60 times per second:
Code: Select all
void runNdsLoaderCheck (void)
{
if(*((vu32*)0x027FFE24) == (u32)0x027FFE04)
{
irqDisable (IRQ_ALL);
*((vu32*)0x027FFE34) = (u32)0x06000000;
swiSoftReset();
}
}
-
- Site Admin
- Posts: 1986
- Joined: Tue Aug 09, 2005 3:21 am
- Location: UK
- Contact:
Re: homebrewmenu as library
Actually, yes, one of the planned improvements to the default core is a method to run custom arm7 code from the arm7. The code currently in svn was written quite some time ago and has mostly just been updated to build and work with the latest tools.
I'm still a bit busy with DSi related things but I hope to tweak the menu code again soon - there are a few things in there that need changed for DSi.
I'm still a bit busy with DSi related things but I hope to tweak the menu code again soon - there are a few things in there that need changed for DSi.
Who is online
Users browsing this forum: No registered users and 0 guests