The Arduino code simply ignores that ninth bit the PS/2 mouse provides.

EnterMice read the full 9 bits and divides the result by 2.

Dividing 9-bit signed number by 2 the result has 8 bits (preserving sign)
You may also like that (replace MSB bit):

Between turning the RTS line and reading the data takes around 90 μs at first read and 65 μs all another.

My (now only private) development shows that the auto switch between joy-1 and j-column mouse emulation works nicely! I did this by introducing another watchdog. It's not mouse/entermice/hardware related unlike the nibble counter reset stuff, but Xep128's emulator-only based stuff. On each RTS changes it is started/cleared. On port 0xB6 read it's checked if more than 10000 usec passed since the last pulse. If no, mouse behaviour is emulated if yes, joy-1. Of course, if k-column is used (entermice) this is not needed at all. In this way SymbOS and EGI still seems to work. Moreover applications like EPDOS which were confused by mouse existence (j-column, because of expecting a joy-1 there) now are not confused: it does not provide RTS pulses, so Xep128 emulates joy-1 behaviour. A mouse aware application normally pulses RTS more frequently than 10000 usec (but maybe other value would be better ...) so it will get mouse mode while it does. And even if it stops doing that for a loooong time, the next RTS pulse will "pull back" the mouse mode. Also, in case of a "random" RTS change (ie some program do a pulse for whatever reason ... but not because it wants mouse) won't cause to stuck in mouse mode, because the new watchdog expires shortly. Also leaving mouse aware program results in expired emulation mode watchdog. Etc ... etc.

Now situation is more clean, mouse grab / no grab mode has *nothing* about the emulation mode any more! It merely only affects that mouse events are updated in the emulation or not. This also means, that mouse pointer does not move when you leave mouse grab mode, as the application still pulsing RTS so Xep128 provided the mouse emulation mode, just without any update on the movement/buttons from the PC mouse via SDL (only that needs mouse pointer grab).

Again, in case of mouse on K-column, this algorithm is not even needed as there is no conflict ... Currently my code chocks on this, and I would like to fix this issue as well ...

I've been testing your sound implentation, and it is very good for me. The only problem are some clicks now and then even when in silence.

Well, that's the problem Currently sound is only an ugly hack (that's the reason audio is not enabled by default, it's so lame). Ie, the sampling rate is set to be about the same as Dave emulation "should" work. However since there is a slight difference (integer can't be float number ...) and also the load of the PC and the OS's scheduler to run Xep128, it won't be perfect ever, so audio buffer undeflow happens. Or at extem cases the opposite. Etc The correct solution would be the sound buffer state to be calculated into the main emulation sleep loop, but I haven't got the mood/time to deal with that too much Honestly, I am even surprised that audio is "so good" now if you consider the fact that it shouldn't even work this way too much :-/

On the last official win32 compilation the mouse movement seems to have being fixed, without the glitch when moving fast.

Interesting as nothing should cause changes there, hmmm. What you mean about "official"? The "-entermice.exe" or the regular xep128-win32.zip stuff?

Thanks for all the effort you put  on your Xep128.

Thanks for your help in mouse related topics Ep128emu is still more accurate and advanced by light years but unfortunately it does not support some things, like SD card, or well ... mouse, for example And also it's fun to try to write an own emulator, that's the another point ...[/quote]

I mean the Xep128-win32.zip. May be it is glitch-free now because I am testing it on another PC?

Not impossible ... as there is no correct sync with audio buffer and delay code it's maybe depends on many "random" things how it behaves ...

It can be the sound is so good to me only because it exists.... It is a great step from the total silence.

Sound drives me mad by the way, it's kinda hard to do it well :-/ It seems humans are much more picky about sound than even the video output. Eg if video output stalls for a frame in every one second or so, it can be noticable but maybe not so annoying. But if audio does this ...

You are reaching more and more milestones with Xep128. May be it is not accurate, but just now is a great emulator.

Well, yes, the good thing with that if you can do something you feel the power to solve another problem What can be bad, if you can't do it something too much for long time, the mood can go away to continue the whole work :-/ Especially with hobbies which are not "compulsory" and should be done for fun. This is the reason I start different parts all the time with Xep128, so I can find some place for improvement everywhere Like sound, it was a good try to have *something* ... then I started another thing, like better mouse support ... But I am sure I will go back to sound some time ... If you understand my point Or maybe I am just an odd person to think that way ...

The old topic:

Can you test the new xep128-entermice.exe? Well it sould behave the same ... At least it shouldn't be worse ... But again I had to rewrite some parts of the code, it was already ugly. Now two joysticks with three buttons are supported, but of couse no code yet in Xep128 which can send the events for that ... Also, the "emulation mode watchdog" is implemented, so in case of colliding mouse/joystick-1 (if J column is used for mouse) Xep128 tries to detect with RTS pulses that it must be a mouse query but reverts back into joy mode if no RTS pulses for a longer time. Now (more or less as a debug) even OSD tells if control port emulation mode changes, you can see it. At least I tried that with EGI, SymbOS, and tested if EPDOS is not confused by the usual mouse existence, all of three seems to be OK, but I am not a good test person Also I tried only mousemode 1.

A new topic ...

Another question, if I can have ... I don't have any windows. Funny, but I compile for Windows (with Linux) that I can't even test if works I also don't have experience (even not as a user ...) with windows. That's why I ask this: what happens if you start the exe from a console (DOS?) window? Does it print anything? I ask this, because mingw cross-compiler (basically gcc, targeted for windows, with limited posix emulation) supports -mwindows and -mconsole switches. According to the documentation, this sets a flag in the windows PE executable that it's a GUI or soncole application ... I really don't know that it does, honestly. I guess, in case of console app, window is always open if an application produces (textual) output on "stdout". SDL for windows sets that for -mwindows so I guess it won't happen now with Xep128 win32 builds, however I have no idea what happens if you run Xep128 from a "console" already Ok, maybe it was a stupid question ...

You say: Can you test the new xep128-entermice.exe?  But I don't know what or where it is.

The usual place for that http://xep128.lgb.hu/files/xep128-entermice.exe
I mean that URL if I say "xep128-entermice.exe", but indeed, sorry for the not so clear statemant ...

The last compilation I have(yesterday) is the Xep128.exe from your page, and it works good for me.

Yes, but it is not the rewrite (again!! heh...) of mouse stuffs I mentioned. Unfortunately, it's hard to say "it's OK, leave it that way" because even if it works great, the code can be a mess which is a limtation on further development then. I often want to understand things resulting messy code, and if I understand, and works, I should rewrite in a much cleaner way

I've tested it from a Dos console and it works flawlessly. It opens the Xep128 windows the same and gives it the control. If you close the emulator then the control returns to the Dos console windows.

Ok, but I mean does it print messages to the DOS window, or anything? I mean things like this:


Of course the exact output would be different especially paths on Windows ...