Use ~10€ to connect modern mouse to MSX

Enlighted (6094)

04-01-2014, 09:51

Prodatron wrote:

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.

Sounds like working, but how now ie. SymbOS knows, should it read 2 or 4 bytes? Do you want to do this manually in Control panel or should we put in some ID bits so that this can be recognized?

Quote:

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).

You are now assuming things without looking the BIOS-source I posted... There is no such additions... XD2 is destroyed at #352A (LD A,D) and YD2 is newer even read back from the mouse... Only read clocks are sent out to mouse to keep it in sync.

By Prodatron

Paragon (1857)

04-01-2014, 17:22

Seems, that I became a little bit slouze during the last 12 monthes
Next attempt:
So let's always send for 4 bytes from the PS/2 mouse.
- Byte 3 doesn't contain the trackball-bit (-> stay compatible with MSX2 BIOS)
- Byte 4 contains a "PS/2-bit" for recognition (-> new driver will recognize, that it's a PS/2)
- If bytes 3/4 are not read within 3000 microseconds, it jumps back to byte 1 (stay compatible with MSX1 software); this also helps synchronising the 4byte boundary

That means:
- MSX1 software will only read 2 bytes; because of the timeout/jump back to byte 1 there shouldn't occure any problems.
- MSX2-BIOS will ignore bytes 3/4, as byte 3 doesn't look like the trackball byte
- new mouse drivers with wheel support (like the one in SymbOS) will always read 4 bytes. As the forth byte contains the special PS/2-bit, it is recognized as extended PS/2 data (without the bit in byte4 the driver would only use byte 1+2)
- we don't need any handshaking at the beginning; no need for two different protocol modes

What's about this? I am curious what mistake I made this time

By NYYRIKKI

Enlighted (6094)

04-01-2014, 18:17

No, this sounds good... So... Can I test SymbOS with wheel mouse support tomorrow?

By Prodatron

Paragon (1857)

05-01-2014, 01:36

So how could byte3+byte4 look like?

byte3
   bit 76543210
       00??????
       0 -> these bits are always 0 ("no trackball")
       ? -> not yet defined, reserved for future enhancements

byte4
   bit 76543210
       1TFBWWWW
       1 -> this bit is always set ("PS/2 protocol")
       T -> third mouse button
       F -> forward button (not yet supported in SymbOS)
       B -> backward button (not yet supported in SymbOS)
       W -> mouse wheel delta (signed)

By NYYRIKKI

Enlighted (6094)

05-01-2014, 12:25

Prodatron wrote:

So how could byte3+byte4 look like?

byte3
   bit 76543210
       00??????
       0 -> these bits are always 0 ("no trackball")
       ? -> not yet defined, reserved for future enhancements

byte4
   bit 76543210
       1TFBWWWW
       1 -> this bit is always set ("PS/2 protocol")
       T -> third mouse button
       F -> forward button (not yet supported in SymbOS)
       B -> backward button (not yet supported in SymbOS)
       W -> mouse wheel delta (signed)

Ok, I will give my suggestion:

- All the bits that are discussed here are actually inverted when talking to hardware! (Because also DX & DY are inverted)

Byte 3 high nibble = ID nibble: (bits 7-4) = 0010
bits 7 & 6 are for MSX-BIOS mouse identification
bits 5 & 4 are for "PS/2 protocol" identification

Byte 3 low nibble = Z (bits 3-0) = Mouse wheel signed delta

byte 4 high nibble = 0000 = Unused, reserved for future.

byte 4 low nibble:
bit 3 : 0 = Unused, reserved for future
bit 2 : 5th mouse button: 0=Not pressed, 1=Pressed
bit 1 : 4th mouse button: 0=Not pressed, 1=Pressed
bit 0 : wheel button (/3rd): 0=Not pressed, 1=Pressed

... I think you could use 4th & 5th (aka forward / back) as fixed wheel roll up / down. (Unfortunately I don't right now have a proper mouse to test this functionality though)

By Prodatron

Paragon (1857)

05-01-2014, 13:14

Ok fine, so there is the possibility for at least two more additional protocols!
The only thing I wonder is, why not putting buttons + wheel together into the 4th byte (high nibble = 3 buttons + 1 unused bit, low nibble = wheel). Maybe this saves some decoding code on driver side, as you only have to handle one byte of data.

By NYYRIKKI

Enlighted (6094)

05-01-2014, 13:18

I'm not sure if 4-bits (-8 to 7) will be ALWAYS enough for Z (I'm sure it will be enough for wheel mouse & SymbOS but I'm thinking also other possible controllers & uses... Like WII Nunchuck & 3D-game)

So here is my alternative suggestion 2:

Byte3: 00ID0543
Byte4: ZZZZZZZZ
ID=01 for "PS/2"
543 = mouse buttons

Other details as in previous suggestion.

Would someone else like to vote / suggest something?

By NYYRIKKI

Enlighted (6094)

05-01-2014, 13:29

In the last suggestion we could actually have at least 7 more additional protocols I was also thinking that you could handle Z-axis with same routine as you handle X & Y-axis...

But if you think that ANDing bits from 1-byte suits you better, then that is fine with me also... I don't know how you have implemented the mouse routine ATM. I was just thinking that maybe getting out ID first (in order to select correct protocol) could be good idea.

By Prodatron

Paragon (1857)

05-01-2014, 14:10

I didn't take care about other controlers yet, that's why I thought that 4bits for the wheel is enough. In SymbOS I figured out, that you hardly have values >+1 or <-1 within a 1/50 second. Anyway your last suggestion now makes most sense for me, and that can be handled in a good way by the driver. So protocol "01" (PS/2) would be fine.

NYYRIKKI wrote:

but I'm thinking also other possible controllers & uses... Like WII Nunchuck & 3D-game

What's about protocol "10" (game controller):
Byte3: 00IDBAAA
Bytes 4...: [BUTTONS]
Bytes ...: [AXES]
ID=10 for "game controller"
B = number of additional buttons/8-1
AAA = number of additional axes-1
In this case, you can support up to 16 additional buttons and 8 additional axes!

By edoz

Prophet (2501)

05-01-2014, 14:25

Yes, I use the game controller in symbos for pacman !

What about this device ? (philips nms-1150)

Maybe handy if we creating a paint program for symbos :D (in future)