Hm, it is a real possibility, and how can we avoid it?

With this you assure that all the clicks only last 1/50 seconds, being immediately released on the following cycle. Then, if the key is keep pressed(or a slow click), the game is not fooled to react to two clicks, as it thinks it is already released.

The "immediately" means exactly 1500 μs.

But it caused key bouncing on EDCW and SWAP...

If you study my injected mouse routine in SWAP you will see how I fixed it.

Actually I implemented two debouncing fixings on the mouse routine for the mouse clicking.

Itsvan says that on SWAP the key click routine is out of the 1500 us timeout. Can it be the same problem with CM2000?.

I don't know how it can be tested...

Yes, but the buttons didn't work well and I put a debouncing routine. Just like EDCW, the main mouse button remained pressed until I put a debouncing routine on it. Do you remember?

But the Swap is working on real machine... interesting!

So, on the real machine, the mouse buttons always work as the second and third fire buttons on EXT1, even without an RTS state change? That could be tested with this program.

Still the same annoying error on ChessMaster 2000 when on the real machine upgraded with 1MB, not on the 128k. May be IstvanV can aid here if I explain what happens.  It can be the memory so fast?

The memory should not make a difference, CM2000 always disables wait states and the mouse routine runs in normal (not video) RAM even on 128K machines. I did not find any obvious errors in the code so far, but I may need to check more. Perhaps it is a problem specific to that particular 1 MB machine? Do others have the same issue with CM2000 on real machines?

In the emulator, I found only some minor issues, like the sensitivity, which also seems to be higher on the X axis, I think it is 4x X sensitivity and 2x Y compared to MOUSE.XR. Using NEG on the 8-bit motion values can also overflow, but only when the mouse is moved very fast (NEG(-128) = -128), so it does not really matter in practice.

On SWAP, the contrary, the button works on the real thing  and XEP128 but not on EP128emu.

The current version of ep128emu emulates the mouse buttons on EXT1 columns K and L only while the 1500 us timer is active. Using the actual joystick buttons works in SWAP, but perhaps the mouse buttons should be mapped to EXT1 fire 2 and 3 all the time, and not only for 1500 us after an RTS state change?

Another annoying "feature" of the input in SWAP, and I think this is not emulator specific, is that the pointer already needs to be moving in the direction of the swap at the moment when the button is clicked. That is, it is not possible to move the pointer to the tile that needs to be swapped, then press the button, and then while it is held down, move the pointer to the other tile to swap with. This, combined with the high sensitivity, makes controlling the game not very convenient. Using the external joysticks has the same issue, but interestingly not the keyboard/internal joystick.