Re: [ql-users] Future of QL - Part 1E120 (I had to increment it ! ;-)
On Wed, 9 Jan 2002 00:21:20 +0100, Richard Zidlicky wrote: On Tue, Jan 08, 2002 at 01:38:48PM +0100, Thierry Godefroy wrote: 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)... it seems that your idea is a bit different than mine. If you use the non-dir device driver interface than you don't have any filename in the cdb and IOSS will never touch it except for the first 14 bytes. It will neither reuse anything and the filesystem driver will be left completely unsupported with all the work like recognising files already open - which may be a good thing in the end. I don't use the non-directory device driver IOT implement the CDROM device driver (which will indeed be a legal SMSQ/E directory device driver): I use a FAKE non-directory device driver so to intercept the long filename, store its address in a safe place for later use by the actual directory device driver (here, the CDROM one), and then replace it (changing the address passed by and back to the IOSS in A0) by a truncated filename; once this is done the fake device driver reports a failure to recognize his device (in fact it got no device name at all) and then the IOSS scanning for the proper device driver may continue with the truncated filename... As a result a directory device driver channel definition block WILL be setup (with the truncated filename in it, thus the need for the random characters at the end of it)... Thierry ([EMAIL PROTECTED]).
Re: [ql-users] Future of QL - Part 1E120 (I had to increment it ! ;-)
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
Re: [ql-users] Future of QL - Part 1E120 (I had to increment it ! ;-)
On Tue, 08 Jan 2002 10:36:08 -0500, Phoebus R. Dokos wrote: Just my two cents (and pardon my cluelesness in many parts) Just got the QDOS/SMS reference manual and begun (thanks partly to the work of Norman with assembler and the good contributions of every savant one in the list) to understand roughly a little more on how SMS works. Based to all Thierry did with the ATAPI drivers The ATAPI thing is only responsible for the ATA/ATAPI protocol layer, it does not implement anything directly related with filesystems; it is only responsible for sending and receiving ATAPI packets (as well as a few ATA commands) to the ATAPI-compatible devices on the ATA-IDE interface (either the ISA I/O board of the Q40/Q60 or the Qubide board of SGC-based systems). BTW you may use it from either assembler, SBASIC or even C (I will also write a small C library for it)... OTOH, the CDROM thing (which is still in embryonic state for now) is responsible for the standard SMSQ/E filesystem API implementation (the TRAPs #2 and #3), provides support for reading data from a CD-R (on a direct access basis), and _will_ provide full facility to plug filesystem support modules in it (ISO-9660 and its extensions, namely Joliet and Rockridge, as well as packet-CD filesystem): I will probably write the ISO-9660 pluggin myself as well (and then perhaps another programmer will follow my steps and implement other extensions/filesystems pluggins)... wouldnt it be possible to go a similar way (and by reusing as much of Thierry's code - no use of reinventing the wheel!) and provide an interface for ALL devices under SMS? The way I think about it if a Device Driver API (along the lines of the Meta devices proposed by Nasta) was implemented as a thing it would be possible to trap all IOSS functions and translate them to something a device would understand and vice versa. What could be done under SMSQ/E is something similar to QVFS (which was written by Hans Peter Recktenwald) but that would use all the standard SMSQ/E TRAPs (QVFS did not, by design and because it was to run on QDOS as well: the DELETE system call could therefore not be implemented and had to be supported by a special TRAP #3 call). Using things and a more memory based approach (for example QVFS was using a file to define the mount points: IMO this should be held in memory and (un)mounts should occur via an extension thing call), this could give you support for UNIX naming conventions on all filesystems (including old ones), with long filenames support (as well as soft links) while preserving the backward compatibility with software using the QDOS file naming convetions (i.e. it would still be possible to access the QDOS filesystems directly). Note that there is no need to change the API (TRAPs) to obtain this dual compatibility... This is one of the projects I have but I never found the time to implement... Note that I did _think_ a lot about it though and got most of the solutions to the problems such a thing/device driver raises. See also the old discussion we had in this list with Richard about non- blocking TRAP #2 calls... This API (?) Thing could be linked as a module to SMSQ/E No need for this, it could just be loaded at boot time as any thing/device driver. Its actual (de)activation could be made via an extension thing call (i.e. a standard extension thing call in assembler, a new keyword in SBASIC, a new library function in C, etc...). together with a UN*X-like filesystem driver written for it In fact it would INCLUDE the UNIX to QDOS file naming translation... no need for a new UNIX filesystem. and provide at the same time the much needed fs update and a method of adding devices logically (I find that the UN*X like approach of devices being part of the filesystem extremely useful). Yes, see the mount discussion above... Note that even newer device drivers/filesystem (such as the future CDROM/ISO9660 one) which already understand the UNIX naming convention could still be mounted (with a do not translate flag)... Additionally it could standarise device driver creation by setting a uniform all-encompassing standard for device driver writing. This is another story !!!... and another thing (in fact a vector collection to be glued into an extension thing) to write ! QDOS/SMS forever ! Thierry.
Re: [ql-users] Future of QL - Part 1E120 (I had to increment the it ! ;-)
On 1/8/02 at 2:11 PM Thierry Godefroy wrote: Actually, the graphic cards device drivers are probably the most complicated and sophisticated ones (especially when you take all ancillary extensions into account, such as the pointer environment)... I for one would hesitate to write such a driver from scratch (there the sources availibilty of existing drivers is more than a critical prerequisite) ! I think that the only one who is able to write such drivers is... TT himself (with the QXL or Q40 SMSQ/E sources, I guess this could be implemented in a few days...). I can only agree on this, but then it should be obvious that the way the drivers and the ancillary parts connect should be at least better documented, or even partly rewritten for better 'separation' - in fact the same should be true for the drivers themselves. It makes changes and rewrites much easyer. OTOH, radically new graphics hardware only comes along relatively rarely, I think that GD2 probably achieves most of the above - but things like Phoebus' mouse question show that the available documentation is inadequate. BTW one of the reasons Aurora stopped at 256 colors (the biggest one being the available screen memory size) because at the time there was no way to pass more than 8 bits for color information in any of the commonly used routines, and investigations by Phill Borman had shown that the 16 bit color specification code was not really there. Mind you, I did download all the specs of the GF a while ago (you even sent me some) and I did read _some_ but, here again, time is the limiting factor ;-( There are very few people who have the knowledge and will to understand the aspects of the hardware as required for programming low-level stuff. You are one (out of three or so) exceptions :-) I must confess, that I do like a lot the onboard Ethernet concept... :-) Actually, this has proven to be a problem - not because of the design which is very simple, but because of the rather unreasonable pricing for the chip. OTOH there are alternatives, which are more reasonably priced, but then you have to buy them in increments of 1000, which pretty much makes the price difference irrelevant. SMSC (the manufacturer of the chip I chose for the design) now has a 10/100 non-PCI chip, which is even simpler to use. The 'toast' board referenced on this list has sown me a way to save some more (precious!) space on the board by using RJ45 jacks with integrated magnetics - Ethernet requires electrical isolation which is normallyaccomplished by a (relatively hard to find!) small transformer (looks like a slightly larger chip) - one more problem component, which is not that expensive, but difficult o find in small quantity. Redesigning the 'tile' of the GF PCB containing the ethernet to use the new 10/100 chip is not a problem at all, but one has to wonder about using a 10/100 chip connected to an 8-bit data bus. The later is a design decision to do with actually making the board routing possible. GF does alow extremely fast cycles over the 8-bit bus, though, so it might be worthwhile - if the new chip is priced reasonably. Yes, I think I can remmember about a few emails we exchanged about the GF design and interrupts management... ;-) Yes, and it was more or less the concensus that it should be implemented the way I designed it, and have the software cope... which may be a problem as history proves. Well, there's the GF stuff - feel free to open fire. But as much as I can understand, the actual specs are quite a bit outdated (ColdFire based, while the processor of your choice is now a 68EC060 IIRC), aren't they ? ;-) Actually, from teh standpoint of the software designer, very little has changed. Except for the differences between 68EC040/5102 and 68EC060 (cache size, no MOVEP, etc) almost everything remains the same. Some interrupt lines may get removed as it became obvious less interrupt routability is needed, but the basic structure remains. The sound chip will be an AD1816 and there is no more provision for AD1815 - but both look exactly the same to the software so no changes. Even if I decide to use the 10/100 chip for ethernet, that is 99.9% register compatible with the previously used one (of course, 100Mbit stuff was added). Some base addresses for the IO may change but register assignments remain the same, etc. Soon the motivation will result from the choice: PCI support or no more cheap add-ons for the QL plateforms... I don't deal with the present situation (there are still a few ISA cards available), but with the _future_ one: if there is no PCI-based successor to the Q60, then what the hell a future (say in five years) Q60 buyer will be able to use with it ? No ISA card = no floppy, no harddisk, no serial port, no parallele port, no network, no nothing but graphic, sound and keyboard ! Actually, you won't be helped much by javing PCI in either case as most of these devices are integrated onto motherboards, and on the chip
Re: [ql-users] Future of QL - Part 1E120 (I had to increment the it ! ;-)
Thierry Godefroy wrote: I don't deal with the present situation (there are still a few ISA cards available), but with the _future_ one: if there is no PCI-based successor to the Q60, then what the hell a future (say in five years) Q60 buyer will be able to use with it ? No ISA card = no floppy, no harddisk, no serial port, no parallele port, no network, no nothing but graphic, sound and keyboard ! No ISA cards in the shops doesn't mean no Q40/Q60 cards available for us! The QL hardware market really does not require lots of extension cards. We can order a batch to ensure future supply, if availability problems might appear. And if there were unexpectedly so many Q60 orders that we need lots of extension cards, there would be enough reason to design the cards ourselves, or integrate the peripherals onto the board!!! :-) If you consider ISA a future Q60 availability problem, it's part is 0.1% of the whole. The other 99.9% of the problem are lack of QL software and QL users. And *no* Q40/Q60 is sold without card. At least the IO card is always part of the Q60, so nobody needs to worry about having a Q60 without these basic peripherals, anyway. I just say that we _could_ support _some_ (OK, let's say just a very few) basic PCI cards (I/O, Ethernet, Sound, perhaps even simple graphic cards). Extremely unlikely. Look at it this way: The Q40 software development started 4 years ago. In this time we have not even managed to make full SMSQ/QDOS use of one single (and relatively simple) ISA card. Better not calculate how long the (complicated) PCI BIOS *and* PCI card will take. BTW the Milan folks also thought they were clever, going for PCI. The Milan started at the same time as the Q40. And now? The *ISA* cards for the Q40 are still available. New and in full production! The *PCI* cards for the Milan are no longer produced. So much for using PCI. All the best Peter
Re: [ql-users] Future of QL - Part 1E120 (I had to increment it ! ;-)
On Tue, Jan 08, 2002 at 01:38:48PM +0100, Thierry Godefroy wrote: 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)... it seems that your idea is a bit different than mine. If you use the non-dir device driver interface than you don't have any filename in the cdb and IOSS will never touch it except for the first 14 bytes. It will neither reuse anything and the filesystem driver will be left completely unsupported with all the work like recognising files already open - which may be a good thing in the end. 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. this is how it works in UQLX filesystems (hostfs+XQVFS. It breaks (or becomes ugly) when you try to support SMSQ-style subdirectory creation. Create the subdir cdr1_My_Directory_My and you have automatically renamded the file. 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... :-( No idea what kind of DV3 you are speaking about. The SMSQ drivers I have seen are limited to 36 because of their layout on storage devices. The QDOS/SMSQ traps still behave the same old way for compatibility reasons. If there is some framework inbetween that might in theory support 80 chars than it is just vapourware. [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...) ? Yes it is, when you have all the other SMSQ modules. Bye Richard
