Breaking news: The QIMSI Interface

[dilwyn]

Unfortunately I only have one PS/2 socket to USB plug adaptor and I don't know if it's passive or not.

Does it resemble the example in the manual?

Almost. Bigger.

[dilwyn]

Had a power cut in the bad weather while typing one of my replies, may have lost the post before I submitted.

The black mouse Stephan and Peter suggested is available here, but at nearly 16 pounds/€16 is nearly twice the price on Amazon as the same item in Germany it seems.

I ordered the £5 grey mouse hastily earlier, as I had to go to deal with a leaking window. Will try that when it arrives middle of next week and let you know.

[Pr0f]

If you are ocd like me, you can get those adapters in the green and purple, should you wish to maintain that PC standard.

[Derek_Stewart]

Hi,

It is not a matter of colour matching, the PC97 colours indicate the type of PS/2 device, Green = Mouse, Purple = Keyboard.

The PS/2 connections, look, according to the all the research I have done, the Keyboard and Mouse use the same Data and Clock pins, see Wikipedia page:
https://en.wikipedia.org/wiki/PS/2_port

Pin 1 +DATA Data
Pin 2 Not connected (Sometimes, mouse Data for splitter cable.)
Pin 3 GND Ground
Pin 4 Vcc +5 V DC at 275 mA
Pin 5 +CLK Clock
Pin 6 Not connected (Sometimes, mouse Clock for splitter cable.)

Keyboard and mouse ports may be combined into a single port which can be used to connect both by splitter cable. The splitter cable attempts to route the Mouse and Keyboard signals to the correct device. Which sometimes work and sometimes does not.

This is the problem on the Q68 where some mouse(s) work and some do not.

On a PC with a dedicated PS/2 controller, the signals are directed onto the correct port, and probably to save money only Pins 1,5 are used for Mouse and Keyboard.

If pure PS/2 connections are used the Mouse should connect to Pin 2: Data, Pin 6: Clock, but there seems to no standards, well PC97 tried to do this, but seems to of failed.
Maybe the reason for certain Mouse(s) to not wik with QIMSI and Q68 is they are wired the same as the Keyboard and Q68 and QIMSI are expecting the Mouse to wired as a PS/2 Mouse.

[Derek_Stewart]

Hi,

Fitted a 8749 with Hermes v2.2 programmed code onto my Issue 5 QL with QIMSI, all work great.

[Peter]

Hi Derek,

Maybe the reason for certain Mouse(s) to not wik with QIMSI and Q68 is they are wired the same as the Keyboard and Q68 and QIMSI are expecting the Mouse to wired as a PS/2 Mouse.

I think the standard wiring of a mouse is identical to keyboard, and should not matter. My own guess is, that some mice boot too slowly and are not ready when QIMSI begins to access them.

(I have added enough delay to get all available mice to work for Stephan and me, but an even larger delay would become problematic. This is because the MiniQ68 inside QIMSI, which does the mouse initialization, is also interested in accessing the SD card before it is "gone" to the QL side. Both tasks must be completed in a short time frame.)

But that is just a guess, as all my own mice, both combo and pure PS/2, work fine.

[dilwyn]

Aurora and QIMSI.

Someone asked about this. I tried QIMSI on my Minis-QL Aurora this evening. It works.

As my Aurora card has no QL-Style ROM port connector on the main board (and anyway there might not be room for the QIMSI because of the number of cables in the way even if it had a QL-style ROM port connector), it is replicated on the M-Plane backplane you can see in the first picture. Normally this is occupied by my old RomDisq simply because I had no other use for it these days.

View of Aurora's M-Plane

I removed the Qubide from the backplane (to avoid WIN name clash). Leaves just the Aurora, SuperHermes Lite, M-Plane, Super Gold Card and floppy disk drive.

The second picture shows the QIMSI plugged in where the RomDisq used to be. You can see the RomDisq resting loose on a cable in the picture, since I was too lazy to free it from its LED cable.

QIMSI inserted

Obviously, for the Aurora's PS2 keyboard to work via the SuperHermes, you have to copy the ipcexts file to somewhere where it'll boot from. Seemed to work fine from QIMSI.

So it seems to work fine. The QIMSI is upside down in this particular system so you can't see the LED, and the micro SD card slot is beneath the board making it hard to see to insert a card if you want to change it.

Apart from that inconvenience, all seems to work OK.

[Peter]

Someone asked about this. I tried QIMSI on my Minis-QL Aurora this evening. It works.

Many thanks. It was not me who asked. But this is a scenario we could not test yet, and I'm glad to hear it works!

The QIMSI is upside down in this particular system so you can't see the LED, and the micro SD card slot is beneath the board making it hard to see to insert a card if you want to change it.

Unfortunately this is a use case I did not have in mind at design time. It would not have been difficult to provide pads for an external LED.
Right now, without design changes, an external LED would require soldering at the pads of the microSD socket according to the following picture:

With thin wires, not impossible for an experienced tinkerer. But only makes sense if the card is rarely changed. (Inisde a MinisQL case, replacing RomDisq, I would expect that.) Another option might be a microSD extension cable/adaptor.

[dilwyn]

Exactly Peter. It is not an issue for me because my QIMSI will only be used with a QL. But as someone asked about Aurora, and I have one, I thought I would try it out to see if it can work.

I was quite used to the old RomDisq being hidden away inside the Minis-QL, I'd run a short cable to an LED on the front panel since the RomDisq had a couple of pins for this purpose. Until I dismantled the case to try the QIMSI I'd actually forgotten that the RomDisq extension LED was there.

As a BTW, the Qubide in that Minis-QL system used to have a small mechanical hard disc. That hard disc is now in the great hard disc graveyard in the sky, so using a small IDE CF card board, I replaced the hard disc with CF cards, which are just fine for me. I added the RomDisq as a sort of internal backup for the important system files in case the use of CF cards didn't quite work out as I expected it to. As it turns out, 8MB RomDisq was more than enough enough for that, but has never been needed.

[dilwyn]

Quick update on my situation regarding getting a PS/2 mouse to work with QIMSI.

A new mouse and PS/2 adaptor has arrived now and the situation is much better, thanks to a lot of help from Peter (thank you Peter).

I can list the following mice as working with QIMSI. The mice with PS/2 plugs will need a PS/2 female to USB male adaptor to connect to the OTG USB lead for the QIMSI of course.

Cherry M5400 (part no. M540001), USB plug, grey coloured, optical mouse
Mitsumi ECMS 67002, PS2 plug, beige coloured, optical mouse
Acer MS11.200.080, PS2 plug, black, optical mouse
Fujitsu M-S48, PS2 plug, beige coloured ball mouse

One mouse with PS/2 plug I still haven't managed to get to work:

Fachi Electrical Scroller Ball 99-P, ps/2 plug, black ball mouse

I have another 6 or 7 mice here which don't work with either QIMSI or Q68. They all have USB plugs and mostly unbranded, so I'm assuming that none of them are PS/2

A couple of things we have learned, some of which Peter will document in future versions of the manual:

1. If the QL has a QIMI fitted inside, SMSQ/E must be configured to "IGNORE QIMI" for the QIMSI mouse to work. I found that if the QIMI is enabled, even if no mouse connected to it, that all the working mice would not register left or right button presses through QIMSI, although pointer movement would work normally. At best, only about one in five button presses gets through via QIMSI in this scenario. The mouse movement left/right/up/down works normally, so (like me) you might think you have configured "IGNORE QIMI" and not spot that in fact you did not really save the changes, so QIMSI mouse button presses don't work even though the rest of the mouse does.
Anyone know if QIMI can be disabled in QDOS? (probably easier to just remove the internal QIMI, or just leave QIMSI mouse unconnected and use the QIMI mouse if you HAVE to use QIMSI on a QL with QIMI).

2. Not all PS/2 to USB adaptors are the same! Only passive ones work. I have three here now. Two are known to work, the other doesn't (it's a lot fatter than the other two, so might not be passive).

3. If the QL has a floppy disk drive and you boot from a floppy disc for any reason, the magic of the startup sequences leaves the WIN device of the QIMSI named as MDV. It's a side-effect of the way interfaces boot up by changing their names as they boot up. I only found out because I left a floppy with a BOOT program on it in the drive overnight by mistake. After the floppy BOOT program ran, the device called WIN didn't exist - DIR WIN1_ failed. DIR MDV1_ gave a listing of the SD-card! So I had to use a WIN_USE "win" command to manually change the SD-card device name from MDV to WIN if the QL had booted from floppy disk on the Gold Card.

4. The version of SMSQ/E 3.39 supplied doesn't have a QIMSI mouse driver in it - need to load MOUSE_bin in both QDOS and SMSQ/E in the version that came with my QIMSI.

I've tried the QIMSI on my Aurora again since resolving the earlier issues. It seems to work fine as long as everything is set to ignore the Aurora's QIMI and the SuperHermes Lite keyboard driver is loaded first.