Post by: geecab on March 09, 2013, 01:47:03 pm
Not sure if this is of interest to anyone, I hacked a ps2 mouse and built a mame driving cab recently. For games that used 360 wheels (pole position, change lanes, super sprint etc) it was great. For games that limited the turning circle of the wheel (outrun, wec le mans) it wasn't so good. I found that if I over steered, the wheel's central position would wander. I've kind of got used to it, but I notice when my friends have a go its takes them a while to adjust.
So I decided to see if I could hack the mame source code a bit. My hack works so that the position of the wheel when the game starts up will always be its central position (players car will travel in a straight forward direction). If you then spin the wheel, say, 3 spins clockwise (hard right), you'll be required to spin the wheel back anti-clockwise 3 times in order to get the car going straight again. Spinning your mouse/spinner/360wheel beyond the limits of what the actual arcade game wheel would allow just means the game's maximum left turn or right turn value is applied.
Hope that make sense, here's a youtube clip of me trying to show that working...
Mame modification that makes outrun easier to play with mouse (http://www.youtube.com/watch?v=-smfqFj_ybU#ws)
I'll post my mame source code changes shortly incase someone else is thinking of doing the same thing!
Post by: BadMouth on March 09, 2013, 02:15:10 pm
Does each driver in MAME have to be modified, or will this work with with all the driving games?
On Hard Drivin', does the wheel do as many turns as the original arcade one before hitting the virtual end?
(it had a 10 turn pot, but IIRC the wheel turned 7+ times lock to lock)
FYI, years ago, bkenobi had a fix using glovepie.
http://forum.arcadecontrols.com/index.php/topic,92363.0.html (http://forum.arcadecontrols.com/index.php/topic,92363.0.html)
Post by: BadMouth on March 09, 2013, 02:37:51 pm
If you have the skills to make it optional, and in a way that MAMEDev finds acceptable, consider submitting it.
Post by: geecab on March 09, 2013, 04:20:31 pm
Getting hard drivin' going was tricky, I don't think that multiple turning pot thing (with some strange latching bit when the wheel turns 360 degrees past the central point) has ever been emulated correctly. My hack for hard drivin is different to my outrun/hang-on/weclemans hack, I shall post the hack I made specifically for hard drivin in another post a little later on.
So regarding the outrun/hang-on/weclemans change, you don't have to change all the individual game driver files, just one file (found in src/emu/ioport.c). Also, I'm editing mame source version 0145. You are looking for a function called "apply_analog_min_max", below is what the function looked like originally (before my hack):-
Code: [Select]
INLINE INT32 apply_analog_min_max(const analog_field_state *analog, INT32 value)
{
/* take the analog minimum and maximum values and apply the inverse of the */
/* sensitivity so that we can clamp against them before applying sensitivity */
INT32 adjmin = APPLY_INVERSE_SENSITIVITY(analog->minimum, analog->sensitivity);
INT32 adjmax = APPLY_INVERSE_SENSITIVITY(analog->maximum, analog->sensitivity);
/* for absolute devices, clamp to the bounds absolutely */
if (!analog->wraps)
{
if (value > adjmax)
value = adjmax;
else if (value < adjmin)
value = adjmin;
}
/* for relative devices, wrap around when we go past the edge */
else
{
INT32 range = adjmax - adjmin;
/* rolls to other end when 1 position past end. */
value = (value - adjmin) % range;
if (value < 0)
value += range;
value += adjmin;
}
return value;
}
Now, outrun/hang-on/weclemans used an absolute device for steering. 'value' is passed into the function as the position of where your mouse x axis is. 'value' is limited to adjmax or adjmin if you moved your mouse further than the arcade game allowed.
So now onto my fix, basically, if 'value' is limited by adjmax or adjmin, I make a note of the difference (I called it "spin_history" for some reason). Then the next time I'm in the apply_analog_min_max, I add the spin_history (which maybe positive or negative depending on which way the wheel was turned) to the 'value' passed in, which then may be limited again, which I then save the spin_history again, etc.. etc... Finally, I only want this to happen for the IPT_PADDLE type because that is the steering wheel device, other devices also go through this function too (IPT_PEDALS for example) which I don't want to alter:-
Code: [Select]
INT32 spin_history = 0;
INLINE INT32 apply_analog_min_max(const analog_field_state *analog, INT32 value)
{
/* take the analog minimum and maximum values and apply the inverse of the */
/* sensitivity so that we can clamp against them before applying sensitivity */
INT32 adjmin = APPLY_INVERSE_SENSITIVITY(analog->minimum, analog->sensitivity);
INT32 adjmax = APPLY_INVERSE_SENSITIVITY(analog->maximum, analog->sensitivity);
/* for absolute devices, clamp to the bounds absolutely */
if (!analog->wraps)
{
if(analog->field->type == IPT_PADDLE)
{
value = value + spin_history;
spin_history = 0;
if(value > adjmax)
{
spin_history = value - adjmax;
value = adjmax;
}
else if(value < adjmin)
{
spin_history = value - adjmin;
value = adjmin;
}
}
else
{
if (value > adjmax)
value = adjmax;
else if (value < adjmin)
value = adjmin;
}
}
/* for relative devices, wrap around when we go past the edge */
else
{
INT32 range = adjmax - adjmin;
/* rolls to other end when 1 position past end. */
value = (value - adjmin) % range;
if (value < 0)
value += range;
value += adjmin;
}
return value;
}
There is an obvious bug with this, like if you span your wheel enough (moved you mouse in one direction enough) spin_history would get so large (or so small) that it too would wrap around. I could sort this out at some point though.
Anyways, I think that's it for now as I think I'm going on a bit, hope some of this made sense ;)
Post by: geecab on March 10, 2013, 09:29:49 am
Ok so first off, I modified the apply_analog_min_max function in src/emu/ioport.c agian. The big comment should hopefully explain what I'm up to...
Code: [Select]
INLINE INT32 apply_analog_min_max(const analog_field_state *analog, INT32 value)
{
/* take the analog minimum and maximum values and apply the inverse of the */
/* sensitivity so that we can clamp against them before applying sensitivity */
INT32 adjmin = APPLY_INVERSE_SENSITIVITY(analog->minimum, analog->sensitivity);
INT32 adjmax = APPLY_INVERSE_SENSITIVITY(analog->maximum, analog->sensitivity);
/* for absolute devices, clamp to the bounds absolutely */
if (!analog->wraps)
{
if(analog->field->type == IPT_PADDLE)
{
//Limit the turning circle so that you can not turn the wheel more than 270 degrees to
//the left or 270 degrees to the right. I limited the turning circle because things
//seemed to mess up if I turned more that 360 degress left or right. The values I've
//hardcoded adjmax/admin may need to be altered depending on your analogue PADDLE settings.
//Press the Left Shift key in game and a small debug window appears for a few seconds
//(one of the mame developers must have added this), it shows you what position mame thinks the
//arcade wheel is in. It should be the same value as reported by the game if you Press F2
//(invoke the service menu), then pressing 5/6, and turning key (1) on CONTROL SIGNALS.
//From what I can work out, the value 0x800 in the debug window should be
//dead center, 0xC00 is about 270 degress to the right of the central position, 0x400 is
//about 270 degrees to the left of the central position. If you use a different
//PADDLE SENSITIVITY, the values shown in the debug window may exceed the 0x400 to 0x800
//limit in which case you probably what to a adjust the hard coded limits of adjmax/adjmix
//(by trial and error, holding the left shift key down in game and see how things look/play).
//
//This is what worked for me with my analogue settings set to:
// PADDLE DIGITAL SPEED = 0
// PADDLE AUTOCENTER SPEED = 0
// PADDLE SENSITIVITY = 25
adjmax = 150016; //Stop the steering going over 0x0C00, before the latch bit is set
//Central position seems to be 0x0800
adjmin = -150016; //Stops the steering going under 0x0400, before the latch bit is set
value = value + spin_history;
spin_history = 0;
if(value > adjmax)
{
spin_history = value - adjmax;
value = adjmax;
}
else if(value < adjmin)
{
spin_history = value - adjmin;
value = adjmin;
}
}
else
{
if (value > adjmax)
value = adjmax;
else if (value < adjmin)
value = adjmin;
}
}
/* for relative devices, wrap around when we go past the edge */
else
{
INT32 range = adjmax - adjmin;
/* rolls to other end when 1 position past end. */
value = (value - adjmin) % range;
if (value < 0)
value += range;
value += adjmin;
}
return value;
}
With the hack above, things worked quite well, but I found the steering would occasionally wander away from dead center after doing a few erratic turns. I guessed it might be something to do with the wheel edge/latching processing which I don't really understand. So I found in src/mame/machine/harddriv.c a function which appears to do something with this latching bit each time the wheel goes past its central position and I modified it and it fixed the wandering problem.
This is what the function originally looked like...
Code: [Select]
READ16_HANDLER( hdc68k_wheel_r )
{
harddriv_state *state = space->machine().driver_data<harddriv_state>();
/* grab the new wheel value and upconvert to 12 bits */
UINT16 new_wheel = input_port_read(space->machine(), "12BADC0") << 4;
/* hack to display the wheel position */
if (space->machine().input().code_pressed(KEYCODE_LSHIFT))
{
popmessage("%04X", new_wheel);
}
/* if we crossed the center line, latch the edge bit */
if ((state->m_hdc68k_last_wheel / 0xf0) != (new_wheel / 0xf0))
state->m_hdc68k_wheel_edge = 1;
/* remember the last value and return the low 8 bits */
state->m_hdc68k_last_wheel = new_wheel;
return (new_wheel << 8) | 0xff;
}
And this is what it looked like after my modification (Once again big comment should hopefully explain what I'm up to)...
Code: [Select]
UINT16 g_latchpoint = 0x860; //Ajust this g_latchpoint by trial and error. You want it so that
//when your wheel is dead center and you press left shift key in game, the value reported is 0x800.
//Setting the latchpoint as 0x860 was dead center for me (not sure why this is, I had calibrated
//everything correctly in the F2 service/configuration menu).
READ16_HANDLER( hdc68k_wheel_r )
{
harddriv_state *state = space->machine().driver_data<harddriv_state>();
/* grab the new wheel value and upconvert to 12 bits */
UINT16 new_wheel = input_port_read(space->machine(), "12BADC0") << 4;
/* hack to display the wheel position */
if (space->machine().input().code_pressed(KEYCODE_LSHIFT))
{
popmessage("%04X", new_wheel);
}
if(new_wheel == g_latchpoint)
{
if(state->m_hdc68k_last_wheel != g_latchpoint)
{
state->m_hdc68k_wheel_edge = 1;
}
}
else
{
//I noticed after many harsh turns of the wheel, mame's perception of where
//the arcade wheel is (shows by pressing the left shift key in game) would
//wander from what was actually reported in the hard drivin' serivce menu
//(Pressing F2 in-game and view the CONTROL SIGNALS page). I guessed this was
//something to do with the edge/latching bit stuff that should get set when
//the wheel passes the central position. My modification is to make sure the
//m_hdc68k_wheel_edge thing is set when we pass the central position, even
//if we don't hit the value exactly.
if(new_wheel > g_latchpoint)
{
if(state->m_hdc68k_last_wheel < g_latchpoint)
{
state->m_hdc68k_wheel_edge = 1;
}
}
else if (new_wheel < g_latchpoint)
{
if(state->m_hdc68k_last_wheel > g_latchpoint)
{
state->m_hdc68k_wheel_edge = 1;
}
}
}
/* remember the last value and return the low 8 bits */
state->m_hdc68k_last_wheel = new_wheel;
return (new_wheel << 8) | 0xff;
}
Finally, I only have a high/low shifter and wanted to use the 4 speed manual gear option. As I've got shift up and shift down firebuttons on my CP I decided to try and use them. So this is my shifter hack (I've done similar hacks for games like night driver, Sprint 1), let me know if you're interested in seeing them.
Once again, in src/mame/machine/harddriv.c I found the function that takes care of the gears, this is what it originally looked like...
Code: [Select]
READ16_HANDLER( hdc68k_port1_r )
{
harddriv_state *state = space->machine().driver_data<harddriv_state>();
UINT16 result = input_port_read(space->machine(), "a80000");
UINT16 diff = result ^ state->m_hdc68k_last_port1;
/* if a new shifter position is selected, use it */
/* if it's the same shifter position as last time, go back to neutral */
if ((diff & 0x0100) && !(result & 0x0100))
state->m_hdc68k_shifter_state = (state->m_hdc68k_shifter_state == 1) ? 0 : 1;
if ((diff & 0x0200) && !(result & 0x0200))
state->m_hdc68k_shifter_state = (state->m_hdc68k_shifter_state == 2) ? 0 : 2;
if ((diff & 0x0400) && !(result & 0x0400))
state->m_hdc68k_shifter_state = (state->m_hdc68k_shifter_state == 4) ? 0 : 4;
if ((diff & 0x0800) && !(result & 0x0800))
state->m_hdc68k_shifter_state = (state->m_hdc68k_shifter_state == 8) ? 0 : 8;
/* merge in the new shifter value */
result = (result | 0x0f00) ^ (state->m_hdc68k_shifter_state << 8);
/* merge in the wheel edge latch bit */
if (state->m_hdc68k_wheel_edge)
result ^= 0x4000;
state->m_hdc68k_last_port1 = result;
return result;
}
And this is what it looked like after my modification...
Code: [Select]
int g_gear = 1;
int g_have_seen_shift = 0;
READ16_HANDLER( hdc68k_port1_r )
{
harddriv_state *state = space->machine().driver_data<harddriv_state>();
UINT16 result = input_port_read(space->machine(), "a80000");
int has_changed = 0;
if(!g_have_seen_shift)
{
if(result != 0xFFFF)
{
if (result & 0x0100) //SHIFT UP
{
//printf("shift up\n");
g_have_seen_shift = 1;
g_gear++;
if(g_gear > 4) g_gear = 4;
has_changed = 1;
}
if (result & 0x0200) //SHIFT DOWN
{
//printf("shift down\n");
g_have_seen_shift = 1;
g_gear--;
if(g_gear < 1) g_gear = 1;
has_changed = 1;
}
}
}
else
{
if ((result != 0xFEFF) && (result != 0xFDFF))
{
//printf("shift OFF result=0x%X\n", result);
g_have_seen_shift = 0;
}
else
{
//printf("shift STILL ON! result=0x%X\n", result);
}
}
if(has_changed)
{
if (g_gear == 1)
{
//printf("gear1\n");
state->m_hdc68k_shifter_state = 1;
}
if (g_gear == 2)
{
//printf("gear2\n");
state->m_hdc68k_shifter_state = 2;
}
if (g_gear == 3)
{
//printf("gear3\n");
state->m_hdc68k_shifter_state = 4;
}
if (g_gear == 4)
{
//printf("gear4\n");
state->m_hdc68k_shifter_state = 8;
}
}
/* merge in the new shifter value */
result = (result | 0x0f00) ^ (state->m_hdc68k_shifter_state << 8);
/* merge in the wheel edge latch bit */
if (state->m_hdc68k_wheel_edge)
result ^= 0x4000;
state->m_hdc68k_last_port1 = result;
return result;
}
Then in mame the Key you define for '2nd gear' will act like a shift up, and the key that you define for '1st gear' will act like a shift down. Also, while your defining keys in mame, define the clutch key as the same keys as you chose for the '1st gear', '2nd gear' and 'turn key'. That way you should be able to make really quick smooth shift changes whilst automatically pressing the clutch down.
I think that is everything :)
Post by: huwman on September 08, 2013, 04:20:42 am
I've recompiled mame with your file as described, but am still getting the floating centre point issue. Are there any setup options I might have missed? Thanks for any further guidance.
Post by: geecab on September 08, 2013, 05:31:06 am
Post by: huwman on September 08, 2013, 08:48:38 am
The game I've tried it with so far is SCI. It seems better than without the hack, but I'm not sure. I've played around with the various analogue settings in mame.
Any chance you could post a compiled version with your hack, just so I could check it's not a problem with my version? Or just the hacked file, then I could use that when compiling? Thanks very much.
Post by: geecab on September 08, 2013, 10:01:14 am
Thanks, just wanted to make sure.
>>I simply copy and pasted your text into the file over the original text, so I think I did that right too.
Yes that's all you should need to do.
I've just had a go with SCI and it doesn't work for me either. Not sure what SCI is doing differently to outrun/hangon/wecleman, but I'd have to debug it to find out.
How about running outrun, hang-on or wec le man to verify if the fix is working?
Post by: huwman on September 08, 2013, 11:48:26 am
Post by: geecab on September 08, 2013, 12:41:52 pm
Should be fine.
>>I must have compiled Mame correctly as it works, which maybe leaves my hacked ioport.c file as the culprit? i'll double check it, but if you've got one you can post that would be great!
OK, I've zipped up the exe I compiled and my ioport.c. The zipped file is called build_0145_outrun.zip and you can download it here:
http://www11.zippyshare.com/v/73958392/file.html (http://www11.zippyshare.com/v/73958392/file.html)
Hope this helps! :)
Post by: huwman on September 08, 2013, 04:15:49 pm
If you ever get a chance to look at SCI please let me know. I'll do whatever I can to help, but as you can probably gather, I'm a total novice! This really should be implemented in MAME as it improves the experience of playing these games so much.
Thanks again!
Post by: geecab on September 09, 2013, 03:56:59 am
>>This really should be implemented in MAME as it improves the experience of playing these games so much.
Cool, I agree too :) I think I'll try and come up with the cleaner solution for it at some point, making it work in the latest version of mame too (ioport.c stuff changed quite significantly in v0147, which is why I've just stuck to editing the old v0145 source), then submit it to the mame team and see what they say.
Post by: huwman on September 09, 2013, 03:52:01 pm
I've tried messing around with the dipswitches on SCI in MAME, as there are options for 360 or 270 wheels, but it doesnt seem to make a difference. I also tried Superchase Criminal Termination, as its part of the same series, and that has the same problem.
But Chase HQ works fine, and so does Power Drift!
Thanks again, and I'm looking forward to hearing if you can make any progress with SCI!
Post by: geecab on September 09, 2013, 06:30:46 pm
Here what my apply_analog_min_max function looks like now (there just one line that is different from the original outrun hack):
Code: [Select]
INT32 spin_history = 0;
INLINE INT32 apply_analog_min_max(const analog_field_state *analog, INT32 value)
{
/* take the analog minimum and maximum values and apply the inverse of the */
/* sensitivity so that we can clamp against them before applying sensitivity */
INT32 adjmin = APPLY_INVERSE_SENSITIVITY(analog->minimum, analog->sensitivity);
INT32 adjmax = APPLY_INVERSE_SENSITIVITY(analog->maximum, analog->sensitivity);
/* for absolute devices, clamp to the bounds absolutely */
if (!analog->wraps)
{
if((analog->field->type == IPT_PADDLE) || (analog->field->type == IPT_AD_STICK_X))
{
value = value + spin_history;
spin_history = 0;
if(value > adjmax)
{
spin_history = value - adjmax;
value = adjmax;
}
else if(value < adjmin)
{
spin_history = value - adjmin;
value = adjmin;
}
}
else
{
if (value > adjmax)
value = adjmax;
else if (value < adjmin)
value = adjmin;
}
}
/* for relative devices, wrap around when we go past the edge */
else
{
INT32 range = adjmax - adjmin;
/* rolls to other end when 1 position past end. */
value = (value - adjmin) % range;
if (value < 0)
value += range;
value += adjmin;
}
return value;
}
Anyways, I've zipped up the exe I compiled, and my ioport.c. The zipped file is called build_0145_sci.zip and you can download it here:
http://www7.zippyshare.com/v/18199545/file.html (http://www7.zippyshare.com/v/18199545/file.html)
Hope this helps! :)
Post by: huwman on September 10, 2013, 03:49:33 pm
This happened once after the car had spun out, but the other times started to happen towards the end of the level when driving next to the train. It almost seemed like the appearance of the train triggered the centre to drift! I'll play it through several more times and see if any patterns emerge.
Thanks again!
Post by: huwman on September 11, 2013, 09:54:41 am
Post by: Marcoqwerty on February 07, 2017, 05:26:04 am
Sorry if i resurrected this old 3D but i'm really interested to know if there are some news about it....or if with new mame version this kind of "issue" was solved or improved....
Actually i'm working on a Original Jamma Driving Upright cabinet to convert it on a mame cab.
Thant you for your work dude!
Post by: geecab on February 09, 2017, 05:13:37 pm
To be honest, I got a bit side tracked with other projects and forgot about submitting anything to the mamedevs about this :p I shall post something to them soon I think (Will post a link on here to the thread when I do).
Out of interest, what sort of wheel are going to have in your mame cab (360 or limited turning circle)??
:)
Post by: Howard_Casto on February 09, 2017, 06:30:56 pm
Post by: Marcoqwerty on February 19, 2017, 12:08:19 pm
Hi! Thanks for the interest! I'm still running my mame cab with a 360 wheel with my hacked versions of mame - I am still happy with them.
To be honest, I got a bit side tracked with other projects and forgot about submitting anything to the mamedevs about this :p I shall post something to them soon I think (Will post a link on here to the thread when I do).
Out of interest, what sort of wheel are going to have in your mame cab (360 or limited turning circle)??
:)
Ehiii thank you for reply me!
About your question, is a bit hard to answer....i had found this old "original cab" (maybe an italian remake of CISCO HEAT)with a WORLD RALLY (GAELCO) jamma board, and the pinout was set to ANALOG CONTROL (in this kind of jamma you could setup 3 way of control joy/analog/digital ).
My wheel are 360 suppose analog (see the image below), maybe in the beginning there is digital, with a pcb for convert the signal....
I love your project, and SEGA MONACO GP it's one of my first game i would play on this cab, SPY HUNTER is the other (i will change the original gear maybe to another with some button, the TURBO SWITCHER could be working.....)
At the moment i miss the monitor, so i cant make any hardware test, i plan soon to add a PC with MAME (arcadevga and other interface to old controls) without removing the original jamma harness.
I would use both....jamma original and pc!
Post by: baritonomarchetto on February 19, 2017, 04:15:03 pm
If the pcb was set to stick, would you suppose your wheel was a digital stick?
Post by: Marcoqwerty on February 19, 2017, 05:26:59 pm
That wheel is optical, not analog (potentiometer).
If the pcb was set to stick, would you suppose your wheel was a digital stick?
mmm no i found the online the manual of WORD RALLY, the wheel is set to "360 steerling wheel optical"...no other clue :dizzy: dip 4 and 5 on the game settings are ON
sorry for the mistake....
http://www.gamesdatabase.org/Media/SYSTEM/Arcade/Manual/formated/World_Rally_-_1993_-_Gaelco.pdf (http://www.gamesdatabase.org/Media/SYSTEM/Arcade/Manual/formated/World_Rally_-_1993_-_Gaelco.pdf)
Post by: geecab on February 21, 2017, 06:54:07 pm
Considering your cab's current condition, I think I'd just recommend quickly wiring/hacking up an old PS2 mouse to your steering mechanism and trying a load of games out and seeing how you get on (Though I probably would recommend this approach considering its what I did with my cab! :P )
You be able to play all the driving games. Driving games such as Pole Position, SuperSprint, Buggy Boy, APB, World Rally, Turbo, My Monaco GP remake ;) - They will will all play really great. You'll also have the advantage of being able to play lots of non-driving games on it too (Cameltry, PuzzLoop, Arkanoid, Tempest, Warlords etc...).
Things like OutRun, Super Hang-On, Chase HQ, Wec-le-Mans, Daytona, Sega Rally will all still be very playable, but after a few games you'll probably get a little annoyed (as did I) with the way the steering centre position wanders (as described in this thread). If so, let me know, I'll fix my download links and you could give my modified versions of mame a try for yourself.
I see from another thread you want to play SpyHunter and considering what you should do about your current gear shifter (whether to add more fire buttons to the control panel). I also encountered the same dilemma when building my driving cab. In the end I just stuck with the Hi/Low shifter. By the side of the shifter I added 2 buttons, these buttons are 'Shift up' and 'Shift down' buttons, used for driving games that have more than 2 gears (E.g. Virtua Racing, Super Monaco GP). I also bought a bunch of cheap black push buttons on ebay that I concealed into the control panel that I use for things like the SpyHunter weapons, Daytona Car View point, Super Spint player 2 etc... Take a quick look at my "Pole Position II cab scratch build" thread as there are quite a few pictures of my control panel, it might help give you a few ideas.
Hope this helps :)
Post by: PL1 on February 21, 2017, 10:04:08 pm
Considering your cab's current condition, I think I'd just recommend quickly wiring/hacking up an old PS2 mouse to your steering mechanismIf you don't have a spare mouse but do have an Arduino, use StefanBurger's Illuminated Spinner (http://forum.arcadecontrols.com/index.php/topic,152868.0.html) firmware.
The hex firmware file is on the thingiverse page (http://www.thingiverse.com/thing:2021152).
Load the hex on the board using ArduinoBuilder.
Four wires and an optional jumper connect to the Pro Micro board:
- Ground (2nd pin, top row, blue wire)
- 5v (4th pin, top row, red wire)
- Data A (1st pin, bottom row, green wire)
- Data B (2nd pin, bottom row, white wire)
- X-axis enable jumper (3rd to 8th pin, bottom row) *not shown* Without this jumper it operates on the Y-axis.
(http://forum.arcadecontrols.com/index.php?action=dlattach;topic=152868.0;attach=355473;image)
Scott
Post by: baritonomarchetto on February 22, 2017, 12:45:49 am
The mouse hack is obsolete nowadays
Post by: Marcoqwerty on February 22, 2017, 05:31:39 am
Cool, thanks for the pics! Yes indeed you have a 360 optical wheel. By the looks of things, a few optical disk teeth are missing (Seen in your 2nd picture) so that's going to be a problem should you try and somehow get the sensor circuit working with mame...
I fixed it with a piece of plastic bottle and a bit of black paint... :P
Considering your cab's current condition, I think I'd just recommend quickly wiring/hacking up an old PS2 mouse to your steering mechanism and trying a load of games out and seeing how you get on (Though I probably would recommend this approach considering its what I did with my cab! :P )
I would to use an external controller looks like OPTI PAC, but made from an italian user (and friend) of arcadeitalia forum, the board name is SMARTASD. You can controls opti and analogs device and, with and easy external circuit, others 8 light buttons or simply game light trought mamehook. http://www.arcadeitalia.net/viewtopic.php?f=43&t=20198 (http://www.arcadeitalia.net/viewtopic.php?f=43&t=20198)
I see from another thread you want to play SpyHunter and considering what you should do about your current gear shifter (whether to add more fire buttons to the control panel). I also encountered the same dilemma when building my driving cab. In the end I just stuck with the Hi/Low shifter. By the side of the shifter I added 2 buttons, these buttons are 'Shift up' and 'Shift down' buttons, used for driving games that have more than 2 gears (E.g. Virtua Racing, Super Monaco GP). I also bought a bunch of cheap black push buttons on ebay that I concealed into the control panel that I use for things like the SpyHunter weapons, Daytona Car View point, Super Spint player 2 etc... Take a quick look at my "Pole Position II cab scratch build" thread as there are quite a few pictures of my control panel, it might help give you a few ideas.
Hope this helps :)
At the moment im in front of two working options (looking for better to play driving games and SPY HUNTER also) :
- remove my old steerling wheel and replace it with an original SPY HUNTER wheel (yes i found one), so i play definally fine SH but bad the other 360 gams (right?)
- leave the original 360 wheel and use the UP/DOWN shifter gear....with NOS butto (pic below) (for the fire on SH), and add some "view" buttons usefuls for both kind of games...
I'm totally noob for driving cab conversion....im on yours hands! :notworthy:
PS: Yes...please reup your mame version hack.... :cheers:
Post by: baritonomarchetto on February 22, 2017, 05:47:18 am
Post by: geecab on February 22, 2017, 05:54:07 pm
The NOS gear shift with the side button looks good, and its cool if you can get hold of a Spy Hunter controller too.
Unfortunately, it is fact that if you go for '360' style steering mechanism (PolePostion/SuperSprint/Arkanoid), then some 'Limited turning circle' style games (SpyHunter/Daytona/OutRun) might not play so great. And similarly the opposite is true in that if you go for a 'Limited turning circle' style steering mechanism, then '360' style steering mechanism games won't play so great (or not at all).
The problem you are going to have is building a driving cab that suits all your needs, as there is not one solution that suits everything. Everyone who has built a driving cab has had a similar dilemma at some point. I guess only really you can decide what to go for based on what games are most important to you :)
>>PS: Yes...please reup your mame version hack..
No worries. I'll try and upload them this weekend.
Post by: Thorvald on March 07, 2017, 05:12:11 pm
I'm running the latest 1.82 so I'll likely have to setup a dev environment and apply your changes to a newer build. Then also look into possible LUA methods (assuming we can get to that low of a level).
Cheers
Tim
Post by: geecab on March 08, 2017, 07:39:02 pm
Here's my mame steering hack build (Mame version v0.148 Windows 32bit).
mame_0148_geecab_hack_v1_0.zip (http://www.mediafire.com/file/ytny3pbql7odn2u/mame_0148_geecab_hack_v1_0.zip)
In the zip file there is a 'mame_0148_geecab_hack_v1_0.txt' file that reads:
Code: [Select]
Mame v0.148 Geecab Hack v1.0
============================
In this build, if you run:
mame.exe -showusage
You should see that I've added 2 new options in the CORE MISC OPTIONS section:-
-hack_steering Hack: Permanently associate the mouse's axis position at
rom start, with the game's central steering wheel
position.
-hack_gears_semiauto Hack: Allows shiftup & shiftdown for racing games that
use more than 2 gears. '1st gear' key shifts you down,
'2nd gear' key shifts you up.
Example usage
=============
To run Outrun, ChaseHQ, SCI, HangOn, SuperHangOn, PowerDrift, Harddrivin
(Compact version only), RaceDrivin (Compact version only), Wec Le Mans,
KonamiGT, etc... so that they're play better with mouse apply the following:
mame.exe -mouse -hack_steering
For Harddrivin and RaceDrivin you can also apply the -hack_gears_semiauto
option:
mame.exe -mouse -hack_steering -hack_gears_semiauto
Note. The -hack_gears_semiauto option currently only works for Harddrivin
(any version) and RaceDrivin (any version).
Source code changes
===================
I modified the following 6 files (Included in the 'hacked_src_files'
directory. Search for //GEECAB comments to give you an idea where I made
my changes):
mame0148s\mame\src\emu\emuopts.h
mame0148s\mame\src\emu\emuopts.c
mame0148s\mame\src\emu\ioport.c
mame0148s\mame\src\emu\mame.c
mame0148s\mame\src\emu\ui.c
mame0148s\mame\src\mame\machine\harddriv.c
Other
=====
You can still download the original mame v0148 source and binaries from:
http://mamedev.org/oldrel.html
Please be a little prepared as you visit the mediafire site, you might get adverts for other software appear, encoraging you to download something else. Just make sure you only click on the big green 'Download' button near to top right of the page, and the file that you download to your computer is called "mame_0148_geecab_hack_v1_0.zip" (Its 20MB in size).
Post by: geecab on March 08, 2017, 07:46:31 pm
Thanks for all the work on this! I just finished my cabinet and have a pair of spinners with the 6 inch wheel attachment from Ultimarc. Works great except for those games that hate 360's...Hi Tim! A cabinet with 2 spinners sounds cool! I bet its great for things like super sprint, warlords etc :) Unfortunately, I can't seem to build the latest version of mame anymore (I've done a bit of googling and I think its because mame's latest build environment doesn't support XP users anymore) otherwise I'd have put the steering hacks into the latest version for you. Hopefully the older version will be ok for now (Perhaps you can (like I have done) configure your cab's frontend to run different versions of mame depending on the game you select)?
I'm running the latest 1.82 so I'll likely have to setup a dev environment and apply your changes to a newer build. Then also look into possible LUA methods (assuming we can get to that low of a level).
Cheers
Tim
Post by: Marcoqwerty on March 09, 2017, 04:23:56 am
Sorry for the delay!
Here's my mame steering hack build (Mame version v0.148 Windows 32bit).
mame_0148_geecab_hack_v1_0.zip (http://www.mediafire.com/file/ytny3pbql7odn2u/mame_0148_geecab_hack_v1_0.zip)
Ehiii!! Thank you geecab! :notworthy: :notworthy: can i upload on ArcadeItalia (the most important arcade/coin-op italian forum) server your release to avoid missing file again? i provide here the link after upload it.
Yes a new release would be better, i follow on queue to the Thorvald request....
Post by: baritonomarchetto on March 09, 2017, 05:00:16 am
Post by: Marcoqwerty on March 09, 2017, 05:40:27 am
The most important Arcade forum in Italy is arcademania.eu, as far as I know...
The first (born in 2006)....and most old (11 years) ...and with the large amount of italians users!
PS: with a own wikifiles to store the arcade project and anything else useful for coin-ops and flippers
:blah:
Post by: baritonomarchetto on March 09, 2017, 06:27:11 am
Anyway, nothing you cited make a forum significant.
Post by: geecab on March 09, 2017, 08:21:42 am
Ehiii!! Thank you geecab! :notworthy: :notworthy: can i upload on ArcadeItalia (the most important arcade/coin-op italian forum) server you release to avoid missing file again? i provide here the link after upload it.That's cool with me, post/upoad it whereever you like! :)
Yes a new release would be better, i follow on queue to the Thorvald request....
Ok I think the next step is that I shall post a message on the mame dev forum about this. See if I can encourage their developers that a mouse/steering option like this is a worthwhile addition. Its a long shot, but its worth a try. If the mamedevs do decide to add it, they'll probably make a much nicer/cleaner job of the implementation into the latest mame version than I would. I'll post my message to the mamedevs in the next couple of days, will post link on here when its posted :)
Post by: baritonomarchetto on March 09, 2017, 09:02:32 am
Post by: geecab on March 11, 2017, 01:16:03 pm
http://forums.bannister.org//ubbthreads.php?ubb=showflat&Number=109129#Post109129 (http://forums.bannister.org//ubbthreads.php?ubb=showflat&Number=109129#Post109129)
Fingers crossed :)
Post by: Marcoqwerty on May 22, 2017, 06:19:42 am
Sorry for the delay!
Here's my mame steering hack build (Mame version v0.148 Windows 32bit).
mame_0148_geecab_hack_v1_0.zip (http://www.mediafire.com/file/ytny3pbql7odn2u/mame_0148_geecab_hack_v1_0.zip)
Sorry Geecab for bother you again... i have a question about your modified version of mame, because i installed it on my driving cab.
Your version isnt a groovymame hack right? just a simple mame....because would be useful compile a groovymame version to use that on crt soft15Khz crt monitor as mine (image looks more "arcade" also the resolutions more close to real arcade)
I'm totally noob to recompiling mame, i tried a couple of windows software but no good results happens....(also i havent find any .diff on your package)
Can you have a bit of time to recompile a new version using the groovymame diff (maybe youve some dedicatd machine with all installaion stuff over it)? https://drive.google.com/open?id=0B5iMjDor3P__Wnk4SkI3cXZkbXM (https://drive.google.com/open?id=0B5iMjDor3P__Wnk4SkI3cXZkbXM) (183)
thank you for everything! youre my last chance to use this amazing hack, not all have an 360 original steerling wheen on a jamma coin-op.... :dunno
:cheers:
Post by: isamu on December 29, 2017, 07:03:05 pm
Post by: Marcoqwerty on December 29, 2017, 08:31:03 pm
This is cool but what about those of us with 270° wheels that want to play the 360° games?
You should play with mame sensibility and find the right setting "in game test mode"....but if you are on beginning to a new project, better to move on a 360 wheel imho.
Post by: Martin0037 on February 27, 2018, 10:49:08 am
Has anyone any idea if a newer version of mame has been released with this sorted or has anyone compiled a newer version of mame with geecabs hack applied?
I’ve tried your mame hack version geecab and it works brilliant, can’t seem to run newer games on it such as ridge racer or rave racer, think ridge racer was 0.159 but I might be wrong.
I’m a total noob when it comes to compiling...
Post by: geecab on March 21, 2018, 04:35:42 am
Does this sound like a good way forward? I guess first off, are you able to compile the latest mame source 'as is'?
Post by: Yolo_Swaggins on April 14, 2024, 11:02:34 pm
I was able to make a code mod that applied a offset to recenter it when this happens but once the offset is greater than 127 the wheel starts pulling to one side badly again. I tried forcing the center value of the wheels port_minmax to be sent as the wheel position at the exact moment that wheel edge =0 and then watches for wheel movement going past the center point to set it to 1 again as usual but that code doesnt seem to work maybe because the game reads the wheel positions value too fast before the mame driver can intercept it? I've been told that Hard Drivin's Airborne uses a spinner wheel in the original prototype hardware and that this is the reason why only this game has this behaviour. All the other hard drivin's/race drivin's are working fine.
Street drivin would make the car go in circles and i modded the code for that and i fixed the brake input being mapped to the wrong 8 bit ADC channel and the steering fix works on airborne to stop the car going in circles too and it's been merged into the latest version of the mame source code on github but i've been trying now for a couple of weeks to fix this bug in airborne and cannot get my code to work it's close but the maths behind it just doesn't work. I googled some keywords to see if i could find more info and found this post from 2013 where you seem to have basically made a fix for the old version of mame that im sure could fix the wheel alignment problem in Hard Drivin's Airborne. I cannot work out how to get your older code to be modified correctly to work in the latest version of mame and was wondering if you could maybe have a look at it again?
I'll post my almost working code below. It's replacing the wheel latch code in the harddriv.cpp file. I'm using a Logitech G923 wheel.
Code: [Select]
uint16_t harddriv_state::hdc68k_wheel_r()
{
static const uint16_t g_latchpoint = 0x800; // Central point for wheel detection.
static int16_t wheel_offset = 0; // Cumulative offset to adjust the wheel position based on game events.
static bool last_wheel_edge = false; // To track the last state of crossing the center.
// Read the current wheel position from the 12-bit ADC port.
uint16_t new_wheel_raw = m_12badc[0].read_safe(0xffff);
// Apply the cumulative offset to align with the game's perceived center.
int16_t new_wheel = static_cast<int16_t>(new_wheel_raw) + wheel_offset;
// Clamping the wheel position to avoid overflow and keep it within expected range. I found out that this helped stop the steering drifting off center when you hit the 2nd last checkpoint on the mountain track.
const uint16_t min_clamp_value = 0x063A; // Observed minimum value when wheel is turned all the way to the right
const uint16_t max_clamp_value = 0x09C6; // Observed maximum value when wheel is turned all the way to the left
if (new_wheel < min_clamp_value) new_wheel = min_clamp_value;
if (new_wheel > max_clamp_value) new_wheel = max_clamp_value;
// Edge detection logic to detect being at or crossing the center point using raw ADC data.
if ((m_hdc68k_last_wheel < g_latchpoint && new_wheel_raw >= g_latchpoint) ||
(m_hdc68k_last_wheel > g_latchpoint && new_wheel_raw <= g_latchpoint) ||
new_wheel_raw == g_latchpoint) {
m_hdc68k_wheel_edge = 1; // Set edge flag when at or crossing the center based on raw input.
}
// Check if the wheel edge flag has changed from 1 to 0, as reset by the game.
if (last_wheel_edge && !m_hdc68k_wheel_edge) {
int16_t new_offset_adjustment = g_latchpoint - new_wheel_raw; // Calculate the offset adjustment
new_offset_adjustment /= 1; // Significantly reduce the impact of each adjustment
wheel_offset += (new_wheel_raw > g_latchpoint) ? -new_offset_adjustment : new_offset_adjustment;
wheel_offset = std::clamp(wheel_offset, static_cast<int16_t>(-0xfff), static_cast<int16_t>(0xfff)); // Cap the offset to 3-digit hex range
new_wheel = static_cast<int16_t>(new_wheel_raw) + wheel_offset; // Reapply the updated offset.
// Re-clamp the wheel after offset adjustment
if (new_wheel < min_clamp_value) new_wheel = min_clamp_value;
if (new_wheel > max_clamp_value) new_wheel = max_clamp_value;
}
last_wheel_edge = m_hdc68k_wheel_edge; // Store the last known state of the wheel edge flag.
// Display current wheel information for debugging.
popmessage("Wheel Raw: %04X, Wheel Adjusted: %04X, Edge: %d, Offset: %04X (Hex), %d (Dec)",
new_wheel_raw, new_wheel, m_hdc68k_wheel_edge, static_cast<uint16_t>(wheel_offset & 0xFFFF), wheel_offset);
// Store the current wheel value for the next comparison.
m_hdc68k_last_wheel = new_wheel_raw;
// Return the processed wheel value, formatted as required.
return (static_cast<uint16_t>(new_wheel) << 8) | 0xff;
}
Post by: geecab on April 15, 2024, 12:19:52 pm
Unfortunately, my mind is a bit hazy regarding my hard drivin' fix/hack but will try and help as best I can.
A few things off the top of my head:
1. My fix was to make hard drivin’ play ok with mouse/spinner, rather than a SteeringWheel/Joystick (that has a fixed centre). So I’m a bit concerned that porting whatever I did back in 2013 might not help much.
2. You’re probably already aware of this, but I’ll mention it anyway - My fix only worked for the Compact British version of hard drivin’ roms (That expects optical encoders for steering, and did the weird centre point latching thing). The full cockpit versions of hard drivin’ & race drivin’ used potentiometers for steering. I am guessing when you say hard drivin’ & race drivin’ are working fine for you, that you must be using the cockpit roms? I don’t suppose there are any street drivin’ or airborne roms available for cockpit cabinets are there?
I have to say, I am fascinated to know what’s going on with this steering/latching stuff again, so at some point soon I’ll get building mame again and try to recreate what you are seeing (I’d also like to have go at street drivin’ and airborne too 😊)!
Post by: Yolo_Swaggins on April 17, 2024, 05:52:20 am
Original wheel edge bit latch code from harddriv_m.cpp here
Code: [Select]
uint16_t harddriv_state::hdc68k_wheel_r()
{
/* grab the new wheel value */
uint16_t new_wheel = m_12badc[0].read_safe(0xffff);
/* hack to display the wheel position */
if (machine().input().code_pressed(KEYCODE_LSHIFT))
popmessage("%04X", new_wheel);
/* if we crossed the center line, latch the edge bit */
if ((m_hdc68k_last_wheel / 0xf00) != (new_wheel / 0xf00))
m_hdc68k_wheel_edge = 1;
/* remember the last value and return the low 8 bits */
m_hdc68k_last_wheel = new_wheel;
return (new_wheel << 8) | 0xff;
}And this is the modification i made for Hard Drivin's Airborne to work better and stop going out of alignment so much.
Code: [Select]
uint16_t harddriv_state::hdc68k_wheel_r()
{
static const uint16_t g_latchpoint = 0x8000; // Central point for wheel detection.
static int16_t wheel_offset = 0; // Cumulative offset to adjust the wheel position based on game events.
static bool last_wheel_edge = false; // To track the last state of crossing the center.
// Read the current wheel position from the 12-bit ADC port.
uint16_t new_wheel_raw = m_12badc[0].read_safe(0xffff) << 4;
// Apply the cumulative offset to align with the game's perceived center.
uint16_t new_wheel = new_wheel_raw + wheel_offset;
// Edge detection logic to detect being at or crossing the center point using raw ADC data.
if ((m_hdc68k_last_wheel < g_latchpoint && new_wheel_raw >= g_latchpoint) ||
(m_hdc68k_last_wheel > g_latchpoint && new_wheel_raw <= g_latchpoint) ||
new_wheel_raw == g_latchpoint) {
m_hdc68k_wheel_edge = 1; // Set edge flag when at or crossing the center based on raw input.
}
// Check if the wheel edge flag has changed from 1 to 0, as reset by the game.
if (last_wheel_edge && !m_hdc68k_wheel_edge) {
// Calculate the offset adjustment when the wheel is recalibrated.
int16_t new_offset_adjustment = g_latchpoint - new_wheel_raw;
// Apply the adjustment based on the current wheel position relative to the center
if (new_wheel_raw > g_latchpoint) {
// Wheel is to the left, need to decrease raw value towards the center
wheel_offset += abs(new_offset_adjustment); // Use addition to adjust back towards the center
} else {
// Wheel is to the right, need to increase raw value towards the center
wheel_offset -= abs(new_offset_adjustment); // Use subtraction if below the center
}
new_wheel = new_wheel_raw + wheel_offset; // Reapply the updated offset.
}
last_wheel_edge = m_hdc68k_wheel_edge; // Store the last known state of the wheel edge flag.
// Display current wheel information for debugging.
popmessage("Wheel Raw: %04X, Wheel Adjusted: %04X, Edge: %d, Offset: %X",
new_wheel_raw, new_wheel, m_hdc68k_wheel_edge, wheel_offset);
// Store the current wheel value for the next comparison.
m_hdc68k_last_wheel = new_wheel_raw; // Update last_wheel to the raw value to ensure proper comparison next cycle.
// Return the processed wheel value, formatted as required.
return (new_wheel << 4) | 0xff;
}Seems to work fine in Street Drivin' too but that didn't have a wheel alignment issue after the last patch i did on it anyway and it doesn't set wheel edge to 0 when you crash so not a issue there or in any of the other ones really. This code might not play well with the compact versions because of how they do the wheel alignment I think you can just skip the wheel calibration setup and it should work anyway I applied a overclock in the source code for my own version of mame I'm testing and got the frame rate way higher in every one of them because i exceed the 400% limit on the GSP.
I made a dip switch that can toggle between 6 or 7 different types of wheel/sensitivity. I have my Logitech G923 wheel dialled in on it but not tidied the code up or labelled them appropriately yet i'll finish doing that later today or tomorrow after some sleep.
Post by: geecab on April 17, 2024, 09:49:44 am
I'm still catching up. I've managed to get mame built from github and I can run hard drivin' (compact) and airborne. I've just not hacked the code yet (But I think that's what I need to do to get a feel for what is happening). I'll start experimenting with my wheel at the weekend.
Something that has always bugged me with the compact roms, is that it is not possible (yet, I think) to successfully calibrate the wheel using the service menu. I went and did some reading/investigation, trying to work out what values to expect (When viewing the "Control Inputs" service menu) from a successfully calibrated wheel. I didn't get very far. Thought I'd post my notes as they might be of interest/help:-
Code: [Select]
Compact harddrivin service manual (HDC_TM-329_2nd.pdf):
041787-02 Steering Encoder Disk.
043807-02 Centering Encoder Disk.
HDC_TM-329_2nd.pdf, From the "Control Inputs" service menu:
As you turn the steering wheel clockwise, the hexadecimal number should increase and change to zero once every turn.
As you turn the wheel counterclockwise, the number should decrease. Everytime the steering wheel passes the center position,
the words center edge should change from blue to green.
HDC_TM-329_2nd.pdf, from a section near the end about installing a new encoder wheel:
Install the steering wheel with the center spoke down. Make sure the single hole on the centering disk is between the opitcal reader on the centering
PCB so the steering wheel will be correctly centered.
From the Race Drivin' Compact Manual, for the Main Board Memory Map, it says:
OPTO: Optical Steering Wheel Reader
400000 (R) OPTORD Read the Optical Counter
404000 (W) OPTORES Reset the Optical Counter
408000 (W) CENRES Reset the Optical Centre Flag
I found a picture of a 041787-02 Steering Encoder Disk, and counted 72 holes. Based on this, I don't think we should see a steering value (When viewing the "Control Inputs" service menu) reported that exceeds 72 (Or maybe 144 if we are counting teeth passing as well has holes). Thus, when turning clockwise you'll see 0 increase to 72 then back to 0 etc... When turning anticlockwise you'll see 72 decrease 0 then back to 72 etc... In mame, I think we see values much greater than 72, this might cause strangeness. I think I'll try and hack things so that I force these 'ideal' values to occur at calibration.
Something odd I noticed, is that in mame when viewing the "Control Inputs" service menu and turning the wheel clockwise, I see the hexadecimal number decrease, not increase...
:)
Post by: PL1 on April 17, 2024, 10:54:59 am
Something odd I noticed, is that in mame when viewing the "Control Inputs" service menu and turning the wheel clockwise, I see the hexadecimal number decrease, not increase...Sounds like the optical data lines (A and B) are swapped, which reverses the axis.
- It could be your setup (not likely), settings, the connections in MAME (also not likely), or the axis reversal setting in MAME's Analog menu. :dunno
(https://upload.wikimedia.org/wikipedia/commons/thumb/6/68/Quadrature_Diagram.svg/600px-Quadrature_Diagram.svg.png)
Scott