Well, I admire you if you can understand this mouse world of EP, really For me, it's quite confusing. Especially this quite slow method to "step" over nibbles then "scan" bits in the nibbles, detecting using, etc :-@ I would say, it's better to create some parallel protocol/interface but indeed, it would mean a bus expansion card, which is maybe not so nice. Oh well, maybe it's still the more simple, only problem that it's not so simple from the view point of programmers

You are emulating the hardware of a two buttons mouse(1 effective button at the end....)  because implementing the captions of the extra buttons and wheel is very difficult, as you said:

Xep128 can do more than JSep (the javascript web emulator), since Xep128 is a native application, no problem with the mouse buttons used by browser, or not handled at all, etc. It's mater of SDL in fact, as far as I can see, it means at least 3 buttons (but the mouse header file of SDL also defines X1 and X2 so maybe it means five buttons?), I have no idea about wheel scrolling etc though. So it's possible to emulate more functionality, I guess ... Also note, that game controllers/joysticks for some degree is already supported by JSep (because modern browsers has API for this) and maybe in Xep128 too in the future, so there is really room for the improvement here

The driver then will attempt to read that fifth nibble and will default to the simpler mouse. Other programs that use older versions of the driver or internal routines like SymbOS will work because they don't read that fifth nibble.

Ok, now I'm officially lost ... How it can be done "not to read the fifth nibble"? I guess it's not possible, since the "stepping" over nibble iterates over nibbles, so if there are more than four, old software won't work which expects four "stepping" to get the nibble being the "first", then you need more stepping pulse to get the same result. Also I couldn't understand too much what happen if a program send a pulse by mistake before your program to be able to run, then nibbles will be "shifted", since there is nothing which can tell which is the "first" nibble, no way to find a sync point.

Here you can see the complete protocol, there are a lot more of nibbles added by Pear... Your XEP doesn't need to know that...

I see, and it's indeed a very nice and helpful draft on the protocol within a single table. However, I still can't get it, if you have more nibbles, no software will be compatible, ie 4 nibble mode softwares does 4 "pulses" to "cycle" nibbles so if there are more, it simply won't work.

You can admire me, as mice and its relation with EP's is the only thing that I can understand.....

The cause of the existence of the MSX protocol (and therefore the Boxsoft and EnterMice ones) is that inside every single msx mouse there are a 4 bit microprocessor(the Neos chip) calculating the movement of the mouse and sending nibbles over a 4 bit input parallel bus formed with the four direction leads. One output line more is needed for requesting information to the Neos chip. You already know this. The AY sound chips used on the MSX computers have additional I/O data ports that are used to form "easily" the joystick ports(at the end it is not so easy, as they must be read through the AY chip by commands).

The convenience of this method is to discharge the Z80 from the task of decoding the movement of the mouse. It returns two bytes, one for X and other for Y that express the amount of movement from the last reading. Then, the processor only have to add those signed numbers to the pointer position, putting care on borders or "objects" in screen.

But you know that reading the joystick ports adds a little of difficulty when implementing this on the Enterprise...

On a MSX computer you only need the mouse for it to work, but the controller ports of the Enterprise are not so standard and need to be converted. On a C64 the adaptation was almost straight, because the signals where compatible, only that it used other pinout, the Atari one.

Is for all this I think that the Boxsoft interface is a little miracle.

On the other side its existence has opened us the way to a EP SymbOS port, as they use the same protocol.

-------------

Ok, XEP128 can emulate more than two buttons, but first we must make work the most basic mouse.

-------------

It is a fact that a real MSX mouse returns 0000 if a fifth or more nibbles are requested, it only returns the four first nibbles of the movement, then waits for the next 1/50 second, the next interrupt. Based in this, Prodatron and NYYRIKKI  invented the extended MSX protocol.

A mouse with more than two buttons(a PS/2 to MSX converter like EnterMice) always returns 0001 on the fifth nibble read.

---------------

Then you must put 0000 on the 5th nibble, the mouse driver will read it and will stop requesting data, the actual version of SymbOS or the older driver will not read it, but it doesn't matters, as the movement is already read, and then your emulator, not requested for more data, will wait up to the next reading cycle, the next 1/50 second. If you don't request for more nibbles the mouse or the EnterMice doesn't sends more. And it is not a malfunction.

Once the rest time has passed, the program begins again another lecture cycle from the first nibble.

It is more simpler than you can think.

Well, I've just discovered (hmmm, re-discovered ...) the wiki page, it's quite a good one! It can explain many things, even some of my questions, though not all of them. What I can't still get it: in my naive implementation, "shifting" nibbles are "circular" ie, after max number of nibbles for the given protocol, it warps around to the beginning of the "cycle". What is the correct behaviour? It should be endlessly emits bytes '0' if it does not know entermice stuffs, and just start again after a time of "silence" of query (the so called watchdog)? And is it the same policy in alll protocol modes? Eg, with entermice protocol extension, byte 7 is device id which seems to be constant. Now that's 16 nibbles, what happens if I endlessly try to "shift" for the next nibble, I will get the nibbles of the 0x5D (entermice device id), or only its last nibble, or it warps around to byte 0? Sorry, this sounds a bit cryptic for me, that how it works ...

The Msx protocol is driven by a 50 Hrz interrupt. Once the reading begins, the mouse sends packets until it detects a big pause, then it doesn't obeys the \Select signal until the next interrupt(It doesn't detect the interrupt, only waits the estimated time).

Pear discovered that a great amount of nibbles can be potentially sent between interrupts, so he implemented his re-extended protocol...

Watchdog is a timer which is started before beginning to wait for a long-term process.
If the process is completed at the expected time, the watchdog timer is stopped. Otherwise, the timer triggers an emergency procedure.
In this case, it has been used to reset the counter of nibbles after expire 1500 μs since of receiving last nibble.

I'm sorry, but your second attempt is even more ungovernable with the mouse driver in Boxsoft mode. On the other side it works with SymbOS.

Now the same http://xep128.lgb.hu/files/xep128-entermice.exe

Not so much change, and I have no idea why it does not work, but now you can configure your mouse at least. :XEP EMICE is gone, :XEP MOUSE is used now! There are six mouse modes, identified by a number. 1, 2, 3 means J-column query 2, 4, 8 bytes protocol, values 4, 5, 6 are the same but for the K-column. Default is mode 1, which should be the good old boxsoft.

Note, that without mouse grab (ie you clicked into the emulator window and PC mouse cursor is gone), the mouse emulation is not so much usable or correct ... Maybe you should try that before any mouse-related functionality is used. Though there is a try in emulator to detect mouse usage (even OSD shows that with SymbOS) it may or may not work with other software and/or mouse modes.

Also, I've commited the changes into github repository, so you can see the source here: https://raw.githubusercontent.com/lgblgblgb/xep128/master/input.c

I've tried to comment things, and so on. If you have time and mood please have a look, maybe it helps to identify problems. Now mouse_buffer is used, which is a 8 byte array according to the JPG image you have posted (and found in the wiki). On RTS signal changes, the nibble_counter increments, incrementation by two is one byte further in the buffer (the lowest bit of course is about low/high nibble selection). mouse_protocol_nibbles limits the buffer fetch (ie, read will provide nibble of zero if reached, not from this buffer anymore!) for the selected mouse mode, ie for boxsoft it's 4 (2 byte protocol, 4 nibbles). The key functions are mouse_read() which is called when port 0xB6 is read, and mouse_check_data_shift() which is called when port 0xB7 is written. watchdog is used with about 1500 usec timeout to reset the nibble counter.

SymbOS seems to work in all mouse modes where J-column is used, no wonder, as I guess SymbOS reads mouse from video interrupt or such, so watchdog resets the nibble counter before SymbOS has the chance to see "new" nibbles, even if the full 8 bytes (16 nibbles) mode (mousemode 3 in my emulator) is selected.

Even if this works in the future, it's still a task for me to update mouse_buffer, for extended buttons and wheel ... Of course it can be only read, if the correct mouse mode is selected, anyway ... Note, that currently, if mousemode is 1, mouse_buffer won't ever been read further than 2 bytes, even if you see there the next byte ... In mousemode=1 the next nibble will be zero if tried to be read. But if you use mousemode=2 for example, nibbles of bytes 3 and 4 are also read before the "constant" zero nibble answer.

Well, I've written this during the night I haven't looked too much about your new posts here, but I will