aowen escribió:Alcoholics Anonymous escribió:Supporting types like sna & tap just offers a way to organize your programs through the .run command. For sna, I will try to load up and run .snapload to do the actual load in that case.
That will be a pain to do. You'll have to get out of divMMC RAM into main RAM and force the BASIC command ".snapload <filename>". The way divMMC arbitrarily gets paged in and out is bad enough to begin with before you have to deal with dropping in and out of divMMC RAM.
Dot commands dont't have to be hard because you can load them to 0x2000, put a command line in HL and then jump to 0x2000. Because this is a snapshot loader you don't have to worry about trashing any ram.
But doing taps means you have to somehow do LOAD"" and keep basic happy. If pushing LOAD"" into the edit buffer is the way to go then maybe it would be just as easy to do ".snapload name" that way too.
Or you could just have a path file in the OS folder as a plain text file with a list of folders.
Yes that may be the way to go. Have a special "PATH" file that is easy to edit and is available to anything. Place it in the root dir of the system drive. If it is absent then just default to a built in default search path.
Paths would probably have to be able to accommodate a drive identifier:
hd0:/programs
If drive id is left out, maybe a default can be provided. Paths have to be absolute so if initial / is missing, that's an error. Paths can be separated by CR/LF (one per line). Leading and terminating whitespace in a path is ignored. Maybe accommodate both / and \ as directory separator.
So:
.run [n] name ["command line"]
will look for the program name to launch in the ordered list of directories in PATH.
name can be a relative pathname (path without leading / followed by name)
name can be an absolute pathname with optional drive (no PATH search is done)
the optional n is a number indicating the nth match should be used in a PATH search
optional command line enclosed in quotes
.run -w name
will report which directories name is found in
.run -p
will identify problems in PATH
(it's essentially free since checks will be done anyway)
One thing I would like to avoid is competing standards. I've been working on this for nearly a year now and, like the rest of UnoDOS 3, it will be open source. So there's the potential to contribute somewhere down the line. Of course I can't stop anyone from doing it (which is why I haven't published full details on the format ... because a certain group of people are likely to help themselves to it and break compatibility).
Yes things should stay compatible. I think the only point of incompatibility is how to load that first binary. In my view there has to be a header and it has to be a header that can change if new ideas come up.
At the moment I can see a header like this being useful:
<?> Signature
<2> Length of header from here
<2> Optional RAMTOP value (0 = no ramtop check) - behaviour is to exit RAMTOP no good if current RAMTOP is too high
<2> ORG of binary following header
<2> Optional length of binary following header (0 = load whole thing)
<1> Flags: bit 0 = 1 to pass command line, bit 1 = 1 to pass file handle
If such a header does not exist (signature is not there) then just load at 32768 and execute.
The file handle thing is there because I see the option of loading the first part of a file as a loader and then the loader continues with that file handle to load the rest of its bits into memory banks.
The command line is constructed on the stack which will be below RAMTOP.
So loading would mean reading the initial header block to learn ORG and all that and then load the rest to execute.