The Sinclair QL Forum

Peter wrote:That's a valid answer. But would they use such a card for more than the a-ha effect, or would it just be a collection item?

In other words, would (some) people actually type on the QL keyboard rather than PS/2 keyboard for their QL related work?

All of those as well. It's a bit like an owning an old car and tuning it up People just love using the old stuff. The Q68 is still great though

Derek_Stewart wrote:I am not bothered by the lack of USB interface, even if there was a USB interface who would write the drivers for all the USB devices. I doubt USB device manufacturers would write the device driver for the small QL world.

This is why I was suggesting using a Pi to do the hard work and then give a standard, simplified interface to the QL side. It leverages the work others have done already and makes the QL side easier (and takes the interrupt load off too).

stephen_usher wrote:This is why I was suggesting using a Pi to do the hard work and then give a standard, simplified interface to the QL side.

As for "hard work", the work of such a Raspi implementation has not been done. And why should someone be motivated to do it, while he could just run a QL emulator on the Raspi? Also note, that during Raspi boot, one would not be able to type.

If someone does it anyway, I propose PS/2 as standard. It is well documented, long established, and implemented on superHermes and Q68. It could also be of general use beyond the QL.

Peter wrote:

stephen_usher wrote:This is why I was suggesting using a Pi to do the hard work and then give a standard, simplified interface to the QL side.

As for "hard work", the work of such a Raspi implementation has not been done. And why should someone be motivated to do it, while he could just run a QL emulator on the Raspi? Also note, that during Raspi boot, one would not be able to type.

If someone does it anyway, I propose PS/2 as standard. It is well documented, long established, and implemented on superHermes and Q68. It could also be of general use beyond the QL.

It's also obsolete and has been for 20 years. Getting new PS/2 peripherals is problematic at best. And again, you're concentrating purely on the keyboard (and maybe mouse) and not the plethora of other devices, such as printers, networking, storage etc.

Would waiting a couple of seconds for a stripped down Pi boot be so much of a problem? Remember it wouldn't be a full system, merely a kernel and the minimal number of processes required to handle the USB and interface to the QL side of things. No shells, no other daemons, no systemd, read-only filesystem.i.e. an embedded system device controller, as per the set-up for the ZX Spectrum Next.

P.S. Imagine being able to do something like this, for example:

OPEN #6,"URL_https://www.qlforum.co.uk/index.html"

And the Pi doing all the TCP/IP and TLS encrypton stuff and the QL side being given the decrypted stream of bytes.

Or, setting the default printer output to a networked printer with the Pi translating ESC/p encoded pages from Quill etc. into PCL5 or postscript.

For many things even a faster QL wouldn't have the horsepower to do these things. Better to let a dedicated peripheral controller do it and allow the QL side to do the things that it's best at.

stephen_usher wrote:

Peter wrote:If someone does it anyway, I propose PS/2 as standard. It is well documented, long established, and implemented on superHermes and Q68. It could also be of general use beyond the QL.

It's also obsolete and has been for 20 years. Getting new PS/2 peripherals is problematic at best.

In this context I meant PS/2 for interfacing your hypothetical Raspi USB "coprocessor" to QL/Q68-style hardware, not to connect peripherals. But it could also be SPI or I2C - that's a relatively minor issue, and I lack the time to explain in more detail.

stephen_usher wrote:And again, you're concentrating purely on the keyboard (and maybe mouse) and not the plethora of other devices, such as printers, networking, storage etc.

Of course I'd concentrate on USB HID first, if I worked on USB via Raspi/ARM (I don't !). Because if that amount of work is already too high, it is pointless to raise complexity even more.

stephen_usher wrote:Would waiting a couple of seconds for a stripped down Pi boot be so much of a problem? Remember it wouldn't be a full system, merely a kernel and the minimal number of processes required to handle the USB and interface to the QL side of things.

Please feel free to actually set up such a system and start implementing QL support for your above mentioned devices. The more you look into the details, the more you will understand the issues. I don't want to go into a full "USB for the QL" discussion here.

stephen_usher wrote:No shells, no other daemons, no systemd, read-only filesystem.i.e. an embedded system device controller, as per the set-up for the ZX Spectrum Next.

So the Spectrum Next has USB mouse, printers, networking and storage support via Raspi this way? Can you provide a link?

Peter wrote:So the Spectrum Next has USB mouse, printers, networking and storage support via Raspi this way? Can you give us a link to that?

As far as I know, it doesn't. The Raspi is used as an accelerator board only and (maybe, I'm not sure) to emulate a printer port.
Mouse and keyboard are using PS/2 ports.
Network is using ESP8266 WiFi module and does not need the Raspi to work
The SD card slot also does not need Raspi (it is DivMMC compatible)

Thanks, Andrew. So probably none of the mentioned peripherals got USB support this way. That does not suprise me, because it would be quite some work on both ARM and Spectrum side. (And the Spectrum community is probably 100x larger than us.)

On the Next it will be being used for general USB interfacing (and all the code is being written by one or two people as the hardware interfacing is using the Linux kernel drivers), but that's beside the point. I'm not arguing that your system support everything itself, merely give a useful GPIO compatible interface.

I2C is useful for low data rate devices (it's a big-banging serial interface) but for anything like disk access you need a faster way to move data. The GPIO interface can be used as an 8bit parallel bus for data transfer in addition to the i2C and normal serial. If this was memory mapped with a bi-directional latch was implemented then it would be a useful hardware addition that others in future could take advantage of it. You could potentially use a Pi Zero W for WiFi networking. No low-level ARM programming involved, merely high-level Linux/UNIX style development. Putting most of the intelligence in this layer would make the QL side device drivers simpler, aiding development.

I'm looking at this as an enabling technology for others to use in future as a springboard for fun and useful projects.

Hi,

The hardware to interface to a QL or Q68 is relatively easy, the problem area is the software driver.

There is not many people that could write driver software to interface to a RPi.

I am open to any suggestion to implement the software interface to connect a QL based system to a RPi.

It escapes me why you would want a connected RasPi to do "anything like disk access" and you thus "need a faster way to move data."

The Q68 has a fast enough disk (SD) interface. It also has a fast enough serial interface and a fast enough Ethernet port - Most applications available today don't even use these fully.