For Xep128, _mouse_dx and _mouse_dy are for relative movement (d for delta) in X and Y directions. These are updated by SDL movement events, signed values. Function mouse_check_data_shift() is the key stuff in input.c. As you can see there is the _mouse_read_state variable which iterates over four possible values, two "half" bytes for X and two for Y directions. After X or Y is read, those delta values are zeroed. Well, this is what I could understand for MSX protocol + boxsoft, and it seemed that implemented this way allowed both for EGI and SymbOS to work using the mouse. I haven't mentioned the buttons here, but it's simplier case than the movements. Function mouse_check_data_shift() is called from cpu.c in _pwrite(), when 0xB7 port is written by the CPU, the mentioned mouse function checks if the bit changed (bit mask 2) in an "edge triggered" way (so if it changed only). When 0xB6 port is read, and it's for mouse (check function _pread() in cpu.c) function mouse_read() is called, it's in input.c of course. That uses the "half data" stuff set by mouse_check_data_shift(). It also set the button state bit using a variable set by SDL event handler for button change (up/down).

Or something like this I only wrote this, to help understanding/following my probably not so well structured code

About more buttons: in emulation it can be problematic. For example maybe the real PC mouse used with the your PC (which running Xep128 then) don't even had so much buttons. And even for more buttons, eg for JSep, in browsers it's problematic to handle the right button as it's usually "locked" for the browser's local menu, and only the left button can be used to trigger JS events. Well, it's possible to override the other button as well with some tricks - if I remember correctly - but it's kinda tricky and maybe (?) not portable between different browsers easily.

And now for the "jumpy movement".

void mouse_check_data_shift(Uint8 val)
{
if ((val & 2) == _mouse_last_shift) return;
_mouse_last_shift = val & 2;
_mouse_pulse = 1;
switch (_mouse_read_state) {
case 0:
_mouse_data_byte = ((unsigned int)_mouse_dx) & 0xFF; // signed will be converted to unsigned
_mouse_dx = 0;
_mouse_data_half = _mouse_data_byte >> 4;
break;
case 1:
_mouse_data_half = _mouse_data_byte & 15;
break;
case 2:
_mouse_data_byte = ((unsigned int)_mouse_dy) & 0xFF; // signed will be converted to unsigned
_mouse_dy = 0;
_mouse_data_half = _mouse_data_byte >> 4;
break;
case 3:
_mouse_data_half = _mouse_data_byte & 15;
break;
}
_mouse_read_state = (_mouse_read_state + 1) & 3;
}
As I said, EnterMice is compatible with Prodatron's extended MSX mouse protocol. This adds at least 2 more bytes on every lecture cycle. That makes 8 nibbles, not only 4 like on your emulator.  The extra lectures fool your routine because it  only sends 4 nibbles.

The Mouse driver then receives the correct movement alternated with (-1,-1) movement, as it reads 255,255(no movement) when it ask for the rest of the data.

You can fix the problem limiting the lectures to four on every lecture cycle(frame), just like the Neos mouse does.

If case is greater than 3 then you must put 0 on the fifth nibble . This indicates to the Mouse driver that  a two mouse button is connected, and it stops asking for more data.

This is enough for now.

Please, can you add EnterMice emulation? I gave you the hints on the three previous messages.

There isn't a XEP128 thread in English and you said that your two emulators use similar approach to emulate the Boxsoft interface.

OK, I have to overwrite the previous version ... Now it goes in the original 4 nibble, etc mode, but you can change it run-time with typing the following EXOS commands:

:xep emice
:xep emice 1
:xep emice 0

For query, set and disable Entermice mode. The same EXE above, the URL is my previous post.

The changes from the previous Xep128 version, so you can see:

https://github.com/lgblgblgb/xep128/commit/db5fa219951a182313a2b7170e8541dcb444d92d

By the way ... Sorry, I don't follow every topic too closely recently because of other (official) works ... But do you have the mouse interface in the form of a ROM too?

I've seen your attempt to implement an 8 nibbles protocol, but it is unnecessary, as a two buttons PS/2 mouse only  writes four nibbles. You must put a 0000 on the fifth and subsequent nibbles, and the driver detects it and does the rest, waiting for the next reading cycle on the next interrupt.

You can see that the difference between Boxsoft and EnterMice is only the bit where the information is extracted, 0 or 1. It was moved to not collide with the external joystick 1, that is also read on bit 0.

Edit: The driver searchs for a 0000 on the fifth nibble. If found it is a two buttons mouse and it stops the reading cycle. If diffent of 0000 is read then an eight nibble protocol is expected. This is applicable on the Boxoft and EnterMice side.

Yes, also eight nibbles on the Boxsoft side, it may seem confuse, but in reality is was a simplification of the protocol when the extra buttons and wheel where implemented..