On Mon, 7 Jan 2002 00:40:01 +0100, Richard Zidlicky wrote: > On Sun, Jan 06, 2002 at 07:32:14AM +0100, Thierry Godefroy wrote: > > > > the problems are QDOS specific: > > > - drivers can be practically written only in assembler, > > > > True, but as far as I am concerned (I don't want to restart the "assembler vs > > C" flame war), this is not a problem but a GOOD THING ! > > may be a good thing for you but not everyone is good enough with assembler > to write more complex pieces of software in it and hardware drivers are the > worst nightmare to debug if something doesn't work. > Realistically we would probably have a few more drivers if it was possible > to write them eg in 'c' or even SBasic.
It looks like the "Assembler vs C" war is about to break out again... just kidding ! ;-) Well, nothing prevents you to write device drivers in C for QDOS/SMS (this will be somewhat tricky because of the limitations on stack space usage but a possible solution is to use static variables), but you will have to do some assembler written "glue" code (typically putting registers contents on the stack before calling the C routine and extracting the returned parameters from the stack on return) and the result will be very inefficient drivers... As of SBASIC, you will probably appreciate that I did the very first ATA/ATAPI protocol testing with SBASIC written routines. ;-) .../... > > As an example, for the ATAPI thing and the CDROM device driver, most of > > the development time was spent searching, printing, reading and under- > > standing the ATA, ATAPI and ISO specs (nothing less than 10Mb of PDF > > files...). The actual implementation of ATA/ATAPI took about 40% of the > > total time... > > why did you bother with the broken standard if HW vendors obviously > don't read it ;) Yes indeed, they apparently did not read the standards (or at least they interpreted them the wrong way) ! There are actually some workarounds that had to be implemented to cope with some broken implementations of the protocol (and I'm pretty sure that we will find even new problems with other broken CD-ROM readers while the user base will grow...). ;-( .../... > > > To be fair, all QDOS/SMSQ filesystems are long overdue to be scraped. > > > > To be fair, do you know of a filesystem in _any_ 20 years old OS (QDOS > > is already 19 years old !) that did not or should not get scraped ? > > The mass media just evolved too fast and too hugely for anyone to guess > > right what the filesystems limitations had to be in first place... > > absolutely agreed, although there are notbale exceptions of filesystems > older 20 years which arent completely obsolete most are. Doesn't change the > situation though, there is not a single QDOS filesystem that is worth to > be reused. This is why I don't intend to reuse any... > > > There are jewels like maximum 65535 files per drive, > > > > This is driver specific, there is no such limitation into QDOS/SMS OS > > itself, as an example, the "maximum file per drive" (I suppose you > > are talking about the 16 bits "File Id" into the files channel > > definition block) will be 4 billion (32 bits) for the CDROM device > > driver. > > there are many places where this and similar limits are implicitly hardwired > into SMSQ. Nothing that could not be cured with a whole new filesystem > design. Exactly but what I want to point out is that these limitations may all be circumvented in SMSQ/E. The fact that the current SMSQ/E filesystems are outdated in many aspects does NOT prevent anyone to implement new, up to date filesystems, and I am going to prove this with the CDROM device driver ! > > > maximum name length (including directory path) 36 chars > > > > I already explained on this list how to circumvent this problem under > > SMSQ/E. In fact, with my "trick", you can use up to 32765 characters > > (QDOS string limit) per path+filename. This should hopefully be enough, > > even in a far future... ;-) > > agreed, and I will patch QDOS and Minerva to allow for this trick. Beware, that I did not told everything about my trick (because the message was already too long for my taste ;-) You must also ensure that a new open call on an already open file DOES NOT reuse the existing channel definition block (something the IOSS does auto- matically): this can easily be done by putting "random" characters as the last (say the last 4) characters of the truncated filename (the one which will get passed to the IOSS during directory device driver scanning)... .../... > > If you are making allusion to the file naming conventions (such as the > > directory separator which is "_" in current QDOS/SMS filesystems), they > > are just that: conventions ! The CDROM device driver will accept both > > "/" (natively) and "_" (for backward compatibility) separators... > > "_" is still a problem when the rules whether it can be part of > filenames are rather complicated. Complicated but possible (I already got a few different algorithms in mind to solve this issue, the problem will be to find the fastest one). Let's say that you want to open "My_File" into the sub-directory "My_Directory" of "cdr1_"; with my device driver, you will be able to pass either cdr1_My_Directory/My_File (UNIX naming conventions, excepted for the device name) or cdr1_My_Directory_My_File. > Basically SMSQ has no working concept of subdirectories. >.../... > Overly complicated and inconsistent just to allow some compatibility > with earliest MDV drivers and long forgotten software. Yes, basically SMSQ is QDOS compatible and QDOS directory device driver IOSS part was designed for microdrive only... This is the weight of the past, just like the DOS file naming conventions are for Windoze... Remember that TT had to re-introduce some bugs in SuperBASIC so that old badly written program could run under SMSQ and so that users cease to complain about "incompatibilties" (which where in fact only due to programs written beyond documented QDOS standards)... I can warn every future CDROM driver user right now: I will NOT do ANY concession to such badly written software. My philosophy is: if a program can't run under SMSQ/E and (legal) modern extensions anymore, then it must go to the trash can ! > > > Unfortunately > > > the OS interface in both QDOS and SMSQ still has severe limitations, > > > practically enforcing the 36 chars limit. > > > > Untrue, SMSQ/E DV3 (device driver level 3) has built-in support for 80 > > chars filenames instead of 36. Alas the current (native) SMSQ/E device > > drivers don't use this feature. > > the IOSS is still enforcing this limit. Not for DV3 device drivers if you choose so... The limit is then 80 chars. The problem being the lack of _publicly_available_ documentation about DV3: this precludes any open source software to use it... :-( > The only way around is your "trick" ( quite legal and reasonable IMO) but > that requires a wholy different filesystem design and thus obsoletes DV3. Not really, both may coexist happily: a device driver will have to declare itself to the "long filename support thing" (I still not have choosed a defintive thing name for it) so to get this support: as DV3 drivers do not do so, they will continue to work happily with their existing filename length limit (currently 36 chars into SMSQ/E)... > Not a problem, just making my point that it needs a new filesystem. > > > > If you write eg an > > > PCI bus initialiser the OS must have hooks to execute the code very > > > early. Both QDOS and SMSQ have some way to do it but eg the SMSQ way > > > appears very cumbersome. It would work somehow by linking the code > > > into SMSQ which seems like a nightmare (for all parties) to get > > > the distribution and copyright somehow correct. > > > > TT himself explained how to link new modules into SMSQ/E (in QL Today or > > IQLR IIRC), he did not mention any copyright restriction. I think that > > this would not pose any problem as long as you ask him. > > there is a copyright problem because I can't possibly distribute any > SMSQ, so I would have to get TT or someone else with a valid license > to do that. This is simply inconvenient for all parties. [additional SMSQ/E modules] > Btw, if you want to modify the MMU setup sequence in SMSQ how do > you do that? I did not check for this (and do not have any QDOS/SMS doc with me here, in Indian Ocean), but I suppose it is possible to replace the initialisation module of SMSQ/E (this would have to be done on another QDOS/SMS system of course...) ? > > Another way around > > is to provide the module separately from SMSQ/E together with a small > > installer which would then link in the module on the user system (Aurora > > was provided which such a module); this would only pose a problem if the > > target system can't initialize without the module... > > which would be the case with a PCI initialiser. Then the module linking would have to be done on another QDOS/SMS system (or from another OS such as Linux !), but this is still possible... QDOS/SMS forever ! Thierry.
