>> Well, I hate to be a party breaker, but guess what: all standard CD file
>> systems have a deeper directory structure and/or longer names than the
QL
>> is capable of handling with it's 36 character path+name limit.
> Wrong! ISO9660 is limited to 32 chars in filenames (path name included)
> and to 8 levels of sub-directories...
True, as long as the unextended ISO9660 is used (without Joliet). I don't
have the ISO specs handy, but wasn't it originally 8+3 filenames?
>> As a result, it is not possible to implement a directory device driver
>> that would do anything but direct sector access, or some sort of bodged
>> file access.
> Wrong again !
> By using a small trick, I can make a SMSQ/E (NOT QDOS !) directory
> device driver to use long filenames. Here is how the trick works:
In QDOS/SMS, when an OPEN system call is issued, the IOSS (Input Output
Sub System) first extract the device/file name and asks to each non-
directory device driver if it recognizes this name as one of its device
(+parameters) name, the length of this name is not limited (well it is,
but to a bigger number of chars: 127 if the name was not quoted, 32765
if it was).
Yes, once a long time ago I wrote about this. because non-directory devices
are searched first, and they basically accept a QDOS string as name plus
parameters, this enables a driver to get to the untruncated string which
may or may not be a file name.
> To overcome the 36 chars limit, [a non directory device driver has to]
> to store the long filename somewhere, truncate it to 36 chars [and return
> not found so that scanning continues to the directory driver which then
> sees a 36 character name and handles it]
> When a new device driver wants support for long filename, the only thing
> it must do is to register itself to the "long filename" thing... by
> passing it it's device driver linkage block address [where the pointer
> to the long name will be placed]
> Now why only SMSQ/E and not QDOS? Because SMSQ/E implements support for
> all TRAP #2 calls into the non-directory device drivers. E.g., when
> issuing a DELETE system call under QDOS, only the directory device
> drivers list is scanned [so the long file name handler would not be
> called]
Well, I am glad to have been proven wrong on this. Briliant idea!
I wonder if a more complete spec could be made for such 'registration'
mechanisms as they could be useful for other parts of the driver, not only
the long file names. Regarding long file names, some kind of 'shorthand'
may be required when referring to them, such as the concept of 'current
directory'. Are we going to have the directory separateor argument again, i
wonder? :-)
I do see one remaining problem, though. There is still a limit to the
number of directory devices that can be in use simultaneously. Since all
calls in SMSQ/E are passed to a non-directory driver, I have to ask, why
bother with a directory driver?
>> I won't even go into ideas of having the CD driver being modular,
>> something that links to a regular 'ide' driver through correct sector
>> access - cause QDOS has no real linking capability, so it would have
>> to be yet another bodge.
> Still wrong...
> My CD-ROM device driver is implemented as a thing and will
> implement a registering "thing extension" that will allow
> for a "module" to plug itself into the device driver. The
> module will have to implement OPEN, CLOSE and all I/O
> sytem calls for its own filesystem.
This is not really what I meant. What I emant is that 'mounting' of a
devices, i.e. linking of a driver to a piece of physical hardware, should
logically be handled by TRAP #2. However, there are no calls to do this -
but special parameters passed to open/close or even format calls could be
used for this. However, even if they are, at the very lowest level, where a
single piece of hardware can be used by many drivers, there may be a
problem, unless all of the drivers that can access the hardware are
rewritten to take account of each other, or a 'hardware' driver was
written, into which other drivers are linked (problem here is that we might
end up with more than the max number of simultaneous directory drivers).
IDE is the example that comes to mind on a QL. Suppose that the user
connects a hard drive and a CD ROM as master and slave on a single IDE
channel. Effectively, this looks like a set of registers for each device,
however, only one set at a time can be used, and this is switched by one
bit. This bit is visible and changeable by both drivers. Unfortunately,
most (if not all) drivers assume the hardware will exclusively be used by
themselves - and here we have a problem, they rely on the state of
registers to be preserved.
SCSI is another related example. A SCSI host adapter does nothing of
itself, but may have many different devices connected to it, that all
require treatment by essentially different drivers. This may look
irrelevant, however, ATAPI is essentially a SCSI data transport protocol
that works over IDE, which wasn't originally planned with this capability
in mind. As a result, the bank switched registers mentioned above don't
even have the same functions, when a CD and a hard drive is connected.
> Provided I know where to find the ATA registers, I could
> port the CD-ROM device driver on any hardware based system
> (don't even think about porting it on emulators !). Qubide
> is a candidate provided some doc (or source) is available
> for it...
All the necessary hardware data can be found in the files area of the
QLhardware egroup.
The problem of two (or more) drivers using the same hardware unfortunately,
still remains, because Qubide only has one channel. The way around them
would be modifying the Qubide driver. It may be a better idea to actually
modify the QWA driver for Qubide, this should be relatively easy since
Qubide and Q40 IDE is not that different.
My fear here is that this will be a recurring problem, with lots of
different hardware.
All the best,
Nasta
