turbotwist 2 choice - USB vs PS/2

[rockin_rick]

What is the difference between the USB and PS/2 'version' of the turbotwist 2?  Of course I understand USB vs PS/2 (I don't need an explanation of these), but why would I choose one or the other based on the operation of the TT2?

I'd rather use PS/2 as long as the performance is not worse than USB.  I guess I'm old school and have had too many 'issues' over the years with USB, and have never had any problems with PS/2.  I've also seen posts about others having issues with multiple devices getting assigned in random orders when connected and thus requiring reconfiguring in mame.

Does the TT2 work exactly like a USB mouse/seen by the PC as a USB mouse?

Can I get the USB version and use a USB to PS/2 adapter (that sometimes (or used to) come with USB mice - often green) if desired later?

IIRC, don't USB mice update faster than PS/2 mice?  Would this itself make USB a better choice?  Or does it not matter to the TT2 and either interface is equal in terms of performance?

Is the only difference between the USB version and the PS/2 version simply a different cable?  If so, can I get the USB version and also the PS/2 cable and interchange them at will?  Are there any firmware differences? 

I'm looking to be able to plug this in and have it Just Work.  If the USB connection will do that, then I'm all for it.  Otherwise, if the PS/2 is just as good, then I'd choose PS/2.

What interface did anyone else use?  Has it been problem free?

Thanks,
Rick

[AndyWarne]

I can comment on this with regards to our SpinTrak spinner which has a very high resolution, as does the TT2. The comment is probably valid for the TT2 as well. Basically USB is the way to go IMHO. Although our spinner is a dual-interface device I don't really sell it as a PS/2 device because the PS/2 interface just isnt fast enough to deal with the data rate from the high-res device. I would definitely recommend USB.
The multiple device problem should not be an issue as this only arises when you have several of exactly the same device connected, such as a pair of identical gamepads with the same USB ID.
Andy

[RandyT]

The TurboTwist 2 performs quite well using PS/2 with my test systems.

In fact, if I spin the TT2 really hard (many, many times harder than one would ever think of doing during gameplay)  I can get some backspin using USB.  It's not easy to do, but I can do it.

Strangely enough, I could not get backspin at all with the same extreme test when using the PS/2 interface.  This test was conducted at the Windows desktop, as it is one of the better places to get uniform testing conditions. 

I can't speak for other devices, but with the TT2, it's a matter of which interface suits your configuration the best, including how you intend to use it.  If you have swappable panels and don't want to reboot your system when you swap, USB will be the best choice.  If you have a fixed installation, where you won't be plugging and unplugging things all of the time, it's really up to you.  The TT2 interface is a true dual-interface control so if you change your mind, a simple passive (no electronics) plug adapter will let you switch to the other type.


RandyT


*edit*
It should also be mentioned that I most likely cranked up the PS/2 sampling rate to 200hz at some time in the life of my machines.  I don't see that setting in the current driver, but I have used it in the past.  If your driver doesn't have this option, there are programs out there to give you this boost.  200hz, BTW, is about twice the average report speed of "low-speed USB" mouse controllers.

More specific answers to your questions:

The TT2 is seen by the system as a mouse in PS/2 mode, just like in USB.  No fuss.

As stated earlier, you can use one of those "often green " plug adapters later.

When you plug it in, it will "Just Work", but with PS/2 you will probably need to do a re-boot.

We sell more USB than PS/2 versions.  There are a lot more USB ports on a computer than PS/2 mouse ports, so this probably has a lot to do with it

I refrained from jumping into your thread because it sounded like you wanted to hear from actual users of the product, but it seemed necessary.  Hopefully other users can add to, confirm or deny the info presented so you can get the info you are looking for.

[AndyWarne]

Backspin? Thats not good. I don't see how this can happen in a way thats attributable to the use of USB though. Lack of data throughput would cause a limit on the speed of movement rather than backspin.

[RandyT]

Backspin? Thats not good. I don't see how this can happen in a way thats attributable to the use of USB though. Lack of data throughput would cause a limit on the speed of movement rather than backspin.

Something has to give if information is being collected faster than the host system is processing the packets.  This rate defaults to ~100hz for low-speed USB devices.  It occurs at the interface level, but is caused by an overflow related to USB processing requirements and polling frequencies.

Do you really find it surprising that PS/2, which has far less overhead and polling at twice the speed of "low speed" USB, shows fewer anomalies?

Also don't forget, the TT2 has 20% more resolution than the next closest spinner.  That means 20% more data needs to be collected in the same time-frame and more is expected from every part of the processing chain.  This is why I don't make guarantees of performance when the TT2 is used with hardware not specifically designed for them.

As I have stated before, and as has been confirmed by actual users; TT2 gameplay at all levels, including those surpassing normal use, is perfect regardless of the interface used, so it's a non-issue. 

Do you really care if the tires on your Rolls-Royce burst into flames at 400 mph?   

RandyT

[AndyWarne]

Does it actually have a 300 PPR encoder? Most of the minature ones such as the Avago HEDR series are 200 PPR.
A standard 10ms poll rate would be a limiting factor at this resolution.

[RandyT]

Does it actually have a 300 PPR encoder? Most of the minature ones such as the Avago HEDR series are 200 PPR.

Yes, it actually does have 300, for 1200 actual transitions per revolution.  We are talking perfect DOH with enough left over to fix the feel of a larger than original sized knob.

There is not really a "default" poll rate for the USB device, it's whatever is specified in the descriptor.

I'm surprised that you don't already know this, but your statement is only half true.  "Low Speed" USB HID devices are throttled by a number of OS's, either intentionally, or due to marginal USB implementations.  There are hacks to up that speed on some OS's, or as used with expensive gaming mice, one can create custom drivers at the expense of standard HID compatibility.  There are also practical limitations imposed by the "work to be done" at the hardware level.

I would think that this resolution would need a 5ms poll rate otherwise the math indicates the maximum speed would be limited.

There is always a max speed limitation for any devices like these.  Please show your math so we can better discuss how you achieved that number and maybe we can relate that to "rotations per second" at a specific report rate, which is the real number of interest.

To anyone watching this discussion and not understanding what's being said:

This thread probably stopped being important to your gaming interests about 4 posts ago.  The current discussion is "academic" in nature, so feel free to tune out whenever you get bored.  My apologies to the OP.

RandyT

[2600]

"default" may be a poor word choice.  Per the USB Spec, 100Hz is the fastest poll rate low-speed devices can request.  where as the fastest full-speed devices can request is 1000Hz.  The Host can choose to poll faster, which Windows does and default's to polling at 125Hz for low-speed mice.

Usually, the backspin is caused because the poll rate is too slow and the buffer fills up.  There are 2 ways to alleviate this type of backspin.  I've never seen it caused by the Host not being able to process the packets.

1. Faster poll rate - Which can be accomplished two ways.
A. Patch Windows default Poll Rate, there are few software apps that do this and most low-speed mice don't have a problem with it.
B. Use USB full-speed, to get a faster poll rate from the Host.  Although, 1000 Hz would be insane and cause a lot of traffic to have to be processed by the host.  4 or 5ms would be a better choice to put in the descriptor for full-speed devices.

2. Larger output buffer.  Mice typically use an 8 bit buffer per axis, but I've heard of at least one low-speed mouse that uses a 16 bit buffer.  I haven't tested this so am unsure of the trade offs.


EDIT: Randy got in, before me.  You two type too fast for me to keep up.

[AndyWarne]

Too fast for me too. I edited my post but Randy got the pre-edit version quoted!
Absolutely correct of course. I was forgetting that I am dealing with full-speed devices right now (ie the Mouse portion of the Ultrastik 360) in which I can set the poll rate to whatever I want (but of course being sensible about the resulting overhead).

Andy

[RandyT]

The Host can choose to poll faster, which Windows does and default's to polling at 125Hz for low-speed mice.

This is the 2K / XP default.  As I understand it, other Windows versions are different.

Usually, the backspin is caused because the poll rate is too slow and the buffer fills up.  There are 2 ways to alleviate this type of backspin.  I've never seen it caused by the Host not being able to process the packets.

I was relating processing to USB overhead internal to the hardware as well as the polling.  The host can't process the packets if they aren't being sent.

1. Faster poll rate - Which can be accomplished two ways.
A. Patch Windows default Poll Rate, there are few software apps that do this and most low-speed mice don't have a problem with it.

This works, as long as a faster poll rate is specified in firmware.  But if the user's system is not patched, or the device is used on a different OS, that faster rate causes problems.  Not a great choice, IMHO.

B. Use USB full-speed, to get a faster poll rate from the Host.  Although, 1000 Hz would be insane and cause a lot of traffic to have to be processed by the host.  4 or 5ms would be a better choice to put in the descriptor for full-speed devices.

Agreed, were it actually necessary for proper operation of the device in question.

2. Larger input buffer.  Mice typically use an 8 bit buffer per axis, but I've heard of at least one low-speed mouse that uses a 16 bit buffer.  I haven't tested this so am unsure of the trade offs.

Larger buffers can store more data, but going to 16 bit buffers means quite a few more processing cycles at every transition.  I haven't tried this either, but my first impressions are that it could actually slow things down at the very important "data collection" phase.  Better to overflow the buffer in extremely unlikely circumstances than to miss transitions all the time.

RandyT

[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]

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.

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. 

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.

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.

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.

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]

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!

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

[RandyT]

So perhaps PS/2 is the preferred interface, as long as it's not needed for something else.

I don't think I would go that far.  Both interfaces will have their place depending on what is required by the installer. 

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...

The device is true dual, so yes and no.  The units are provided with the native connector for the type of interface selected, and the appropriate cable is provided.  However, I recently bought a bag of those green USB A female to PS/2 Male connector converters that should work fine for PS/2 operation on a USB configured device.  Once I test them out, I will add them to the store.

They are the same connectors you probably threw away when you got your mouse, so if you have one around, it will probably work fine. 
 
RandyT

[Zeppo]

Two Questions for RandyT:

1. I read in another thread about USB devices not getting the same ID, and that would throw MAME off so that a guy had to re-set it each time, or something like that.
Is this really a problem? Like if I had a USB trackball and got the USB TT2?


2. Any chance of you working on a push/pull version of the TT2 for Discs of Tron?


Thanks!

[RandyT]

Two Questions for RandyT:

1. I read in another thread about USB devices not getting the same ID, and that would throw MAME off so that a guy had to re-set it each time, or something like that.
Is this really a problem? Like if I had a USB trackball and got the USB TT2?

As long as the devices are physically different, then there would be no device swapping issues.  The only exception to this is the original TurboTwist and TT2.  These both use the same ID's for each device number, so if for some reason you are using an original TT and a TT2 on the same panel, you need to use different device numbers.

2. Any chance of you working on a push/pull version of the TT2 for Discs of Tron?

There's a chance    But seriously, this one is off a ways if it ever happens.  I have something on paper that is totally untested so I can't say yes or no, and won't know until I get prototypes, etc...  It would also be a totally different device at a different price point.

RandyT

[FrizzleFried]

Randy - What is the chance of you putting together a list of popular spinner games with the correct sensitivity setting so us TT2 customers can set our cabinets up as close to arcade authentic as possible??!?

[RandyT]

Randy - What is the chance of you putting together a list of popular spinner games with the correct sensitivity setting so us TT2 customers can set our cabinets up as close to arcade authentic as possible??!?

There are a couple of problems with this.  The first one is that this info barely exists.  Derrick Renaud asked for some help in compiling this info a while back, but I think he only came up with a couple of games worth.

The other issue is that the size of the knob (settle down) plays a big part in the feel of the game.  If you have a knob that is considerably larger than the original one used, the feel won't be the same unless you increase the sensitivity proportionately.  Therefore, to accurately replicate the feel of the original game, you need the following information:

A: The number of apertures of the original control
B: The knowledge as to how the game translated those apertures (1, 2 or 4x)
C: The diameter of the original knob

Without C: the other info is a starting point, and so far it looks like we have these starting points:

Tempest:  6% (perfect)
Arkanoid: 41% (actually 40.5, but needs to round up to 41)
DOH: 81% (perfect)

These have been extensively discussed and that is the only reason these numbers exist.  More people need to get involved in order to find more real data on the subject.

RandyT

[FrizzleFried]

...and the bigger the knob (for example - Big Blue),  the MORE sensitive you want to make it...right?  Any estimate on about how much (percentage wise) to account for Big Blue?

This is a very interesting project to undertake.  I imagine it would be difficult finding out how many apertures each game has and how they are translated...

[ahofle]

I can understand how the size of the knob would affect the feel of the game, but I'm not seeing how it would affect the sensitivity setting.  One 360 degree rotation is 360 degrees no matter how big your knob is.   

[RandyT]

...and the bigger the knob (for example - Big Blue),  the MORE sensitive you want to make it...right?  Any estimate on about how much (percentage wise) to account for Big Blue?

That will depend on the game in question.  Many games had different knob sizes.  The way you would figure this out would be to use a ratio based on the difference of the diameter of the original and the diameter of "Big Blue."  So if the original game had a knob that was 25% smaller, you would want to add 25% to the number of "ticks" (transitions, whatever you want to call it) of the original game and then do the rest of the math.

Here are two practical examples based on things we already know;

Tempest:

Big Blue is 1.75" in diameter.  Tempest used, IIRC, a knob with a grip diameter of 1.25".  This means that Big Blue is 40% larger than the original.  Tempest used a 72 aperture encoder at 1x, so the number is modified to 100.8 transitions (72 x 1.4)

The TT2 has a resolution of 1200 transitions so the sensitivity setting should be very close to 8 (rounded down) for a similar feel to the original (100.8 / 1200).


DOH

Big Blue is 1.75" in diameter.  DOH used, IIRC, a knob with a grip diameter of 1.5625".  This means that Big Blue is 12% larger than the original.  DOH used an encoder system with 486 effective apertures at 2x, for 972 transitions, so the number is modified to 1088.64 transitions (972 x 1.12)

The TT2 has a resolution of 1200 transitions so the sensitivity setting should be very close to 91 (rounded up) for a similar feel to the original (1088.64 / 1200).


Make sense?

This is a very interesting project to undertake.  I imagine it would be difficult finding out how many apertures each game has and how they are translated...

It just requires individuals who have access to the original controls / games to provide the information to someone like Derrick Renaud, who I am sure can take it to the next step.

RandyT

[RandyT]

I can understand how the size of the knob would affect the feel of the game, but I'm not seeing how it would affect the sensitivity setting.  One 360 degree rotation is 360 degrees no matter how big your knob is.   

We're still talking spinners, right?   

In any event, unless you have a swivel in your wrist, you will play a game by running the outside surface of the knob through your fingertips.  The larger the diameter, the more surface inches that need to travel through your fingers.  Increasing the sensitivity will bring this distance back to where it was with the original sized knob.

To anyone doubting this, try the numbers I came up with in the last post with your Big Blue and TT2.  How does it feel?  Like you remember?

RandyT

[FrizzleFried]

Well hell...I guess we just need to get all the folks out there with spinner arcade CP's to count the number of "ticks" on each controller...the hard part,  I'd imagine,  is determining if they are running 1x, 2x, 4x, etc.

[byKnight]

I can understand how the size of the knob would affect the feel of the game, but I'm not seeing how it would affect the sensitivity setting.  One 360 degree rotation is 360 degrees no matter how big your knob is.   

I only got a C in freshman physics 20+ years ago. But I know enough to know you've completely missed the point.

See Randy's explanation above. It's quite succinct.

[freckleface]

It's simple geometry applied to interface.  Not a matter of degrees traveled but circumference of dial relative to encoder definition relative to MAME sensitivity settings.

And on the buff controls maker thing:

I could get you there, Randy, with just 20 minutes three times a week.

[rockin_rick]

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 have also found this to be true.

[EDIT] This is, for me, only minor and doesn't really occur during gameplay in tempest.  Even then it only occurs in 125Hz USB mode - PS/2 and 250Hz USB don't exhibit this trait.  See my next post regarding these edits in more detail.[/EDIT]

--------------------

I've done a bunch of testing in Win XP with this.  Other OS's have different mouse update speeds, so different approches may be needed.  Givens: enhance pointer precision disabled, mouse speed set to middle.  Microsoft IntelliMouse Optical connected via USB the entire time.  XP installation has never had a PS/2 mouse connected to it before, nor have I touched the settings.  'Extra' IntelliMouse drivers not installed / XP installed the basic built in IntelliMouse drivers installed when it was setup.



USB mode does cause backspin during gameplay.  It is easily noticed when entering initials in Tempest, as it only moves two to three letters per one revolution of the knob.  So when you try to get to the middle/end of the alphabet, you give it a good spin and the letter just bounces between a couple/few.  Also noticed when spinning around the tube fast - it will just flutter back and forth between a few.

In Warlords, I would also see backspin during gameplay.

[EDIT] I believe that I may have had my tempest sensitivity set too high.  When I retested with Warlords I didn't see this.[/EDIT]

To test to determine backspin, in the windows desktop, turn the pointer speed to minimum.  Then give the spinner a spin.  For me, a good spin will backspin and make the pointer go the opposite way about an inch, then go the correct way 4-5 inches.  Another test I did was set the pointer speed to middle, and turn the spinner left.  The spinner should butt up against the left edge of the screen and stay stuck (like glue) there.  Once there spinning it left again should not cause the pointer to move - if it does it is backspinning.  It didn't stay stuck there indicating backspin.

I then decided to give PS/2 mode a whirl.  I got my extra 'green adapter' (the Microsoft branded USB to PS/2 adapter that came with my IntelliMouse Optical.  Shut down XP.  Plug in and restart.  New hardware found - installed.  Restart required.  After restart, spinner didn't work.  Restart again, it works.  I then retried my tests:

Turn speed to minimum - NO backspin at all!  Sweet.
Set speed to middle - pointer butts against left edge and sticks like glue!  Sweet!
Tempest - sweet!

I did some checking into all of this and have found out some things.  I downloaded a program called "mouse rate checker" v1.1b from:

http://tscherwitschke.de/mouseratechecker.html

This program will tell you the update rate of your mouse.  Using (moving the pointer with) my MS mouse via USB reports ~124Hz.  The TT2 in USB mode also reports ~124Hz.  Now here's what's interesting.  The TT2 in PS/2 mode reports ~235Hz.  (FWIW - the advanced mouse properties are set to the defaults - rate is set to the 100Hz, input buffer length = 100, fast initialization enabled.)  hmmmm

I'm theorizing that windows XP adapts to the rate required.  Perhaps as it gets data packets from the mouse, it detects the data getting close to the maximum, and speeds up the rate preventing overflow.  This higher rate will cause the movement data to be less (per update interval) and not overflow. 

Also, using the TT2 in PS/2 mode also doesn't allow (my) XP to shut off the monitor via Power Options (it always did before I plugged the TT2 into the PS/2 port).  Perhaps windows is thinking that the TT2 (mouse) is moving so it doesn't allow the monitor to shut down.

Next I decided to change the USB mouse update rate.  I found Mouse Rate Switcher:

http://www.softpedia.com/get/Tweak/System-Tweak/USB-Mouserate-switcher.shtml

I used it to set the update rate to 250Hz.  My USB MS mouse reports ~250Hz.  The USB TT2 reports ~250Hz.  No backspin.  Tests good.  Allows windows to shut off the monitor.

My advice is if using the TT2 with XP, use PS/2 or patch the USB rate to 250Hz.

With other OS's, probably the best way is to use USB and patch the rate.  Older MS OS's have slower PS/2 speeds and I'm unsure if you can speed those up.

Good luck,
Rick

[RandyT]

Thanks for checking into the poll frequency hacks and reporting your results.

Givens: enhance pointer precision disabled, mouse speed set to middle.

I just want to mention a couple of things;

The first is that your mouse speed needs to be set to the lowest position under 98SE and earlier and dead center on 2K / XP.  Enhance pointer precision / acceleration also needs to be disabled.  Any other settings will cause more data to be kicked through to the games than is actually coming from the spinner and will cause problems.  You should probably try your tests again at this setting to see how things improve.

The other thing is to be careful not to set the sensitivity settings in a game too high.  Tempest is a real stickler about this.  It used an encoder having only 72 apertures at 1x  for a full rotation of the spinner!.  It should always be set to 6 (perfect divisor) or below.  If your mouse speed under Windows was set to "middle", even a setting of 6 could cause big problems.

Regardless of the settings in the hardware, Windows XP alway fixes the report rate to about 125hz without the hack.  But this should be more than sufficient to prevent any backspin issues during gameplay, as long as the mouse speed is set correctly at the desktop and the sensitivity levels in the game are set to reasonable levels.

Keep in mind that backspin is something that can be made to happen with virtually any spinner/trackball on the market, even the low-res ones.  Crank up the speed of the mouse at the desktop level and then set a very high sensitivity on a game, and you will see it.  The extra resolution of the TT2 just moves the parameters that can cause it into a lower range.

Also, I have experimented with a 500hz version of the firmware and it appears to work under 2K and 98SE.  I consider it "experimental" due to the unknown stress it puts on the rest of the system, but I'd be happy to offer it to those who would like it for a small charge.  It does not improve performance under XP at all, due to what was stated above.

RandyT


*edit*

Fixed an incorrect statement I made by replacing it with the underlined text.

[spelosi]

The first is that your mouse speed needs to be set to the lowest position under any version of Windows.  Any other settings will cause more data to be kicked through to the games than is actually coming from the spinner and will cause problems.  You should probably try your tests again at this setting to see how things improve.

Unless I did something wrong (I mave very limited experience with dual mouses) I found setting the mouse speed to the the lowest is not practical. Both mouse devices seem to share the same settings. Setting the mouse to the lowest resolution makes my trackball useless.

[RandyT]

The first is that your mouse speed needs to be set to the lowest position under any version of Windows.  Any other settings will cause more data to be kicked through to the games than is actually coming from the spinner and will cause problems.  You should probably try your tests again at this setting to see how things improve.

Unless I did something wrong (I mave very limited experience with dual mouses) I found setting the mouse speed to the the lowest is not practical. Both mouse devices seem to share the same settings. Setting the mouse to the lowest resolution makes my trackball useless.

Even so, by not setting it to the lowest speed (which is 1:1) you are changing the output of both your spinner and your trackball.  The whole dynamic changes with higher settings, and is generally considered undesirable for the sake of accuracy.

The reason your trackball moves so slowly on the desktop at 1:1 is because arcade trackballs have very low-res encoder wheels in them.  The EI trackball we offer has had the encoder wheels replaced so that addresses this concern.  You can also replace the encoders in your own trackball using the kit we offer, or you can make your own.

A trackball is not designed to be a PC mouse, so you can't really expect it to perform the same way without modifying it to.

RandyT

[spelosi]

Even so, by not setting it to the lowest speed (which is 1:1) you are changing the output of both your spinner and your trackball.  The whole dynamic changes with higher settings, and is generally considered undesirable for the sake of accuracy.

The reason your trackball moves so slowly on the desktop at 1:1 is because arcade trackballs have very low-res encoder wheels in them.  The EI trackball we offer has had the encoder wheels replaced so that addresses this concern.  You can also replace the encoders in your own trackball using the kit we offer, or you can make your own.

A trackball is not designed to be a PC mouse, so you can't really expect it to perform the same way without modifying it to.

How does adding higher-res encoding wheels help to more accurately replicate the arcade experience if arcade trackballs have low-res encoders?

what's the benefit of turning down the mouse speed in windows, only to make it more sensitive by changing the encoder wheels?

I'm not trying to give you a hard time -btw. I'm really am trying to understand this.

Thanks,

Steve

[RandyT]

How does adding higher-res encoding wheels help to more accurately replicate the arcade experience if arcade trackballs have low-res encoders?

what's the benefit of turning down the mouse speed in windows, only to make it more sensitive by changing the encoder wheels?

I don't think anyone ever stated that higher res encoder wheels on a trackball would specifically more accurately replicate the arcade experience. 

But as stated already stock arcade trackballs suck (you can literally hear the whooshing noise  ) at the desktop level when the speed is set where it is supposed to be set, at 1:1.

In MAME, you can set the sensitivity to what you want, so you can divide the higher res trackball back down to arcade authentic levels, if you want.  With replacement encoders, you would have all of the following:

A) A faster, more accurate mouse pointer in Windows
B) The ability to make the output arcade authentic
C) Better compatibility with other types of PC games which expect the higher resolution a mouse provides. 

Cranking the speed up in Windows, is exactly like boosting the sensitivity in MAME to over 100%.  Things move faster, but at the expense of precision.

RandyT

[spelosi]

Ok, I get it now. Thanks.

One more thing I've got to order for the cab!

[rockin_rick]

The first is that your mouse speed needs to be set to the lowest position under any version of Windows.  Any other settings will cause more data to be kicked through to the games than is actually coming from the spinner and will cause problems.  You should probably try your tests again at this setting to see how things improve.

The other thing is to be careful not to set the sensitivity settings in a game too high.  Tempest is a real stickler about this.  It used an encoder having only 72 apertures at 1x  for a full rotation of the spinner!.  It should always be set to 6 (perfect divisor) or below.  If your mouse speed under Windows was set to "middle", even a setting of 6 could cause big problems.

With the TT2 in USB mode and the 250Hz mod in place, I just tried setting the pointer speed to each minimum, middle, and maximum and tried tempest at 6% and there was no difference in the speed of the 'crab' (?).  It moved five spaces for one complete revolution of the TT2 each time.  (This 'spec' was provided here: http://forum.arcadecontrols.com/index.php?topic=23967.msg201068#msg201068)  I was sure to pick the correct speed and click OK to close the mouse properties and then load the game with mame32.  The mouse speed adjusted properly after choosing the speed - IOW when it was at minimum I had to pick up the mouse 20 times to get it to where it should be to load tempest along with the spinner moving the mouse really slowly, too.  Is this not normal and is something up with my setup?  It appears that mouse speed has no effect.

I also tried this with the 250Hz mod removed - using the default 125Hz with the same results.  I could tell no difference between different mouse speeds in tempest, warlords, offroad, kick, super sprint.


I also checked out backspin issues in those games in 125Hz USB mode.  There wasn't really much of a problem during gameplay (as I mentioned before).  I think that I did have the sensitivity in tempest set too high/higher than normal.  I only noticed the backspin occasionally in tempest when really cranking on the spinner at the end of a level (not important) and it was also not too (but somewhat) noticable when entering initials in tempest.  Definately manageable/acceptable if you are not able to mod the update rate.  I still would change it to 250Hz USB or go with PS/2, as it will alleviate those minor backspin issues - why not make the TT2 work perfect, it doesn't cost anything to change that!

I still would appreciate input about different mouse speeds not effecting mame, though...

Thanks,
Rick

[RandyT]

I still would appreciate input about different mouse speeds not effecting mame, though...

I have to admit, I don't yet fully understand the dynamic between XP and MAME.  It's possible that the mouse input code on newer versions of MAME aren't affected by the desktop settings, or it may be an XP thing. 

But if you are seeing no differences in MAME with higher pointer speeds under XP,  apparently there is something very different as opposed to how it works with 98SE and 2K.  I just did a quick test under 98SE and 2K  with Tempest and, as I expected, it was virtually unplayable with the speed set higher than 1:1 (slow on 98SE and middle setting on 2K.) 

But you folks are indeed correct in that the mouse speed needs to be set at the middle under 2K / XP.  I watched the mouse cursor jump more than one pixel when at one click higher than center, so apparently "middle" on 2K/XP is "slow" on 98SE.  My apologies for that one.  On 2K, the mouse acceleration should also be set to "off".

Under XP, "acceleration" is tied to the "enhance pointer precision" box. To see how this affects the cursor, take a look at the "mouse pointer ballistics under XP"  page from MS.

Here's probably the line of the most interest to this discussion:
----
7.  If the feature is turned off (by clearing the Enhance pointer precision check box underneath the mouse speed slider in the Mouse Properties dialog box [Pointer Options tab]), the system works as it did before without acceleration. All these functions are bypassed, and the system takes the raw mouse values and multiplies them by a scalar set based on the speed slider setting.
----

I will conduct the same tests under XP (with the same MAME version) to see if the desktop settings are used or ignored.  But they do make a big difference under 2K and 98SE.

On the bright side, on both XP and 2K, the PS/2 poll rate selection looks like it is built into the default divers, so cranking up the PS/2 poll rate is simple from those two OS's.

RandyT

[Derrick Renaud]

FWIW, I recomend this utility for XP users.  Use it to set the USB rate to 250-500.  I use 500.
http://www.majorgeeks.com/USB_Mouserate_Switcher_d4469.html

Using PS/2 with the polling rate set to 200 is the bare minimum. But USB set to 250-500 is best.  USB set to 1000 is overkill.  I have written my findings on this in the past and have mentioned that it should be put in a faq somewhere, but never has as far as I can tell.  Without using this utility, then PS2 beats USB.  125 is too low.

You also need this utility to confirm the polling rate.  Even though it is called PS2 rate, it reads USB rates too.
http://www.majorgeeks.com/PS2Rate_Plus_d300.html

So to recap.  Spinners need high resolution so they can be easily scaled and also need a high polling rate of 200 - 500.

Even low res spinners and trackballs need 200+ polling rate.  This balances the data for when an emulated game actually reads the data.  MAME trys to emulate reading the real control where the game would read at the game's vblank.  But windows gets the data at a fixed rate which is different.  So even if a spinner is turning at a fixed rate, the values read by the game drift a little because some vblank reads will have more mouse polling samples then others.  So the faster the polling, the lower the difference sent to mame.

THROW away your serial mice.

D.

[spelosi]

Thanks, I found this very useful.

[Chris G]

Ok, probably stupid question, but can I use the PS/2 version of the TurboTwist2 AND the PS/2 version of the ICE-T on the same machine?  Thanks

[RandyT]

Ok, probably stupid question, but can I use the PS/2 version of the TurboTwist2 AND the PS/2 version of the ICE-T on the same machine?  Thanks

Not enough ports

Either one will work on either interface.  Run the trackball off of USB with one of those little passive pin adapters if you really want to go PS/2 with the TT2.

You could also attach the TT2 to the Z-Axis of the TB interface, but that gets a little trickier on the software side.

RandyT