Q68 support thread

[Pr0f]

Hi,

If you have a spare switch, maybe you could send me one for testing.

You could always look at the SMSQ/E source code in the /smsq/q68/driver/ section where the file mouse.asm is defined, it is interrupt driven.

I have a feeling this mouse port query happens at a lower level (bootstrapping code) and before any OS has been loaded from SD card.

[Peter]

What would be useful to know is what query does the Q68 send out on the PS/2 keyboard and mouse ports to detect devices - it must be sending something as it can identify if a scroll wheel is present on the mouse.

My guess would be that what ever is sent is just being ignored by the KVM and so it doesn't send any response - I will probably have to get the scope on this one... I was hoping Peter might be able to tell me what command byes were sent out.

You should not expect that I always follow the forum. Better to wake me up by PM or something if you need a reply.

The Q68 keyboard I/F does not send anything.

The Q68 loader sends the sample rate sequence 200, 100, 80 to enable intellimouse if present (each rate preceded by the commad $F3).
Then it sends the "Get device" ID $F2 and reads the reply.
Then it enables "Data reporting" by writing $F4

It is known that the Q68 had problems with faulty PS/2 implementations of USB-to-PS/2 converters, which ignored the PS/2 host blocking input. There was a workaround for that in a later Q68 FPGA version. Could be your KVM switch is similarly misbehaving. Could also be, that it does not support the "Data reporting" mode at all. PCs typically use others modes. At last, there has always been a very small number of mice which are incompatible to the Q68 for unknown reasons.

[Peter]

I have a feeling this mouse port query happens at a lower level (bootstrapping code) and before any OS has been loaded from SD card.

That is correct. Mouse initialization is done by the OS loader, presenting a simplified mouse interface to the OS.

[Pr0f]

What would be useful to know is what query does the Q68 send out on the PS/2 keyboard and mouse ports to detect devices - it must be sending something as it can identify if a scroll wheel is present on the mouse.

My guess would be that what ever is sent is just being ignored by the KVM and so it doesn't send any response - I will probably have to get the scope on this one... I was hoping Peter might be able to tell me what command byes were sent out.

You should not expect that I always follow the forum. Better to wake me up by PM or something if you need a reply.

The Q68 keyboard I/F does not send anything.

The Q68 loader sends the sample rate sequence 200, 100, 80 to enable intellimouse if present (each rate preceded by the commad $F3).
Then it sends the "Get device" ID $F2 and reads the reply.
Then it enables "Data reporting" by writing $F4

It is known that the Q68 had problems with faulty PS/2 implementations of USB-to-PS/2 converters, which ignored the PS/2 host blocking input. There was a workaround for that in a later Q68 FPGA version. Could be your KVM switch is similarly misbehaving. Could also be, that it does not support the "Data reporting" mode at all. PCs typically use others modes. At last, there has always been a very small number of mice which are incompatible to the Q68 for unknown reasons.

Thankyou Peter - and duly noted about the PM's. The belkin KVM appears to have a CY7C63722 on the PS/2 interfaces that would be connected to each host - this is a microcontroller with specific PS/2 / USB hardware built in - but I have no idea what code is programmed into these and if it supports that data reporting mode, although I think the start up sequence for a mouse on Windows OS's does involve sending this command. I think I need to get a sniffer on the wires and see what's passing back and forward.

[Peter]

Another thing that comes to my mind, is that the mouse (or the simulation of it by the microcontroller inside the KVM) needs time to boot on power-on. The Qzero was too fast for some mice, so I had to add extra delay before the mouse initialization. The Q68 usually stays in power-on-reset longer than the Qzero, but might still be faster then a PC.

Overall it looks like a nasty issue, debugging it could be unpleasant.

[Pr0f]

I stat with the KVM's guide suggestion of powering that on first - as it talks to the console keyboard / mouse and sets them up - then any devices plugged in as servers are powered up - so in theory the KVM should be ready and waiting for any requests from hosts. I am not sure if the kvm will be smart enough to offer the same device capabilites as the mouse plugged in on the console - but it does say it supports mice with multiple buttons and scroll wheels - so it understands the expanded comms packets for enhanced mice

I can sniff the console side of the KVM and the host side - trying a pc and the Q68 to see if and what differences there are. Like you say Peter - it could get messay.

Also expecting delivery of a new boxed KVM with a better provenance (new old stock and not pulled from a server room) - it's 16 port but is otherwise identical to the 8 port KVM and shares the same base board and firmware. If one of my existing 8 port switches behaves the same way I can send that one to Derek to have a play.

[bwinkel67]

It is known that the Q68 had problems with faulty PS/2 implementations of USB-to-PS/2 converters, which ignored the PS/2 host blocking input. There was a workaround for that in a later Q68 FPGA version. Could be your KVM switch is similarly misbehaving. Could also be, that it does not support the "Data reporting" mode at all. PCs typically use others modes. At last, there has always been a very small number of mice which are incompatible to the Q68 for unknown reasons.

Yup, the cheap ones (Black Box), where I found a seller on eBay having a bunch and sent to you guys, weren't very reliable without the workaround FPGA fix. I did manage to secure a slightly more expensive TripLite one that has worked well -- found one for $30 on eBay but a bit more on Amazon ($81 but PCNation.com has them for $78):

https://www.amazon.com/Minicom-Converte ... B00404YD8W

[Derek_Stewart]

Yup, the cheap ones (Black Box), where I found a seller on eBay having a bunch and sent to you guys, weren't very reliable without the workaround FPGA fix.

You sold them to me, I did not resell the adapter because of the limited numbers.

I was going to copy the adapter, but manufacturer; Black Box, indicated to me that they are end of life, but still retain the copyright. So no progress.

I did manage to secure a slightly more expensive TripLite one that has worked well -- found one for $30 on eBay but a bit more on Amazon ($81 but PCNation.com has them for $78):
https://www.amazon.com/Minicom-Converte ... B00404YD8W

Too expensive, if adapter for each Q68 sold, was purchased, I would have to overlay $500 to supply this adapter, I doubt anyone would take this option at that price, it would be a financial disaster.

[bwinkel67]

I was going to copy the adapter, but manufacturer; Black Box, indicated to me that they are end of life, but still retain the copyright. So no progress.

Oh wow, that sucks. Would have been cool to re-create these.

Too expensive, if adapter for each Q68 sold, was purchased, I would have to overlay $500 to supply this adapter, I doubt anyone would take this option at that price, it would be a financial disaster.

Yup, still expensive, but they have come down in price at least. They used to be $120'ish.

[Derek_Stewart]

Hi,

Maybe I should forget about the copyright issue with the Black Box PS/2 to USB adapter and try and reverse engineer the adapter.