Are there directory devices with a name longer than 3 letters

[ql_freak]

As the Subject aks: Are their any directory devices which have a name with more than 3 characters (without the trailing digit and underscore) or can a device be defined (with e.g. FLP_USE) with a longer name than 3 characters. Example is a name like "HDSK" possible?

I want to write a SuperBASIC function, which strips the Directory Device Name from a filename, and it would be much easier, if I can rely, that no directory device has a name which is longer than 3.

[tofro]

Directory devices in QDOS can have up to four characters in length (then, obviously, you cannot use a unit number anymore).

The most prominent that actually uses all four characters (and the only ony I know) is "BOOT", which is booted from even before "mdv", thus used for boot overrides for new directory devices temporarily during the boot process. But this is typically re-named during startup to, for example, "win" or "flp" - So, not encountered on a running machine, typically.

You can argue whether BOOT is a directory device - it supplies a stream only. OTOH, it's used for booting, so it must be one

If you look into the definition tables, a directory device driver name has a word length - so, in theory, it could be much longer in QDOS.
SMSQ/E has only four characters reserved for that string.

For programs like yours, I'd recommend walking the list of directory device drivers (base address in system variables) and checking the string at $3c in each linkage block - this way, you can build a list of valid directory drivers for this specific machine.

The QL network complicates things even more: Note "NET2_win1_" is a valid directory device!

[RalfR]

As the Subject aks: Are their any directory devices which have a name with more than 3 characters (without the trailing digit and underscore) or can a device be defined (with e.g. FLP_USE) with a longer name than 3 characters. Example is a name like "HDSK" possible?

The known devices are seen at SV_DDLST.

[NormanDunbar]

This might help, it's from DJToolkit:

https://superbasic-manual.readthedocs.i ... l#dev-name

Or this:

https://superbasic-manual.readthedocs.i ... l#max-devs

Cheers,
Norm.

[ql_freak]

For programs like yours, I'd recommend walking the list of directory device drivers (base address in system variables) and checking the string at $3c in each linkage block - this way, you can build a list of valid directory drivers for this specific machine.

I have tried this (afaik). But (at least on QPC2) there has been a problem. I didn't get all DDs, or there was a gap - can't remember.

The problem are those dreaded (SuperBASIC) default directories. I think I have to write a new SuperBASIC extension "fopen" function or so, which ignores the default directories. All File I/O functions/procedures are unfortunately handled by the default directories of SB :-(

The QL network complicates things even more: Note "NET2_win1_" is a valid directory device!

I know :-(

[mk79]

Directory devices in QDOS can have up to four characters in length (then, obviously, you cannot use a unit number anymore).

At least in SMSQ/E directory drivers always must have a drive number in the range 1..8. So in theory you can have 4 chars + number, but I've never seen it in practice and all hell might break loose if you try

You can argue whether BOOT is a directory device - it supplies a stream only. OTOH, it's used for booting, so it must be one

Due to the missing number (and filename!) it must be a stream device But do you actually know anybody implementing the BOOT device? All auto-boot implementations I know temporarily rename their device to MDV for auto-booting. Makes things interesting when two devices do this I considered implementing a BOOT device for QL-SD, but due to space considerations I staid with the simple MDV thing for now.

The QL network complicates things even more: Note "NET2_win1_" is a valid directory device!

True, those are a pain to handle.

[NormanDunbar]

Hi Peter,

I have tried this (afaik). But (at least on QPC2) there has been a problem. I didn't get all DDs, or there was a gap - can't remember.

I started QPC2 this morning and:

Code: Select all

dev_use 1, win1_c68_

1000 addr = 0
1010 REPeat loop
1020   PRINT "<" & DEV_NAME(addr) & ">"
1030   IF addr = 0 THEN EXIT loop: END IF
1040 END REPeat loop

The result was:

Code: Select all

<DOS>
<DEV>
<FLP>
<WIN>
<RAM>
<>

For some unknown reason - unknown to me anyway - there always seems to be a directory driver with a null name. The list created is all the directory drivers enabled on my QPC2 system - I'm puzzled as to why you think there might be something missing or a gap?

Try the above with DJToolkit loaded, see what you get.


Cheers,
Norm.

[tofro]

Due to the missing number (and filename!) it must be a stream device But do you actually know anybody implementing the BOOT device? All auto-boot implementations I know temporarily rename their device to MDV for auto-booting. Makes things interesting when two devices do this I considered implementing a BOOT device for QL-SD, but due to space considerations I staid with the simple MDV thing for now.

All versions of the QubIDE driver seem to do this.
They implement a device named "BOOT" which is higher in the boot hierarchy than any other driver. That enables QubIDE to co-exist (and move itself in front of them) whith floppy device drivers that go the mdv way, and still revert all the changes it did to the names.

The "open" code of QubIDE's BOOT device will then walk the list of device drivers and count the number of "mdv" occurences - If there's more than one, it detects "there must already be a floppy device driver that has renamed itself to mdv" - In this case, it will chain in and rename itself "mdv" to be the boot device - It needs to detect this in order to find out what needs to be reverted after boot from "mdv".

Tobias

[mk79]

For some unknown reason - unknown to me anyway - there always seems to be a directory driver with a null name.

Bug or definition problem in DEV_NAME. It doesn't return the next block in addr, but the current one. So on RAM it returns with the addr of RAM, you call it again, then it tries to go to the next block, only then realising that it's finished and returning an empty device string afterwards.

Marcel

[pjw]

For programs like yours, I'd recommend walking the list of directory device drivers (base address in system variables) and checking the string at $3c in each linkage block - this way, you can build a list of valid directory drivers for this specific machine.

I have tried this (afaik). But (at least on QPC2) there has been a problem. I didn't get all DDs, or there was a gap - can't remember.

The problem are those dreaded (SuperBASIC) default directories. I think I have to write a new SuperBASIC extension "fopen" function or so, which ignores the default directories. All File I/O functions/procedures are unfortunately handled by the default directories of SB

The QL network complicates things even more: Note "NET2_win1_" is a valid directory device!

I know

I have torn a lot of hair out due to similar problems over the years. Some of my solutions in S*BASIC can be found at my Knoware site. See for example GO TO/Files.
PS None of these solutions are geared towards network drivers tho', as at the time I was most active QL networking was more a matter of fluke than of logic.