On Jeudi 28 Juin 2001 04:13, ZN wrote:
[long filenames support via "special" device driver and thing]
> 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.
Which parts ?
> Regarding long file names, some kind of 'shorthand' may be required
> when referring to them, such as the concept of 'current directory'.
There is already references to "current directory" into the channel
headers of level 2 devices...
> Are we going to have the directory separateor argument again, i
> wonder? :-)
Nothing to argue about: both QDOS and UNIX namming conventions may
be implemented into an ISO9660/Joliet device driver. They are just
that: "conventions"... and not driver programming constraints.
> I do see one remaining problem, though. There is still a limit to the
> number of directory devices that can be in use simultaneously.
Yes, 16...
> Since all calls in SMSQ/E are passed to a non-directory driver,
> I have to ask, why bother with a directory driver?
Because the IOSS takes care of most ancillary tasks when opening
a channel on a directory device driver:
- device physical definition block check and allocation (if absent).
- channel definition block duplication in case of a shared open call
on an already open file.
- automatic freeing of channel def. block for DELETE calls.
And also because non-directory device drivers don't get listed into
the programs that scan the directory device driver linked list to
find out which directory devices are available on the system (QPAC2
Files menu, Cueshell, PWfile, etc)...
["modular" device driver]
> 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
Yes there are...
Under SMSQ/E this is handled through extensions things when needed
(i.e. floppy and ramdisks do not need this mechanism, but hard disks
and ATAPI device do and got one). For hard disks (on Q40/Q60 and
probably ATARI), you got the SBASIC WIN_DRIVE command (which in fact
calls an extension from the "WIN control" thing): e.g. WIN_DRIVE 1,0,1
links win1_ to first IDE drive (1st IDE controller, master) and to the
second partition (0=1st, 1=2bd, etc...).
With the CDROM device driver, you got CDR_DRIVE device,drive,session.
E.g. CDR_DRIVE 1,1,3 links cdr1_ to the fourth session on the second
IDE drive (1st IDE controller, slave).
The problem is that I don't have the "WIN control" specs, so I don't
know if my implementation of the "DRIV" extension (same problem for
the "USE" one BTW), in the "CDROM" thing is the same (on the parameters
passing point of vue) than the one of the "DRIV" extension in the "WIN
control" thing... I will write to TT about this (let's hope he will
reply this time...). Of course, these extension should ideally share
the same parameter passing conventions so that they can be called from
the same routine in assembly or C (or whatever language). Example with
a C library routine:
int set_device(char *thing_name, int device, int drive, int volume);
Such function would then just have to call the thing which name is
thing_name with "DRIV" as the required extension and device/drive/volume
as parameters...
> but special parameters passed to open/close or even format calls could
> be used for this.
I see the "meta device" sea serpent emerging once again here... ;-)
Let me say that this is (although definitely possible) NOT in the
philosophy of QDOS/SMS. TRAP #2/TRAP #3 are related to channels
(with the notable exception of the FORMAT TRAP #2), and NOT to
anything related to device driver (or drive) parameter settings...
Here AGAIN, think "thing" !
> 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).
If all device driver are properly written, there is no risk for this...
> 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.
This is my case on my Q60... But IDE specs do take care for this
and a same IDE bus may be shared by the two master and slave devices
provided they both obey to the IDE specs (see below)...
> 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.
You are alas right on this point: the built-in SMSQ/E hard disk
device driver thinks it is the only one to own the IDE controller
and therefore makes some risky assumptions (and simplifications)
about its state. For the more techie among QLers, it assumes that
when the BUSY flag is 0, the controller is free and ready to receive
a new command; in fact it should check for DRQ (data request) = 0
too...
As for the CDROM device driver, this imposes to perform all the
transfers for a single command into the same scheduler loop call
rather than allowing to split this transfer between several calls.
The result is that the system is "frozen" while the CDROM spins up...
A solution resides in the overlapped ATAPI command protocol (a protocol
that allows to release the IDE bus, for use by another ATA device, just
after an ATAPI command was sent and until the data for this command is
ready).
Alas I don't have currently an overlap capable drive attached to the
Q60. I will nevertheless implement this protocol later (but obviously
it will be usable with the most recent CD-ROM drives only...).
Another possibility is to ask TT to change slightly his IDE hard
disk device driver so that it takes DRQ into account; in this case
there would be no more conflict and I could split easily the CDROM
scheduler loop task so that the system is no more "frozen" while
accessing the CD-ROM...
> 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.
As of ATAPI, this is not a problem: my device driver got a "queue ATAPI
packet" extension thing: any driver (or even user level software, such
as a CD-R recorder ;-) that needs to send an ATAPI command to a drive,
just has to call this queueing command and wait for it to complete (by
scanning a flag value). The CD-ROM device driver takes care of sending
the command and recovering/sending the related data to the proper drive
on the proper IDE controller (8 drives/4 controllers are supported right
now but more could be added)...
> > 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.
I will take a look once everything works on Q60...
> The problem of two (or more) drivers using the same hardware
> unfortunately, still remains, because Qubide only has one channel.
This is to be checked, perhaps Qubide is behaving "only as bad" as
the SMSQ/E hard disk device driver: in this case my CD-ROM driver
will work out of the box for Qubide as well ! ;-)
> 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.
Hardware is not the problem here: software (drivers) is !
QDOS/SMS forever !
Thierry.
