Turbo Twist 2 & Trackball won't play nice!

[mybrainhurtz]

I just received my 3" happ trackball and TT2 and am working on tweaking them in mame (using a custom compiled 121 to add highscore support).

I hooked the x and y axis to the trackball(because I want it to double as a mouse) and the z-axis to the spinner, but I found that even if I set the sensitivity of the wheel in windows to "1 line" and the analog sensitivity in mame to 1% it still was way too sensitive and was getting bad backspin (I was testing it in Tempest).

Are there any other registry tweaks or programs that I can download to have more control over the sensitivity of the mouse wheel/z-axis?

I have tried the spinner on the x axis, and I can adjust the sensitivity in mame to get it to work perfect. I haven't tried the trackball on the y and z axis, but I imagine that it is going to be a pain in the butt to make the horizontal and vertical motion of the trackball feel even with the large sensitivity difference between the axis...and I wont be able to use it as a mouse in windows set up this way.

What do you guys suggest I do? I did not purchase an opti-wiz when I ordered the TT2 because I read here that you could hook a trackball up to it with no problems.

Thanks for your infinite knowledge guys!!

[Encryptor]

You can try the stuff in this thread. I've been having issues myself. I don't know if I have a wire loose now or what but it's horrible at the moment. I haven't been that worried about it because I'm building a new cp soon. Good luck and keep us updated.

http://forum.arcadecontrols.com/index.php?topic=73364.0

Encryptor

[DeLuSioNal29]

Did you try using a different axis for the spinner?  Sometimes the z axis has sensitivity problems.

~ D

[RandyT]

Did you try using a different axis for the spinner?  Sometimes the z axis has sensitivity problems.

Just to clarify, the problem is with the way the OS deals with the Z-Axis.  At one time, the Z-axis was being divided down with the official MAME distributions in order to allow the Z to behave like the X and Y.  But I'm not so sure this is still being implemented.  Something tells me it's been changed back, based on all the comments about the Z-axis lately.

If the Z-axis is crazy sensitive when compared against the X and Y axes, then the MAME code is probably no longer doing what it used to.  Try using a version prior to the addition of the new input system.

RandyT

[mybrainhurtz]

Thanks for the replies... here is what I know so far...

• If I put the spinner on x or y, it works fine.
• If I use an older version of mame(ex. v105) it works fine.

The next thing that I need to do is move forward in versions of mame until I find which one implemented the input change. I would simply run version 105 all the time, but after doing some random sampling in 105, I found that many games don't run nearly as good as they do with 122.

why do they have to keep taking useful stuff out of mame... highscores... z-axis... sigh...
(I know they have good reasons, im just frustrated haha)

So, what are my options? I don't suppose there is an easy fix such as a diff out there that I can compile with the newest version of mame to slow down that pesky z-axis is there?

Probably not... 

I don't want to run a different OS, since I plan on running a few windows games from my cab.

I installed Microsoft's Intellipoint drivers to try to get more control over the scroll wheel speed, but  even with the slider the whole way to slow, it still makes no difference.

I guess the real easy fix is to go out and buy an opti-wiz, but I thought I was done buying controls... argh!

hmm... what about hacking a mouse for my trackball... would I have issues with backspin?

Well, this started out as a quick update and turned into a frustrated rant... sorry about that LMK if you guys have any other suggestions for me... I am hoping that there's some way around this...

Thanks!

[Encryptor]

Does anyone know if there is a setting or line of code in MAME that can be changed to fix this?

Any smart programmers that can fix this and release a patch?

I just upgraded not long ago to v120. I'd hate to have to go back to a much lesser version to fix this issue.

Any help would be greatly appreciated!

Encryptor

[u_rebelscum]

Without looking at any code, I'll bet it's the switch to RawInput.  I'll check it out.

[mybrainhurtz]

That sounds great... do some detective work and let us know what you come up with. I would rather hook it to the TT2 interface, but for now I just wired my trackball to an old mouse that I had sitting around and it seems to work pretty well.

[Encryptor]

Without looking at any code, I'll bet it's the switch to RawInput.  I'll check it out.

u_rebelscum - Just curious to know if you ever get a chance to look into this?


Encryptor

[u_rebelscum]

Without looking at any code, I'll bet it's the switch to RawInput.  I'll check it out.

u_rebelscum - Just curious to know if you ever get a chance to look into this?

Freaky, even though I didn't read your post till today, for some reason I had an urge and time to look at this issue again this weekend.   Spent too much of the free time I had DL'ing the source and finding and rewiring my TT2 (it's not on a CP yet), though.

So I was only able to test normal mouse & TT2 Z axis on XP with rawinput, and look in the code.   From glancing at the code, mame isn't dividing by 120 (or 30) like it used to in directInput nor in rawInput.  IIRC directInput & TT2 didn't need the divisor, and from testing it looks like normal mouse Z axis on rawInput doesn't need the divisor.  I'm busy tonight (league game), but maybe tomorrow while it's still fresh.

TODO
test on directInput
test divisors (I'm guessing I needs 120 on TT2, but then normal mice won't work)
(maybe) write independent for mame rawinput & dInput testing app
test possible fixes (I'm thinking increase sensitivity range beyond the 1% to 255%).

[Encryptor]

Can you look at previous versions of MAME to find out what they used for a divisor before? When I first hooked up my TT2 it worked great and the mouse worked fine because it was on the X and Y axis. I think I was using around MAME 108 then.

Encryptor

[bent98]

So to clarify if you purchase optiwiz you wont have this issue with newer mame version? If so what does the optiwiz do different?

[ideft]

The TT2 will not work with a standard Opti-Wiz interface.  The master
version of the TT2 will support a trackball with the correct cable, but
a TT2 needs a TT2 interface to function.

[RandyT]

So to clarify if you purchase optiwiz you wont have this issue with newer mame version? If so what does the optiwiz do different?

I can see there is some confusion here, so I will try to clear it up a bit.

This issue is only when using the TT2 on the Z-axis with certain versions of MAME.  MAME was tweaked several versions back to overcome an OS "feature" that makes the Z more sensitive than the X and Y axes.  The tweak was undone in a later version when the RAW Input code replaced the earlier input code (thanks u_rebel for verifying this).

The only way an Opti-Wiz (or other optical interface) will help, is to leave the TT2 on it's own interface and move it to either the X or Y axis, and use the Opti-Wiz for the Trackball.  Note: this is not necessary for the Electric ICE Trackball, as it has it's own interface.

This is actually the better approach anyway, as later versions of MAME will show the separate devices as MOUSEx , meaning that there is no possibility of interference between controls.  Having the TT2 on Z and the Trackball on X and Y accomplishes this separation as well (all on the same MOUSE device,) but relies on the specific version of MAME in use to support that configuration.

RandyT

[fryguy]

Rats.  I just recently bought a Happ harness trackball and TT2 separately and thought I'd be able to use them together on the TT2 OptiWiz interface without incident.  Now it looks like I'll need a second OptiWiz for the trackball, so as not to limit myself from using current and future versions of MAME.  Bummer.  Makes me also second-guess getting the harness trackball instead of the USB version.  20/20 hindsight sucks.

[mybrainhurtz]

Thanks for continuing to work on this u_rebelscum. Right now, I am still running the mouse hack for my trackball. If you don't come up with a solution, next time I place an order with GGG, I will pick up an opti-wiz so I can hook things up right!

And thanks for clarifying the situation Randy. When I first had this problem about a month ago, I had trouble finding an explanation. Hopefully this will help others that are having the same sensitivity issues.

Oh, and I just want to say... I love the GP-Wiz and the TT2 now that I am able to play with them...they are both fantastic products!

[u_rebelscum]

Okay, some info from last night:

Confirmed: TT2 Z axis sends mame too big counts, and cannot be fixed by decreasing mame sensitivity to 1%
Confirmed: the Z axis for TT2 and my kensington TB have a minimum step of 120 counts, in both RI & DI in XP.
Confirmed: mame currently does not divide for the Z axis either RawInput not DirectInput anymore (used to be / 30 starting ver. 0.110u5)
Tested: current mame works sort of okay for normal Z axis (on my mouse I tested)

Tested: if Z axis count is divided by 120, then normal mice Z axis suck (and mame sensitivity can't be set to 12000% to compensate)
Tested: if Z axis count is divided by 120, then TT2 on Z axis works great

Still have
TODO: find & test the couple mice I have that have "scaled Z axis" that might have < 120 count minimum.  (true in DI & win9x, IIRC)
TODO: look at older versions of mame to see when changes were made
TODO: (maybe) dig out my 9x box and repeat tests on it


Randy, I can't remember the details of the z axis, and can't find threads on it (besides the 0.110u5 what's new).  Do you have better memory or searching skillz?

[RandyT]

Randy, I can't remember the details of the z axis, and can't find threads on it (besides the 0.110u5 what's new).  Do you have better memory or searching skillz?

That's the first version with the fix.  The only other info I have is from an email from Derrick Renaud, who was responsible for it.  He wrote:

------
This is how the Z-axis will now work.

Windows Input changes:
 Scaled Mouse Z axis by 30 to make it usable.  Most mice inc/decrement by 120 for each wheel click.  Some rare ones are 30.  So this means for most mice, using a Sensitivity setting of 25%, you will get 1 inc/decrement for each wheel click.

I did not want to make this a MAME core change because I do not know how Linux, Macs, etc handle the Z-axis.
------

Does that help?


RandyT

[u_rebelscum]

...Does that help?

A little, jogged my memory some, thanks.


On the testing news:
I tested one of the accelerated Z axis mice, and it does non 120 steps (as I remembered, yah! ).  However the minimum still is 120.  Z axis values at my settings included: 120, 127, 140, 183, 202, 331, 364, & 448, and others higher and in bewteen but less often.  (The mouse is a MS wireless laser mouse 5000 with the MS IntelliPoint driver.)

More later.

[Encryptor]

...Does that help?

A little, jogged my memory some, thanks.


On the testing news:
I tested one of the accelerated Z axis mice, and it does non 120 steps (as I remembered, yah! ).  However the minimum still is 120.  Z axis values at my settings included: 120, 127, 140, 183, 202, 331, 364, & 448, and others higher and in bewteen but less often.  (The mouse is a MS wireless laser mouse 5000 with the MS IntelliPoint driver.)

More later.

u_rebelscum,

I just want to say thank you very much for looking at and trying to come up with a solution to this problem. I appreciate it a great deal.

Encryptor

[u_rebelscum]

Ok, some more testing this weekend.  My other accelerated Z axis mouse (logitech MX revolution + its driver) is totally different than the ms mouse, and gives values 120, 240, 360, 480, and then in the 1000's to 3000's (and backspins/backscrolls on many win apps).  I tried mixing/matching mouse and driver, but then the Z axis acts like normal Z axis, whether it's an accel Z mouse or normal mouse.  (All testing on winXP.)  Multiple mice enabled acted the same as the default disabled.


With all the different (non-120 multiplied & non-accelerated) cpr numbers between 24 and 1200 and different scaling (and not) on the Z axis numbers, it's not going to be easy one-fix-all solution.

For those with TT2 on Z axis and the TT2 is the only mouse Z axis used in mame, there is a one line fix.  However, this ruins normal mice's Z axis use.  Use attached diff file, or change src/osd/windows/input.c, line 2039 from:

devinfo->mouse.raw_z += (INT16)data->usButtonData * INPUT_RELATIVE_PER_PIXEL;

to:

devinfo->mouse.raw_z += (INT)((INT16)data->usButtonData * 4.267);

FWIW, INPUT_RELATIVE_PER_PIXEL = 512, and 512 / 120 = ~4.266666667

I know almost nothing about writing mouse drivers, but the ms mouse shows that (somehow) the Z axis can have steps not a multiple of 120.  It's still unclear about being able to go below 120 is legit to windows.  I wonder if someone could write a high res Z axis rawinput compatible special driver for TT2?

A maybe possibly mameDev acceptable solution is to change mame's sensitivity from an 8 bit int (1% to 255%) to 16 bit int (0.01% to 665.35%), (or 32 bit int, or real) and "just" have TT2 Z axis users change the sensitivity to 1/120 of the default on axes that use the TT2 Z axis. Of course, this isn't easy for TT2 Z axis users, and would mess up all existing cfg/cfg files for games with analog inputs.


FWIW, this is beginning to sound very familiar to me, with IIRC one rare exception missing: directInput multiple mice (which only works in win9x anyway) Z axis step of 1 in some but not all cases. 

[deano728]

This patch worked wonders on Tempest for me in version 125u1.  I tried to compile 125u4 and I got an error trying to use this patch.  Does it need to be modified for u4?  The error is "can't find a file to patch at input line 4".    Do I even need this patch in U4?  Did Mame developers fix the problem in a previous release?

[u_rebelscum]

This patch worked wonders on Tempest for me in version 125u1.  I tried to compile 125u4 and I got an error trying to use this patch.  Does it need to be modified for u4?  The error is "can't find a file to patch at input line 4".    Do I even need this patch in U4?  Did Mame developers fix the problem in a previous release?

The patch works for me.  (patch -p1 < t2_zaxis.diff)
Did you apply the mame u# updates to a freash 0.125 source, or to your modified 0.125u1 (w/ tt2 hack)?

This has not been added to official mame and won't be since it makes all normal mouse scroll wheels stop working; mamedev will not break 99% of the users' hardware just for the tt2.

[Havok]

I just tried out the patch, and it works for me as well. I initially got the same error, however I opened input.c and replaced the line myself. I even patched the hiscore.diff after that, and it compiled great. Due to a controller problem, I had to temporarily put my spinner on the Z axis, and this fixed the problem. Thanks u_rebelscum!

[Gamester]

My TT2 is connected to the z-axis and is going crazy in MAME too.

Has anyone had success applying this fix to MAME v134?  After I applied it, any movement of the spinner caused MAME to crash with the following error:

-----------------------------------------------------
Exception at EIP=00A00EE1: ILLEGAL INSTRUCTION
-----------------------------------------------------
EAX=00000400 EBX=00000028 ECX=00000000 EDX=0001004F
ESI=0022E7AC EDI=04EDF4E0 EBP=0022F7C0 ESP=0022E778

I'm assuming something has changed in MAME's code that has broken this instruction, as it doesn't crash with the original, unmodified code.

I've seen that others have had success with the previous version (v133), but man, I'd sure rather not have to go through all the hassle of redoing my roms and recompiling all the patches, etc..

Just as another note, the diff file wouldn't apply to v134 at all, so I had to change the line manually.

Any tips are appreciated...

[Gamester]

My TT2 is connected to the z-axis and is going crazy in MAME too.

Has anyone had success applying this fix to MAME v134?  After I applied it, any movement of the spinner caused MAME to crash with the following error:

-----------------------------------------------------
Exception at EIP=00A00EE1: ILLEGAL INSTRUCTION
-----------------------------------------------------
EAX=00000400 EBX=00000028 ECX=00000000 EDX=0001004F
ESI=0022E7AC EDI=04EDF4E0 EBP=0022F7C0 ESP=0022E778

I'm assuming something has changed in MAME's code that has broken this instruction, as it doesn't crash with the original, unmodified code.

I've seen that others have had success with the previous version (v133), but man, I'd sure rather not have to go through all the hassle of redoing my roms and recompiling all the patches, etc..

Just as another note, the diff file wouldn't apply to v134 at all, so I had to change the line manually.

Any tips are appreciated...

bump.

u_rebelscum, you out there?  Any ideas?

My fallback plan is to just get another Opti-Wiz so I don't have to use the spinner on the Z axis, but then I think that raises a new set of configuration considerations with having multiple mouse devices.

[u_rebelscum]

Sorry, must have missed it the first time. 

Do you still want 0.134, or an even newer mame?  I'll have to re-D/L the source or apply patches if you want 0.134 or 0.136u2, respectively, before I can be of real help.  I think it will be a pretty easy patch.  I'll be in classes tomorrow, though, so I won't be able to look at the source until Thursday, minimum.

As for a second opti-wiz, be sure to get a different "USB Device Number".  Then setup can be very easy to a little more work, depending on if mind the TB & spinner able to mess each other out or not.  If you don't mind, leave mame -multimouse option disabled, hook the spinner to the X axis, and you're good to go.  If you do mind, or you want to use the TB and spinner at the same time controlling different input in mame, you'll need to enable -multimouse, and remap the TB, dial, and maybe AD_stick, paddle, and lightgun inputs in "Input (general)".  (I prefer ctrlr file over the default.cfg file of "Input (general)", but it's two more steps and most people don't need/want to do it.)

[Gamester]

u_rebelscum,

Thank you so much for your response.

I'm using 0.134u3, so a fix for that version would be terrific, but I'm willing to be flexible if needed.

I realize you have a life, so whenever you can get to it is fine... I'm just thankful you're willing to help! 

[u_rebelscum]

It seems to work on my tests with arkanoid.  I did basically the same edit; updated for 0.134u3 diff attached.

I wondering if you mistyped something since you edited by hand, or if it's a game specific error?  edit:  IOW, if the diff doesn't help, what games have you tested?

[TopJimmyCooks]

u_rebelscum: 
I'm trying to keep my turbotwist on the Z axis but i'm running mame 141 currently and I've tried to compile 144u7 (current mame as of this date) with this diff.  The diff will not apply. I can get the exact error message if needed but clearly something has changed with the updates of mame source.  Any chance you could do an update of the z axis diff?  I would really appreciate it.  If not, I'll give it a go at finding the mouse input line and doing the hand edit listed below, seems pretty straightforward. 

By the way your knowledge of and explanation of mame Joystick mapping was key to me getting full use of my u360.  Thanks for that as well.

[TopJimmyCooks]

Please disregard my last post.  I made the change to the source code.  Easy enough for you computer guys but a little daunting for us end users!  Thanks.  Now off to compile, fingers crossed.