Small 'direction lag' upon change of mouse movement direction.

[dh219]

Symptom can be demonstrated on stock firmware:

• Switch to a low screen resolution (not necessary, but makes visualising it easier)

• Slowly move the mouse pointer left, right, up or down.

• Stop

• Slowly move the mouse pointer in the opposition direction, right, left, down or up.

The initial movement of the mouse will be the first direction rather than the second.

This makes delicate selection difficult -- important in lower resolutions. I can reproduce this on Atari and Acorn hardware.

Can anyone else confirm this? Can anyone suggest where in the firmware to look for this 'direction lag'?

Regards,

DH.

[simoninns]

This was a very well spotted bug :) Took me quite a while to work out what was causing it... Turns out that the quadrature phase was not being reset when the mouse changed direction, so for the tiny part of the phase left over the host computer didn't see the direction change. In the V1.2 firmware the quadrature phase is reset as soon as there is a change of direction, which solves this issue (at least it does on the Acorn Archimedes A310/1 that I tested it on).

[dh219]

Hi Simon,

Thanks for looking into this and deploying a proposed fix. Unfortunately the fix appears to be worse than the cure when tested on my Falcon.

With both the divisor (another requested feature added -- thanks) and the rate limiting (now defaulting to 500 -- thanks again) disabled to avoid any cross contamination with other new features, the quadrature output now seems to simply drop a lot of movement at low speed resulting in very strange jerkiness. Very occasionally some directional lag is still seen.

I've been trying to understand the effect the mouseEncoderPhaseX/Y=0 lines should have, but can't see how setting those when there is no movement should fix the original problem. Indeed, commenting them out restores behaviour to that of the 2017 variant, so I can see they're the source of this new behaviour.

From what I can understand, changing mouse direction should just change the direction of the quadrature state rather than starting again from zero, so I'm not sure this is the right place to address the bug.

I've put together a small video demonstrating the effect. Apologies for the mobile-pointing-at-a-screen quality.

https://youtu.be/rnZ-SXimxc0

[simoninns]

I've reimplemented the fix in (what I think) is a more logical way. I don't see any lag on my Archimedes A440/1; can you test the latest git commit @dh219 and let me know if it solves the issues for you?

[dh219]

I've reimplemented the fix in (what I think) is a more logical way. I don't see any lag on my Archimedes A440/1; can you test the latest git commit @dh219 and let me know if it solves the issues for you?

Hi @simoninns ,

Apologies for the long delay in getting back to you on this -- I blew up my unit and it's taken me this long to build a new one!

On the face of it, this seems to work beautifully compared to the previous releases. It's obviously more noticeable in lower resolutions so I've done some extensive testing at 320x200 (by playing Lemmings -- the test of champions) and all seems well here.

I don't know if you're interested in collecting known good settings, but FWIW, I found a DPI divisor of 3, a rate limit of 400 and a buffer limit of 400 produces very usable results on the Atari ST range with my set of cheap Amazon laser mice. I haven't tested on my A3000 yet, but that should behave like your A400 and be generally far more forgiving of higher rates.

Many thanks again and sorry for the delayed response.

DH.