Unfortunately the snapshot didn't load in my PC either. But the other new snapshots did so far.

The snapshot was saved with ep128emu 2.0.10 (not beta; by the way, I wonder why "ep128emu-2.0.10_cmos-x86_64.tar.xz" is downloaded so much?). The snapshot format is compatible between different operating systems and CPU architectures, a snapshot saved on Linux should load on Windows, which I tested as well. You may be using an old (beta) version of the emulator, or it could be some Windows problem.

I like your ugly hack!

With  +-4 it seems more or less as difficult as the joystick controller.

The main difficulty is in finding free space for the mouse code, there does not seem to be any that I am sure it is really unused on the segments visible at the time when keyboard/joystick input is read. The hacked version temporarily pages in the system segment (FFh), and the new code is on a part of the EXOS stack that I hope is not used by Bricky Prise (but even that assumption might not be correct). Of course, code running in video RAM is much slower, and because the memory paging is changed, I disable interrupts, but this breaks digital sample playback which needs interrupts at a high frequency. There are also some other issues I did not debug yet.

Another free hint:

For an horizontal movement like of this bat, you only need the X movement, the first two nibbles that are read. Nothing happens if the third and fourth nibbles are not read, at the following cycle at the next frame the first and second nibbles will be X again. The Mouse or the EnterMice interface restarts every cycle. You only have to ensure that you leave the RTS signal high.

This way the routine last only a little more than half the total time, as you still have to read the button. Also you can process 1, 2 or none buttons if necessary.

Also you can easily fuse the Joystick reading routine with the mouse routine to gain space and time. I did it on the SWAP game modification.

I can send you the sources, if you do not get heart attack when you see it

(original package, hopefully it is up to date)

I checked, this is the latest release, date of the program is 10.11.2016

The EnterMice "wired" buttons don't reflect their status if RTS is not moved. It is just because the Atmel chip converts the PS2  data to MSX protocol only when the RTS is triggered. On the Original Boxsoft interface the two buttons are really wired.

Try this.

Was it in the original also, or just after mouse implementation?

It was not a problem in the original. I changed various bits of code that I was not aware of being modified from elsewhere in the program (mostly when the various extras are activated by the "?" bricks), so that caused crashes in the mouse enabled version. I fixed these where I found them, but I could still have missed some. The specific extras that I patched are the one that inverts movement direction (it writes into the input code), and another that allows the player to shoot the bricks (this modifies and calls the drawing code, where I also made changes). However, if there are no more bugs to be fixed, I think the source is not needed now.

The EnterMice "wired" buttons don't reflect their status if RTS is not moved. It is just because the Atmel chip converts the PS2  data to MSX protocol only when the RTS is triggered. On the Original Boxsoft interface the two buttons are really wired.

The reason why the current version of the game with my modifications cannot be started with the mouse is that this part of the game uses a separate routine for reading the input, while everywhere else the one at 1B00h is called, and I patched that. For the title screen, additional patching would be needed, but it also seems the digital music playback really slows down the code there, only a few Z80 instructions can be executed on a 4 MHz machine before another IRQ occurs. I wonder if this would cause problems with the timing or performance if I tried to add mouse input there.

By the way, in the EnterMice documentation, what does the standby time mean exactly?

Time from change state of RTS signal to issue data (nibble) for reading    25 μs
Standby time for the next reading (counting from data issue)    14 μs

Does it mean that there has to be at least 39 us (25 + 14) between RTS state changes, or 14 us (if the nibble data is ignored), or something else?

By the way, in the EnterMice documentation, what does the standby time mean exactly?Does it mean that there has to be at least 39 us (25 + 14) between RTS state changes, or 14 us (if the nibble data is ignored), or something else?

Pear can answer it better, but you must think EnterMice like a car's engine.

-If no RTS signal, the interface stops to work.

-If found RTS but not sync, the interface is on Idle but at least the "wired" buttons are send.

-If RTS is in sync, the interface is running and the "wired" buttons, X and Y deltas, and all the other software buttons and wheel (if present), are send.