Suzo- Happ PC Arcade Spinner? Plug and Play?

[FrizzleFried]

Bender has been wrestling with the TT-HL's incompatibility with his 64 bit OS.

It works fine, so apparently it's not incompatible.  And the solution is not an "OS patch".  It's just a piece of software that the crazy 64-bit MS OS makes you jump through a few more hoops in order to use.  Lot of folks on the web have been using it and do so without crippling their systems.  Stuff happens, but not all of the time, and not to everyone.

No doubt we'll see USB 2.0 versions of the TT2 and TT-HL in the future.

Unlikely.  As I have already stated in a different thread, I won't sacrifice compatibility with the huge number of USB 1.1 systems out there in order to accommodate the relatively microscopic number of 64 bit users in this market, especially when a widely used software solution exists which can actually outperform the "out of the box 2.0 only" approach.

RandyT

My understanding was the USB 2.0 is backwards compatible with USB 1.1 in that if you plug a USB 2.0 device in to a USB 1.1 hub or port that the USB 2.0 device will act like a USB 1.1 device?   How is including USB 2.0 compatibility sacrificing compatibility if this is the case?

[Derrick Renaud]

so if I understand the problem, it is that there is too much data being thrown at windows to handle at 125Hz
so if you have a regular resolution spinner wouldn't that be less data being sent, and wouldn't that explain why a standard resolution spinner works fine under the 125Hz windows standard?

A hi-res and lo-les spinner should both have the same issue with windows locked at 125Hz.  But you have to remember, they both have to be scaled so they turn at the same full turn count rate as the original game.  Let's stick with Tempest.  We know that a 1200 count hi-res is 300 optical counts times the 4 edges counted by the IC.  And that it should be set to a MAME analog sensitivity of 6% to match the 72 count of the real game control.

A lo-res spinner has 24 optical counts.  I'm sure there are others, but let just use this as an example.  Now we times this by 4 edges counted by the IC.  This gives a resolution of 96.  So 72/96 = .75 or 75% MAME analog sensitivity.

Both spinners should now have the same backspin when locked at 125Hz poll rate.  Remember as I have previously shown, the Hi-Res 1200 count spinner will not overflow at 125Hz until you manage to spin it over 13 revolutions per second.  Good luck trying.

The problem here is realizing that there is the windows poll rate and the original game's poll rate.  The supplied windows polled data is scaled by the MAME sensitivity before it is polled by the emulated game.  So if both hi and lo res spinners are set as I described, and both spinners are polling at the windows 125Hz rate, and you spin both the same, then the emulated game receives identical data.  Except the movement/data will be smoother with the hi-res spinner.

The problem is 125Hz is half of the game's poll rate.  And as the game only uses a 4-bit counter, it will easily overflow because the game receives a value of 0 for the first poll, because windows has not supplied new data.  Then the game receives the total of 2 of it's expected polls at it's next poll.  So in effect the game can accept a change of 15 on each of it's polls before it rolls over, but windows is limiting this to 7.  Sorry I can't explain it any simpler then that.

Actually I think I might be beginning to understand why people think lo-res is better for not having backspin.  I think people are taking their 96 resolution spinners and setting the MAME analog sensitivity to 25% or so and saying, "Hey, now it does not backspin.  I fixed it!"

That is not the case.  If you are setting it to anything lower then 75%, you are in effect gearing the spinner down.  At 25%, you are now spinning the control 1/3 the speed of the original control and not moving as fast as the real control would spin.  If you set the 1200 hi-res spinner to 2%, they would now both be behaving the same again.  But you did not fix the backspin issue.  You are only masking it by turning slower.

Lets put this another way.  If you hack the ROMs in the original game, tell it to always use a data of 0 for the first sample and then use the accumulated value of 2 samples for the second sample, then the original game (not emulated) would have the same backspin issue as we are seeing in an emulated game with a poll rate of 125Hz.

Someone is going to have filter all the info I've supplied in the 3 different spinner topics where we have been discussing this issue and turn it into readable lay-english for the wiki.   

D.

[RandyT]

My understanding was the USB 2.0 is backwards compatible with USB 1.1 in that if you plug a USB 2.0 device in to a USB 1.1 hub or port that the USB 2.0 device will act like a USB 1.1 device?   How is including USB 2.0 compatibility sacrificing compatibility if this is the case?

This is not always true.  I have seen instances of where even the *backward* compatibility of some 2.0 systems has not worked as expected, and required a change in the firmware to accommodate it, where that same device worked flawlessly on a 1.1 system. 

One might be able to get around things by using a 2.0 hub on a 1.1 system and let the hub do the re-negotiations, but at that point, you might as well install a new USB card.

RandyT

[Derrick Renaud]

BTW, to diverge a little, the whole optical encoder (tooth) count being counted on each of the 4 edges by modern encoder ICs is the reason most trackballs need to be scaled using a MAME analog sensitivity of 25%.

If your trackball is the same size as the original trackball and has the standard 24 teeth, then it needs to be scaled to 25%.

D.

[RandyT]

BTW, to diverge a little, the whole optical encoder (tooth) count being counted on each of the 4 edges by modern encoder ICs is the reason most trackballs need to be scaled using a MAME analog sensitivity of 25%.

If your trackball is the same size as the original trackball and has the standard 24 teeth, then it needs to be scaled to 25%.

Interesting.  Someone should probably tweak that one somehow as well.  Regular 24 tooth trackballs are poor when you try to use them as a mouse because they go so slow.  This makes upping the hardware resolution very attractive, which would require lower sensitivity settings.  And one thing MAME lacks severely, is tweakability at the low end of the sensitivity scale.  How about adding some tenths to the sensitivity settings?  Not very useful at the +100 levels, but very useful below.

RandyT

[Derrick Renaud]

Some final thoughts/rant.  The goal of all this is to get your arcade control to behave as close as possible to the original control.  If you believe that lo-res is close enough, then I have a VHS player in the basement you can have as trade for your DVD player.   

Seriously, if you play and like Arkanoid (and other games), you can not use a low res spinner.  There is no way you can master hitting the ball on the paddle exactly where you want.  A lo-res spinner just will not move in single pixel increments across the screen unless you are turning it further then the original control.  Thereby not getting the original experience of the game.  Which really is the goal of this forum.

There is no way you can play Clowns and similar potentiometer based games with a low-res control for the same reason.  Even Tempest is noticeably better with a hi-res spinner.

CD audio is sampled at 2x your hearing range for a reason.  Your control should be either 100% the same resolution or at least 2x more then the original.  96 lo-res is not 2x the Tempest 72.  Just like the emulated poll rate should be 2x the fastest game game poll rate.  Which is why I recommend 500Hz.

Knob diameter also has an effect on the game experience, but you should not adjust the full turn count/MAME analog sensitivity to compensate.  You really need a knob close to the diameter as the original game if it bothers you.  I allways find myself grasping the knob to turn on slow parts of a game or games like Clowns/Arkanoid.  Then I find myself rolling my thumb against the edge of the knob during faster gameplay.  The only way you can have both is with the original full turn count and a similar sizes knob, or get used to play with the new knob.

Just a disclaimer... I have no interest in selling hi-res spinners.  I am just stating my opinion based on my emulation experience.

[Derrick Renaud]

And one thing MAME lacks severely, is tweakability at the low end of the sensitivity scale.  How about adding some tenths to the sensitivity settings?  Not very useful at the +100 levels, but very useful below.

Thought about it but it would be a hard sell to the rest of the team.  It would involve increasing the values from the current single byte.  Then you would also need to modify the UI to add direct entry of the value.  It would take forever to just use arrows.  But really both should be added.  The only way to sell the change to the team would be to also add the direct numeric entry.

I also think an XML based help system should be added to the UI.  And an XML based control name override.  But now we are really getting off topic.

These are all things some bored programmer could add to MAME.  Anyone out there who does not really know anything about emulating a game, but knows how to program, up to the challenge?

Well, I'm off to look at the MAME input code.  I imagine it's changed quite a bit since I last looked at it.

[RandyT]

Thought about it but it would be a hard sell to the rest of the team.  It would involve increasing the values from the current single byte.  Then you would also need to modify the UI to add direct entry of the value.  It would take forever to just use arrows.  But really both should be added.  The only way to sell the change to the team would be to also add the direct numeric entry.

Ok, I actually typed this earlier and then erased it .

How about an "Decrease" / "Increase" toggle, that when clicked, used the full 255 (8-bit) values for each?  This would give a granularity of about .4% which is better than twice the current 1%.

No direct entry required, and it wouldn't take any longer to scroll through   

RandyT

[AndyWarne]

Andy, have you tried the mouserate program available here: http://mas0ne.servegame.com/mousepolling_rate_vista?

Can you test your interfaces on Vista64 SP1 with it and confirm you get faster then 125Hz? 

I understand what you are saying that your devices are not locked, but that does not mean that you can use them at a faster rate then Microsoft has decided to allow you to.

I would not doubt that MS deliberately does this, so other vender's can sell their mice with drivers that magically allow higher poll rates when they pay for driver signing.

Derrick, there is no need to use this program with the full-speed devices because Windows does follow the poll rate set in the device descriptor.
I can observe this on a USB bus analyzer. Its clear to see that the device is being polled at 2ms intervals as the descriptor requests.
Low speed devices always get polled at 7ms intervals no matter what the descriptor says.

Focusing on the device within Windows (as opposed to Mame where, as you mention there are other issues), I can say that during product development I have found that its very easy to max-out the 127 increment on a low speed interface with a 1200 pulse spinner. I dont disagree with your calculations but in practice it easily happens with a fairly modest spin, the kind of spin which you might do when moving from one side of the screen to the other. I think the RPM attainable is probably higher than you might think.
Using an older low-res Slikstik spinner connected to a low-speed interface its impossible to reach the maximum but with a Spintrak its easy, hence the need for increasing the poll rate, packet length (ie with a full-speed interface) or at least preventing "roll over" to a negative value.

[Derrick Renaud]

Derrick, there is no need to use this program with the full-speed devices because Windows does follow the poll rate set in the device descriptor.

The program is just an easy test program.  It does not change anything.  It would just confirm that windows is not doing anything between the USB port and when DirectX/RAWmouse gets the data.  IMO just because the analyzer says so, does not mean windows does not screw with the data and dole it out as it sees fit.

If you could just please run it and confirm that Vista64 really is outputting the 500Hz rate you have specified in the descriptor.  Thanks.  Other OSes may work fine, but Vista64 does what Vista64 wants to.

Low speed devices always get polled at 7ms intervals no matter what the descriptor says.

So then the Opti-Pac is a low speed device which is then locked to 125Hz in Vista64?

If so, do you have plans on making a version that allows a 500Hz poll rate in Vista64?

Thanks,
D.

[Bender]

ok you guys had me thinking I was crazy
as I said several times I undersand the theory, I repeat I understand the theory

I got my Apache spinner out it has only has a resolution of 48 and checked the poll rate which is 125Hz (window standard)
I set arkinoid so that one pass across the screen is between 120 and 130 degrees (mame analog sensetivity set to 20)
It works, but you are right it is just sightly choppier, but man you really have to look for it, and is certainly playable (though given I'm not an expert)
In Tempest I saw no difference at all
so I'm not crazy
I don't pretend to know the mechanics of it but it just works.

and Derrick you are right about the backspin, it is harder to get but when I set up the apache spinner in tempest, again the poll rate is 125Hz, there is backspin, never noticed it before cause it is so hard to do, unlike the Hi-res spinner before the patch

I'm not poo-pooing the Hi-res spinner at all
now that I have it fixed I'm very happy with it
I just think the regular resolution spinners (by that I mean everything under 100) are getting a bad rap
and the advantages of the hi-res spinner seem minimal (and moot to me since I don't even play arkinoid)
I was going to post some video but I think the lo-res of you tube WOULD be an issue with the video
in fact you couldn't tell the hi-res and the apache apart on video that small

[Derrick Renaud]

First it seems I must apologize to Bender, he and Andy are right.  A hi-res spinner locked by windows at 125Hz will backspin.  The numbers must lie.  Even though I can't fathom how you can spin it quicker then 13 times per second to cause backspin, it seems the initial acceleration of the spinner will overflow.

 

Also, I tried my fix, and found it won't make a difference, because it seems after the input system rewrite of around version 0117, MAME now only polls the OS at 40Hz.  It smooths out the data, like I planned, from there.

So it all goes back to the original fix.  There needs to be a way to unlock Vista64 to support 500Hz with current hardware.  But failing that, if the fix is through a piece of hardware, then so be it.

Let's see an Opti-Pac 2 or Opti-Wiz 2.

Well I'm off to setup an XP/Vista Dual boot.  Maybe I should have tried to buy XP64 instead of Vista with the new computer. 

[Derrick Renaud]

 

Well I drank a couple beers and figured it out.  Vista 64 SP1 can be patched to do 500/1000 Hz.

The hidusbf mentioned here did not work for me.  So I mixed and matched some stuff on the net and came up with this hopefully easy to follow guide.

Download dseo12.exe, mouserate.exe and dimr.exe from here.

dimr & mouserate both do the same thing.  They show the mouse poll rate.  Try both and see which you prefer.

Download the "Vista USB Poolrate.7z" USB driver from here.

Download RemoveWatermark_20090117.zip.

Then follow these directions:

1. Copy dseo12.exe to the desktop.  Trust me, you'll want it there when you lock up your mouse.

2. Copy the usbport.sys file for the refresh rate you want to c:\

3. Run dseo12.exe and Enable Test Mode.

4. Restart the computer, press F8 repeatidly while booting to get to the boot menu. Run Safe Command Prompt mode.

5. You will probably be in the c:\windows\system32 directory so type "cd drivers".  Make sure you are at the c:\windows\system32\drivers prompt.

6. execute this command:   takeown /f usbport.sys

7. execute this command:   cacls usbport.sys /G username:F

** Replace username with your username.  Use quotes around it if your name has spaces in it.  If you have changed your original user name, for some reason you have to use the name you installed Vista with.  Can't remember?  Check c:\users - there will be a directory there with the name you need.

5. You should still be in the c:\windows\system32\drivers directory.
   execute this command:   ren usbport.sys usbport.old

6. execute this command:   copy c:\usbport.sys

7. Ctrl-Alt-Delete.  Lower right corner - Restart Windows

8. What the hey?? No mouse.  Hit Alt-Tab to select the desktop.  Use the arrows to select dseo12.exe that you put on the desktop.  Enter to run it.  Navigate with Tab and arrows as needed to finally select "Sign a system file".  Tab to select "Next" then enter.  Type "c:\windows\system32\drivers\usbport.sys" and then enter.  Now restart the computer from the windows key.  You don't need to close the program.

9. Your mouse now works.  Run mouserate.exe and/or dimr.exe to verify that you now have a 500/1000Hz polling rate.

10. Yes, it now says Test mode on your screen,  Get over it.  Or run removeWatermark_20090117.

[Bender]

 

I can't seem to download the file though

[Derrick Renaud]

I can't seem to download the file though

Hmmm.. I don't know what to do.  I tried shrinking the file and re-naming it but you are right, it will not download.  One of those days where nothing is working right.

Give me a few minutes and I will put links to the original files.

OK. I modified the post using links to the files.  Not as easy but it is all there.

[Derrick Renaud]

To finish up this mess....

XP users have a much easier time switching their poll rate.  Just go here.

[RandyT]

Congrats, Derrick.  I had a feeling you would get it working eventually.  It even looks like you found a unique way to get it done.  Too bad there isn't some way to automate the steps...I'm guessing Vista makes something like that impossible.

Great job  and thanks loads for doing the step by step.  I'm sure it will be plenty appreciated by those adopting Vista x64.

RandyT

[RandyT]

I got my Apache spinner out it has only has a resolution of 48 and checked the poll rate which is 125Hz (window standard)
I set arkinoid so that one pass across the screen is between 120 and 130 degrees (mame analog sensetivity set to 20)
It works, but you are right it is just sightly choppier, but man you really have to look for it, and is certainly playable (though given I'm not an expert)
In Tempest I saw no difference at all
so I'm not crazy
I don't pretend to know the mechanics of it but it just works.

Bender, I know you say you don't care much for the Arkanoid games, or those similar to it, but trust me when I say that they are big reasons why people opt to get spinners in the first place.  I would estimate that at minimum, 70% of the folks who buy them, want realistic gameplay for those types of titles (and others, of course.)  Tempest has very low requirements, which is why you need to crank the sensitivity all the way down to 6 for the TurboTwist 2 / High-Low.  So I absolutely agree that if folks are looking primarily to play that game, and / or those with similarly low requirements, then find a good deal on one of the older tech models and enjoy. 

But understand that cutting the possible paddle positions to almost 1/3 of those available in Arkanoid, will severely impact playability.  The ball bounces off that paddle in different directions based on where it strikes it, and if you don't have fine control, you can't always put that ball where you want it to go.  It's more than just a visual choppiness issue.  When you play other games, for instance one like Avalanche, where the paddle and the falling objects get increasingly smaller as the game progresses, this precision becomes even more important.

BTW, with that low res spinner, you should have been looking at a sensitivity of about 244, but you said 20 above.  Was that a typo?


RandyT

[AndyWarne]

My understanding was the USB 2.0 is backwards compatible with USB 1.1 in that if you plug a USB 2.0 device in to a USB 1.1 hub or port that the USB 2.0 device will act like a USB 1.1 device?   How is including USB 2.0 compatibility sacrificing compatibility if this is the case?

This is not always true.  I have seen instances of where even the *backward* compatibility of some 2.0 systems has not worked as expected, and required a change in the firmware to accommodate it, where that same device worked flawlessly on a 1.1 system. 

One might be able to get around things by using a 2.0 hub on a 1.1 system and let the hub do the re-negotiations, but at that point, you might as well install a new USB card.

I think you are still getting confused. Full Speed USB is not specific to USB 2.0. This was in the original USB 1.1 standard. There is no compatibility issue.

A device which runs only FS USB is not any different between USB 1.1 and USB 2.0. The device only becomes different when its capable of running High Speed USB which is specific to USB 2.0

Don't take my word for it, check the USB 2.0 spec. Page 122, table 7.1:

Low-/full-speed Driver:  The low-/full-speed driver is used for low-speed and full-speed transmission. It
is required to meet all specifications called out in USB 1.1 for low-speed and fullspeed
operation.

The possible compatibility issues you are referring to might be from devices which are capable of running High Speed USB (480 Mb/s) and are not working properly on a 1.1 host which cannot run High Speed USB. This is not relevant on a device which only runs Full Speed USB (12 Mb/s) or Low Speed USB (1.5 Mb/s).
There is no more likelihood of a Full Speed device being incompatible with a USB 1.1 host than a Low Speed device.

[AndyWarne]

If you could just please run it and confirm that Vista64 really is outputting the 500Hz rate you have specified in the descriptor.  Thanks.  Other OSes may work fine, but Vista64 does what Vista64 wants to.

Screenshot:



Our full-speed devices include:
I-PAC 2
trackball interface
spinner interface
U-HID
U-HID nano

The Opti-PAC is low-speed as we have not updated it owing to serial compatibility. We plan to discontinue serial support in a couple of months as we hardly ever get asked for it, then it will be full-speed.

Andy

[RandyT]

I think you are still getting confused. Full Speed USB is not specific to USB 2.0. This was in the original USB 1.1 standard. There is no compatibility issue.

A device which runs only FS USB is not any different between USB 1.1 and USB 2.0. The device only becomes different when its capable of running High Speed USB which is specific to USB 2.0

Don't take my word for it, check the USB 2.0 spec. Page 122, table 7.1:

The spec is the spec.  Individual implementations are a different story.  How many folks here have had issue with USB encoders made for 1.1 on 1.1 machines?  It happens over and over again, when it probably shouldn't, according to the spec.

Regardless, if what you are saying is true, then you have established publicly that there is no advantage whatsoever to a "USB 2.0" spinner, and that those claims are pure "marketing fluff".  We have already established that the only functional difference with a non-high-speed device is the need to install a widely used and well tested driver on some OS's, which can yield a poll rate for that device which is twice that of the "USB 2.0 hardware"....if the user desires. 

Or, have I misunderstood?

RandyT

[Derrick Renaud]

Centipede has never played well

This has been a common complaint and I would like to hear more from owners of an actual cabinet or those that have access to one.

First thing I noticed in the code is that it internally scales to input by 4.  So even though you would normally set a trackball to 25% MAME analog sensitivity, you don't do that for Centipede.  Centipede should be at 100% if you are using the same 2.25" trackball.

What I would like to know is how the original game plays is you swap in a 3" trackball.  Would it play the same as MAME at 100% sensitivity?  At 100% Mame seems to slow/backspin if you move fast.  But regular game play is more responsive.

I know the numbers failed me on Hi-res backspin, but lets see how the numbers work for centipede.

First we can assume a 2.25 trackball would be set to 100%, so lets convert the circumference values.  2.25PI/3PI = .75 = 75% sensitivity.

Seems quite responsive for regular gameplay.  But moving the trackball fast can still cause lag.  Is this because you can more easily move a larger trackball faster? 

So i guess we need to know how the newest MAME plays with 100% sensitivity on a real Centipede 2.25 ball.  What happens when spun fast?

It would be nice to see good video of the player movement on a real machine when the player is spun quickly from one side to the other with both 2.25" and 3" trackballs.

[RandyT]

It may be time for a "Fixing Centipede Control" thread

First thing I noticed in the code is that it internally scales to input by 4.  So even though you would normally set a trackball to 25% MAME analog sensitivity, you don't do that for Centipede.  Centipede should be at 100% if you are using the same 2.25" trackball.

Let me be the first to say that most aren't using 2.25" trackballs. A sale of one is a bit of an anomaly for us.  If a builder has space for a 3-incher (and they aren't much larger than the 2.25", BTW) in it goes.

So this is probably significant.

First we can assume a 2.25 trackball would be set to 100%, so lets convert the circumference values.  2.25PI/3PI = .75 = 75% sensitivity.

I don't have an original Atari 2.25" unit in front of me, but I can tell you that it may not be that straight-forward.  The Imperial variety  2.25", which I will assume is the same for "parts swapping" reasons, has a different diameter roller internally.  It is 1/16" larger in diameter, which means that the action is geared down even further than just as a result of the smaller ball.  Exactly the opposite action one would expect.

Seems quite responsive for regular gameplay.  But moving the trackball fast can still cause lag.  Is this because you can more easily move a larger trackball faster? 

Quite possible, but I'm not sure that is the issue.  I used to play a fair bit of Centipede "in the day" and recall a much more "real-time" feel.  Pretty much like a mouse pointer.  Moving from one side of the screen to the other is normally very fast, and necessary to play the game well.  For some reason, when trying to do this in MAME, I recall it being more of a "capped speed" sensation, where the maximum wasn't sufficient.

So i guess we need to know how MAME plays with 100% sensitivity on a real Centipede 2.25 ball.  What happens when spun fast?

It would be nice to see good video of the player movement on a real machine when the player is spun quickly from one side to the other with both 2.25" and 3" trackballs.

I'll see what I can do about the 2.25" test, but here's one that I was able to pretty much verify wasn't a video of someone playing MAME.  Something which is difficult to do when searching.  It seems to have a "snappiness" in movement that differentiates it.

[youtube]http://www.youtube.com/watch?v=wbM2XaR3tXQ[/youtube]

[Derrick Renaud]

It may be time for a "Fixing Centipede Control" thread

First we can assume a 2.25 trackball would be set to 100%, so lets convert the circumference values.  2.25PI/3PI = .75 = 75% sensitivity.

I don't have an original Atari 2.25" unit in front of me, but I can tell you that it may not be that straight-forward.  The Imperial variety 2.25", which I will assume is the same for "parts swapping" reasons, has a different diameter roller internally.  It is 1/16" larger in diameter, which means that the action is geared down even further than just as a result of the smaller ball.  Exactly the opposite action one would expect.

Good point.

Thanks for the video.  That actually shows the problem quite well.  I had youtubed up a few videos, but no one was moving their player around as fast as that.  So then yes, it looks like Mame has a problem.  So I don't really need to see any other video.

I'll see if I can do anything.  But from first look at the code, it seems that the trackball port handling should be OK.  And the port is read from the CPU directly, so maybe an IRQ issue or  , but I'll look.

[Morpheus]

I read this whole thread, but I still have two questions. Which spinner is better? or are they both good products?  Could people who have on or the other (Or both) just give their experience with their spinner...

Thanks!

[RandyT]

I might as well add something to this thread now that it has re-surfaced.  As a result of the discussion with Derrick about how MAME handles input, the TurboTwist 2, High-Low, EIectric ICE Trackball and all other optical interfaces shipping from GGG are now backspin-free, with no changes whatsoever required by the user to the OS.  In order to maintain the high-speed polling of the optical sensors, I opted against having this as a user-configurable option.  It is automatically disabled by systems with higher poll rates enabled anyway.

Based on the way MAME deals with input now, capping the outputs has a practical zero negative effect, and high polling rates have a practical zero positive effect.  An 8ms poll rate at +/-127 position offsets is extremely fast movement (about 13 revolutions per second before backspin would occur!), and is impossible to maintain by a human hand or ever be an issue while playing.  The only time an overflow would really come into play is at the moment of initial acceleration when one really tried to "flick" the knob to spin it fast.   Derrick has been telling me, if I am understanding correctly, that MAME doesn't actually poll the hardware but once every 16ms, or once per frame refresh. In cases where the original hardware expects smaller chunks of data to be received more frequently, MAME then divides up the movement data it received at the last poll and then uses a sort of smoothing algorithm to feed the data to the original code at a rate it would expect.  It should also be noted that there is no way for any spinner interface to prevent backspin at the level of the actual game.   This is strictly a function of the interaction between MAME, the OS and the original game code / hardware emulation.  In other words, if you could make the original game backspin, as you could with Tempest, then you would be able to do it no matter which spinner you used.  Otherwise, you would not have true emulation.

So the short of it is that, once the outputs are capped to prevent overflow at the initial moment of inertia when spun rapidly, extremely high poll rates are of questionable benefit.  But upping the poll rate in the OS is still an option and will make it so the capping never kicks in, if one so desires.

RandyT