Re: [ql-users] Re: Q40/Q60 device drivers
On Wed, Jun 27, 2001 at 06:06:17AM +0100, Dave Walker wrote: My DiscOVER can already read CD's if it can get direct sector access (it can also handle DOS format hard disks if the same can be done). Unfortunately it appears that none of the current emulators give this level of access to the native media on which their QXL.WIN file systems reside - a great shame I believe. UQLX will give you direct sector access through normal Unix devices, simple open#4,'/dev/fd0' will do. The positioning is linear bytewise ( though sector boundaries should probably be respected for compatibility). Bye Richard
Re: [ql-users] Re: Q40/Q60 device drivers
On Fri, 29 Jun 2001 00:20:40 +0100 Q Branch [EMAIL PROTECTED] writes: In article [EMAIL PROTECTED], Thierry Godefroy [EMAIL PROTECTED] writes On Jeudi 28 Juin 2001 23:42, Tony Firshman wrote: On Thu, 28 Jun 2001 at 21:16:18, you wrote: C'est l'exception qui confirme la règle (which I will risk to try to translate into: This is the exception which confirms the rule) The exception proves the rule I knew it was risky... ;-) In actual fact the word 'exception' as used in the context of this saying originally meant the opposite of what it does today. Therefore the expression means that an example taken from a a list will confirm the premise and not the meaning held today that an example which contradicts a rule will confirm it. A concept which is plainly stupid. This is a good example of English meaning changing over the years and people being too happy to parrot a meaningless phrase rather than apply any thought. The original translation was closest. I'm sorry to say that the immediately above is spurious and requires comment: Actually, the phrase proves the rule MAY BE TRANSLATED TO THE VERNACULAR AS tests the rule ... The almost archaic use of the word proof is still (no pun intended) used in the labeling of alcoholic spirits. I believe that some fuel ratings are referred to as test ... So, 'the exception _tests_ the rule' is the correct transliteration to the vernacular. Similarly, 'the _proof_ is in the pudding' would be transliterated to 'the _test_ is in the pudding'. Yes, the same word is frequently used as BOTH a verb AND a noun in English whereby the external form is the same AND the internal form is etymologically kindred. Further, Such-and-such proving grounds IS readily understood to be Such-and-such testing grounds ... So, we find the word proof and test maintain their synonymous nature when used as EITHER a verb OR noun OR adjective OR __. A common external form (i.e., 'word') having multiple grammatical utilization is, of course, a consequence of the general lack of declension and/or conjugation (where applicable) in the English language. GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.
Re: [ql-users] Re: Q40/Q60 device drivers
At 01:12 PM 6/28/2001 -0400, Nasta wrote: Let me give you an example. Suppose someone implemented SCSI on the Q40. Then, you could connect an IDE and a SCSI hard disc to it. Boh would use the QWA file system, but here is the problem: each device would have it's own copy of the QWA handling code. If there was a CD connected to either (and here we would already be circumventing another driver that works on the same hardware), with a QXL.WIN on it, then the CD driver would also need it's own copy of the QWA handling code. And, there would be no way to make one be win1_ the other win2_ and the QXL.WIN on the CD be a win3_, although they logically should be. It could be done, if they were all set to _USE another name, then some sort of DEV_USE would be used to make them dev1,2,3, and then a DEV_USE win would make them win 1,2,3. Total number of QWA copies: 3. Total number of directory devices used: 4. If you think about it, only one copy of the QWA handler code and only one device driver would really be needed. Now, I'm not an expert in XFS (the IRIX file system), but I spent enough time listening to the experts talking about it so that I know a little about it. With XFS, the file system is separated from the physical device by a virtual file system (vfs). In other words, an XFS inode, points to a vfs inode, which points to a physical device sector. This way XFS can work across hard drives and CD's. This also allows for a volume manager (XLV) to come into play, and step in between XFS and the VFS. XLV allows striping and disk mirroring. With SCSI pretty much being the only way to hook up disks and tapes, the SCSI controller one the one point where every call has to go through and the controller could handle multiple conversations (sort of timeshared as the SCSI protocol only allows one conversation at a time). Something like this could be implemented in SMSQ/E, but it would take a concerted effort. The XFS team had about 5-8 people at any one time. With SMSQ/E we just have TT. Tim Swenson
Re: [ql-users] Re: Q40/Q60 device drivers
In article [EMAIL PROTECTED], [EMAIL PROTECTED] writes SNIP The exception proves the rule I'm sorry to say that the immediately above is spurious and requires comment: SNIP An interesting new take on the subject. I got my information from my English lecturer at college who extensively studied English usage and the changes which have occurred over the centuries. Of course the usage of the word to prove have been changed over the years too and, in baking parlance, you use the word to describe the fermenting process so that harks back to the 'pudding'. This is, however, not a real subject for discussion on this list and should be continued in private if you want. -- Roy Wood Q Branch 20 Locks Hill, Portslade, Sussex BN41 2LB Tel : +44(0)1273-386030 / Mobile : +44 (0) 7836-745501 Fax +44 (0)1273-381577 web site : http://www.qbranch.demon.co.uk/
Re: [ql-users] Re: Q40/Q60 device drivers
On Sat, 30 Jun 2001 21:19:53 -0500 Phoebus Dokos [EMAIL PROTECTED] writes: At 12:20 ðì 2/7/2001 +0100, you wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] writes SNIP The exception proves the rule I'm sorry to say that the immediately above is spurious and requires comment: SNIP An interesting new take on the subject. I got my information from my English lecturer at college who extensively studied English usage and the changes which have occurred over the centuries. Of course the usage of the word to prove have been changed over the years too and, in baking parlance, you use the word to describe the fermenting process so that harks back to the 'pudding'. This is, however, not a real subject for discussion on this list and should be continued in private if you want. -- Roy Wood Q Branch 20 Locks Hill, Portslade, Sussex BN41 2LB Tel : +44(0)1273-386030 / Mobile : +44 (0) 7836-745501 Fax +44 (0)1273-381577 web site : http://www.qbranch.demon.co.uk/ I can't help it but butt in the actual phrase is a translation of an ancient Greek phrase which actually means, the EXCEPTION REAFFIRMS (NOT TESTS) THE RULE :-) Test as in testament!?! So, the translation from the original Greek phrase would appear to remain authentic despite thoughts to the contrary. Of course, this reminds me of a couple of proverbs which I first heard in Russian and which, many years later, I subsequently heard in English -- from wither and whence is the real origin? GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.
Re: [ql-users] Re: Q40/Q60 device drivers
In article [EMAIL PROTECTED], Thierry Godefroy [EMAIL PROTECTED] writes On Jeudi 28 Juin 2001 23:42, Tony Firshman wrote: On Thu, 28 Jun 2001 at 21:16:18, you wrote: C'est l'exception qui confirme la règle (which I will risk to try to translate into: This is the exception which confirms the rule) The exception proves the rule I knew it was risky... ;-) In actual fact the word 'exception' as used in the context of this saying originally meant the opposite of what it does today. Therefore the expression means that an example taken from a a list will confirm the premise and not the meaning held today that an example which contradicts a rule will confirm it. A concept which is plainly stupid. This is a good example of English meaning changing over the years and people being too happy to parrot a meaningless phrase rather than apply any thought. The original translation was closest. -- Roy Wood Q Branch 20 Locks Hill, Portslade, Sussex BN41 2LB Tel : +44(0)1273-386030 / Mobile : +44 (0) 7836-745501 Fax +44 (0)1273-381577 web site : http://www.qbranch.demon.co.uk/
Re: [ql-users] Re: Q40/Q60 device drivers
On 6/29/01 at 9:49 PM Robert Newson wrote: What's wrong with using a parallel port to access a storage device? Or is this based on the misconception that parallel port = printer [output] port (as that's for which they're generally used [by most PC users] and only that driver is installed)? My first meeting with a parallel port was on the Commodore Pet (3032) - an IEEE 488 interface (aka HP-IB; a parallel port) IEEE488/HPIB/GPIB is NOT the parallel port regular printers are attached to, that one also being known as 'Centronics'. In fact, by function, and 'parallelness' the closest relative to IEEE488 would be SCSI, except that IEEE488 was planned as a more general purpose peripheral bus from the very start. The difference between a regular 'Centronics' and IEE488, or for that matter, SCSI, which, hardware-wise could also be called a kind of a parallel port, is that it does not, in itself, implement any kind of protocol - it is actually the device attached to it that does. When there is nothing attached, there are no signals. With IEEE, SCSI and similar interfaces, the protocol exists regardless of devices attached, it only returns an error if you are trying to communicate with a non-existing device. There is nothing wrong with having storage devices connected to a port that was originally only a collection of buffers to get signals over long wires. As a matter of fact, that's how IDE started. Both have evolved somewhat from the time they were concieved. For instance modern 'printer port' implementations have modes where they DO implement a protocol of their own, even with nothing connected. IDE still doesn't, though. But that's beside the point - in theory you only need two wires to connect to anything anyway. What IS wrong is that many computers can communicate with devices that connect to parallel ports, and that are not printers, but the QL supposedly 'can't'. In some cases, there are hardware limitations, but in others, for instance, Q40, there are none, so what is the problem? It is exclusively a driver issue, and because the way QDOS/SMSQ defines drivers is largerly the same for all of them, the problems are by no means restricted to parallel ports! In particular, QDOS/SMSQ does not enforce a speciffic internal structure for drivers, it just defines how the 'top end' - the TRAPs it needs to support - must look, and provides some resources for the 'bottom end' - interrupts and queues. How one gets from handling interrupts and moving data to and from IO registers, to traps, which do things like 'move file pointer' or 'read string', is entirely left to the 'internals' of the driver. At first glance, there is nothing wrong with this. However, the consequence is that the driver writer does not feel compelled to think about a possibility that someone else may want to attach hardware onto an interface his driver handles, that he did not plan for, or that other interfaces may use the same protocols he used in his driver. So, when someone decides to add the new capability, in the first case, the only way to find out if a driver can use hardware already used by another driver, is to dissasemble the other driver, or have the source - and then, in 99% of all cases it will be determined that without modifying the existing driver (not always possible), adding the new functionality is simply not possible. In the second case, you may have to reinvent the wheel and do your own version of something that has already been done. In the interest of compatibility, you may have to actually again either dissasemble existing code, or have the source. In the best case, even if you were just given the required 90% of already existing code, it would be needlessly duplicated. In the worst case, you'll spend 90% of your time doing things that were already done, based on rather unreliable knowledge of how there were supposed to be done. Even worse, you may be copying someone elses bugs! This is NOT the way to write drivers! Nasta
Re: [ql-users] Re: Q40/Q60 device drivers
On Vendredi 29 Juin 2001 22:49, Robert Newson wrote: Don't invoke LOGIC here, as I see no logic in your proposal: they are DIFFERENT devices (one SCSI and one IDE) on DIFFERENT hardware... Even UNIX uses DIFFERENT device names for SCSI and IDE ! But Unix DOESN'T have to! It only does so to assist the user; [roughly speaking] Unix uses special files which are actually pointers to device drivers (as defined by the major number of the file) which can obviously be named anything you [as root] like. Major numbers are DIFFERENT for SCSI and IDE drive as they refer to DIFFERENT device drivers: so your remark is pointless Thierry.
Re: [ql-users] Re: Q40/Q60 device drivers
It's amazing the crap I write when I'm tired. Thinking it through I realised it was crap, re-editied it down, saw it was still crap and intended to bin it, but hit the wrong button and sent it before logging out. Sorry.
RE: [ql-users] Re: Q40/Q60 device drivers
OK this thread is way over my head, but I'm reading it - I might even learn something. Just to take off at a tangent, how about an open source (type) project to build a new Operating System for ALL the QLs/compatibles/emulators out thare to use. Same hardware, same everything - if at all possible - I don't know if that is possible, we could call it OSOS (Open Source OS) just for fun. I'm not saying that we should rewrite QDOSMSQ and/or SBASIC, but why not have a bit of fun in our spare time writing the ultimate OS for our hardware. What could we do with all these years of experience ? (Dons Nomex flame proof suit.) Norman. Norman Dunbar EMail: [EMAIL PROTECTED] Database/Unix administrator Phone: 0113 289 6265 Lynx Financial Systems Ltd. Fax:0113 201 7265 URL:http://www.LynxFinancialSystems.com
RE: [ql-users] Re: Q40/Q60 device drivers
OK this thread is way over my head, but I'm reading it - I might even learn something. I know what you mean; I need to go and have a lie down between each post :) but I'm trying to follow the thread. For me, an operating system should boot with built-in support for just the basic features I need to make the system usable, i.e. a keyboard for input, a screen to display output, some memory to run my programs in, and a backing store large enough to store my programs and data but fast enough to access those files dynamically in applications. Secondary to that are other useful devices: a printer, a large capacity read/write removable media for making backups and transferring files (which need only be a streaming device, not random access). Because these devices are used infrequently (relatively, compared to the hard disk) there is no need to bloat the O.S. with drivers and make them permanently resident at boot time. If I want to print a document or backup some files, I can manually - or from the application - load the necessary driver, then unload it again when the job is done. Then there are the more esoteric devices that the industry is inventing all the time, aimed at specific uses, e.g. scanners. It might not even be necessary to provide separate drivers at all; the applications through which the device is intended to be used could be completely self-contained. If that is the 'spirit' of QDOS/SMSQ then woo-hoo; QDOS/SMS forever ! Well, that's all the waffle, now the main points (oh, alright then, more waffle): I want my operating system to be small, fast, reliable and not constantly being changed to add features (and bugs along with them) that I might never want to use, when these can be provided in optional add-on packages that I only have to load when I use them - particularly if their presence would be detrimental to overall performance. If, on the other hand, the O.S. IS going to be bloated by all this extra stuff that I have no option about loading, then I become much more concerned about how it is implemented - quality, efficiency, standards and how it will all affect basic performance. I look forward to trying the CD driver. I don't really care how it works. I don't care if it supports only ISO9660, doesn't support DVDs, or XYZs. I don't care if the devices are called CDRx_, WINx_ or anything else. If it lets me get files off a CD onto my hard disk then I'll be doing more than I can do already, and I'm grateful somebody did all the hard work and saved me the effort of trying to figure out how to do it myself. But if, at the end of the day, I don't like it, then I don't have to use it and my computer will carry on working just the way it did before, until another solution comes along (like LS120 support on Q40, please! :O) Well, that's my two pen'orth. Doesn't add anything to the technical thread, but...well. cheers, Ian. -Original Message- From: ndunbar Sent: 29 June 2001 08:38 To: ql-users Cc: ndunbar Subject: RE: [ql-users] Re: Q40/Q60 device drivers OK this thread is way over my head, but I'm reading it - I might even learn something. Just to take off at a tangent, how about an open source (type) project to build a new Operating System for ALL the QLs/compatibles/emulators out thare to use. Same hardware, same everything - if at all possible - I don't know if that is possible, we could call it OSOS (Open Source OS) just for fun. I'm not saying that we should rewrite QDOSMSQ and/or SBASIC, but why not have a bit of fun in our spare time writing the ultimate OS for our hardware. What could we do with all these years of experience ? (Dons Nomex flame proof suit.) Norman. Norman Dunbar EMail: [EMAIL PROTECTED] Database/Unix administrator Phone: 0113 289 6265 Lynx Financial Systems Ltd. Fax:0113 201 7265 URL:http://www.LynxFinancialSystems.com Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed
RE: [ql-users] Re: Q40/Q60 device drivers
At 08:38 AM 6/29/2001 +0100, Norman wrote: Just to take off at a tangent, how about an open source (type) project to build a new Operating System for ALL the QLs/compatibles/emulators out thare to use. An interesting idea, Norman. There are some pluses and some minuses: + Good way to expand our knowledge of QDOS + Possible way to get additional features - More fractionalizing of QDOS community (QDOS, Minerva, SMSQ, etc.) If this was to go forward, there are two ways to go: - QDOS Classic (should be able to use in North America) - Minerva (if ever publicly released) An organization similar to what Linux is using could be setup to keep the project running smoothly. We do have a number of experts (outside of Tony Tebby) that might be willing to contribute to the project. I'd be willing to help on the documentation side (so that I could learn QDOS better). There might need to be some work to replace some commercial parts of QDOS that have become integrated in QDOS (PE), or some arrangement worked out, or an assumption that they will stay commercial. Anyone willing to step up and play project leader? Tim Swenson
RE: [ql-users] Re: Q40/Q60 device drivers
At 10:21 ðì 29/6/2001 -0700, you wrote: At 08:38 AM 6/29/2001 +0100, Norman wrote: Just to take off at a tangent, how about an open source (type) project to build a new Operating System for ALL the QLs/compatibles/emulators out thare to use. An interesting idea, Norman. There are some pluses and some minuses: + Good way to expand our knowledge of QDOS + Possible way to get additional features - More fractionalizing of QDOS community (QDOS, Minerva, SMSQ, etc.) If this was to go forward, there are two ways to go: - QDOS Classic (should be able to use in North America) - Minerva (if ever publicly released) An organization similar to what Linux is using could be setup to keep the project running smoothly. We do have a number of experts (outside of Tony Tebby) that might be willing to contribute to the project. I'd be willing to help on the documentation side (so that I could learn QDOS better). There might need to be some work to replace some commercial parts of QDOS that have become integrated in QDOS (PE), or some arrangement worked out, or an assumption that they will stay commercial. Anyone willing to step up and play project leader? Tim Swenson A-HA! Here we go again.. :-) A quick look back about 2-3 years ago on this mailing list will reveal that the discussion was made over and over again :-) Lots of flaming on that one To say it once more... (and hoping this time around the idea is more ripe) I firmly believe this is the best way to support, enhance and even spread QDOS compatible systems. Phoebus
Re: [ql-users] Re: Q40/Q60 device drivers
[meta-devices] NO! Channels are meant to exchange DATA, NOT to send COMMANDS or PARAMETERS to a piece of hardware ! (of course, you could argue that commands and parameters are just some form of data, but you won't, will you ? ;-) This reminds me of how the Apple ][ disk drives were accessed from within a program - via PRINT! The device driver scanned all output looking for a lead-in escape sequence and then used the rest of the output line as the command and its parameters to execute. Don't invoke LOGIC here, as I see no logic in your proposal: they are DIFFERENT devices (one SCSI and one IDE) on DIFFERENT hardware... Even UNIX uses DIFFERENT device names for SCSI and IDE ! But Unix DOESN'T have to! It only does so to assist the user; [roughly speaking] Unix uses special files which are actually pointers to device drivers (as defined by the major number of the file) which can obviously be named anything you [as root] like. Things were easy when the only thing you could connect to a floppy interface was a floppy. Trouble started when they inroduced tape drives. With IDE things got complex faster - it started off as hard drive only, now you can put almost any storage device (including floppy) onto it, using two distinct protocols. With SCSI, things are even worse, cause there you can use non-storage devices. Funny you should mention SCSI, I've just got a copy of next-next month's (August) Computer Shopper (it's still June and I can no longer buy a June NOR July issue!) and therein I came across an artice about it. Although SCSI was originally devised by a hard disk manufacturer (Shugart), it is actually more of a peripheral bus (hence its ability to have longer cables than IDE). What's actually worse about it is that SCSI normally refers to SCSI-3 which isn't very standard (from what I could gather from the article - sorry, left the mag at work, otherwise I'd give quote(s)) Then, we have non-storage oriented interfaces that got storage devices grafted to them, I suppose SCSI could be defined as the opposite: a storage interface that [early on, in acceptance stage by standards people,] had non-storage devices grafted on. such as parallel ports. What's wrong with using a parallel port to access a storage device? Or is this based on the misconception that parallel port = printer [output] port (as that's for which they're generally used [by most PC users] and only that driver is installed)? My first meeting with a parallel port was on the Commodore Pet (3032) - an IEEE 488 interface (aka HP-IB; a parallel port) by which its floppy disks (along with a printer and any other devices) were attached. Then, if you go to the Commodore VIC-20, that (if I've got the right machine) had a floppy disk drive that was attached via a SERIAL port! Food for thought? Keep up the good work Robert
Re: [ql-users] Re: Q40/Q60 device drivers
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
Re: [ql-users] Re: Q40/Q60 device drivers
On Wed, Jun 27, 2001 at 10:13:41PM -0400, ZN wrote: 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? technically there is no such limitation, ie you can have up to 32 mixed case chars per name and unlimited nesting depth. However infinit wisdom triumphed and the standard was botched to say that ISO9660 compliant drivers are only required to handle 8+3 UC names + maximum subdir depth of 8.. apparently to grant DOS 2.10 the ISO9660 compliant sticker. Most reasonable OS like RISC OS and Amiga OS fully support the uncrippled version of the standard. Also the primary vendor independent extension format of IS9660 is not Jolliet (which suffers a silly 64 char/name limitation) but Rockridge. 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. I think Thierry looked at the SMSQ disassembly, there should be no surprises. This could get a real problem when SMSQ starts using interrupts for IDE. Bye Richard
Re: [ql-users] Re: Q40/Q60 device drivers
On 6/28/01 at 11:14 AM Thierry Godefroy 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 ? Exactly the ones you describe in the rest of your answer. 1) have a _USE and _DRIVE thing that handles the corresponding commands for all devices 2) your 'que atapi packet' thing, if slightly extended, could be used by anything working over IDE etc... Don't think that I am nagging - you have obviously thought of many things (maybe even everything :-) ) and I for one am VERY glad to see it, but you must already realize you are breaking new grounds here. I hope you will document it all, otherwise people will have to read the code again, and we know how 'well' that works :-) 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... Well, that's nice to hear. Are they being used? 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 meant things like opening files at ../somewhere. i.e. embedded 'shorthand' for directory level up/down etc :-) 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... This is why your thing approach is perhaps the best given circumstances. If that is in the philosophy of QDOS/SMSQ is, well, a philosophical question, but I'll get to that later. [Why directory drivers] 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. This code should have been a thing (for all I know, it is) - anything that needed those services would then just call it, and it could be changed or 'evolved' in time. But what I really wanted to ask is this: is the 16 device limit only a limit because of the slave block mechanism using limited bits to track what blocks belong to which device? 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)... I see what you mean - this cannot be solved by a driver :-( 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... Well, not for TRAP #2, which are IO management and should logically also manage devices, FORMAT being the case that sets the precedent. Using the same argiment as you have later, FORMAT is not entirely in the spirit of QDOS/SMSQ. It shouldn't really be a TRAP #2, but an extension (thing) like the _USE and _DRIVE commands. On the other hand, if there was a TRAP #2 for the _USE and _DRIVE, would they be in the spirit of QDOS/SMSQ? This may all sound like I am starting an argument. Well, no - I am just pointing out that the QDOS/SMSQ way of managing devices was originally shoved into TRAP #2 in the form of a FORMAT call, which the proved to be insifficient. Even using extension things to do the device management is insufficient for some functions - it is a problem, and eventually, it should be solved. I'm just tryngt to point this out. 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... you got the SBASIC WIN_DRIVE command (which in fact calls an extension from the WIN control thing)... With the CDROM device driver, you got CDR_DRIVE The problem is that I don't have the WIN control specs, so I don't know if my implementation of the DRIV extension [is correct][ 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... Hm, but you provide some proof to the contrary in your own answer - the ATAPI command que. You
Re: [ql-users] Re: Q40/Q60 device drivers
Thierry Godefroy wrote: JOCHEN PLEASE READ THIS ! * As far as I know he doesn't read the list at the moment. Marcel
Re: [ql-users] Re: Q40/Q60 device drivers
On Thu, 28 Jun 2001 at 21:16:18, you wrote: (ref: [EMAIL PROTECTED]) Well, we should ask Tony then... But my guess is that FORMAT was accidentally put in TRAP #2 calls. As we say in France: C'est l'exception qui confirme la règle (which I will risk to try to translate into: This is the exception which confirms the rule) The exception proves the rule lots snipped This discussion is getting _very_ good. It almost now needs a referee (8-)# -- QBBS (QL fido BBS 2:257/67) +44(0)1442-828255 mailto:[EMAIL PROTECTED] http://www.firshman.demon.co.uk Voice: +44(0)1442-828254 Fax: +44(0)1442-828255 TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG
Re: [ql-users] Re: Q40/Q60 device drivers
On Jeudi 28 Juin 2001 23:42, Tony Firshman wrote: On Thu, 28 Jun 2001 at 21:16:18, you wrote: C'est l'exception qui confirme la règle (which I will risk to try to translate into: This is the exception which confirms the rule) The exception proves the rule I knew it was risky... ;-) Thierry.
Re: [ql-users] Re: Q40/Q60 device drivers
On 6/28/01 at 11:14 AM Thierry Godefroy wrote: [lots snipped] OK, this is supposed to be a discussion, not an argument, so let me make some things clear right here. Thierry, I am not arguing 'my' approach over yours. We are really on the same side here and arguing serves no purpose. If nothing else, I've written no QL software, and you are famous for it, so you have done infinitely more than I have, therefore I really have no grounds for arguing at all. Besides, YOU are doing the driver, so you will eventually do exactly what you want. I'm just hoping you are keeping an open ear :-) You did pull my tongue about MDs and I just told you why I envisioned them the way I did, that's all. I agree with all of the ideas you expressed, though not with all details. I'll elaborate later. That said, on to the matter at hand: [Documentation] I am relieved to see you are going to extensively document your effort. There are surely people who will use and apreciate the documentation. [Directory shorthand and directory separators] Agreed, it should not be handled by drivers anyway. On that level, one works with channel IDs, not file names. [hidden things] [device driver speciffics] should have been a thing (for all I know, they are) - anything that needed those services would then just call it, and it could be changed or 'evolved' in time. The fact is that when QDOS was written, things did not exist at all and when SMSQ(/E) was written, it had to be upward QDOS-compatible... Agreed, except the part about SMSQ/E. QDOS has no way of knowing if drivers are internally made up of several things that pass stuff to each other, so no real compatibility issues there. The only reason I mention this, and you later allude to, that this is how some SMSQ/E drivers may actually alredy be constructed, it's just that it isn't documented, or at least the docs are not widely available. [16 device drivers limit] the pointers to device physical definition blocks are held (unlike all other QDOS tables) _into_ the system variables (i.e. there is only room for 16 table entries)... So basically, the only way to circumvent this would be to modify SMSQ/E. OK, no-one is holding their breath here :-) [Trap #2 and FORMAT] But remember that things were not available when QDOS was written: FORMAT had to be vectored, and TRAP #2 was the closest and more logical approach then... Oh, I agree. What is 'right' here is a philosophical question. When implementing a new driver the available resources should be used to the greatest advantage. As I said, you did 'pull my tongue' and I explained why and how the MD idea came about. The reson why channels were used was because they were there, and it minimized the amount of new stuff to invent. It wasn't implied that's the ideal or only way. I will, however, stand by my conviction that, as they are currently documented, QDOS/SMSQ drivers and devices leave a lot to be desired. It is high time some of that was addressed, and I for one admire your courage for doing so. However, since you will, in essence, be setting up the standard, I think we both know it's for your own good to leave 'space for expansion' and that just involves some advance thinking - and I'm sure you are doing that. Well, we should ask Tony then... But my guess is that FORMAT was accidentally put in TRAP #2 calls. As we say in France: C'est l'exception qui confirme la règle Oh, I completely agree there. The saying translates directly and completely accurately into Croatian :-) FORMAT was just put into TRAP #2 because, even though it may not have been the ideal fit, it was the best available at the time. Even using extension things to do the device management is insufficient for some functions - it is a problem, and eventually, it should be solved. I'm just trying to point this out. You can do almost everything you want in things... As such, I don't see how things could be insufficient! Not things themselves. The nice thing about things is that they can be anything ;-) I was referring to the available extensions to date. Your own admission about guesswork about the _DRIVE extension makes me think it would be a good idea to decide on some sort of a set of standard extensions. Or at least document the existing ones, and proclaim them as standard :-))) You yourself are introducing new ones here - long file name handler, command queue. While no-one can predict the future, we can make very educated guesses. I was just making mental leaps, really. I do agree that POSIX is not the be-all and end-all, but it is a good model to look at, and while it certainly should not (or even cannot) be copied verbatim into QDOS/SMSQ, there is no harm in 'stealing the good bits' from it. [meta-devices] NO! Channels are meant to exchange DATA, NOT to send COMMANDS or PARAMETERS to a piece of hardware ! (of course, you could argue that commands and parameters are just some form of data, but you won't, will you ? ;-) I could
RE: [ql-users] Re: Q40/Q60 device drivers
-Original Message- From: Dave Walker [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 27, 2001 6:06 AM To: [EMAIL PROTECTED] Subject: Re: [ql-users] Re: Q40/Q60 device drivers I would be more than happy to make the DiscOVER sources available Nice one Dave, I'd like to see the sources please. although whether anyone else could fathom their way around them ... Aha, a challenge ! I like those :o) Norman. Norman Dunbar EMail: [EMAIL PROTECTED] Database/Unix administrator Phone: 0113 289 6265 Lynx Financial Systems Ltd. Fax:0113 201 7265 URL:http://www.LynxFinancialSystems.com
RE: [ql-users] Re: Q40/Q60 device drivers
Ahem, I *think I understood that :o) Norman. Norman Dunbar EMail: [EMAIL PROTECTED] Database/Unix administrator Phone: 0113 289 6265 Lynx Financial Systems Ltd. Fax:0113 201 7265 URL:http://www.LynxFinancialSystems.com -Original Message- From: Thierry Godefroy [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 27, 2001 10:44 AM To: [EMAIL PROTECTED] Subject: Re: [ql-users] Re: Q40/Q60 device drivers VERY LARGE INFORMATIVE SNIP
Re: [ql-users] Re: Q40/Q60 device drivers
IAn Interesting discussion this and some very good points raised by all. I see, as usual that Thierry has his finger firmly on the pulse here and is way ahead of most of us. When we discussed CD drivers at Eindhoven last weekend we were suggesting that it be ported to the Qubide and that a new Qubide ROM would be commissioned ( Phil is making the sources available soon I gather). I had no idea that it might be a problem with the rate though. My suggestion of being able to at least read a QXL.WIN file was based on that being in the root directory and on the complaints over the years from QXL / QPC users that they can backup their files to CDs or ZIP drives but then not read them on the Aurora etc. -- Roy Wood Q Branch 20 Locks Hill, Portslade, Sussex BN41 2LB Tel : +44(0)1273-386030 / Mobile : +44 (0) 7836-745501 Fax +44 (0)1273-381577 web site : http://www.qbranch.demon.co.uk/
Re: [ql-users] Re: Q40/Q60 device drivers
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
Re: [ql-users] Re: Q40/Q60 device drivers
At 10:13 PM 6/27/2001 -0400, Nasta wrote: 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. Just to expand on what Nasta said, different drivers (such as disk or tape) utilize the SCSI controller to talk with their respective devices. The controller is opened as a device and just handles the SCSI conversation between the devices and their drivers. I've done some SCSI Bus trace analysis so I'm familiar with how the protocol works. I wrote an article for Sys Admin mag on the subject if anyone wants to know more. Tim Swenson
