Urs, File transfers to and from FAT format devices will still be possible using the File Manager, but a native QDOS driver will not now be supported.
There is one massive limitation with the standard QL hardware that cannot be overcome anyway, and that's the fact that it can only support 4800 baud with one stop bit. This means that even when the driver is working it is so slow that transferring anything larger than a few small text files is a painful experience. These are the issues that remain outstanding with RC3 of the driver on Base QL serial hardware: - Out of order Trap #3 requests (in other words a second Trap #3 request issued before the first Trap #3 has completed), or Trap #3 requests with non-infinite timeouts, can leave unfinished I/O transactions as hanging threads in the driver. There appears to be no way to reliably prevent this, and recovering from it is especially problematic. In a normal device driver talking to fast hardware, where all that's needed is to move a few bytes into some control registers this wouldn't be a problem and everything could be completed in the scope of a single trap handler invocation, but the Ser-USB driver has to cope with a transaction that could take thousands of times longer than that. - If QDOS decides that it's time to flush a slave block then - that's it - you WILL flush that slave block! It doesn't matter what your driver is doing, or whether it needs that block in memory. You WILL flush it - and just for good measure you are prohibited from returning an error code to QDOS to say that it failed! This is pretty much a show stopper. The current driver uses a double cache system that transfers the block into a holding area to be written when current I/O is finished, but if there is a large volume of data going through the driver it's hard to interleave the flush request correctly. - As a further bonus, if QDOS has decided that you WILL flush a large number of slave blocks, the driver will exhaust all of the available memory trying to double buffer the requests. - I could disable slave block handling altogether, but then every single request would generate serial I/O, slowing the driver down to an unacceptable level of performance. - For reasons as yet unknown, reading large executable files back off the disk results in data corruption - but not if you don't use the Queue Manager (which you need to be running for a base QL). This last problem was uncovered this morning and was probably the straw that broke the camel's back! All of these problems stem from the same root cause: the serial ports. Not just the poor hardware, but the driver. Do a serial I/O trap with superHermes in supervisor mode and, providing you use zero timeout, you're fine. Do the same thing with the standard QL serial ports and the trap never completes. So the end result is that you _can_ use the driver with a base QL, provided that you only copy small files in small quantities and none of them have an executable header. In my opinion nobody could be expected to accept those limitations. I'm sure that there _is_ a way to get this all to work and, honestly, the current code comes very close, but I believe that to do it reliably, it would be necessary to start again from the ground up, probably based around a brand new serial driver that can serve the dual purpose of serial I/O and USBWiz interface, thus avoiding the problems of "Device Driver on Device Driver" code. On a QL equipped with superHermes, as far as the testing so far has established, the driver works fine. It's also very happy running under QPC and Q-emuLator. Adrian Footnote: If anyone wants to propose a hack to QDOS/SMSQ to allow the slave block flush operation to be deferred by the device driver code I would be very interested to discuss the possibility. -----Original Message----- From: ql-users-boun...@lists.q-v-d.com [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of Urs Koenig (QL) Sent: 12 April 2011 12:44 To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] Announcement about the future of Ser-USB Adrian Ives wrote: > I know the Ser-USB works with superHermes and works very well. Hermes > is an unknown because I have never seen one, but it would be useful to > test it. > In any event it's not just the hardware itself; the driver for the > serial port also plays a part. Adrian, I'm following your development with great interest. As said a while ago in a pm "Great work"! It's sad you decided to skip standard QL serial ports support. Maybe you can rethink the story as I see big chances for Ser-UsbWiz spreading. I'm following the world-wide Retro-Scene where collectors exchange (sell/buy) working QL's in a rate of approximately 3 QL's a week. Many of those newbies are interested not only to collect the machine but also to fire some software. As almost all second hand microdrive cartridges are in such a bad condition that they refuse to load those people have no other chance that to put the QL on their shelves as eye-catcher only. Even I'm also not going for the sake of Mammon, I see a market for Ser-UsbWiz. Think of easy loading SD-cards with QL software and up you go. Maybe you can develop the driver in a way that for standard QL serial ports it runs in a throttled/safe mode with reduced performance. What about 4800, 2400 or even 1200 baud for such environments? Hermes is another story. Even it is the same Intel 8049 chip as the QL's IPC it has completely rewritten IPC firmware which makes the QL's serial ports performing a lot better. If you cannot support the crappy standard QL configuration, maybe you can the Hermes configuration. It would be great if someone (Tony, Rich) could borrow Adrian a Hermes chip. Thank you and QL forever! Cheers, Urs _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
