Directory support in QDOS
Directory support in QDOS
Hi everyone,
I've been experimenting with the support for directories in the Toolkit II extension. The underlying reason is that I want to make more efficient use of floppy diskettes, which have around 7-times the capacity of Microdrive cartridges, by storing multiple programs on the same diskette. However, I wanted to minimise the amount of configuration I needed to do, by using built-in directory support -- for example, PROG_USE and DATA_USE commands to set default directories for file operations. I started by creating a floppy diskette with some different development tools, putting the C1 FORTH compiler and an M68008 assembler files in flp1_c1forth_ and flp1_c1ass_.
Results have been mixed as the PROG_USE and DATA_USE don't look to be universally supported; EXEC and EXEC_W do respect the PROG_USE environment but LRUN does not, so I have had to edit the BASIC BOOT program where applicable. I also suspect programs may need to be aware of the DATA_USE environment in order to default to accessing data from a particular directory and I don't know how many programs will do this -- though C1 FORTH was able to find its dictionary without me explicitly telling it to look in flp1_c1forth_.
Anyone else thought about this or come up with a more reliable way of multiple applications on a single device?
George.
I've been experimenting with the support for directories in the Toolkit II extension. The underlying reason is that I want to make more efficient use of floppy diskettes, which have around 7-times the capacity of Microdrive cartridges, by storing multiple programs on the same diskette. However, I wanted to minimise the amount of configuration I needed to do, by using built-in directory support -- for example, PROG_USE and DATA_USE commands to set default directories for file operations. I started by creating a floppy diskette with some different development tools, putting the C1 FORTH compiler and an M68008 assembler files in flp1_c1forth_ and flp1_c1ass_.
Results have been mixed as the PROG_USE and DATA_USE don't look to be universally supported; EXEC and EXEC_W do respect the PROG_USE environment but LRUN does not, so I have had to edit the BASIC BOOT program where applicable. I also suspect programs may need to be aware of the DATA_USE environment in order to default to accessing data from a particular directory and I don't know how many programs will do this -- though C1 FORTH was able to find its dictionary without me explicitly telling it to look in flp1_c1forth_.
Anyone else thought about this or come up with a more reliable way of multiple applications on a single device?
George.
Re: Directory support in QDOS
Georgio,
there is a number of extensions that support you in the arrangements of directories and finding executable programs.
The most important one might be the pth_ device - This does more or less what PATH does in Linux and Windows, but different (you might have thought so...) - And it relieves you of the need to cram all of your executable programs into one single folder. Just put them where you want them, add the directories to pth1_ using PATH_ADD and set PROG_USE to pth1_. You'll never need to remember where you put your programs again when you want to run them.
Next you want to be looking at is the dev_ device - That allows you to work with a directory as if it were a straight device like mdv1_ . dev_ is invaluable for programs that don't support directories at all.
Others are extensions in SMSQ/E that remember where you loaded something from (home and lastload support). If you load a program from, for example, flp1_verylong_pathname_and_long_program_bas and are too lazy to type that name again when saving, just do so: SAVE_O without any argument will simply save to the same file you loaded the program from. SMSQ/E does that remembering for you.
x = FOPEN(HOME_DIR$&filename_dat) will open a file in the same directory the BASIC program was loaded from. This allows you to write programs without hard-coded directory names.
Your examples are based on floppies, on even larger storage like SD-Card or hard disk, directories are invaluable means of supporting you to find where you've put your stuff.
A forum answer is much too short to tell you about all the possibilities modern QDOS system have available to support you in handling directories - The above is only a short rundown of options I tend to use.
The QL-SD manual has a quite extensive chapter on how to handle large storage space with the tools available.
Tobias
there is a number of extensions that support you in the arrangements of directories and finding executable programs.
The most important one might be the pth_ device - This does more or less what PATH does in Linux and Windows, but different (you might have thought so...) - And it relieves you of the need to cram all of your executable programs into one single folder. Just put them where you want them, add the directories to pth1_ using PATH_ADD and set PROG_USE to pth1_. You'll never need to remember where you put your programs again when you want to run them.
Next you want to be looking at is the dev_ device - That allows you to work with a directory as if it were a straight device like mdv1_ . dev_ is invaluable for programs that don't support directories at all.
Others are extensions in SMSQ/E that remember where you loaded something from (home and lastload support). If you load a program from, for example, flp1_verylong_pathname_and_long_program_bas and are too lazy to type that name again when saving, just do so: SAVE_O without any argument will simply save to the same file you loaded the program from. SMSQ/E does that remembering for you.
x = FOPEN(HOME_DIR$&filename_dat) will open a file in the same directory the BASIC program was loaded from. This allows you to write programs without hard-coded directory names.
Your examples are based on floppies, on even larger storage like SD-Card or hard disk, directories are invaluable means of supporting you to find where you've put your stuff.
A forum answer is much too short to tell you about all the possibilities modern QDOS system have available to support you in handling directories - The above is only a short rundown of options I tend to use.
The QL-SD manual has a quite extensive chapter on how to handle large storage space with the tools available.
Tobias
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Re: Directory support in QDOS
Hi Tofro,
Thanks for that. I'm using a standard QL, with a Trump card, so will experiment with pth_ and dev_ options. Looks good.
Thanks again,
George.
Thanks for that. I'm using a standard QL, with a Trump card, so will experiment with pth_ and dev_ options. Looks good.
Thanks again,
George.
Re: Directory support in QDOS
Just checked: The "HOME" thing is available to straight old QDOS as well - See Dilwyn's page on "Toolkits"
Tobias
Tobias
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Re: Directory support in QDOS
Remember that SuperBASIC and SBASIC "programs" are data files (file type 0) as far as the operating system is concerned, so LRUN etc use DATA_USE settings (not PROG_USE). Remember that in this sense, a QL "program" is something you start with EXEC or EXEC_W or EX or EW or similar commands (file type 1).georgeo wrote: Results have been mixed as the PROG_USE and DATA_USE don't look to be universally supported; EXEC and EXEC_W do respect the PROG_USE environment but LRUN does not, so I have had to edit the BASIC BOOT program where applicable. I also suspect programs may need to be aware of the DATA_USE environment in order to default to accessing data from a particular directory and I don't know how many programs will do this -- though C1 FORTH was able to find its dictionary without me explicitly telling it to look in flp1_c1forth_.
Support for defaults and directories in software generally is a bit of a mess - every program does its own thing and support varies. As far as I know, there is no list of which programs do what. Some programs have configurable defaults, some do use defaults and some don't. There is all sorts of add-on software to enhance what is possible but older programs (not true in each and every case though) in particular don't know how to use defaults systems written after the program itself was written. No simple one size fits all solution I'm afraid.
--
All things QL - https://dilwyn.qlforum.co.uk/index.html
All things QL - https://dilwyn.qlforum.co.uk/index.html
- janbredenbeek
- Super Gold Card
- Posts: 632
- Joined: Wed Jan 21, 2015 4:54 pm
- Location: Hilversum, The Netherlands
Re: Directory support in QDOS
LRUN does in fact use both DATA and PROG directories. AFAIK it tries DATAD$ first and if it can't find the program there it uses PROGD$.
Unfortunately these default directories are not implemented at the QDOS TRAP level so any EXECable application that wishes to make use of them need to read out the appropriate system variables (at $280AC, $280B0 and $280B4 for PROG, DATA and DEST respectively). According to the TKII manual there is another way to open files with default directories, by preparing a special header after the $4AFB + program name at the beginning followed by another $4AFB followed by your own code (which will be executed as part of SuperBASIC, not as an executable job). I do not know of any programs that make use of this facility.
'Hard' subdirectories on FLP devices are only available with V2 drivers which are implemented in the (Super) Gold Card, SMSQ and a few others.
Interestingly, when you do a DIR on these subdirectories you get only the files from the subdir but always with the full subdir name in front of it, which I find a bit annoying (I've written a SuperBASIC procedure 'ls' which suppresses them to make the output much like the Unix 'ls' command).
later, Jan.
Unfortunately these default directories are not implemented at the QDOS TRAP level so any EXECable application that wishes to make use of them need to read out the appropriate system variables (at $280AC, $280B0 and $280B4 for PROG, DATA and DEST respectively). According to the TKII manual there is another way to open files with default directories, by preparing a special header after the $4AFB + program name at the beginning followed by another $4AFB followed by your own code (which will be executed as part of SuperBASIC, not as an executable job). I do not know of any programs that make use of this facility.
'Hard' subdirectories on FLP devices are only available with V2 drivers which are implemented in the (Super) Gold Card, SMSQ and a few others.
Interestingly, when you do a DIR on these subdirectories you get only the files from the subdir but always with the full subdir name in front of it, which I find a bit annoying (I've written a SuperBASIC procedure 'ls' which suppresses them to make the output much like the Unix 'ls' command).
later, Jan.
Re: Directory support in QDOS
A Question:
Is there any chance, to support longer pathnames than the currently 41 chars (devX_ + filename_with_36_chars)?
QL was great at its times with its 36 character long filenames, but unfortunately this is also the maximum pathname length. We need a new directory device, which supports longer pathnames.
Is there any chance, to support longer pathnames than the currently 41 chars (devX_ + filename_with_36_chars)?
QL was great at its times with its 36 character long filenames, but unfortunately this is also the maximum pathname length. We need a new directory device, which supports longer pathnames.
http://peter-sulzer.bplaced.net
GERMAN! QL-Download page also available in English: GETLINE$() function, UNIX-like "ls" command, improved DIY-Toolkit function EDLINE$ - All with source. AND a good Python 3 Tutorial (German) for Win/UNIX
GERMAN! QL-Download page also available in English: GETLINE$() function, UNIX-like "ls" command, improved DIY-Toolkit function EDLINE$ - All with source. AND a good Python 3 Tutorial (German) for Win/UNIX
Re: Directory support in QDOS
Peter,
it's not the driver that limits the length of a QDOS path name.
Actually, it's the channel definition block (that is, the message vehicle between the driver and the OS) that is actually allocated by QDOS that limits this length (A CDB reserves exacly 40 bytes for a path name).
Another data structure limiting the file name length is the file header structure. It reserves the very same 40 bytes per name in a directory entry.
Regards,
Tobias
it's not the driver that limits the length of a QDOS path name.
Actually, it's the channel definition block (that is, the message vehicle between the driver and the OS) that is actually allocated by QDOS that limits this length (A CDB reserves exacly 40 bytes for a path name).
Another data structure limiting the file name length is the file header structure. It reserves the very same 40 bytes per name in a directory entry.
Regards,
Tobias
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
-
- RWAP Master
- Posts: 2837
- Joined: Sun Nov 28, 2010 4:51 pm
- Location: Stone, United Kingdom
- Contact:
Re: Directory support in QDOS
I might be barking up the wrong tree (I am struggling to keep awake at the moment), but it must be possible to do something similar to level 2 drivers, so that a special driver is written, which stores paths in a new file structure on the disk (hard disk etc).
It could be written so that from a program point of view, it would work similar to the DEV device (say called EXT3_), so you could set up:
EXT3_USE pd,'win1_programs_basic_toolkits_public_domain_'
This would add a line to a special file (say win1_EXT3) in the root of win1_ which would contain the shortname ('pd') and the longname ('win1_programs_basic_toolkits_public_domain_')
DIR ext3_
would then provide a list of the shortnames only which are defined in the file win1_EXT3
Another tool / command would be required to look up the long name....
SAVE ext3_pd_boot
You could even potentially extend it by allowing you to set a home path, which is then looked up whenever you do LOAD or SAVE ext1_
would tell the ext3 device driver to look up the correct path for the shortname pd and then write to the proper long name:
win1_programs_basic_toolkits_public_domain_boot
These long directories would not be visible from within a normal DIR / SAVE / LOAD command structure - so they may need to be hidden in some way (maybe a special file type and re-write the drivers for win and flp drivers to ignore that file type?)
The main problem would be the physical directory structure on the device - how would you get around the 40 character limit?
Might have shot myself in the foot with the last issue... However, something to consider...
It could be written so that from a program point of view, it would work similar to the DEV device (say called EXT3_), so you could set up:
EXT3_USE pd,'win1_programs_basic_toolkits_public_domain_'
This would add a line to a special file (say win1_EXT3) in the root of win1_ which would contain the shortname ('pd') and the longname ('win1_programs_basic_toolkits_public_domain_')
DIR ext3_
would then provide a list of the shortnames only which are defined in the file win1_EXT3
Another tool / command would be required to look up the long name....
SAVE ext3_pd_boot
You could even potentially extend it by allowing you to set a home path, which is then looked up whenever you do LOAD or SAVE ext1_
would tell the ext3 device driver to look up the correct path for the shortname pd and then write to the proper long name:
win1_programs_basic_toolkits_public_domain_boot
These long directories would not be visible from within a normal DIR / SAVE / LOAD command structure - so they may need to be hidden in some way (maybe a special file type and re-write the drivers for win and flp drivers to ignore that file type?)
The main problem would be the physical directory structure on the device - how would you get around the 40 character limit?
Might have shot myself in the foot with the last issue... However, something to consider...
Rich Mellor
RWAP Software
RWAP Adventures
SellMyRetro
Retro-Printer Module - add a USB printer to your QL
Also Involved in:
Icephorm
RWAP Software
RWAP Adventures
SellMyRetro
Retro-Printer Module - add a USB printer to your QL
Also Involved in:
Icephorm
Re: Directory support in QDOS
With my "Winny" I use modify all the Superbasic lines and then the Code parts that makes calls on MDV of FLP: naturally in some cases is impossible to work with all files in the same dir (with a trump card without ROM 2) but is always a good compromise (most of the program files on dir and the rest in the root).georgeo wrote:Hi everyone,
I've been experimenting with the support for directories in the Toolkit II extension. The underlying reason is that I want to make more efficient use of floppy diskettes, which have around 7-times the capacity of Microdrive cartridges, by storing multiple programs on the same diskette. However, I wanted to minimise the amount of configuration I needed to do, by using built-in directory support -- for example, PROG_USE and DATA_USE commands to set default directories for file operations. I started by creating a floppy diskette with some different development tools, putting the C1 FORTH compiler and an M68008 assembler files in flp1_c1forth_ and flp1_c1ass_.
Results have been mixed as the PROG_USE and DATA_USE don't look to be universally supported; EXEC and EXEC_W do respect the PROG_USE environment but LRUN does not, so I have had to edit the BASIC BOOT program where applicable. I also suspect programs may need to be aware of the DATA_USE environment in order to default to accessing data from a particular directory and I don't know how many programs will do this -- though C1 FORTH was able to find its dictionary without me explicitly telling it to look in flp1_c1forth_.
Anyone else thought about this or come up with a more reliable way of multiple applications on a single device?
George.
Is all ordered too.
With the WIN_REXT command of the Winny you can simulate a WIN2_ as a DIR but you have to make resident this file each time you need it.