Laurence, I'm a little bit surprised by your comment that I am misusing slave blocks. Obviously the authors of the original QUBIDE driver, on which Ser-USB was based, were also misusing them!!! Like them, I use the slave blocks to keep mirrors of the data on the drive in memory to save having to re-read it. (Which, I think is what you then go on to say) In fact, I have barely changed the slave block handling code from QUBIDE - I'm certainly not using them for any other purpose.
Sorry, but I don't understand what you mean by the statement "The driver doesn't even get told about that." QDOS calls the Forced Slaving vector and tells the driver to dispose of a slave block ... and that's where I have had a lot of problems. Adrian -----Original Message----- Laurence wrote: I believe you are misusing slave blocks. They are not intended to be used for general I/O buffering. If you want that, allocate memory from the common heap. Ideally, slave blocks are used just to mirror data present on a mass storage device, and being asked to release it is completely simple. The driver doesn't even get told about that. The microdrive code does use them for data to be written, and causes anything that makes any sort of memory allocation request - if the allocation needs space - to hang until the microdrive completes flushing the slave blocks (or fails!). As a flush of slave blocks can be triggered for any sort of memory request - from the common heap, expanding (a) SuperBasic, or RESPR - you have to work within that. The microdrive driver does just that. When it finds that it cannot flush a dirty slave block, it treats it as a microdrive "bad or changed medium" error. That's after seven times around the tape, which I think equates to roughly a minute before the triggering memory request might get serviced. _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
