Centipede Speed Up request

[Hetzen]

Thanks for clearing that up. So could the acceleration I'm seeing be baked into the mouse firmware?

[thorr]

It's possible the acceleration is inherent in the USB trackball itself. I didn't notice any significant acceleration going on when I was testing my Happ trackball. I didn't test it extensively, but I did think about it while I was testing and it didn't seem to be there. You have to keep rolling the ball to get it to move where with acceleration you can roll it faster to get it to move more. Edit: Hetzen, you and I posted at the same time and had the same thought.

[Hetzen]

@thorr

Could you try a little experiment? Move your finger from one side of the track ball as quick as you can to the other without it spinning on. Then move the full arc as slowly as you can and see if the screen pointer returns to the same spot.

[thorr]

I will try when I can. I am at work right now.

[thorr]

Ok, here is what I found out...

Centipede sometimes misses readings from the trackball. This causes inconsistency in the travel. The faster I spin the ball, the more it seems to miss the trackball movements. So faster movement will often end up with less travel. Because it misses the inputs sometimes, it will sometimes travel further and sometimes not, with both slow and fast movements. EDIT: SEE MY UPDATE BELOW...

Missile command does not miss readings from the trackball. It may vary slightly from each attempt, but in general, I think it doesn't matter if you go slow or fast, the travel is pretty much the same. I can spin the ball pretty good and the cursor will continue to move.

Both are set for 200%. I tried other speeds and it didn't make any difference. Also, Missile Command has a dip switch setting for trackball speed. Setting this to fast was actually nice combined with the 200% setting.

I got Crystal Castles working by copying the rom zip file in place. update_all isn't getting it. Setting it to mouse makes the trackball work perfectly with no missed readings. Moving it fast or slow seems to make no difference in how far the bear travels.

EDIT: SEE MY UPDATE BELOW...

[Hetzen]

Thanks for doing that @thorr. So your Happ trackball is running through an Arduino?

It looks like there are 64 teeth on that high res wheel upgrade.

[thorr]

No, not an Arduino. It is running through GroovyGameGear's Opti-wiz. http://groovygamegear.com/webstore/inde ... cts_id=260

[thorr]

UPDATE: I am pretty sure I had a misalignment issue inside my trackball. When I was previously testing, moving the ball to the right was less smooth than moving to the left, like the ball would stop prematurely when spinning to the right. I took my trackball over to my PC to test with Mame as a comparison. Physically moving the trackball corrected the internal alignment issue, and now moving left and right are both smooth.

I discovered that there is a maximum speed of the guy you control. If you try to go faster, he will not go faster. He will just continue to move at the maximum speed that is allowed. In Mame, there is a buffer, so if you go really fast and immediately stop the ball, the guy will continue to move for a bit before stopping. On the MiSTer, there is no buffer, and if you immediately stop, so does the guy. I don't know which way is more accurate, but I greatly prefer the way the MiSTer is handling it. The Mame way makes it seem very laggy.

If I move the ball fast a certain amount and then move the ball the same amount but moving really slow, the fast moving ball will travel less distance. This is true in both Mame and the MiSTer. This is most likely because I am exceeding the speed limit.

In summary, I am happy with the way the Centipede core is working now. I am not sure why the other two cores had smooth movement when my trackball was misaligned, but it might be because they handle the input differently and the issue wasn't apparent like it was in Centipede.

[Zeosstud]

I finally managed to get a Happ 2.25" trackball plate level with my new Dig Dug control panel, while not perfect, nothing a little wood putty and eventually a control panel overlay will not hide. This thing plays really really well in Centipede using the 400% setting, like I do not know what a real one is like but I can not imagine it is better. It is plugged in via USB and I made to changes to any .ini settings to effect it. I think @jimmiestones nailed this, really hoping now that the Millipede core gets made!

DigDugMistercade.jpeg (563.23 KiB) Viewed 2009 times

[offset]

Requesting that the Centipede 800% speedup be made part of the core that is included as part of update_all. 800% works great for the smaller egret ii trackball/spinner controller. Every time I run update_all my centipede is replaced with the version that doesn't have the 800% update (just 400%). Thanks!

+1 on Millipede core!

[offset]

I've just pushed a new version with a 400% speed option, should be available for update within an hour or so...

(the reason it's 400% is mainly because x2 or /2 is much easier for the FPGA and causes less stress on the core!)

Would it be possible to get the 800% version pushed to the Mister repo so its automatically included as part of update_all?

It works great with the egret ii trackball / spinner controller

Thanks!

[jimmystones]

I don't think I built the 800% version, I think it was funkycochise? I don't have the source for it exactly...

I was trying to get 800% and 1600% options in there but the core is a bit unstable and wouldn't build repeatably after the change - and then I got busy and somewhat forgot about it

I may have time to look at this over the holidays, haven't really had much time available for FPGA dev for a while now, which is annoying!