Directory support in QDOS

Anything QL Software or Programming Related.
Post Reply
georgeo
Bent Pin Expansion Port
Posts: 95
Joined: Wed Aug 03, 2016 8:49 am

Directory support in QDOS

Post by georgeo »

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.


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Directory support in QDOS

Post by tofro »

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


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
georgeo
Bent Pin Expansion Port
Posts: 95
Joined: Wed Aug 03, 2016 8:49 am

Re: Directory support in QDOS

Post by georgeo »

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.


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Directory support in QDOS

Post by tofro »

Just checked: The "HOME" thing is available to straight old QDOS as well - See Dilwyn's page on "Toolkits"

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
dilwyn
Mr QL
Posts: 2753
Joined: Wed Dec 01, 2010 10:39 pm

Re: Directory support in QDOS

Post by dilwyn »

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_.
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).

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.


User avatar
janbredenbeek
Super Gold Card
Posts: 629
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: Directory support in QDOS

Post by janbredenbeek »

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.


User avatar
ql_freak
Gold Card
Posts: 353
Joined: Sun Jan 18, 2015 1:29 am

Re: Directory support in QDOS

Post by ql_freak »

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.


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 :-)
User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Directory support in QDOS

Post by tofro »

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


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
RWAP
RWAP Master
Posts: 2834
Joined: Sun Nov 28, 2010 4:51 pm
Location: Stone, United Kingdom
Contact:

Re: Directory support in QDOS

Post by RWAP »

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...


User avatar
Outsoft
Super Gold Card
Posts: 695
Joined: Sat Apr 19, 2014 1:30 pm
Location: Italy
Contact:

Re: Directory support in QDOS

Post by Outsoft »

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.
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).

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.


Post Reply