Main > Main Forum
turbotwist 2 choice - USB vs PS/2
AndyWarne:
If we consider a 10ms poll rate and ignore any processing overhead, and assume that the maximum displacement data per packet is 128, this gives a maximum pulse rate of 12800 per second.
So, with a 1200 PPR spinner, this means that the theoretical top speed of the spinner will be 10 revs per second.
In practice it would be less because of overheads. But this should not cause backspin unless incorrect data is being sent.
Incorrect data could be sent if the interface buffer is not prevented from counting more than 128 pulses. This can be prevented by logic in the code.
In PS/2 mode the interface spends a large amount of time actually sending the packets becasue they are not sent by a dedicated engine. This means that it is probably sampling the encoder at a lower rate and missing pulses, so the buffer does not overflow, but the displacement data is sent at a lower rate so the pointer would be slower. So even without overflow protection no backspin occurs.
RandyT:
--- Quote from: AndyWarne on February 02, 2007, 03:36:19 pm ---If we consider a 10ms poll rate and ignore any processing overhead, and assume that the maximum displacement data per packet is 128, this gives a maximum pulse rate of 12800 per second.
So, with a 1200 PPR spinner, this means that the theoretical top speed of the spinner will be 10 revs per second.
In practice it would be less because of overheads.
--- End quote ---
Ok, that's a better number to play with. Even 6 would be very good in this instance as it is beyond human capabilities and well beyond what could be considered reasonable use in a gameplay application. However, if you try to make it happen by applying a substantial moment of inertia that is beyond what is reasonable, you will succeed.
--- Quote ---But this should not cause backspin unless incorrect data is being sent.
Incorrect data could be sent if the interface buffer is not prevented from counting more than 128 pulses. This can be prevented by logic in the code.
--- End quote ---
Incorrect data, the textbook result of a buffer overflow, BTW, is incorrect data regardless of the form it takes. If you insert code at every increment or decrement of the buffer to prevent the overflow from occurring, you are just discarding transition data, which still makes it wrong. The only thing checking for that condition at every transition does is waste precious processing cycles that could cause real accuracy problems. It's a pointless exercise as the net gain is null. However, if the goal is to hide the occurrence of the phenomena, rather than fix the underlying cause, it would succeed in doing that.
--- Quote ---In PS/2 mode the interface spends a large amount of time actually sending the packets becasue they are not sent by a dedicated engine. This means that it is probably sampling the encoder at a lower rate and missing pulses, so the buffer does not overflow, but the displacement data is sent at a lower rate so the pointer would be slower. So even without overflow protection no backspin occurs.
--- End quote ---
This paragraph contains a lot of conjecture and assumptions. Even if the PS/2 code were sampling at a lower speed (I'm not saying that it isn't,) it does not dictate a problem condition. Issues would only arise if the sampling speed were inadequate. Anyone who has written this type of code understands the importance of interleaving the sampling routines with the PS/2 communication routines.
And this scenario doesn't add up. Missed pulses (transitions) means big problems when using state-based quadrature decoding. If you miss a read (or two) you get states that would almost guarantee backspin, or at minimum, very erratic movement of the cursor. Neither of those things occur, so obviously transitions are not being missed.
RandyT
spelosi:
I have found that PS/2 works a lot better. USB was causing some annoying backspin in tempest, even with the sensitivity lowered to 7% in mame, and acceleration turned off in windows.
I'm much happier with PS/2. I love this spinner!
RandyT:
--- Quote from: spelosi on February 06, 2007, 10:45:51 am ---I have found that PS/2 works a lot better. USB was causing some annoying backspin in tempest, even with the sensitivity lowered to 7% in mame, and acceleration turned off in windows.
I'm much happier with PS/2. I love this spinner!
--- End quote ---
I'm very pleased to hear that you are enjoying the unit. :)
Tempest is sensitive to having a lot of data thrown at it for some reason, more so than any other game. But 6% is the perfect Tempest setting for arcade authenticity (1200 x .06 = 72 , and a 72 spoke encoder used at 1x on the original control.) A +1% deviation in sensitivity seems like a small difference, but with the high resolution of the TT2, this translates to a ~17% increase in data sent to the game! Fortunately, Tempest is somewhat unique in this respect.
But if it feels good at 7% and PS/2 is getting the job done better for you, then that's cool too!
RandyT
rockin_rick:
So perhaps PS/2 is the preferred interface, as long as it's not needed for something else.
Is the ONLY difference between selecting PS/2 and USB the cable that is shipped? If so, can I order both cables? Perhaps that should be a choice on the product page...
Rick