Ha ugy ertetted a kerdest, hogy "normal erzekenyseg", hogy adott sw szinten, akkor meg kell kerdezni Gflorez-t, hogy pl az o mouse drivere milyen elmozdulast minek feleltet meg

Yes, that is what I meant, I need to convert the coordinates of the mouse pointer to the dX/dY values sent to the emulated hardware in a way that gives a reasonable sensitivity with most Enterprise software. If the majority of software with mouse support assumes or supports a certain resolution for dX/dY, for example dX = +16 moves one character to the left, then it is possible to write the emulation in a way that in those software the sensitivity of the emulated mouse matches that of the host OS. That is, if you move the pointer by one character on the screen, then it will also move by one character in the EP software, even if the actual position cannot be matched.

The same applies to the mouse wheel, although in that case there might not be a real sensitivity, and it is more like simple up/down buttons that should send +1/-1 as the delta whenever such events are received?

Xep128-ban olyan feature is van, hogy "kitalalja", hogy a program joystick-ot kerdez vagy egeret, akkor is, ha amugy utkozes lenne, es aszerint valaszol.

I planned a similar feature, while the 1500 us (is that value correct?) timer is active, reading the B6h port returns data from the mouse buffer, otherwise it is the joystick input like before. It would also be possible to send the mouse data on both columns (bits 0 and 1 of port B6h at the same time), if that is of any use and it does not break any software.

Yes, that is what I meant, I need to convert the coordinates of the mouse pointer to the dX/dY values sent to the emulated hardware in a way that gives a reasonable sensitivity with most Enterprise software.

I think, it's more a "try it" thing At least I've done that, implementing and trying the result how it "feels". I cannot say there is an 'exact' value. However what I found, that using Xep128 in window and full screen mode, the "scaling" between the mouse-proto-level dx dy should be modified somewhat compared to the situation when it's fullscreen, since in window mode mouse "feels" too sensitive, for obvious reason. Maybe it's of course not the window/full screen topic at all, but on the fact, how big the emulated screen is (I mean on the PC monitor, that is), currently.

If the majority of software with mouse support assumes or supports a certain resolution for dX/dY, for example dX = +16 moves one character to the left, then it is possible to write the emulation in a way that in those software the sensitivity of the emulated mouse matches that of the host OS. That is, if you move the pointer by one character on the screen, then it will also move by one character in the EP software, even if the actual position cannot be matched.

I don't think it would work in general ... Maybe, but for example EP software may be "lazy" to do the check for a while (disk I/O for longer, no mouse check meanwhile) so there will be a difference already. Also, I don't think there is a "standard" of mapping mouse dx/dy values to screen dx/dy, but who knows ... And for me, I would even annoying to see the mouse PC pointer and the EP "drawn" mouse pointer at the same time, to be honest That's true, that you can disable (PC) mouse pointer just for the emulator window, and you can try "not to grab it", ie you can "pull out" mouse from the emulator window, and you can use it normally in other windows on your host OS, maybe, that would be a benefit ...

The same applies to the mouse wheel, although in that case there might not be a real sensitivity, and it is more like simple up/down buttons that should send +1/-1 as the delta whenever such events are received?

Though, I have code for mouse wheel, honestly, I haven't even tried that ever

I planned a similar feature, while the 1500 us (is that value correct?) timer is active, reading the B6h port returns data from the mouse buffer, otherwise it is the joystick input like before. It would also be possible to send the mouse data on both columns (bits 0 and 1 of port B6h at the same time), if that is of any use and it does not break any software.

Honestly, I am even lazy to understand my own code in Xep128 emu But my approach was something like checking "mouse pulses" (what is sent over the serial port) and if there is not so much, I treat the read as "joystick scan" otherwise "mouse scan". On joy-1 conflicting I simply use a "veto" variable that "joy is OK". So maybe, it's OK, that you replicate for both of J and K column, and you just need to take care this "veto" stuff in case of a conflict between joy and mouse.

My work was also some kind of try&error process, for example SymbOS didn't worked without some added work-around, what I can't remember too much in details I mean, if you do this "heuristic" logic, as SymbOS try to "detect" mouse and maybe too "short" period it was for Xep128 to "judge" it as a mouse scan. And if SymbOS fails to "find mouse" it won't use it then, even if it would work on the next msec, for example ...

I think current days enough emulate EnterMice mode only. All old programs use the MOUSE.XR extension which is already updated for EM. Then no conflict with Ext 1 joy.
Pear can write the exact timing of EM.

Is there a Win executable to try?

In EnterMice:
First: No. After this time buttons bits are set to 1.
Second: Yes, it's safe. If overflow appeared, movements are set the max or min value.
Third: I have no idea
Fourth: Not very important.
Fifth: In any case, you can clear the unused half byte.

1- EnterMice enters to a wait state if there is no request on the RTS line, and then it doesn't sends information to the direction bits of the B6h port nor to the Fire bits.  But it activates itself very fast if a change in RTS is detected. This is because EnterMice is a PS/2 to MSX software converter(on a chip), and then the hardware buttons are emulated. This was not the case of the Neos-Boxsoft approach, that wired directly the buttons of the mouse to the EP.

2- Yes, some software produce jumps in the movement, other run smoothly, but I think that it is not produced by the range, as the mouse routine is read every 1/50 sec. It is improbable to reach -128 or 127 even moving very fast the mouse, I think, but I can be wrong, of course.

3- Secondary wired was already possible with the Boxsoft approach, but the Neos mouse lacked the wire as it was used for synchronism(RTS). On the EnterMice approach the secondary mouse button has been put even if no program still uses it.

Especial case are the three software buttons and wheel. To make the interface's software, Pear has followed the extended MSX protocol from Prodatron(SymbOS developer) and NYYRIKKI(MSX developer), that add that new information. This not harm the old software, as the buttons an wheel information go on other lecture cycles. Later, Pear has extended more the protocol to put EnterMice information.

SymbOs still doesn't uses more than the main button, but soon it will do, like other ports of the OS. Is for it that all that buttons are implemented. Of course they are accessible on Exos by the Mouse driver(a new system var has been created) or in the hardware if a developer wants to implement them on new software.

4- These are the extra cycles added by Pear to the MSX protocol, and still there are space to put more information... Basically, what they add is information for the user-developer, not important for its operation. That bytes return type of mouse as detected by the interface, version of hardware and version of software. The last is Pear sign.

As you only have to emulate the complete mouse(5 buttons and wheel), leave that bytes untouched.

5- As I said, still there isn't software that use the wheel. Horizontal wheel is an idea of Pear, not present on Prodatron extended MSX protocol. Actually the upper nibble is not used, but  I must follow Prodatrons's protocol, so I take the two nibbles as a whole byte. I later can change that behaviour easily.

4- {...} The last is Pear sign.

Exactly there are the EnterMice serial number.