The Sinclair QL Forum

tofro wrote:BTW: Supporting interrupt - is not the QL way of doing things. The QL wants to poll peripherals, ideally.

Funny that you say that, it was one of the Q68 design goals, e.g. using a huge FIFO for sampled sound.
QIMI would be the opposite example - needing an interrupt request for every single pixel the mouse moves.

I commented something to that effect but I may have forgotten to submit my edit

FTDI has device and host controllers and the numbering makes no sense. I have an FT122 addressable by a QL and can successfully send it data. In principle it works. With dumb devices like keyboards it doesn't matter too much as they work like a peer to peer. I have poked around and got a DELL keyboard capslock LED to turn on.

I ordered four VNC1L FTDI host controllers as part of my recent USB bits order. Ordered a few random parts to try out on this and other embedded projects.

http://www.ftdichip.com/Support/Documen ... _VNC1L.pdf

Here of course the USB driver runs on an on-chip CPU. At first sight, only three fixed features:

Flash drives: There are already solutions for the QL, including modern ones like SDHC.
Keyboard/mouse: Not much news, just fancier devices than for PS/2. Probably the only point I see in this chip.
USB printer connectivity: Does not solve the main problem which already existed for PAR. Which is generating the output.

The Vinculum chips are far easier to implement than a "standard" USB host controller. They actually might be a solution for the QL. But I go with Peter in saying "Solution? - To what problem?". Keyboard/Mouse is not really a problem, storage neither, and printing should be solved with something like RWAP's retro-printer. That leaves networking, but unless someone comes up with a really powerful CPU upgrade, that is most probably going to end in disappointment.

If you want to come up with something generic that encourages the tinkerers to come up with peripherals, USB is too complicated IMHO, to motivate someone to put together a tinkerer's peripheral. In case that is your goal, come up with a generic SPI interface supporting an address range of like 4 devices - The embedded world has some interface standards that fit much more to a rather slow device like a QL than the modern desktop computer world which is already lightyears away.

To Peter's comment: QDOS is really designed to handle peripherals in a polling way in the polling interrupt. That doesn't mean it wouldn't support direct HW interrupts, but can give you a bit of a headache when doing it. And I do agree with you that non-crackling sound is basically impossible without interrupts. There it's a MUST. And the Qimi design really is a design fault

Tobias

I like this type of discussion. It brings out the pros and cons of ideas very quickly.

I do think keyboards and mice are becoming a slight problem. Not huge, but mice moreso. The device I migrated to above can use SPI so it's implicit in that that SPI would have to exist. Since USB might come up often, it's not a terrible idea to include it. If anything the hard part is having a ROM people can easily update as new things get added.

Let's keep the random ideas coming.

Hi,

3D printed QL-matching case

Could this be external MD drive with QL case similar looks?

I we had more drives, could we also somehow reengineer cartridges. Can cartridges be respooled with VHS video tape?

Tomas

tofro wrote:And I do agree with you that non-crackling sound is basically impossible without interrupts. There it's a MUST. And the Qimi design really is a design fault

I may have badly worded. Q68 sound works without interrupts - all done by the polling routine. It has a large hardware FIFO for over 1000 samples.

BTW now there is SMSQ/E support, I regret that I didn't design a slightly more expensive analogue part for Q68 sound. For 8 Bit it is okay, but 16 Bit DAC would be possible with a separat lownoise power supply and some extra buffers. For a new sound hardware I'd recommend making it 16 Bit-prove.

OK, geddid. Once you make the buffer large enough, you're fine without interrupts. Large buffers, however, make stuff like WinAmps "visual equalizer" more difficult to implement - It's hard to know "what's played at the moment" - That's already hard to do with the current SSS driver that implements the queue in software.

With regards to 16-bit sound: If compatible with the "standard" 8-bit UB SSS in QPC, Qx0, QL-Amiga and SMSQmulator, fine. Depends a bit on the actual implementation. But you definitely don't want an islandish sound system. We don't have enough SSS software anyhow...

Tobias

tcat wrote:Hi,

3D printed QL-matching case

Could this be external MD drive with QL case similar looks?

I we had more drives, could we also somehow reengineer cartridges. Can cartridges be respooled with VHS video tape?

Tomas

Great Idea!!!!

For the QL Microdrives idea, just get two bare QL microdrives, install them in the 3D printed bottom case. It would have a small PCB that plugs into the QL's port and takes the connectors from two microdrives and has a passthrough on the right. It then has a top case that matches the right side of the QL perfectly and would fit right in. As it would cover the reset button, it has a little plastic bar through the front of it that extends that too so the reset will still be on the right edge like before.