Main > Main Forum
Suzo- Happ PC Arcade Spinner? Plug and Play?
RandyT:
--- Quote from: AndyWarne on February 28, 2009, 05:59:22 am ---You are getting confused betwen USB 1.1, USB 2.0 and low speed USB vs full speed USB.
A device does not need to be USB 2.0 to overcome the in-built Windows poll rate. It needs to be full-speed USB rather then low-speed USB.
Full speed USB devices work perfectly well with USB 1.1. There is no compatibility issue at all.
--- End quote ---
Not at all. As a matter of practicality, most decent full-speed chip offerings today are USB 2.0 based.
--- Quote ---It is correct that the high resolution of the spinner brings benefits which is why we went with 1000 pulses on the original SpinTrak, the first high-res spinner on the market....
--- End quote ---
Actually, the first high res spinner was the original TurboTwist. It was doing full Arkanoid resolution before Ultimarc even had an offering....
Derrick Renaud:
--- Quote from: Bender on February 27, 2009, 10:57:28 pm ---
--- Quote from: Derrick Renaud on February 27, 2009, 09:16:09 pm ---Also don't confuse poll rate and hi-res spinners. They are 2 different issues. You do not need a high poll rate to use a Hi-res spinner. Just adjust MAME's analog sensitivity. It will work fine in arcade games that do not have a poll rate higher then your current spinner poll rate.
--- End quote ---
They are two different things but integrally related when the spinner is such a hi resolution it polls at a rate higher than MOST Mame games it effectively makes it the same issue
--- End quote ---
Hopefully you do know that I have more then a passing knowledge of MAME's input code, as I helped write some of it. And I know something about how arcade hardware works. But you are entitled to your opinion of why backspin happens, so let me run these numbers by you.
Say a mouse interface is 8-bit and not the newer 16-bit. This means it can update at max +127/-128 each poll. Windows is locked at 125Hz. The spinner has a 1200 per revolution rate. That gives us:
127*125/1200 = 13.2 turns per second or *60 for 793 RPM. Do you really think you can spin it that quick to make a high resolution spinner overflow? Maybe, just a small maybe, you could get enough acceleration at the start of the spin to overflow for a few samples. But you would really have to be trying and it would not happen in any regular game play.
So hopefully that backs up my original statement. I am not trying to win the argument, just trying to clear up the multiple issues that cause backspin.
If you adjust the MAME analog sensitivity so it scales the hires spinner to the same counts per revolution (PORT_FULL_TURN_COUNT in MAME code) as the original game's control, then using a Hires Spinner locked at 125Hz poll rate is not the cause of the backspin.
The fault goes back to what I described in the other post:
http://forum.arcadecontrols.com/index.php?topic=89658.msg944272#msg944272
Notice I also state there that 125Hz is lower then what MOST Mame games poll at. At least the most complained about backspin issue games. You are still confusing poll rate and the amount of accumulated data per poll. 2 completely separate things that look like the same backspin issue to a player. Both have different fixes. They combine like you say only when the windows poll rate is lower then the emulated games poll rate. Which means the issue is still Windows locking the poll rate at 125Hz. Not the fact that you are using a Hi-res spinner. You will still have the problem with a lo-res spinner that is scaled to supply the proper full turn count.
Now I just have to get off my lazy a** and code my described fix. Which I stated should help but is no replacement for getting the poll rate to 500Hz.
BTW, just so you know where the 6% sensitivity comes from for Tempest. Tempest has a PORT_FULL_TURN_COUNT of 72, meaning the original control and interface supplied 72 counts per 1 full turn. To use a 1200 count spinner we need to do 72/1200=0.06 or 6%. It's mathematical magic. ;D
Derrick Renaud:
--- Quote from: AndyWarne on February 28, 2009, 05:59:22 am ---This is never an issue with full-speed USB as we can have a 16 bit packet which will never max out, even with the standard poll rate. But the icing on the cake is we can increase the poll rate in the device as well without any Windows tweaks.
--- End quote ---
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? You should also be able to test on an unpatched XP.
The opti-pac is not locked, but even on XP, you can not use it faster then 125Hz without patching the poll rate with one of the hacking programs available.
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.
Bender:
--- Quote from: Derrick Renaud on February 28, 2009, 10:13:24 am ---
--- Quote from: Bender on February 27, 2009, 10:57:28 pm ---
--- Quote from: Derrick Renaud on February 27, 2009, 09:16:09 pm ---Also don't confuse poll rate and hi-res spinners. They are 2 different issues. You do not need a high poll rate to use a Hi-res spinner. Just adjust MAME's analog sensitivity. It will work fine in arcade games that do not have a poll rate higher then your current spinner poll rate.
--- End quote ---
They are two different things but integrally related when the spinner is such a hi resolution it polls at a rate higher than MOST Mame games it effectively makes it the same issue
--- End quote ---
Hopefully you do know that I have more then a passing knowledge of MAME's input code, as I helped write some of it. And I know something about how arcade hardware works. But you are entitled to your opinion of why backspin happens, so let me run these numbers by you.
Say a mouse interface is 8-bit and not the newer 16-bit. This means it can update at max +127/-128 each poll. Windows is locked at 125Hz. The spinner has a 1200 per revolution rate. That gives us:
127*125/1200 = 13.2 turns per second or *60 for 793 RPM. Do you really think you can spin it that quick to make a high resolution spinner overflow? Maybe, just a small maybe, you could get enough acceleration at the start of the spin to overflow for a few samples. But you would really have to be trying and it would not happen in any regular game play.
So hopefully that backs up my original statement. I am not trying to win the argument, just trying to clear up the multiple issues that cause backspin.
If you adjust the MAME analog sensitivity so it scales the hires spinner to the same counts per revolution (PORT_FULL_TURN_COUNT in MAME code) as the original game's control, then using a Hires Spinner locked at 125Hz poll rate is not the cause of the backspin.
The fault goes back to what I described in the other post:
http://forum.arcadecontrols.com/index.php?topic=89658.msg944272#msg944272
Notice I also state there that 125Hz is lower then what MOST Mame games poll at. At least the most complained about backspin issue games. You are still confusing poll rate and the amount of accumulated data per poll. 2 completely separate things that look like the same backspin issue to a player. Both have different fixes. They combine like you say only when the windows poll rate is lower then the emulated games poll rate. Which means the issue is still Windows locking the poll rate at 125Hz. Not the fact that you are using a Hi-res spinner. You will still have the problem with a lo-res spinner that is scaled to supply the proper full turn count.
Now I just have to get off my lazy a** and code my described fix. Which I stated should help but is no replacement for getting the poll rate to 500Hz.
BTW, just so you know where the 6% sensitivity comes from for Tempest. Tempest has a PORT_FULL_TURN_COUNT of 72, meaning the original control and interface supplied 72 counts per 1 full turn. To use a 1200 count spinner we need to do 72/1200=0.06 or 6%. It's mathematical magic. ;D
--- End quote ---
First of all Thank you for your work on Mame :notworthy: :notworthy: :notworthy:
and for the informative debate
I did do some research in all of this and was aware of the mathematical magic that got Tempest to sensitivity of 6
and thanks to your post I do have a better understanding of the situation
and like you I'm not trying to win an argument but get to the bottom of the issue
so before I patched the OS poll rate when I played tempest with the hi-res spinner and did a hard spin to move around quickly it moved in the other direction first then went the right way, is that not backspin? Maybe that is just how I play but it didn't do that in the arcade, it didn't do that with a regular resolution spinner, and it didn't do that after the poll rate was patched.
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?
Hence my issue with the Hi-Res spinners
and now after reading Randy's post I can see if your using it as a steering wheel where the Hi-Res would be an advantage
although I don't agree with the first part in practice (I understand it in theory) Arkinoid works fine for me with a regular resolution spinner
RandyT:
--- Quote from: Bender on February 28, 2009, 12:22:53 pm ---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?
Hence my issue with the Hi-Res spinners
and now after reading Randy's post I can see if your using it as a steering wheel where the Hi-Res would be an advantage
--- End quote ---
I think the biggest misconception is that you believe there is a "standard resolution spinner". Before SlikStik and Apache decided to make theirs, OSCAR controls had several different varieties with different resolutions. Before that, folks were hacking mice with whatever they could muster. And long before that, each arcade manufacturer decided upon a specific piece of hardware and decoding method to do what they wanted for a particular game. The only way to support all of the games well, which most want to do because A) good spinners aren't cheap, and B) there are only so many games that support their use, is to have a resolution that is high enough to feed the proper amount of data to the game based on original requirements, optionally taking knob size variations into consideration.
Derrick is stating that some games, like the very popular Tempest, have hardware that is significantly different enough that backspin is still far more likely than it would be otherwise due to the way it collects data. He has a very interesting solution to the situation, that will hopefully help other titles with similar hardware. Centipede has never played well, something like a trackball emulating joystick input, and I would love to see if this approach helps to fix the long standing issue.
And if all you got out of the explanation I posted earlier is that "Hi Res is only an advantage as a steering wheel" (paraphrased), then I apparently failed to explain it well enough.
RandyT