I'm developing a program which needs to know in which directory its .prg file is. How can I find it?
I can check the current directory, but if the program is loaded via:
LOAD"/dir1/dir2/program.prg" I get the current folder from 2 nodes up the tree.
Get starting directory in assembly
Re: Get starting directory in assembly
There's no PROGDIR value. If you've provided a fully specified path to
LOADor to the -prg command line option, without ever issuing a
DOS"CD"to the program's location or using -fsroot to set the working directory, then there's just no way to know what directory the program was run from.
Re: Get starting directory in assembly
Ok, thats unfortunate, but I'll live with it 
Re: Get starting directory in assembly
I was thinking about this too, because we're going to eventually need to support having multiple storage devices connected, and BASIC has no concept of where the currently-loaded program came from, and the closest thing from the era was "is the correct disk inserted?". 
So, the best suggestions I could come up with are:
1) If your program needs to access data files that are supposed to be bundled with it, the user will need to navigate their storage to the correct directory before running your program. I don't think there's a way around this. In this case, you could query each device for the expected filename of your data file, and when you find it, you can assume the rest of the files are there too.
1a) If the files still cannot be found, then that's awkward. This would be where you tell the user to insert the correct disk, but on the X16, you'd need to prompt the user to navigate to the correct directory, either from within the program (with a UI you provide) or by exiting.
2) If your program doesn't need to access bundled files, but does want to provide the ability to load and/or save (like an activity program), then it's a good idea not to make assumptions about which device is correct, nor that the device is in the correct directory. So, I think a simple file browser would be good for this.
2a) Looking for the program's default filename can provide a good hint, but it may not be a good idea to require the user not to rename the program file, so don't error out if you can't find it.
3) We could eventually standardize on a shared memory location for launchers to put metadata in, such as which device should be considered the "preferred" one for disk access, but it'd be up to the program to actually check for that information and react to it. Launchers should already be responsible for navigating the preferred device to a preferred directory before running the program anyway.
So, the best suggestions I could come up with are:
1) If your program needs to access data files that are supposed to be bundled with it, the user will need to navigate their storage to the correct directory before running your program. I don't think there's a way around this. In this case, you could query each device for the expected filename of your data file, and when you find it, you can assume the rest of the files are there too.
1a) If the files still cannot be found, then that's awkward. This would be where you tell the user to insert the correct disk, but on the X16, you'd need to prompt the user to navigate to the correct directory, either from within the program (with a UI you provide) or by exiting.
2) If your program doesn't need to access bundled files, but does want to provide the ability to load and/or save (like an activity program), then it's a good idea not to make assumptions about which device is correct, nor that the device is in the correct directory. So, I think a simple file browser would be good for this.
2a) Looking for the program's default filename can provide a good hint, but it may not be a good idea to require the user not to rename the program file, so don't error out if you can't find it.
3) We could eventually standardize on a shared memory location for launchers to put metadata in, such as which device should be considered the "preferred" one for disk access, but it'd be up to the program to actually check for that information and react to it. Launchers should already be responsible for navigating the preferred device to a preferred directory before running the program anyway.