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 > Return to loader - standardizing

#165383 - chishm - Fri Dec 19, 2008 1:49 am

Now that we have support for passing arguments to loaded programs, there's a desire to allow the loaded program to return back to the menu without resetting the console. This will allow a quasi-plugin system with the menu providing a file selection list for various other programs such as media players, emulators and the like.

So the question is: what is the best way to provide return-to-loader functionality? There are various aspects to consider.

One aspect is how the program knows which menu to load. Should this be done by putting the menu return stub in a standard location on disc, or should the path be passed to the program as the 2nd or last argument?

Another aspect is the format of the return stub. Should it be a complete NDS file that needs to be loaded and run by the returning program in the same way that the program was loaded, or should it be a custom binary format that is loaded into memory at a specific location and jumped to?

There are advantages and disadvantages to each of these methods, and I want to hear other people's opinions before biasing them with my own. Keep in mind that once this is decided on it won't be easy to change.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

#165385 - dovoto - Fri Dec 19, 2008 2:31 am

You cannot simply provide a hook the loader can patch?

This would basically require the menu/file loader to implement how it would want to handle a "return to menu" call via some form of dynamic patching mechanism similir to dldi (not that i know how dldi is implemented). Furthermore, it would require enough space be set asside to hold the necessary boot strap code the menu might require (unless there is some more dynamic way to set asside this space).

It seems to me, passing in only the location of the menu stub (or requiring the menu stub be in a known location) is not an ideal option.

Not only would it require patching to read the stub from disk and require the fat library be implemented in the nds but it seems difficult to adapt this method to something like returning to a non file based loader (say a file booted via dsserial or over wifi directly).

Ideally there would be some way to dynamically allocate onlly the room needed for the menu bootstrap and this bootstrap would be provided by the menu/loader.

I would be interestd in understanding how you handle the seemingly similar aspects of dldi patching.
_________________
www.drunkencoders.com

#165390 - nanou - Fri Dec 19, 2008 4:47 am

I was thinking... if these programs need to be built specifically with support for the loader/host program, why not make them proper plugins and keep the host resident? Or, if the host is likely to eat up too much memory, just keep a portion resident and return to that. This way the host could provide DLDI drivers and whatever else makes sense (if anything) without any patching.
_________________
- nanou

#165403 - elhobbs - Fri Dec 19, 2008 5:36 pm

I think a dldi clone that can be loaded and relocated at runtime would be a good solution. it would probably require two files. the loader and the possibly the dldi for the hardware (though it may be possible to copy and relocate the in memory version at runtime). I think the files would need to have hardcoded file names or perhaps the path could be stored in a file or maybe the bootsector. I see fat access as being a very large obstacle. it might me possible to save all of the sector offset and lengths in memory(vram maybe?) before fat is unloaded and then use dldi directly to load the file.