Software to test mouse counters, modify OS poll rate and acceleration?

[ReadOnlyCat]

I had absolutely zero success searching Aminet and Google for an Amiga application (or several) which would offer the following features:

• Display/log the mouse counters "live" (both raw and overflow-corrected).
• Increase the mouse poll rate of the OS (not the acceleration, there are plenty of Aminet utils/mouse entries which provide that, but the rate at which the OS polls the JOY0DAT counters).

Would anyone know if such things exist?

I'm asking because currently a Razer mouse behaves in a very erratic way when plugged in the Amiga via the Rys MKII (as described in this EAB thread). At slow speed, the cursor just moves too fast to allow precise pointing and at medium to high speeds it quickly clamps to the border of the screen while frequently bouncing back wildly in the direction opposite to the movement.

I suspect that this is due to the mouse high DPI resolution (8200, regular mice rarely exceed 3800) which causes the fast movement a slow speeds and overflows of the JOY0DAT counters at medium/high speeds. Since the HRM mentions how to handle an overflow of the counters I assume that the OS does attempt to detect and correct it but with such a high DPI I suspect that they probably overflow several times per VBL which results in semi random values which could explain the erratic wild backward bounces.

I thought of writing a simple program to test this hypothesis but I don't have any coding resources on my physical Amiga (yet) so I wondered if there existed such a thing as a mouse test bench which could be used for that purpose. If my guess is correct, using this mouse on the Amiga would require to increase the OS mouse polling rate in order to more finely detect and correct overflows. Once overflows are eliminated, a simple sensitivity adjustment should be enough to translate the high DPI into high control precision. (*)

As mentioned above I searched Aminet and Google in vain so if you guys know of such creatures I would be very interested to hear about them.
Thanks!

(*) At the moment, I suspect that all gaming mice exhibit the same issue making them useless on the Amiga.

[Toni Wilen]

It is 100% surely caused by mouse counter under/overflow. I had same problem with UAE, any high DPI mouse = mouse pointer starts jumping backwards and then forwards and so on when moved too fast. (Limiting mouse counter counting to +-128 per mouse counter register read and adding some extra overflow logic fixed it. Unfortunately external hardware can't know when mouse counter is read.)

Mouse counters are read during vblank interrupt and I don't know any simple way (without lots of reverse-engineering) that can be used to increase poll rate without also increasing vblank rate which would cause too many bad side-effects.

[Vot]

Originally Posted by Toni Wilen

It is 100% surely caused by mouse counter under/overflow. I had same problem with UAE, any high DPI mouse = mouse pointer starts jumping backwards and then forwards and so on when moved too fast. (Limiting mouse counter counting to +-128 per mouse counter register read and adding some extra overflow logic fixed it. Unfortunately external hardware can't know when mouse counter is read.)



Mouse counters are read during vblank interrupt and I don't know any simple way (without lots of reverse-engineering) that can be used to increase poll rate without also increasing vblank rate which would cause too many bad side-effects.

Someone posted on fb saying the hardware is capable of reading every scanline. I actually posted teasing saying basically: so what the tank mouse was so horrible it didn't really matter

RJ michael actually replied saying this:
"Yeah, and I remember once setting up the system by accident to send me a mouse position report EACH AND EVERY SCANLINE. Heh heh, a few gigabytes of memory would have been useful that day."

So i guess it's possible if you want to rewrite amiga os to poll more often to not have it overflow... (And burn the cpu cycles that often) Unless of-course there is an overflow within the logic on adapter itself.

[demolition]

Perhaps the designer of the Rys adapter could simply reduce the resolution of the data from the mouse before it is sent to the Amiga? I know that the adapter can be reprogrammed by the user, so multiple firmwares with different divisors could be chosen from, in case you want to use it with a high DPI mouse.

[ReadOnlyCat]

Ah, excellent point, thanks Toni!
It does make complete sense that the problem would occur with UAE as well - that is before you fixed it ^^, I guess this does also finally explain why my mouse seems reactive at slow speed and sluggish at high speeds in FS-UAE: the counters are probably clamped when moving too fast causing the mouse to feel less reactive than it is at low speed. It seems to lag a bit behind but only when moving fast. I'll try modifying the sensitivity of the mouse before launching UAE and see if that helps.

Regarding the OS poll rate you are most likely right, I do keep hoping that the mouse input events might be handled by timers and configurable via input.device or some such but since I haven't found (yet) any utility which offers to control that I suspect that this is not the case and they are probably hard coded in the VBL. With the UAE debugger this might be fun to investigate.

Originally Posted by demolition

Perhaps the designer of the Rys adapter could simply reduce the resolution of the data from the mouse before it is sent to the Amiga? I know it the adapter can be reprogrammed by the user, so multiple firmwares with different divisors could be chosen from, in case you want to use it with a high DPI mouse.

That's already the case. There are three divisors to choose from but that reduces the precision of the mouse. I would rather have the Amiga OS handle it correctly. Moreover it would be pretty cool to pretend that the Amiga can be used for high precision gaming. (Alas this would require patching most games! )

Originally Posted by Vot

RJ michael actually replied saying this:
"Yeah, and I remember once setting up the system by accident to send me a mouse position report EACH AND EVERY SCANLINE. Heh heh, a few gigabytes of memory would have been useful that day."

So i guess it's possible if you want to rewrite amiga os to poll more often to not have it overflow... (And burn the cpu cycles that often) Unless of-course there is an overflow within the logic on adapter itself.

Ohhhh, cool! That could indeed mean that the counters are read via dedicated interrupts which would open the possibility of parametrization.

Thanks again everyone for your answers!

[daxb]

At least the problem is known. There exists several software to speedup/slowdown mouse speed but that doesn`t help while using a mice with a to high dpi value, I was told. The 8 bit wide counter Toni already mentioned is the limit/problem. Only solution seems to be using a mice with lower dpi. Maybe a mice adapter exists that solves the problem in hardware.

[robinsonb5]

Originally Posted by ReadOnlyCat

That's already the case. There are three divisors to choose from but that reduces the precision of the mouse.

It doesn't have to - the firmware would merely have to retain a remainder from the division so the low bits are carried over rather than discarded. (Freewheel does something similar, which is what allows it to adjust mouse acceleration in 1% increments.)

[Vot]

Also if you read it more often wont delta x and delta y be smaller unless your moving it really fast so it has less chance to wrap.

[ReadOnlyCat]

Originally Posted by robinsonb5

It doesn't have to - the firmware would merely have to retain a remainder from the division so the low bits are carried over rather than discarded. (Freewheel does something similar, which is what allows it to adjust mouse acceleration in 1% increments.)

Hum... You very well may be right that propagating the reminder eliminates the sampling error on average but there might still be jitter at low speed movements which usually trigger only a few notch of the scrolling wheel of mechanical mice per second but result in much higher readings on a high DPI optical mouse.

It could be said that the real interest of high DPI mouse lies at low speeds because they allow fine control of the cursor with sub-to-milimeter precision movements. Even with remainder propagation these might register as sub-counter for many frames between each increase.

I might be wrong though so I will try to write a small test program this weekend.

Originally Posted by Vot

Also if you read it more often wont delta x and delta y be smaller unless your moving it really fast so it has less chance to wrap.

Yes, this is precisely why I am looking for a way to modify the OS poll rate.