Page 2 of 3

Re: PS/2 Keyboard Musings

Posted: Wed Oct 07, 2020 3:11 pm
by Pr0f
The Vinculum chips have configurable BIOS that you can build with tool chains to allow different device classes to be accommodated - some of the example code handles 'most' common devices (joystick, mouse, keyboard, serial port, parallel port, 'printer' and flash drives / hard disks, but for those last 2 concurrency is not well supported - so not multiple writers / readers).

However the design goal for putting a Q68 into a QL case REQUIRES a matrix to PS/2 conversion - since the matrix is the QL keyboard and the input to the Q68 is a PS/2 port. Using USB just simply isn't an option here.

Re: PS/2 Keyboard Musings

Posted: Wed Oct 07, 2020 4:48 pm
by Derek_Stewart
Hi,

This has already been done on the Q68, the PS/2 is converted USB, which is converted to QL matrix.

But the cost is very expensive.

I have some PS/2 to USB adapters, which I thought did not work, after extensive testing, the Q68 and Belkin PS/2 Splitter connected to the USB adapter works with most USB keyboards and mouse(s). Also a USB WIFI keyboard Logitech K400+ works.

The limitation is there are only 8 PS/2 - USB adapters and newer designs are available at a high price.

The USB to QL Matrix is very expensive, but useable.

I do not want a Q68 in a case, but a Q68 type expansion connected to the QL, a Super Ultra Diamond Card....

Re: PS/2 Keyboard Musings

Posted: Thu Oct 08, 2020 11:51 am
by Peter
Pr0f wrote:However the design goal for putting a Q68 into a QL case REQUIRES a matrix to PS/2 conversion - since the matrix is the QL keyboard and the input to the Q68 is a PS/2 port.
PS/2 is not a strict requirement - an I2C or extension bus solution would also be okay, but need some SMSQ/E changes.

Re: PS/2 Keyboard Musings

Posted: Thu Oct 08, 2020 12:21 pm
by Peter
mk79 wrote:
Peter wrote:A lot? I know only one project that doesn't require a Linux-like OS underneath and seems relatively suitable.
AT90USB1287 (8-bit processor!) with LUFA USB, many of the STM32 chips with STM32Cube USB host library and a bit more exotic but interesting the Vinculum II chips from FTDI. All provide relatively easy USB host support without any operating system.
I meant suitable projects, which already do USB to matrix conversion, not chips. There are many microcontrollers with USB host support of course, and most have some libs. But then the matrix emulation still needs to be developed.

For what would this effort be good? Having a black QL with keyboard, but putting a PC keyboard beside it?

Re: PS/2 Keyboard Musings

Posted: Thu Oct 08, 2020 12:41 pm
by mk79
Peter wrote:I meant suitable projects, which already do USB to matrix conversion, not chips. There are many microcontrollers with USB host support of course, and most have some libs. But then the matrix emulation still needs to be developed
Every QL FPGA core has the translation figured out already, trivial to translate into code. But yes, I don't really see the point of it either.

Re: PS/2 Keyboard Musings

Posted: Thu Oct 08, 2020 1:41 pm
by Peter
mk79 wrote:
Peter wrote:I meant suitable projects, which already do USB to matrix conversion, not chips. There are many microcontrollers with USB host support of course, and most have some libs. But then the matrix emulation still needs to be developed
Every QL FPGA core has the translation figured out already, trivial to translate into code. But yes, I don't really see the point of it either.
The microcontroller I/O needs to react quickly, when a line is scanned by the 8749, while the USB support code is also active. I wouldn't find this trivial without an actual FPGA. One needs understanding of how to generate fast interrupts from I/O level changes, or other tricks. If one is not already familiar with the µC and its development environment, the overall project with PCB design, the usual problems, etc. could easily become 100+ workhours IMHO.

Re: PS/2 Keyboard Musings

Posted: Thu Oct 08, 2020 2:26 pm
by Derek_Stewart
Hi,

Maybe what is required is a USB interface for not just keyboards, but any USB device.

But I guess there are only a few people who could write the device driver.

Pity the USBwiz disappeared, I never got around to buying one and the design work is probably lost as well.

Re: PS/2 Keyboard Musings

Posted: Thu Oct 08, 2020 3:21 pm
by Pr0f
That might need dynamic device support - would that be possible in QDOS ?

Ability to build and tear down devices like SER and PAR for instance, and a directory device to handle usb sticks (flash) ?

Keyboard, mouse and joystick might need different handling...

Re: PS/2 Keyboard Musings

Posted: Thu Oct 08, 2020 3:22 pm
by mk79
Peter wrote:The microcontroller I/O needs to react quickly, when a line is scanned by the 8749, while the USB support code is also active. I wouldn't find this trivial without an actual FPGA. One needs understanding of how to generate fast interrupts from I/O level changes, or other tricks. If one is not already familiar with the µC and its development environment, the overall project with PCB design, the usual problems, etc. could easily become 100+ workhours IMHO.
Or just wire the controller up to an MT8808 chip and be done with it. Bit expensive for what little it does, you could also get a CPLD for that price, but basically no development time is needed.

Edit: The MT8809 is basically the same and cheaper (<2,50€)

Re: PS/2 Keyboard Musings

Posted: Thu Oct 08, 2020 3:37 pm
by Pr0f
that mimics the action of a keyboard matrix - but we have that already - whoever wants to integrate the Q68 into an original QL case needs to convert the matrix into a serialized code for the Q68 - PS/2 or otherwise...

Quickest hacky way to achieve this :

Butcher a PC keyboard, take out the keyboard controller chip - make up a bit of veroboard with the diodes and 9 way and 11 way connectors on - wire the rows and columns to the appropriate connections on the keyboard controller (these are often on a separate smaller board), wire a new short 4 wires PS/2 connection to ps/2 plug - wire mouse wires to new PS/2 plug for mounting on QL case.

That's the breadboard version - not neat, but it may just work