idea for hacking gpwiz49 board to emulate analog shifter (Hard Drivin)

[Major Rock Hardy]

So I collected a 4 speed microswitch shifter, triple pedal set, and now I want to play Hard Drivin'.  AFAICT, there are two possible ways to go:

1. Play the upright version, but not use the clutch
2. Play the sitdown version, but somehow emulate the analog shifter using microswitches.

Well, #2 is the most appealing since I do have 3 pedals and I plan to use them.  A thought came to me yesterday that I can use a GPwiz49 board to get the microswitch shifter to appear to MAME as an analog joystick (which is what is expected for sit-down Hard Drivin').

I envision working out what signals need to be sent to the GPwiz49 board to emulate the 49-way joystick positioning and wiring up some 5V discrete logic (maybe even a PAL or a GAL) to send those signals, using the microswitches as input bits.  I haven't done any of the Karnaugh maps for the logic or anything, just wanted to throw the idea out there.  I would assume the inputs would have to be de-bounced.  Also, since the Hard Drivin sit down had a reverse gear, you could still use a 4 position shifter but add a Reverse button as another input to the discrete logic.

Am I nuts?  Am I making this too complicated?

[u_rebelscum]

Too complicated IMO.

I'd suggest trying to use mame's internal digital-to-analog input handling first, and see how well it works.  Make sure mame's gear shift AD_stick sensitivity and return to center are set very high.

Hmm, mapping your gears might be the hard part.  The gear switches are in the diagonals, correct?  IOW, gear 1 (up left) is one switch, and gear 2 (down left) is another, gear 3 (up right) etc?  If so, map* (OTTOH):

AD stick Y dec (up): gear1 not gear2 OR gear3 not gear4
AD stick Y inc (down): gear2 not gear1 OR gear4 not gear3

AD stick X dec (left): gear1 not gear3 OR gear2 not gear4
Ad stick X inc (right): gear3 not gear1 OR gear4 not gear2


This should work, but I haven't tested it from work.

*To get ORs, enter, press button(s), wait more than ~1 second (until button(s) show in UI), enter, press other button(s).  To get nots, press button twice in a row quickly (less than ~1/2 second).  To get more than one button, press those buttons either at same time or very soon after each other (less than ~1/2 second).

[brandon]

did you ever get this worked out?  you use the PC gameport with a few resistors and diode to do what you want.. or hack a USB analog fightstick.   for example, if the Y axis uses a 100k pot the 0 ohms might be left 50k is center and 100k is Right..  with some resistors hooked to the 4 switches on the shifter the positions of the axis could be simulated.  I'm not really sure why Atari used an analog shifter in the first place.. seems like overkill...

[SavannahLion]

I'm not really sure why Atari used an analog shifter in the first place.. seems like overkill...

Probably to better simulate a real car. I don't know how much of the shift Hard Drivin is picking up on, but I understand that a lot of effort went into simulating the dynamics of the car as accurately as possible. It would make sense to use an analog shifter rather than a switched one. Most real world manual cars aren't equipped with a slapstick or soft shifter.

[Xiaou2]

Durability, Costs(?), and Ease on Operator maintenance.

  Youd need 5 heavy duty switches... and because the way there is limited
space in there, the way that they are mounted is not an easy task.   That
would also make changing a switch more difficult.

 If a single switch failed... you would not be able to make the time limits
on the game.   It would also be hard to for an Op to keep checking on
them.

 The pot based shifters work amazingly well.. and are very durable.  If a
pot goes bad,  people will complain much more as it will take out
more than gear one at a time.
 
 I used to have to work on these things... and I can say that the Daytona
Usa shifters, which used mini micro switches were always breaking
down.   While I might have had to change the pots once in my 3yrs
service in Race Drivin. 

 Other thing to consider - is that they may have had the plan to
make a shifter plate upgrade in the future - adding more gears
into future revisions, or have other racing games using that same
hardware.   I have to say, Its my favorite shifter.  Its nice
snap lock feel as it goes into gear is beautiful.  The motion
and throws  (pivot points / leverages ) of the thing is great too.   
Its also built like a tank,  not failing easily, even under the most abusive situations.


 I wish they would Fix mames shifter situation.   Adding a MODE to add 
"HELD DOWN BUTTON"  so that a button is always on = Hi,  and letting it
go = Low.    While there are only a few keys on the keyboard that you
wouldnt mind being held down (caps lock, shift, insert?) one can easily
use Gamepad buttons without any windows issues when exiting.

 Mames current situation does not know what the actual switch
position is (in many games).   If you start mame with your shifter in low gear,
mame may think its in High gear.   This does not happen in the real
machines, cause they do not use a phony Toggle mode. 
They are wired to know which is which.

[SavannahLion]

I wish they would Fix mames shifter situation.   Adding a MODE to add 
"HELD DOWN BUTTON"  so that a button is always on = Hi,  and letting it
go = Low.    While there are only a few keys on the keyboard that you
wouldnt mind being held down (caps lock, shift, insert?) one can easily
use Gamepad buttons without any windows issues when exiting.

 Mames current situation does not know what the actual switch
position is (in many games).   If you start mame with your shifter in low gear,
mame may think its in High gear.   This does not happen in the real
machines, cause they do not use a phony Toggle mode. 
They are wired to know which is which.

I always found that to be humorous. MAMEDev seem to really push hard on accurately simulating the hardware for these machines, but there seems to be some hesitation to accurately accept input for very specific parts, like the shifter in question, and give us command line access to enable them. I think I understand that the MAMEDevs want to code for the lowest common denominator, but there are some arcade games that simply cannot be accurately simulated without the necessary hardware.

In any case, I've been told by some people that some analog control input do exist in code for certain games, but are commented out. One would need to examine the code, re-enable them and recompile. Unfortunately, I don't recall which games are like this except for Pole Position's pedals.

Edit: for clarification

[u_rebelscum]

I always found that to be humorous. MAMEDev seem to really push hard on accurately simulating the hardware for these machines, but there seems to be some hesitation to accurately accept input for very specific parts, like the shifter in question, and give us command line access to enable them. I think I understand that the MAMEDevs want to code for the lowest common denominator, but there are some arcade games that simply cannot be accurately simulated without the necessary hardware.

I felt the same way, but then tried to edit mame for a few special-inputs games.  The problem is windows input system.  (Actually all computers input systems.)  Mame has to use it, and gets all the limits of it.  There is no way in modern OSs for mame to directly talk to the input devices like real arcades did.  Thus making any attempt to "accurately emulate" the original inputs to really be simulating the inputs.

So why should a dev program for an input device he does not have, which wouldn't work without special drivers, when a 20 line hack will do the nearly the same thing on what they have to test with?

720 is an example where mame went from almost accurately emulating (one dial axis instead of one normal spinner aixs + one index axis), to a much more user friendly simulation but far less accurate emulation of the original input (analog joystick to dial translation), and 99% of the users were happier.

[brandon]

...and 99% of users would be happier if Mame would make use of 3D acceleration instead of emulating 3D hardware at 5 FPS... but I dont see that changing anytime soon    but anyways... with all the specialized hardware interfaces (optical, analog, and digital) from folks like Ultimarc and Groovy Game Gear couldnt Mame more closely emulate the hardware now?  I know Mame can't directly "talk" to your spinner because of all the layers of OS but couldnt Mame read raw data from some of these speciallized devices by way of USB?  I guess as it is now optical interfaces show up as a mouse to the OS but that's just for simplicity sake right?  I wish there was a way to eliminate the sensitivity settings and other "conversions" in Mame and just have the Mame driver read "pulses" from the actually hardware.. be it an arkanoid spinner, 720 stick, pole position wheel.. etc...

[u_rebelscum]

... all computers input systems....  Mame has to use it, and gets all the limits of it.  ...

So why should a dev program for an input device he does not have, which wouldn't work without special drivers, when a 20 line hack will do the nearly the same thing on what they have to test with?

... with all the specialized hardware interfaces (optical, analog, and digital) from folks like Ultimarc and Groovy Game Gear couldnt Mame more closely emulate the hardware now?  I know Mame can't directly "talk" to your spinner because of all the layers of OS but couldnt Mame read raw data from some of these speciallized devices by way of USB?  I guess as it is now optical interfaces show up as a mouse to the OS but that's just for simplicity sake right?  I wish there was a way to eliminate the sensitivity settings and other "conversions" in Mame and just have the Mame driver read "pulses" from the actually hardware.. be it an arkanoid spinner, 720 stick, pole position wheel.. etc...

As I said, each device would need a special driver.  And even if it had a special driver, the driver would be doing the simulating the so-called "pulses".  ("Pulse" is the wrong term, but close enough for now.)  Well, unless the device had special firmware that didn't send standard USB mouse info, but "pulses".  And even then the original "pulses" would be simulated over the digital USB limits (speed, latency) & through USB driver & USB chip & PC mainboard & OS, vs the direct wiring of the arcade device to the PCB.  After all that, mame would need another major overhaul on the inputs code to handle the simulated signals, including emulating chips and discreet circuitry it doesn't emulate yet (aka possible slowdown, especially for boardline systems). 

Mame is just too far from the input devices for a true emulation of the original hardware.  And why add the extra work of writing a driver and new firmware and emulation code, the first two to stop the mouse firmware from doing what the emu code does?  (IOW, "why re-invent the wheel?")


Can mame come as close as the original hardware with all the limits of modern OSs?  Most games*, yes with simple hacks and proper hardware.  Can mame do it without breaking current support of 99% of the user's hardware?  Only with ugly hacks that go against mame's policies. 

Not to sound against what you want.  I tried adding better support of original hardware in my builds, but the number of different inputs and the different ways they could be done were too much for me to keep at it.   I still want to do it, but need to find a manageable way so I don't burn out again.

*The one original input that would need MAJOR coding (and USB 2 probably isn't precise enough latency-wise anyway), AFAIK, is arcade lightguns.

[Xiaou2]

 
 I dont see why it has to be an Ugly hack to be able to support dual means
of control input.

 Already,  most games support input of either Digital or Analog for any control.

 Already in mame,   there is a system of  'And'  and  'not'  in the control
logic...     and why would it  be so hard to insert a  'held down'  logic in
there?

 Meaning:

1)  Press tab
2)  Select button 1  (shifter)
3)  Press joystick button 3 down (putting your shifter into Hi gear), and hold it there
for 5 seconds
4) then put the shifter back to low gear = switch turning Off & mame accepting it.   

 Mame now would accept that this input must be held down for it to be active,
and would toggle the gear when its let up (off).


 But in reality,  the real 'hack'  is the current driver situation.   Having a button
to toggle the shift is not true... and really is Ugly.

 One could say that all the games should operate as the arcade...  maybe having
Caps lock as the default  Hold-n-release  button.   (can change it as said above)

 And the Cheat method (current mame method)  would be to just press
any key and release it in less then 5 seconds.    This would activate the
toggle HACK.


 Is  that really too difficult for guys who already created a complicated
and and not system?   

 
 --- Edit ---

 Look how they Handle pedal inputs.

  They have a specific set of switches.

 Analog / Digital   switch.

 And then they even allow you to define things for values
of Increase and Decrease.

 
 If that it true..  which is a hack...   then why no the same for
shifters?   

 A Toggle like the analog / digital:

-------
 Shifter  (Arcade mode/Toggle mode)
 Hi    =  button 3  (held)
 Low = (na)
-------

[u_rebelscum]

Xiaou, I was slightly OT, no talking just about gear shifts, but mame's whole input system as one group (which does include gears), and using examples to the quoted questions in my post about mouse, etc.

My bad, too many different definitions.  By "hack" I meant "alteration of code".  Not "a quick job that produces what is needed, but not well" as you used it, nor "an incredibly good, and perhaps very time-consuming, piece of work that produces exactly what is needed", the opposite of the way you used it.   LINK 


With that said, I agree the current haphazard way gears are handled isn't clean code-wise.  However, I don't see any way that both makes it cleaner and without removing features needed by mamedev that only have a keyboard & mouse (the inc/dec to simulate analog inputs from digital inputs).  Your example of adding a toggle vs held down will just make the core code a lot less clean.  Less clean code is the reason I couldn't keep analog+ up to date.  OTOH, your suggestion will clean the drivers if it can be done cleanly.  Hmmm....

[Havok]

So what would be the best way to emulate the analog shifter for Hard Drivin? I recently picked up a cockpit version, and am thinking of using an apac with Mame to get it to be a Race Drivin and Hard Drivin...

[brandon]

So what would be the best way to emulate the analog shifter for Hard Drivin? I recently picked up a cockpit version, and am thinking of using an apac with Mame to get it to be a Race Drivin and Hard Drivin...

The APAC would work fine I'm assuming.. since Mame recognizes the shift as a joystick of sorts.. Heck, you could probably hack a cheap USB flight stick or even a USB gamepad as long as it has analog sticks like this one.  of course, the pots would have to be the same impedence I guess.. Ive never tried it

[brandon]

... all computers input systems....  Mame has to use it, and gets all the limits of it.  ...

So why should a dev program for an input device he does not have, which wouldn't work without special drivers, when a 20 line hack will do the nearly the same thing on what they have to test with?

I'm actually happy with the was Mame handles inputs for most games.  Mainly I just wish there was a way that you could get the sensitivity right on optical controllers without having to guess.  That's really the only reason I mentioned counting "pulses"  which I figure is the only way to get trackball and spinner games to have the right sensitivity.  Otherwise you just guess and go by feel.

[u_rebelscum]

...Mainly I just wish there was a way that you could get the sensitivity right on optical controllers without having to guess.  That's really the only reason I mentioned counting "pulses"  which I figure is the only way to get trackball and spinner games to have the right sensitivity.  Otherwise you just guess and go by feel.

Believe it or not, the bases of this is in the source.  It's still WIP and not ready for prime time, but there is :

Code: [Select]

/* how many optical counts for 1 full turn of the control */
#define PORT_FULL_TURN_COUNT(count_) \
INPUT_PORT_UINT32_PAIR(INPUT_TOKEN_FULL_TURN_COUNT, count_),
The three problems left are: find out the actual number to input for every game that needs it, edit the source to add that number, and last but not least use this number instead or or in addition to sensitivity.

That last one probably needs mame to be able to set a count (per turn) per device since this differs for device to device.

[Xiaou2]

Nice.

 Well,  in the Analog settings menu,  one could add:

----

 Teeth (none) / (count #)

ex:

1)   Teeth - none
2)   Teeth - 32
-----


     Where as there could be a certain set number as default... or
default to  'None'.   

 Press enter and Escape = none
 Press enter and left or right arrow will scroll values up or down.

 Allowing a sensitivity of Zero would solve additional unwanted values.

-----
edit: oops, disregard.  I didnt read the above post correctly.

[brandon]

Believe it or not, the bases of this is in the source.  It's still WIP and not ready for prime time, but there is :

Code: [Select]

/* how many optical counts for 1 full turn of the control */
#define PORT_FULL_TURN_COUNT(count_) \
INPUT_PORT_UINT32_PAIR(INPUT_TOKEN_FULL_TURN_COUNT, count_),
The three problems left are: find out the actual number to input for every game that needs it, edit the source to add that number, and last but not least use this number instead or or in addition to sensitivity.

That last one probably needs mame to be able to set a count (per turn) per device since this differs for device to device.

Some place I have a couple Arkanoid spinners and a Revenge of Doh  PCB...   If I find them I'll contribute to the cause

[u_rebelscum]

...find out the actual number to input for every game that needs it...

Some place I have a couple Arkanoid spinners and a Revenge of Doh  PCB...   If I find them I'll contribute to the cause

Forgot to link to this site's Spinner Turn Count page.  It has the arkanoid info.

edit: fixed quote brackets