#154747 - cloakedguy - Mon Apr 21, 2008 7:22 am
Excuse the potentially silly question.
Why is it that some homebrew requires being installed in the root of the filesystem/card/etc., while other works perfectly well inside a directory... even with support files?
I ask this as a slightly confused user of homebrew, as most homebrew seems content to live happily in a directory (thus keeping the root clean and making it easier to keep files organized), while others require root installation.
Is there a particular reason for it, or is it just homebrewers leaving directory locations hard coded in their code?
#154754 - Lazy1 - Mon Apr 21, 2008 8:22 am
It's because there is no way to know what directory the application was launched from.
I would say that most require the root directory since it's so simple and they know that if installed properly all of the required data will be there.
That being said I believe there is the ability for applications to get their current working directory but no loaders set this up properly at this point.
I could be wrong though.
#154767 - thedopefish - Mon Apr 21, 2008 2:54 pm
Applications need to be able to find their support files on your card in order to load (or save) them. One way to handle this is to have the application look in the current directory; however this requires argv support in the loader (and few/none of the popular homebrew devices have such a loader yet).
So the only option left is to hard-code the path. Note that many PC applications also hard-code the path to some of their files, except that they use a standard location like "Documents and Settings" or "/home". There was some effort to have DS homebrew standardize on "/data", but that didn't really take off, which is why a lot of apps just use the root directory.
_________________
#include <sig.h>
#154768 - simonjhall - Mon Apr 21, 2008 3:16 pm
I'm guilty of the root directory hard-coding problem, and my original reason for doing this was due to not knowing where in the file system to put files. I was going to do something smarter for later versions of my stuff (after talking to theli), but I didn't because
a) I forgot
b) I dreaded the endless support emails as people would have problems with the game not finding its data files
_________________
Big thanks to everyone who donated for Quake2
#154770 - Lazy1 - Mon Apr 21, 2008 3:52 pm
| thedopefish wrote: |
| however this requires argv support in the loader (and few/none of the popular homebrew devices have such a loader yet). |
What's with that anyway?
Hasn't argv support been in libnds for a while now?
#154778 - josath - Mon Apr 21, 2008 5:04 pm
| Lazy1 wrote: |
| thedopefish wrote: | | however this requires argv support in the loader (and few/none of the popular homebrew devices have such a loader yet). |
What's with that anyway?
Hasn't argv support been in libnds for a while now? |
Yes...but it requires changes to the homebrew launchers. Which means soon we'll get to see which flashcard manufacturers care about homebrew and which don't ;)
#154782 - SiW - Mon Apr 21, 2008 6:21 pm
| thedopefish wrote: |
| There was some effort to have DS homebrew standardize on "/data", but that didn't really take off |
I really wish it would. I don't see any reason NOT to do this.
#154785 - Lazy1 - Mon Apr 21, 2008 6:42 pm
| SiW wrote: |
| thedopefish wrote: | | There was some effort to have DS homebrew standardize on "/data", but that didn't really take off |
I really wish it would. I don't see any reason NOT to do this. |
Because it's another excuse for loader devs to not bother implementing argv support.
Not that they seem to be doing that anyway.
#154792 - simonjhall - Mon Apr 21, 2008 7:28 pm
Couldn't something be added to the dldi driver to force all file access to the / directory into a directory based on the nds name?
Bit drastic, I know, but developers have no real incentive to faff around with putting stuff in a directory. Plus there's no common layout for DS homebrew flash cards anyway, so there's no real precident for where to put data files. (for example, on Windows everything goes in Program Files)
_________________
Big thanks to everyone who donated for Quake2
#154802 - josath - Mon Apr 21, 2008 8:40 pm
| simonjhall wrote: |
Couldn't something be added to the dldi driver to force all file access to the / directory into a directory based on the nds name?
|
no...dldi drivers work at a block level, a hack like that needs access to the filesystem level.
It's a bit of a chicken-egg problem. I think the hope is that people start writing homebrew that uses argv. Then they can say "If your loader supports argv, put the .nds file anywhere, otherwise you must keep the file in the root of your card". This in turn will put pressure on the loader-writers to add this feature (see how most flashcart builders now support DLDI, many even auto patch it)
#154821 - Noda - Mon Apr 21, 2008 10:54 pm
My EFS system partially solves this problem, allowing to know the current dir of the .nds (only searched first time or then locatioin changed, then stored inside the .nds) and also allow to append data to the .nds file using NitroFS so no external files are required (while still working with slot-1 card unlike GBFS).
#154822 - wintermute - Mon Apr 21, 2008 11:18 pm
The nitroFS code written by Eris ( see http://blea.ch/wiki/index.php/Nitrofs ) will be integrated into libnds in the not too distant future. Searching the filesystem for the launched file will not - we will be providing a homebrew launcher menu which implements argv in the hope that card manufacturers will follow suit in much the same way they did with DLDI. This should hopefully sort out most of the problems.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#154823 - Maxxie - Mon Apr 21, 2008 11:29 pm
| Noda wrote: |
My EFS system partially solves this problem, allowing to know the current dir of the .nds (only searched first time or then locatioin changed, then stored inside the .nds)
|
This is a method to avoid.
Here it 'just' causes confusion when you create a backup copy of your .nds. You'r method wouldn't recognize the move at all and use the wrong path for data/configuration files if starting the backup.
There was once a leopard that used to store non static data into the bin in the same way. Leading to a major flaw in the firewall (possibly allowing untrusted code to pass)
| Quote: |
and also allow to append data to the .nds file using NitroFS so no external files are required (while still working with slot-1 card unlike GBFS). |
That doesn't work for saving to file nor is it "idiot"-safe, in the way the user adds or exchanges files. Drag&Drop to the SD/CF-Drive will create _much_ less PMs
#154824 - Noda - Mon Apr 21, 2008 11:32 pm
From what I've seen, it's essentially the same as my EFSlib since it's based on libfat, but without the write support and the search functionalities.
It also has devoptab integration, which could be added to EFS but I have not did it just because I'm lazy :p
#154825 - josath - Mon Apr 21, 2008 11:36 pm
| Maxxie wrote: |
| Quote: |
and also allow to append data to the .nds file using NitroFS so no external files are required (while still working with slot-1 card unlike GBFS). |
That doesn't work for saving to file nor is it "idiot"-safe, in the way the user adds or exchanges files. Drag&Drop to the SD/CF-Drive will create _much_ less PMs |
NitroFS is a good feature, when used for the correct purpose. It's good for:
* Data added by the developer
* read-only data that does not change
* having more data than would fit in the 4MB main memory
* working on all flashcarts and emulators
* using the same standard stdio interface people are used to with libfat
(I think the last two only apply when using eris's code, not with EFS)
It's not good for:
* Data which gets changed by the end-user (eg adding levels, themes, settings)
* Data which must change at runtime (eg saving your progress in a game)
I believe EFS tries to add some hacky write-support, but I think it's not that great of an idea personally (just my opinion).
Don't mistake the NitroFS method for being a poor solution just because it doesn't work in all situations.
#154826 - Maxxie - Mon Apr 21, 2008 11:38 pm
No, but it renders NitroFS to be not the "out of the box" solution for the root-folder problem as it was pointed out to be.
#154827 - Noda - Mon Apr 21, 2008 11:39 pm
| Maxxie wrote: |
| Noda wrote: | My EFS system partially solves this problem, allowing to know the current dir of the .nds (only searched first time or then locatioin changed, then stored inside the .nds)
|
This is a method to avoid.
Here it 'just' causes confusion when you create a backup copy of your .nds. You'r method wouldn't recognize the move at all and use the wrong path for data/configuration files if starting the backup.
There was once a leopard that used to store non static data into the bin in the same way. Leading to a major flaw in the firewall (possibly allowing untrusted code to pass)
| Quote: |
and also allow to append data to the .nds file using NitroFS so no external files are required (while still working with slot-1 card unlike GBFS). |
That doesn't work for saving to file nor is it "idiot"-safe, in the way the user adds or exchanges files. Drag&Drop to the SD/CF-Drive will create _much_ less PMs |
Yes it does work if the file is moved, if the file is not present at the path stored, it's simplu searched again.
And yes, it's also self-contained and support writing as long as space is pre allocated.
And the major point, it WAS designed to be idiot-safe, to avoid supporting those who can't check readme to know data was supposed to be copied on the card. With EFS, just put one .nds file where you want on your card and that's it.
#154828 - Maxxie - Mon Apr 21, 2008 11:44 pm
| Noda wrote: |
Yes it does work if the file is moved, if the file is not present at the path stored, it's simplu searched again.
|
If i back it up i.e. because i want one of them to run with a different configuration, the original files stay there. Your method will fail to recognize the move.
I know that this is a limitation you have to deal with until the "commandline" is passed as argument, but it's a bandaid, nothing more.
| Quote: |
And yes, it's also self-contained and support writing as long as space is pre allocated.
And the major point, it WAS designed to be idiot-safe, to avoid supporting those who can't check readme to know data was supposed to be copied on the card. With EFS, just put one .nds file where you want on your card and that's it. |
This only works for static data as already mentioned above, but it doesn't work for the data that is allowed to changed by the user, as it is the case with many of the root-problem programs.
#154832 - Noda - Mon Apr 21, 2008 11:59 pm
| Maxxie wrote: |
If i back it up i.e. because i want one of them to run with a different configuration, the original files stay there. Your method will fail to recognize the move.
|
what do you mean? I don't get your point... if you still want a fresh start because for example of stored savegames inside the nds, you can just get the original archive.
| Quote: |
This only works for static data as already mentioned above, but it doesn't work for the data that is allowed to changed by the user, as it is the case with many of the root-problem programs. |
The same apply for the NitroFS driver up there. But in EFS you can still know the current directory, avoiding the necessity to put data files in the root card. And EFS can be used along with libfat without any problem.
Still, the two things I really like in the NitroFS driver above are:
- devoptab implementation
- automatic gba ram detection, allowing the NDS to run in emulators without hassle
But to my opinion its biggest problems was the mean of my creation of EFS:
- it searches for the .nds files EVERY time you launch the homebrew, and only based on its file name. Not only if the user decides for whatever reason to rename it it won't work, but also it could leads to problems when differents version of the files are stored on the card, and finally searching for the good .nds every time can be reaaaally bothering since it can take very long time on some configuration.
That's why I included a dldi-like system in EFS, with an unique ID generated on compile-time, to recognize the .nds whatever is name is. And that's why also the path is stored inside the .nds, to avoid searching for it everytime (but it can STILL be moved after, it will just make it searched again).
- write support. Although write support is very limited in EFS (need to preallocate files), it's really handy for config files, saves, etc.
I would be really nice to mix eris's implementation with my EFS system, to have the best of both worlds, ie emulator support and devoptab along with the id system and write possibility.
Still, keep in mind that NitroFS as said previously is not the perfect solution in all situation but currently I have this setting for my homebrews:
- highscores, config files and data are stored using EFS
- external data such as user levels, are searched in both root and current .nds directory, and read using libfat.
I found it to be the best compromise.
Last edited by Noda on Tue Apr 22, 2008 12:05 am; edited 1 time in total
#154833 - josath - Tue Apr 22, 2008 12:04 am
A simple example:
color.nds -- stores your favorite color, and when you run it, shows that color.
1. I copy it to /games/color.nds
2. I run it, change the color to 'red' and press 'save'
3. I copy the file to /games/red.nds
4. Now I run /games/color.nds again, change the color to 'blue' and press 'save'
What color will I see when I run red.nds? I suspect it will be blue, which would be incorrect (the red.nds file actually contains the color 'red', but when it starts up, it automatically uses the saved value of /games/color.nds to read data from, and loads 'blue). Perhaps you are doing something else to prevent this case, in which case I would be mistaken?
#154836 - Noda - Tue Apr 22, 2008 12:09 am
If you want to hold 2 different version of the same nds, just run your backup file onto the efs patcher which works exactly like dldi patcher (but without the need for dldi files). It will generate a new unique id for your backup, preventing that problem. Not really practical, but possible.
Your case still is quite uncommon though, and this problem can't be solved using eris's NitroFS driver.
#154837 - Maxxie - Tue Apr 22, 2008 12:16 am
| Noda wrote: |
| Maxxie wrote: |
If i back it up i.e. because i want one of them to run with a different configuration, the original files stay there. Your method will fail to recognize the move.
|
what do you mean? I don't get your point... if you still want a fresh start because for example of stored savegames inside the nds, you can just get the original archive.
|
Yes, you can. But it is contra-intuitive - thus entitled "confusing" by me - that you can't just create a copy and work with the copy as an own entity.
Espacially if they are working on the data, i.e. your artists comparing how different styles are working, my coworkers are usually going to create a simple copy instead of redoing each of their patches to a clean install or puzzle everything together from different sources.
| Quote: |
The same apply for the NitroFS driver up there. But in EFS you can still now the current directory, avoiding the necessity to put data files in the root card. And EFS can be used along with libfat without any problem.
|
I didn't compare EFS, NitroFS, whateverelse-in-binary-included-files i just noted that they are not _the_ soltution to the root-foldering. They are just a solution to _a special case_
#154863 - Noda - Tue Apr 22, 2008 1:59 am
| Maxxie wrote: |
Yes, you can. But it is contra-intuitive - thus entitled "confusing" by me - that you can't just create a copy and work with the copy as an own entity.
Espacially if they are working on the data, i.e. your artists comparing how different styles are working, my coworkers are usually going to create a simple copy instead of redoing each of their patches to a clean install or puzzle everything together from different sources.
|
I'm realling wondering what's the *really* special case that seems to be yours that prevents to copy the nds binary on your computer and leaving only one on your flashcard...
'cause in the case of changing only graphic skins or level data, the .nds file doesn't need to be changed right? Also, as a developper convenience is provided an EFS/libfat switch by the mean of a simple define. For your debug/skin change/level tests, you just uncomment this define which allow you to use libfat along with the root of your card for all your data tests, without the need to backup/recompile your .nds. Then, when it's time for a release, you just comment this define again and no more hassle with external data, everything just work the same but using the NitroFS.
| Maxxie wrote: |
I didn't compare EFS, NitroFS, whateverelse-in-binary-included-files i just noted that they are not _the_ soltution to the root-foldering. They are just a solution to _a special case_ |
You seems to have missed the many times I said EFS allows you to know the current directory for the .nds, thereforce solving the root-foldering (in the meantime flashcart loader implement argv support).
To my opinion, NitroFS/EFS is the best way for managing data in a general sense, that's only *special cases* that absolutely need external data (though external data doesn't mean everything need to be external, NitroFS can be used along libfat...).
#154864 - spinal_cord - Tue Apr 22, 2008 2:18 am
Would it not be simple for people to use a 'homebrew.ini' in the root of the card, with a reference to the software and its path, this would mean that the only file that needs to be in the root would be the homebrew.ini. All a homebrew file needs to do is search the .ini for its own entry, and use whatever path is set. Perhaps checking for a specific file in that location, if not found, search using that file locator code (was it lick's?), then perhaps updating the .ini with the correct path.
_________________
I'm not a boring person, it's just that boring things keep happening to me.
Homepage
#154866 - josath - Tue Apr 22, 2008 2:43 am
| Noda wrote: |
If you want to hold 2 different version of the same nds, just run your backup file onto the efs patcher which works exactly like dldi patcher (but without the need for dldi files). It will generate a new unique id for your backup, preventing that problem. Not really practical, but possible.
Your case still is quite uncommon though, and this problem can't be solved using eris's NitroFS driver. |
but it would be solved by proper argv support. so again we're back to the chicken-egg problem :)
#154914 - nutki - Tue Apr 22, 2008 10:40 pm
I have a few remarks about working directory retrieval.
First if I correctly understand argv solution it is meant for user to parse out path part from argv[0]. If so I see several downsides:
- this method is not standard in any OS I have used, and even did not seen code that would do so; this is because argv[0] usually contains path used in command line which may be relative or none at all (in case of $PATH execution)
- it is only available in main(), cannot be used by libraries unless explicitly passed from user code.
- user does not really need to know the path it would be enough to use relative paths in fopen(), which has minimal or no porting cost.
I think that better solution would be to implement working standard POSIX getcwd(), that could be used by libfat for initial chdir.
I also thought of the no-support, no-use, chicken-egg problem and came up with that it is reasonable to store the directory in upgraded DLDI block.
The pros are as follows:
- DLDI patching is now widely accepted in flashcard firmwares, so it would be easier to push through upgraded DLDI struct that something completely new (passing current directory has less value added than reading fat fs so it is less attractive for flashcart manufacturers).
- It could be used before upgraded firmwares emerge by using something similar to existing DLDI patching. An external PC software called something like this:
> fixcwd F:
could scan all directories for *.nds homebrew and update paths in DLDI block. Of course one would have to use this tool each time directory structure changes.
#154919 - Lazy1 - Tue Apr 22, 2008 11:12 pm
| nutki wrote: |
First if I correctly understand argv solution it is meant for user to parse out path part from argv[0]. If so I see several downsides:
- this method is not standard in any OS I have used, and even did not seen code that would do so; this is because argv[0] usually contains path used in command line which may be relative or none at all (in case of $PATH execution)
- it is only available in main(), cannot be used by libraries unless explicitly passed from user code.
|
I don't see why argv[ 0 ] couldn't point to a full path, though you are right about implementing getcwd().
Maybe parsing out the working directory should be done in the crt startup and libfat switch to the directory immediately in fatInit().
#154923 - nutki - Tue Apr 22, 2008 11:38 pm
| Lazy1 wrote: |
I don't see why argv[ 0 ] couldn't point to a full path, though you are right about implementing getcwd().
|
I don't say it should not. My point is that in my opinion, as in "real world" argv does not contain full path, using it for purpose in question is not a natural thing to do. Actually my proposal of equating program directory with current working directory is not that clean either, as this is also not always true with real OS-es. It is just more convenient.
#154926 - Maxxie - Tue Apr 22, 2008 11:52 pm
Uhm,
there is no OS running that could maintain a CWD, nor is there a parent process from which to derive the CWD. Every's CWD is therefor root, which leads to the case that <relativePath> == <absolutePath> so no issue here whether the one or the other is used.
Makes the porting also pretty easy. If your Win or Linux original supports their absolute and relative pathing (which are possible to occure in both), they shouldn't fail here.
| Quote: |
something similar to existing DLDI patching
|
There is quite a difference.
DLDI patching is actually library linking, representing a part of the compile-process. Creating a composite of static data.
Patching with a working directory however is injecting _dynamic_ data (runtime data) into a static container. Which is just asking for trouble.
Something i would avoid when i could just pass the runtime data at runtime to the main ... which would be the argv[]
#154941 - tepples - Wed Apr 23, 2008 1:25 am
| Maxxie wrote: |
| DLDI patching is actually library linking, representing a part of the compile-process. Creating a composite of static data. |
Just like loading an app on Windows.
| Quote: |
| Patching with a working directory however is injecting _dynamic_ data (runtime data) into a static container. Which is just asking for trouble. |
PogoShell dunnit. And so did DOS with its Program Segment Prefix.
| Quote: |
| Something i would avoid when i could just pass the runtime data at runtime to the main ... which would be the argv[] |
But where would argv[] be placed so that it is guaranteed not to overlap the program or its heap?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#154945 - Dwedit - Wed Apr 23, 2008 2:43 am
Pogoshell wrote information about the selected file somewhere inside free EWRAM. It didn't touch the game code.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#154948 - HyperHacker - Wed Apr 23, 2008 5:34 am
We have argv[] now, I don't see why the path of the NDS file can't just be left there with the arguments (or even as one) for use by getcwd(). That seems like the best solution. Failing that, I don't see why people don't use /data/appname, it's only one line of code.
_________________
I'm a PSP hacker now, but I still <3 DS.
#154955 - Lazy1 - Wed Apr 23, 2008 7:24 am
| HyperHacker wrote: |
| Failing that, I don't see why people don't use /data/appname, it's only one line of code. |
Let's use Quake for an example, everyone wants to play it but the next version will only work if it was given proper arguments at startup.
You can be sure those flashcart companies will get lots of emails asking for them to support argv in their launchers.
Or we just keep using /data/whatever and not force the issue at all.
These devices are supposed to support homebrew and if we don't force the issue on these things it will never happen.
I would go so far to suggest any new applications should fail to start unless they were passed args.
I might do that with the next Wolfenstein release, though since it's not very big I doubt any notice will be taken by the cart developers.
#154957 - nutki - Wed Apr 23, 2008 7:59 am
| Maxxie wrote: |
there is no OS running that could maintain a CWD, nor is there a parent process from which to derive the CWD. Every's CWD is therefor root, which leads to the case that <relativePath> == <absolutePath> so no issue here whether the one or the other is used.
|
I am aware of that. But since there is no OS running we are free to decide what CWD means. Fixing it to '/' is what we have already, I proposed something more useful.
| Quote: |
Makes the porting also pretty easy. If your Win or Linux original supports their absolute and relative pathing (which are possible to occure in both), they shouldn't fail here.
|
But requires DS dedicated code that would parse argv[0] and put it into global variable/chdir to it. Otherwise ported app would just use root as relative path base so no change from what we have now.
| Quote: |
There is quite a difference.
DLDI patching is actually library linking, representing a part of the compile-process. Creating a composite of static data.
Patching with a working directory however is injecting _dynamic_ data (runtime data) into a static container. Which is just asking for trouble.
|
What troubles you have in mind? Aside from what I already stated in previous posts. I just made a proposal for the "chicken-egg" problem solution. I don't say it is perfect, but as far as I'm concern it is the only one.
And also we could avoid modified DLDI in firmware implementations by adding argv retrieval function in DLDI instead just a static offset to a C string. Then a real implementation (not using fixcwd mock-up) could get the argv from wherever including current location (end of ram).
Actually it does not even have to be DLDI, new magic section inside the arm9 binary could be added as well, but I see extending DLDI as a better solution (rationale in my first post).
| Quote: |
| Something i would avoid when i could just pass the runtime data at runtime to the main ... which would be the argv[] |
Using or not using agrv and DLDI usage proposal are completely independent. Setting argv to value from DLDI, as well as getcwd() returning path from what is used now as argv is perfectly possible. The difference with using DLDI is that it makes possible to set the directory with current loaders while r21 path and argument location can be written to only by compatible loader (well I could probably modify linker script to put my argv at end of ram, but then why not just change crt0 to do whatever I want).
#154958 - nutki - Wed Apr 23, 2008 8:10 am
| tepples wrote: |
But where would argv[] be placed so that it is guaranteed not to overlap the program or its heap? |
It is already placed at 0x027FFF70 in devkitARM21, this memory area (last 4k of main RAM) is not managed by linker.
#154960 - Maxxie - Wed Apr 23, 2008 9:39 am
| tepples wrote: |
| Quote: | | Patching with a working directory however is injecting _dynamic_ data (runtime data) into a static container. Which is just asking for trouble. |
PogoShell dunnit.
|
I don't know PogoShell, so ...
But i wouldn't call it an acceptable design tbh.
| Quote: |
And so did DOS with its Program Segment Prefix.
|
No it didn't. The PSP is not included in the .COM binary but prepended into an image at loading time by DOS itself. It didn't change the binary at all.
| Quote: |
But where would argv[] be placed so that it is guaranteed not to overlap the program or its heap? |
Ah, now i get you.
No we don't talk about patching the data in the memory (so keeping a variable a variable). I wouldn't mind that, this is ok, as this is only there at runtime and not remembered in the bin.
I am strongly against patching into the static container as stated a dozen times already.
@nutki:
Well right now i am searching for the configuration file on every startup. With a breadth first search and presenting the choices to the user jit.
Works quite well without a noticeable delay for the most setups.
What troubles i expect from patching the path into the file:
- mirrors of the binary popping up with a different CRC each
- users posting me beloved PMs/emails complaining what a stupid pile of .... well you know that kind of fans, when they can't follow the instructions needed to work with such a system
- unknowingly exposing information of your file system when users sharea binary they allready ran ("Did you see the r0mloader/pr0n/whatever in the path? WTF evil!")
#154962 - simonjhall - Wed Apr 23, 2008 10:15 am
I don't think argv/cwd support is the way forward. I think agreeing on a standard place to put homebrew data would be much more useful and as a result there's barely any code involved.
For instance, just because the current nds I'm running lives in fat:/my/directory/rox doesn't mean the data should live in fat:/my/directory/rox/GAME_NAME, it should live in some user-configurable place. For instance I like all my nds files to be in the root of my flash card but I don't want the data to live there, I'd like it to live in fat:/homebrew_data/GAME_NAME instead.
One way of doing this would be to have some kind of configuration on the card, another would be to have your prefered homebrew data directory written directly into your DS.
Anyone else agree? I just don't think being able to find where your NDS is is the solution.
_________________
Big thanks to everyone who donated for Quake2
#154981 - josath - Wed Apr 23, 2008 4:38 pm
| simonjhall wrote: |
I don't think argv/cwd support is the way forward. I think agreeing on a standard place to put homebrew data would be much more useful and as a result there's barely any code involved.
For instance, just because the current nds I'm running lives in fat:/my/directory/rox doesn't mean the data should live in fat:/my/directory/rox/GAME_NAME, it should live in some user-configurable place. For instance I like all my nds files to be in the root of my flash card but I don't want the data to live there, I'd like it to live in fat:/homebrew_data/GAME_NAME instead.
One way of doing this would be to have some kind of configuration on the card, another would be to have your prefered homebrew data directory written directly into your DS.
Anyone else agree? I just don't think being able to find where your NDS is is the solution. |
Maybe this is a problem with your menu software? I mean you don't hear people complaining that they wish they could put FooApp.exe in a different folder than FooData.dat, almost everybody installs them to something like c:\Progra~1\Foo\FooApp. But thanks to explorer (aka the menu/launcher), all your apps can be nicely organized in your startmenu/quicklaunch bar, separate from their actual layout in c:\progra~1. Maybe the flashcart authors (or homebrew menu authors) need to come up with a way to do something like this? Such as list all .nds files in a single menu, regardless of their location? So even though you've got /homebrew/game1/game.nds and /homebrew/app3/app3.nds etc, you can see them in a single menu instead of having to browse folders?
Even if finding a .nds's location doesn't solve this particular problem, it DOES solve the problem of the .nds finding itself, so it can read appended data. Which is something we need anyway. So just because it might not help organize external data the way you'd want, don't throw away the ability for peoeple who want to make idiot-proof self-contained .nds files that are over the 4MB RAM limit!
#154984 - simonjhall - Wed Apr 23, 2008 5:22 pm
Hmm that's a good point, esp about appended data and better launchers.
I thought, though, with appended data that it's loaded in when the nds starts up? I didn't realise you had to find your nds and pick the data from it...
_________________
Big thanks to everyone who donated for Quake2
#154988 - Lazy1 - Wed Apr 23, 2008 6:52 pm
Support for argv[ 0 ] would also let you get your appended data as well you know :D
Maybe we need to start a petition and send it to the flashcart devs letting them know we want this feature added.
#155017 - HyperHacker - Wed Apr 23, 2008 11:01 pm
I think josath has the right idea. People don't want the app storing its files in the same place as the executable because they store all the executables in the same place and it'll make a mess. On at least Windows, each app has its own directory and you have a menu of available apps.
Fortunately I've been working on just such a menu; development has been slow due to various issues (hardware failure, struggling with different loaders, etc) but it shouldn't be too much longer. I think that's what we need here, a program that gives you a nice customizable menu listing your apps and even letting you pass arguments to them.
Does chishm's loader support arguments, though? I haven't tried that yet.
(And as for its files, it looks for its settings in /data/appname/config.ini, /data/appname.ini and /appname.ini in that order, and all other files are referenced from there so you can stick them wherever you want.)
_________________
I'm a PSP hacker now, but I still <3 DS.
#157668 - Sweater Fish Deluxe - Tue May 27, 2008 7:44 pm
| HyperHacker wrote: |
| Does chishm's loader support arguments, though? I haven't tried that yet. |
No, it doesn't. Is there any sample code anywhere showing how to implement argv in an NDS loader? This would be helpful not only for me, but for encouraging the authors of commercial flash carts to implement it. If we could send them some example code that they might even be able to drop right into their loader code, it would certainly speed things along, I think.
What exactly gets passed with argv anyway? The full filepath including the name of the file, I assume? Is it possible to pass other strings? For example, could it be used to pass the path of the loader app itself so that you can load one NDS from another and then return to the first seemlessly?
...word is bondage...
#157757 - HyperHacker - Wed May 28, 2008 11:52 pm
I would think you can pass whatever you want, just like a command line.
_________________
I'm a PSP hacker now, but I still <3 DS.
#157779 - yellowstar - Thu May 29, 2008 3:34 am
| Sweater Fish Deluxe wrote: |
Is there any sample code anywhere showing how to implement argv in an NDS loader?
|
I think I know how it's done. But unfortunately I can't test it. So this might be wrong, I don't know.
| nds/system.h wrote: |
//! argv structure
/*! \struct __argv
structure used to set up argc/argv on the DS
*/
struct __argv {
int argvMagic; //!< argv magic number, set to 0x5f617267 ('_arg') if valid
char *commandLine; //!< base address of command line, set of null terminated strings
int length; //!< total length of command line
};
//! Default location for the libnds argv structure.
#define libnds_argv ((struct __argv *)0x027FFF70)
// argv struct magic number
#define argvMagic 0x5f617267
|
All I think a bootloader would have to do is, copy the argvMagic number into libnds_argv->argvMagic, allocate memory for commandLine, set length, then copy in the wanted commandLine string. commandLine would probably have the program's path, null terminated, then the parameters, null terminated.
#157780 - HyperHacker - Thu May 29, 2008 4:48 am
It might be wise to wipe out that magic word when your program starts, if you're going to be loading other programs and not passing arguments. Otherwise they might see your arguments as theirs.
_________________
I'm a PSP hacker now, but I still <3 DS.
#157890 - ritz - Sun Jun 01, 2008 12:12 am
Ignore my post please.