MiSTer FPGA Forum

Hey all,

I finally got myself a MiSTer for christmas. All the parts have arrived, I have set up a lot of different cores, and I'm so amazed how awesome this project is. This is like a digital archive of all these great consoles, arcade machines, the Amiga... I have used emulators before, but I was always dissatisfied with the input latency. It just didn't feel right. On the MiSTer, I don't notice any input lag. Every game I tried so far is perfectly playable, looks and sounds just right, no lag whatsoever. And I use only the cheap Competition Pro USB rebuilds, supposedly LLAPI things could be even better. THIS IS CHRISTMAS!

I've noticed an issue with mouse input on the Amiga. Faster mouse movements result in "jagged" lines. Drawing things in a paint program doesn't look right. Like the mouse is jumping around. I try to explain it in a little video: https://odysee.com/@testchannel934723:3 ... 2_145536:2

I recorded the mouse events on the MiSTer and played them back both on MiSTer and on the PC (shown in the video), and the PC doesn't show the jaggedness or jumping. So it's apparently not a problem with the physical mouse connection, or the Linux kernel on the MiSTer. I also tried the Input Test core and it seems to show the same jaggedness/jumping. Turning up the mouse divider in INI settings doesn't fix it.

Has anyone else seen this? Any ideas or pointers?

syn wrote: ↑Thu Dec 22, 2022 2:42 pm

Has anyone else seen this? Any ideas or pointers?

Your PC is huge a magnitude faster than the Minimig core, so its simply able to keep of with (and display) your recorded mouse movements at a greeter granularity.

bbond007 wrote: ↑Fri Dec 23, 2022 3:28 am

Your PC is huge a magnitude faster than the Minimig core, so its simply able to keep of with (and display) your recorded mouse movements at a greeter granularity.

The mouse jumping never happened on a real amiga though. Neither does it happen on an emulator.

I believe you’re mistaken, this is definitely a case of your memories distorting how the Amiga actually performed.

Although I haven’t got a real Amiga in front of me, I performed the same test using Winuae A1200 config (cycle exact) and I can confirm it behaves the same as your mister demonstration.

Like the previous poster said, a modern PC runs at a much higher clock speed, polling the mouse movements much quicker than any system running at 7 or 14mhz.

There's an Aminet project to drive a PS/2-style mouse on a real Amiga. (https://aminet.net/package/docs/hard/ps2m)

From their notes:

- detection of Amiga mouse counters overrun:

Amiga has only one-byte signed counters for mouse, and AmigaOS
checks them only one time per vblank. This means that mouse may
move only 127*VBlankFreq pixels per second (6096 pixels per
second for default DblPAL). If this value was overran, AmigaOS
can't detect true movement of mouse and pointer will disorderly
jump.

Reworded: the Amiga is only polling the mouse once per vblank, either 50 or 60 times per second, and will overrun if you move more than 127 pixels per measurement. The default PS/2 rate, IIRC, is 125 polls/second, a little more than twice as fast as NTSC, and the Mister may be running faster still. Modern gaming mice usually poll a thousand times a second.

Turning your mouse sensitivity down may help. The Amiga is completely overwhelmed by modern mice.

I just tried it with FS-UAE. I cannot reproduce the problem there, even moving the mouse as fast as I can. Mouse input is a bit laggy, and cursor movements speed looks slower, but there are no jagged movements like on the mister/minimig.

Can't reproduce it on WinUAE either. Exactly the same: relatively slow, laggy mouse updates. No cursor jumping. Nothing that looks like the behaviour on the mister/minimig, where the cursor is not slow, but it jumps in the wrong direction sometimes. It looks like an integer overflow to me.

You seem to be misunderstanding the problem.

Digging around in the code a bit, I found this:
https://github.com/MiSTer-devel/Main_Mi ... .cpp#L3622

Mouse deltas are sent to the minimig core as 8-bit values, and if they are too large, they get clamped to -127...127. I inserted some printf statements there, and this code does get hit the moment I see the mouse jumping. Could be related. Will look into it more later.

Malor wrote: ↑Fri Dec 23, 2022 12:48 pm

There's an Aminet project to drive a PS/2-style mouse on a real Amiga. (https://aminet.net/package/docs/hard/ps2m)

From their notes:

- detection of Amiga mouse counters overrun:

Amiga has only one-byte signed counters for mouse, and AmigaOS
checks them only one time per vblank. This means that mouse may
move only 127*VBlankFreq pixels per second (6096 pixels per
second for default DblPAL). If this value was overran, AmigaOS
can't detect true movement of mouse and pointer will disorderly
jump.

Reworded: the Amiga is only polling the mouse once per vblank, either 50 or 60 times per second, and will overrun if you move more than 127 pixels per measurement. The default PS/2 rate, IIRC, is 125 polls/second, a little more than twice as fast as NTSC, and the Mister may be running faster still. Modern gaming mice usually poll a thousand times a second.

Turning your mouse sensitivity down may help. The Amiga is completely overwhelmed by modern mice.

Hey thanks, that looks relevant! This goes exactly in the direction I was thinking. 8 bit delta counter overflow would totally make sense. I did turn down the mouse sensitivity though, and it still happened. And it's weird that I can't reproduce it on emulators.

How many times a second does the MiSTer main process relay mouse events to the core? On MiST I see jerky mouse movements when the firmware's busy with disk activity - writes especially. It's notable because it doesn't happen either on the original Minimig or the TC64 version - both of which have real PS/2 mouse ports which are handled in HDL rather than software.

syn wrote: ↑Fri Dec 23, 2022 1:05 pm

Digging around in the code a bit, I found this:
https://github.com/MiSTer-devel/Main_Mi ... .cpp#L3622

Mouse deltas are sent to the minimig core as 8-bit values, and if they are too large, they get clamped to -127...127. I inserted some printf statements there, and this code does get hit the moment I see the mouse jumping. Could be related. Will look into it more later.

https://github.com/MiSTer-devel/Main_Mi ... .cpp#L5339
The minimum delay between updates is 15ms (~ 66.7 fps). Which is a bit faster than the usual Amiga refresh rate of 50..60 fps. So it's possible that 2 updates get written before the Amiga polls it. Then the first one would get lost. Right? The time difference isn't big so it would only happen sometimes, and only with quick mouse movements, which is what I see.

If that is the issue, or one of the issues, then optimally the updates would be synchronized to the Amiga refresh rate. In an emulator, that would be relatively easy, but as the core runs at its own speed, it could be difficult.

I'm not familiar with the MiSTer code. Am I on the right track?

Try enabling fast polling on usb, it will overclock it to 1000hz. You may need to adjust the mouse speed in the MiSTer.ini afterward.

aberu wrote: ↑Fri Dec 23, 2022 2:13 pm

Try enabling fast polling on usb, it will overclock it to 1000hz. You may need to adjust the mouse speed in the MiSTer.ini afterward.

I tried. Didn't notice a change with or without 1000hz. If anything, 1000hz seems to make it a tiny bit worse. Checked different mice, too.

Tried reducing the mouse speed ini setting too. Will decrease the mouse speed, but jerkyness still there.

Is there a way to check, from the MiSTer side, whether the Amiga has polled the mouse yet? (Probably not)

Or can we check whether a frame has passed for the Amiga?

syn wrote: ↑Fri Dec 23, 2022 2:05 pm

https://github.com/MiSTer-devel/Main_Mi ... .cpp#L5339
The minimum delay between updates is 15ms (~ 66.7 fps). Which is a bit faster than the usual Amiga refresh rate of 50..60 fps. So it's possible that 2 updates get written before the Amiga polls it. Then the first one would get lost.

I changed this delay from 15ms to 20, and the jerkyness went away. Probably not optimal though. Would be better to sync to the vertical retrace, I think.