Breaking news: The QIMSI Interface

[Peter]

a sampled sound card for the QL Internal speaker (brave tinkerers only)

Interesting idea, I wonder how it sounds, given the low quality of the QL internal speaker.

It is important to sufficiently amplify samples, because the speaker is not very loud.
But it sounds better than I thought.

The sad thing with sampled sound on the QL is SLAVEing, which keeps it from playing samples longer than the main memory.
I never understood why it is impossible free the QL from this burden.

Even the 68008 can play long samples from SD card, if the OS with this terribly inefficient buffering method is bypassed.

[tofro]

The sad thing with sampled sound on the QL is SLAVEing, which keeps it from playing samples longer than the main memory.
I never understood why it is impossible free the QL from this burden.

Even the 68008 can play long samples from SD card, if the OS with this terribly inefficient buffering method is bypassed.

Actually, it's perfectly possible to circumvent slaving in a driver completely: All the code to retrieve the bytes simply needs to go into the access layer of the driver rather than in an interrupt or polling loop. That is possible for drivers against fast media like SD-Cards that are nearly as fast as memory.

[Peter]

Actually, it's perfectly possible to circumvent slaving in a driver completely: All the code to retrieve the bytes simply needs to go into the access layer of the driver rather than in an interrupt or polling loop.

Is this more than a theoretical possibility? If neither Tony Tebby, Wolfgang nor Marcel managed to do it, there must be a reason.
From what I understood, the best they could realistically do, was to restrict the maximum memory available for SLAVEing.

SLAVEing has been nothing but a pain for any mass storage hardware since 1997, including the IDE interfaces of Q40 and Q60.
I still remember the "memory wasting routines" needed to work around SLAVE block usage when accessing longer files on the Q60.

[tofro]

Actually, it's perfectly possible to circumvent slaving in a driver completely: All the code to retrieve the bytes simply needs to go into the access layer of the driver rather than in an interrupt or polling loop.

Is this more than a theoretical possibility? If neither Tony Tebby, Wolfgang nor Marcel managed to do it, there must be a reason.

Of course it is. To quote the QL Technical guide:

It is left to the device driver to decide what the slave blocks are used for but it must be prepared to release a slave block if requested to do so by the memory manager.

And if the device driver decides it doesn't want to use slave blocks at all, it can do so. The point is just that you'd need to re-write all the existing device drivers for that. It's a bit of an urban myth that a QDOS device driver has to use slave blocks. And I'm pretty sure not using slave blocks will have very negative impact on multitasking-friendliness on slower than basically "instant" hardware. And I can very well understand that at times when there was no such "instant" hardware, you could argue it's impossible to get rid of slaving (and retain acceptable performance). It's a very different story with flash-based storage, however.

Slave blocks are the main means to allow the access layer of the device driver to communicate with the interrupt back-end (what Tebby used to call the "task"). If you have no interrupt back-end because you do all of the hardware access in the access layer (and there is no need to use the asynchronous nature of the device driver structure because the device is communicating synchronously), no slaving is necessary (but you obviously also don't get the benefits, so all read and write access directly goes to the hardware, regardless of whether some data might already be in a buffer somewhere.) That executes all of the driver code basically in the context of the calling job.

I have a half-baked QL-SD driver somewhere here that runs on exactly two 512 bytes buffers and nothing more. Shoot me an e-mail if you want to have a play.

[Peter]

And I'm pretty sure not using slave blocks will have very negative impact on multitasking-friendliness on slower than basically "instant" hardware.

Magnetic IDE harddisks were not yet "instant "hardware. But what is more negative impact? Being practically unable to access a file length over 10% the RAM size (SLAVEing) or the extra time for a second access in case the harddisk buffer was too small (no OS buffering at all)?

Of course a small fast buffer would be better than no buffer at all. But couldn't that be implemented in the driver itself? Your "exactly two 512 bytes buffers" might do just that?

Slave blocks are the main means to allow the access layer of the device driver to communicate with the interrupt back-end (what Tebby used to call the "task").

Yeah but IIRC his IDE driver didn't even support interrupt-driven background operation. Did any driver do it, except the one for microdrives? Maybe some floppy drivers, but I'm not sure.

I have a half-baked QL-SD driver somewhere here that runs on exactly two 512 bytes buffers and nothing more. Shoot me an e-mail if you want to have a play.

Yes, many thanks!

[tofro]

And I'm pretty sure not using slave blocks will have very negative impact on multitasking-friendliness on slower than basically "instant" hardware.

Slave blocks are the main means to allow the access layer of the device driver to communicate with the interrupt back-end (what Tebby used to call the "task").

Yeah but IIRC his IDE driver didn't even support interrupt-driven background operation. Did any driver do it, except the one for microdrives? Maybe some floppy drivers, but I'm not sure.

Well, with "interrupt" I also include the polling interrupt. And basically all drivers with a task back-end at least use that. That gives the OS a bit of leeway to do something else useful instead of busy-waiting for the drive to execute whatever it has been asked to do. Flash media is synchronous (and basically instant) in nature - There is no "waiting" for the data, so this approach is not really useful (or, rather, everything but useful) there. But you can't blame the designers not to have included support for such futuristic stuff in 1984

[Peter]

But you can't blame the designers not to have included support for such futuristic stuff in 1984

No, but I fail to understand why that 1984 technology was re-used in drivers until today.
1998 saw the ROMdisQ, so the future had arrived 25 years ago.

[napsternds]

Update: I have added scrollwheel and middle button support to my QIMSI mouse driver. Binary and source uploaded in my first post.

The mousewheel even works with Toolkit 2 ED or simple editors like QED. The middle button produces an ALT + '.' which appears to be SMSQ/E standard.

Downloaded and tested in my SGC+QIMSI setup. Works great. I am a heavy user of Q-trans (by dilwyn), and mousewheel is perfect to scroll down long file lists in populated directories. Great job!!!

Thank you Peter

[Peter]

Downloaded and tested in my SGC+QIMSI setup. Works great. I am a heavy user of Q-trans (by dilwyn), and mousewheel is perfect to scroll down long file lists in populated directories. Great job!!!

Many thanks for the feedback. Getting a good amount of testing is not so easy, so that is good to hear.
And yes, I was suprised myself how useful the scrollwheel can be on a QL.

[Nephilim]

Hello EveryBody , is there a 3D Printing case ( STl file ?? ) to protect this marvelous ?