Use ~10€ to connect modern mouse to MSX | MSX Resource Center (Page 3/19)

By raymond

Hero (643)

02-01-2014, 19:00

Content is unavailable it says :-(

By Prodatron

Paragon (1843)

03-01-2014, 17:47

NYYRIKKI wrote:

How about a bit more PS/2 style... I mean with handshake... ie something like:
On first mouse read push pin 7 low and let pin 6 & 8 high. Now wait for 4 VDP-interrupts. If mouse recognizes this, it sends out X & Y-deltas = 127,128 on mouse read completion and after that it switches from 2-byte communication to 4-byte communication. The 3rd byte could be Z axis and 4th byte could be reserved for wheel button, possible 4th & 5th button and maybe something else. To switch back to standard communication, something similar could be used ie. Push pin 6 low and let pin 7 & 8 high (On SymbOS exit)

Sounds fine for me! One more byte (so a total of 3) would be already enough (4bits for the Z-axis, 4bits for additional buttons), but it seems, that it's cleaner to use 4 bytes.

NYYRIKKI wrote:

I think this 4-byte communication could be done to work with MSX-BIOS as well (with some limitations) as each time the MSX-BIOS actually reads mouse, it does it two times because of trackball support. On second read only some bits affect the read result.

So it doesn't matter for the standard mouse, if you always read 4 bytes (8 nibbles) instead of 2? In this case how about finding out what values you get from a standard mouse for the additional 2 bytes, and just send other values with the PS/2 mouse, which then would include the Z-axis? In this case you wouldn't need the handshake at the beginning?

By NYYRIKKI

Enlighted (6067)

03-01-2014, 18:04

Prodatron wrote:

So it doesn't matter for the standard mouse, if you always read 4 bytes (8 nibbles) instead of 2? In this case how about finding out what values you get from a standard mouse for the additional 2 bytes, and just send other values with the PS/2 mouse, which then would include the Z-axis? In this case you wouldn't need the handshake at the beginning?

It is the MSX-BIOS that reads the 8 nibbles. From mouse point of view it is just two reads, so on second time the values are most likely just 0, but I think small number could be detected... at least on theory. On second read BIOS uses X-coordinate to detect if the device is mouse at all. -> If mouse returns big number, it can't be mouse -> It is detected as trackball.

As long as software is using BIOS-routines the 4-bytes communication as I planned is ok, but then there are software (like SymbOS ) that works with only 2-bytes. These might not like if the protocol is enhanced. This is why I would like to see a hand shake as a safety measure.

By Prodatron

Paragon (1843)

03-01-2014, 22:05

Ok, got it I don't see a problem in reading 4 instead of 2 bytes all the time.

What's about this:

deltaX = read_two_nibbles_from_mouse();
deltaY = read_two_nibbles_from_mouse();
tempX = read_two_nibbles_from_mouse();
tempY = read_two_nibbles_from_mouse();
if(tempX<13)
{
    deltaX += tempX;
    deltaY += tempY;
} else {
    // check, if PS/2 mouse characteristics
    // encode deltaZ and buttons from tempX/tempY
}

In this case it seems, that we still don't need a handshake first, do we?

By Prodatron

Paragon (1843)

03-01-2014, 22:20

Oops, maybe it's not that easy? If the PS/2 mouse would always send 4 bytes, the MSX-BIOS would handle it as a trackball, and that would have disadvantages? Does a trackball use all 16bits of the second byte-pair?

By NYYRIKKI

Enlighted (6067)

03-01-2014, 22:45

Yes, if mouse gets detected as trackball then the whole delta calculations change. Please see the commented source I posted.

I don't expect any problems with 4-byte communication with MSX-BIOS/BASIC as long as Z-axis is only 7-bits (way more than enough)

My point is: I would like to add handshake to keep 100% mouse compatibility with ALL the existing MSX-software...

If ie. some MSX1 program (MSX1 does not have mouse support in BIOS) does 2-byte communication, then it may behave a bit weird way when we send Z & button statuses in stead when the program expects X & Y delta. This is the "risk" we don't have to take if we add handshake to enable 4-byte communication instead of 2-byte communication.

Sure there are also other ways to prevent this kind of errors from happening. I could for example add timeout so that if it takes too long before MSX tries to read 3th and 4th byte then it would automatically jump back to sending 1st and 2st byte. Usually MSX reads mouse only at max rate of 1 time / VDP interrupt so I think this method would work ok with most of the 2-byte programs well. I could also add something like "Hold scroll wheel down on power up to enable extended 4-byte communication"

By Prodatron

Paragon (1843)

03-01-2014, 23:06

Yes, sorry, I skipped this section in the source. Thanks for clarifying everthing
So for handshaking I see the following...
advantages:
- driver knows for sure, if it's an MSX or a PS/2 mouse; no problems with "protocol" extensions
- driver can be kept simple; it either grabs 2 (MSX) or 4 (PS/2) bytes, it never needs to test the second byte-pair
- compatible with all existing MSX software
disadvantage:
- you need another handshake to switch back to MSX mouse mode

But if I understood it correctly, without handshaking it doesn't make sense:
- MSX1 software wouldn't work with 4bytes
- MSX2 software wouldn't work, as the BIOS would handle it as a trackball

So I would vote for the handshake methode...

By NYYRIKKI

Enlighted (6067)

03-01-2014, 23:08

Thinking even more about the problem I think this sending any number of bytes depending of how many times byte is read works pretty ok. (Timeout method) How ever next question is, how do you know if the mouse sent X or Z? Should we for example use 4th byte high bits to tell that this is 3-axis mouse similar way as Trackball detection is done on 3th byte?

By NYYRIKKI

Enlighted (6067)

03-01-2014, 23:17

Prodatron wrote:

But if I understood it correctly, without handshaking it doesn't make sense:
- MSX1 software wouldn't work with 4bytes

There is risk that Z delta will be handled as X delta and buttons will be handled as Y delta.

Quote:

- MSX2 software wouldn't work, as the BIOS would handle it as a trackball

No... MSX2 software using BIOS would work ok as we would set the bits so that it will NOT be detected as trackball. No matter trackball or not the BIOS ALLWAYS reads 4-bytes: XD, YD, XD, YD If the later XD is too large value it expects that this is trackball returning value. (Yes, this is a bit complicated as the trackball communicates in totally different way & timing... Too large XD-value just after reading XD-value is just detected as error -> so it must be trackball)

By Prodatron

Paragon (1843)

03-01-2014, 23:58

NYYRIKKI wrote:

How ever next question is, how do you know if the mouse sent X or Z? Should we for example use 4th byte high bits to tell that this is 3-axis mouse similar way as Trackball detection is done on 3th byte?

I think this should be done with your suggested timeout. If there is no additional request after - let's say 3000 microseconds -, the PS/2 mouse jumps back to byte1.

NYYRIKKI wrote:

No... MSX2 software using BIOS would work ok as we would set the bits so that it will NOT be detected as trackball.

But then the BIOS would detect it as a normal mouse. And so it will do XD=XD1+XD2 and YD=YD1+YD2. But as XD2 and YD2 are our additional PS/2 parameters (ZD and additional buttons) the mouse would behave crazy using MSX-BIOS.
That's the reason why I thought, that handshacking would be the only remaining solution (PS/2 only switches to 4byte "extended protocol" mode after handshaking).