Incorrect PS/2 mouse structure handling.

[sorgelig]

https://github.com/MiSTer-devel/Arcade-MissileCommand_MiSTer/blob/eb51c3463775ec69360a6409ca21a5d824561179/rtl/trackball.v#L154-L155

it should be:

 mouse_mag_x = {mouse_sign_x, ps2_mouse[15:8]};
 mouse_mag_y = {mouse_sign_y, ps2_mouse[23:16]}; 

where mouse_mag_x and mouse_mag_y must be 9bit signed values (not 8bit!).

[sorgelig]

https://github.com/MiSTer-devel/Main_MiSTer/pull/765

[JimmyStones]

@sorgelig I've tried to follow the other conversation about this issue but it's gone in some different directions and now I'm confused!

Is there now clarity on whether the movement value is 9 signed bits, or something a bit weirder like that webpage you linked to in the other ticket where is suggests there are 2 sign bits somehow?

Regardless I agree the code may well be wrong :D but I'm not if sure your suggested solution is right - to be clear the purpose of lns 154-155 is to get the absolute values for mouse movement (mouse_mag_x and mouse_mag_y), and the respective signs of those values (mouse_sign_x and mouse_sign_y) - does that make sense?

[sorgelig]

My first post here includes correct handling. You just need further patch to extend mouse_mag_x and mouse_mag_y wires to 9bits. Webpage i gave is not correct. Offset is simple 9bit signed value and doesn't require any transformations.

[garyjsweet]

the purpose of lns 154-155 is to get the absolute values for mouse movement (mouse_mag_x and mouse_mag_y)

We don't believe those are actually magnitudes, but rather just the low 8-bits of the 2's complement 9-bit signed delta.

FYI : Looks like centipede contains the same errant mouse code.

[JimmyStones]

Sorry, to be clear though I do actually want magnitudes for the mouse_mag_x / y values, not the signed number - as the signs are passed through to the trackball input as separate signals. So the original code here was designed to invert the 2s complement of the 8-bit part back into a regular 8-bit magnitude. If I use the replacement code above then the mouse behaviour is completely erratic when moving left / up because the negative numbers are all upside-down!

[garyjsweet]

I do actually want magnitudes ...

Right - I guess the clue was in the name. Let me explain my original issue then:

I'm seeing that very fast trackball movements are causing what looks like an unhandled overflow. For example, putting the mouse cursor at the right edge of the screen and rolling the trackball further right will cause the trackball to jump backwards off the edge. If I clamp the mouse deltas between -127 and 127 that doesn't happen - it works as expected.

So, something is going wrong with values in the range -255 to -128 and 128 to 255, which took us down the path of looking for odd 9-bit behaviour.

I'd be interested to know if you can replicate the same behaviour. My trackball is setup with a 10x multiplier on the pulse count to increase the sensitivity to a reasonable level.

[garyjsweet]

This is what I'm seeing: https://1drv.ms/v/s!AgZXmGPNWbCKj_c1sD999tzPyu4d2w?e=ITTyCx

[JimmyStones]

Ok so with the highest DPI mouse I could find I can replicate that in the Input Test core - but for that same device I can't replicate it in the Missile Command. For Input Test I agree it looks like the handle_ps2 code you mentioned is wrong, not sure how it was working before but I'll fix that first :D

[sorgelig]

ok. If you wan exactly magnitudes then:

mouse_mag_x = mouse_sign_x ? -{mouse_sign_x, ps2_mouse[15:8]} : {mouse_sign_x, ps2_mouse[15:8]}; 
mouse_mag_y = mouse_sign_y ? -{mouse_sign_y, ps2_mouse[23:16]} : {mouse_sign_y, ps2_mouse[23]};

[gary-sweet]

Ok so with the highest DPI mouse I could find I can replicate that in the Input Test core - but for that same device I can't replicate it in the Missile Command. For Input Test I agree it looks like the handle_ps2 code you mentioned is wrong, not sure how it was working before but I'll fix that first :D

I'll get some footage of missile command when I get back from work later today. The problem is more subtle from my recollection.

[gary-sweet]

Another potential issue might be in trackball.v (disclaimer - I'm a C/C++ guy, not verilog):

mousemag values are 8 bits wide:

reg [7:0] mouse_mag_x /* synthesis preserve noprune */;
reg [7:0] mouse_mag_y /* synthesis preserve noprune */;

I am using 200% speed, which left-shifts those magnitudes to double up. For large magnitudes I assume that will lose the top bit.

else if(mouse_speed == 2'd3) // 200% speed
begin
    mouse_mag_x = mouse_mag_x << 1;
    mouse_mag_y = mouse_mag_y << 1;
end

[JimGregory-Advania]

@sorgelig that makes sense thanks, I'll try that later.

@gary-sweet You could be seeing an overflow in magnitudes at 200% if your device is that fast, I'll see about increasing the size (though it sounds like it would be uncontrollably fast for me! 🤣)

[sorgelig]

mousemag values are 8 bits wide:

i've already told above these wires should be corrected to fit 9 bits. It obviously needs further corrections to make sure upper bit won't be lost. Probably, it's worth to clamp value to 8 bits. I don't think higher values are usable in core.

[garyjsweet]

Ok, here's a video of missile command. The behaviour is different to the input tester. This was taken with the mouse speed set to 100% to avoid the left-shift overflow issue.

I hope you can see that when the trackball is moved very quickly there is often a noticeable period where it doesn't seem to move at all in the direction of the trackball movement but will then start moving.

https://1drv.ms/v/s!AgZXmGPNWbCKj_c6nEJrWjqYjHVCsA?e=7zXC3x

I don't believe the lag is coming from the control hardware. I made the control boards myself and measured the input latency using the lag tester core at around 800us. The software for that, and the board design, is all here if anyone is bored enough.

I guess it's possible that this weirdness is actually part of the original arcade h/w or s/w, but I suspect it deserves at least a little analysis / debugging just in case.

[JimmyStones]

Looking at the speed you are rolling the ball there I think you might just be exceeding the speed at which the game itself reads from the trackball hardware! The game code only reads the trackball input so many times per frame (4 if I remember correctly) and if the movement counters roll over before they are read you'll lose data and start 'slipping'. Regardless, I've built a new version with the updated magnitudes as per @sorgelig's code so please give it a try and see if there is any change:

https://github.com/JimmyStones/Arcade-MissileCommand_MiSTer/blob/trackball-speed/releases/Arcade-MissileCommand_20230404.rbf

[garyjsweet]

Thanks, I've just tried the new version. Honestly I can't say that I can see any difference in behaviour. You may well be right about it just being a limitation of the game itself that's causing the slipping.

I originally thought that the problems in the input tester and this might be related, but I suspect they aren't now. It does look like the 200% mode could have overflowed, but I'm guessing you addressed that in the version above. If that's the case we can probably close this issue and just leave the one I raised against the input tester open.

Thanks for your help on this.