Universal Gear Shifter support in MAME discussion

[BadMouth]

EDIT: Link to the spreadsheet mentioned later in this thread: https://spreadsheets.google.com/ccc?key=0ArE1chsgHXQodDd2ckdjLVY3Ujlad2tZWUpteDNtcXc&hl=en&authkey=CIrIhMwE


 

The purpose of this thread is to discuss problems with using various gear shifters with the current MAME build and how a future build might best (and most simply) address these issues.  This thread is not about using old builds or workarounds just to get the game working on your cab.  This thread is also not to ---smurfette--- about MAME or the MAMEDevs.

What I would like to do is collect ALL the issues related to shifters and come up with ideas for some type of input system that addresses them all without having to hack all the different drivers in a bunch of different ways.

I'm not talking about just adding back support for old hi/lo shifters.
I'm talking about being able to play any driving game with any physical shifter setup and have it work correctly without doing much configuring.

I can't write code.   (odd that a thread about coding an input system should be started by someone with no hope of doing it   )
I have some ideas I'll put out there, more information will come out of the discussions, & eventually maybe we'll end up with some coherent idea that's specific enough that it can act as a roadmap for someone to write the code.

Here are Derrick Renaud's quick thoughts on how a universal gear shift port might work:
http://www.mameworld.info/ubbthreads/showthreaded.php?Cat=&Board=news&Number=232699&Forum=news&Words=IPT_GEARSHIFT&Match=Entire%20Phrase&Searchpage=0&Limit=25&Old=allposts&Main=231686&Search=true#Post232699


I'm an end user, so I'm starting from that perspective.
Here are my thoughts on how it might work from the UI

Starting out with an example a little more complicated than the Pole Position shifter, take Cruis'n USA

Input(this game) , we already have

1st Gear
2nd Gear
3rd Gear
4th Gear

So basically, you need a 4 speed shifter or 4 buttons to shift properly.
Now add two more options:

Gear Up
Gear Down

These would be mapped just like any other button and would work simultaneously with the 1st Gear, 2nd Gear, etc.
Kind of like how both an actual Analogue input, Analogue Inc and Analogue Dec all work simultaneously.
I realize that in the Analogue Inc example, those are two different types of input, but both options are there and they can both be mapped and used.
This would provide a good experience to those with sequential & paddle shifters,
which is probably going to cover the bulk of users.

But what about the people who like their toggle button in the current build?
Add just one more:

Cycle Gears

This button will bump up to the next gear until it reaches the top one, then it will reverse order or cycle around.
Again, it will be mapped the same as any other input and will work simultaneously with all other inputs.

I think this makes the latching (or hold gear) unnecessary, but I could be wrong.

There may also need to be a default gear for some games (not sure which ones had a functioning neutral).
This would restore functionality to Hi/Lo shifters where only the Hi position has a switch.
For those, you'd only need to map Hi gear.

Not sure how the Hard Drivin' analogue shifter fits in there, but ideally you'd select the input and move your shifter into the position for that input, same as mapping any other control.

My $.02 to get the ball rolling.
Opinions and good information wanted, ---smurfette--- ing not.

[SavannahLion]

I think that's about right.

However, as noted in the link.

A four speed shifter may not have four switches. It may, in fact, simply use three with no switches equaling gear 1 (or whatever). This leads into my next point of...

How one would handle a switch that's held down. If the interface is mapped to the joystick, this isn't a problem as long as that button is not used for any other MAME interface. If it's mapped to a keyboard input, then you have a problem. It would go into a key repeat just as any other keyboard would.

For these people, I have serious doubts MAMEDev (or anyone else for that matter) desire constructing a special case configuration for that. To that end, the solution presents itself. Construct a circuit that translates the three button states into one that virtualizes the fourth switch

While that is fine and dandy you're still left with trying to come up with a solution that doesn't wack out MAME (or the OS) with the shifter holding down a keyboard key. That leaves the joystick option. Personally, I'm OK with mapping the shifter to the joystick rather than the keyboard. And the controller offerings by GGG and Ultimarc pack a bazillion buttons into their interface.

Ideally, I think any solution would be a combination of hardware and software.

So... without looking at the source code (I should be fixing my TV right now). An ideal interface might look like this...

Gear Down/Lo Gear
1st Gear
2nd Gear
.
.
.
Nth Gear
Gear Up/Hi Gear

Cycle gear would be handled via the Gear Up/Down buttons via a setting. For those games that simply require a cycle gear that you describe, simply map Gear Up (or Down) and set Cycle to 1. There isn't much point in dedicating a two state gear their own buttons since the behavior would exactly mimic Gear Down/Up with Cycle set to 0.

For any of this to work, MAME needs to be state aware. It needs to see that a specific button is held down, know that that represents the shifter and act accordingly. IIUC, the toggling method technically isn't state aware so MAME would simply cycle through the gears. I don't know about this. I don't have a driving cab or any driving roms installed to test this out atm.

[BadMouth]

Currently, Cruis'n USA stays in gear when a button is pressed and released (pressing again puts it in neutral).
I'm assuming it's because of the way the driver was written and not anything to do with the original hardware.

The current toggle hack in the hi/lo shifter games also doesn't register any key presses while I'm trying to configure my keys.

Perhaps something similar could be done to put the car in 1st gear and have it stay there without registering a constant key press.
I understand if the issue is doing it at the shifter port level instead of in the driver.  
Like I said, I don't know code, so may occasionally cross the line into BS with my speculation.

I'm seeing things as what goes in and what comes out.  The underpants gnomes might be involved at some point.  

[SavannahLion]

Perhaps something similar could be done to put the car in 1st gear and have it stay there without registering a constant key press.

It's possible, I recently built a circuit that does just that but.....

What happens during a virtual power cycle or game reset or whatever and the shifter is in low gear (or any other gear for that matter) and the game sets itself to a default gear? The shifter is now out of sync. This is why I suggest defaulting to the joystick interface. You can hold a button down and MAME won't care until it polls the joy.

For keyboard only users... don't know what to tell you.

[BadMouth]

I'm not sure I follow completely.  There's probably some aspect of it on the coding side that I'm not getting.
Or it could mean that it's laundry night, which involves me drinking and playing games while the washer does it's thing.

Are you talking about the gear shifter code that's sending the input to the driver becoming out of sync with the game's driver?
Like if someone goes into the service menu or resets the game while in 3rd gear?
That's something I never thought to consider.  I'll have to ponder that one for a while.

If you're talking about the physical shifter becoming out of sync, here's my logic.....
With the old hi/lo shifter, there was only one switch (on the hi side).
If that switch wasn't closed, it defaulted to low gear.  
Being in low gear is just the normal state of the game, like when no buttons are being pressed.
Think of the high gear switch as a turbo boost button.
Having the shifter in lo means absolutely nothing except that the high gear button isn't being pressed.
Same reasoning would apply to 1st gear on the 3 switch 4 spd shifter.

Thanks for taking an interest in this.
I plan to spend part of Sunday researching & downloading service manuals.
I'd like to end up with some type of spreadsheet listing all driving games, their mame drivers & pertinent info about their controls.
It should come in useful for other projects as well.

[abaraba]

SavannahLion:
- An ideal interface might look like this...

BadMouth:
- Here are my thoughts on how it might work from the UI...

He has most of that sorted out, he says:

- The Player controls UI would only show "P1 Gear Shifter Setup"
- Selecting it will open new menu that allows you to select...

* This would have to be resolved with some FAKE/REAL control scheme


1.) The only problem there is "fake/real" scheme itself. If he wants to be opening new windows in tab menu I am afraid new command line option must follow, and if that's fine then all is solved here. -- If not, there are other ways.


2.) His actual "CONCERNS" you can find at the end of that message. He says switch could be held in ON state when the UI is selected and that may mess up the UI input selection. -- I'm puzzled. Why is this concern when user can shift to second gear and release the switch on HI/LO, while 4-gear shifters only need to be put in neutral.  


I'd say the only problem in the whole story is just to somehow separate mapping of 'toggle' vs. 'normal' switch. I believe MAME UI already implements timing of input when controls are being redefined, so to map 'toggle switch' you could hold longer, while just quick tap would map 'ordinary switch'.

[BadMouth]

Another thought on the gear shift port being state aware:
It's not like we're trying to determine mario's position on the screen or which character was selected.
The gear is a switch.  The state of that switch has to be maintained in the driver somewhere.

So it might be possible to have the gear shift port get the state of that switch from the driver instead of keeping track of it itself.
Of course, it may not be identified the same way in all drivers.

[abaraba]

Another thought on the gear shift port being state aware:
It's not like we're trying to determine mario's position on the screen or which character was selected.
The gear is a switch.  The state of that switch has to be maintained in the driver somewhere.

The state of switch is polled, it's only for hack routines that need to know 'last state' so to figure out in what gear to change. This is all already implemented, hacks are there, that's how it works now. But proper routines are also there, we just need a variable to tell us what kind of input is currently mapped and execute appropriate code accordingly.


REAL/FAKE scheme is nonsense. Just like with 720 where we only need to distinguish whether the input data is 'analog' or 'mouse', similarly here we again only need to figure out whether the input is mapped to 'toggle' type of switch or not.

So it might be possible to have the gear shift port get the state of that switch from the driver instead of keeping track of it itself. Of course, it may not be identified the same way in all drivers.

I have no idea what problem you are trying to solve.


There are no problems really, only imaginary ones. We do not need any REAL/FAKE scheme, new tab menu, or new command line options. All we need here is classification of switches, and just like there is 'analog' and 'digital' joystick classification, so there should be 'toggle' and 'spring-back' type of button/switch/key.  


* Proposed HI/LO shifter mappings:

Gear Shifter ------------- Space
Gear Shifter ------------- Space (toggle)

Gear Shifter ------------- Joy_Button1
Gear Shifter ------------- Joy_Button1 (toggle)

Gear Shifter ------------- Caps Lock
Gear Shifter ------------- Caps Lock (toggle)


If the switch/key is mapped as toggle driver executes routine for authentic functionality, and if it is mapped 'normally' then driver goes for the hack, that's all there is to it. -- So, the solution to all the problems with 'shifter affair' is basically just about providing an option to map a switch/button/key as either toggle or not, and this control scheme should solve the whole problem, not only for HI/LO shifters, but 4-gear shifters as well.

[BadMouth]

The Hi/Lo thing is only a small part and yeah, the hack to the driver can be reversed.  It's been done before.

So it might be possible to have the gear shift port get the state of that switch from the driver instead of keeping track of it itself. Of course, it may not be identified the same way in all drivers.

I have no idea what problem you are trying to solve

The bulk of mame users probably play driving games with a gamepad or standard pc racing wheel.
Except for more expensive wheels, these do not have physical shifters that stay in gear.
Most of them have paddle shifters and maybe a sequential shifter on the side that works no differently than the paddle shifters.

One goal would be to give these users (who are the bulk of the user base) the ability to use their paddle shifters on games that originally had a 4 or 6 speed shifter.  To do this, there would have to be an option for GEAR UP and GEAR DOWN.  

Something would have to keep track of what gear you are in, so it would know which "fake" gear switch to throw when you press GEAR UP.

We're talking about a universal system that takes just about everything into account, not just hacking (or unhacking) the driver of every game we want to "fix"

Please just go away.  

[abaraba]

We're talking about a universal system that takes just about everything into account, not just hacking (or unhacking) the driver of every game we want to "fix"

Please just go away. 

You go away with your imaginary problems.

What you're talking about is already there, it is part of global 'analog hack'. The only thing that is not (quite) there is 'toggle' type of button. And again, we do not need fake/real scheme, all we need is proper classification and identification of input devices, so to be able to execute appropriate code accordingly. That would make everything work: authentic shifters, keys, paddles, spinners, analog sticks... since each type of device could have its own separate handling routine, if necessary.

[abaraba]

In pole position, when changing gear there comes a little window on the screen saying "HI" or "LO", which looks more like MAME user interface message than part of the game, am I dreaming?

[SavannahLion]

Are you talking about the gear shifter code that's sending the input to the driver becoming out of sync with the game's driver?
Like if someone goes into the service menu or resets the game while in 3rd gear?
That's something I never thought to consider.  I'll have to ponder that one for a while.

Yeah, that's pretty much it. It's not hard to realize. Let's say we create an virtual shifter using keyboard buttons A and Z. Press A, we go HI, press Z we go low. Our imaginary player leaves the shifter on HI and exits the game for some reason (any reason, it doesn't matter). Then the gamer reenters the game at some point. The game driver has to make a choice about what state the shifter is in. Is it HI or is it LO? Since the game driver itself did not receive the last state of the shifter it sees that there is no signal and defaults to LO even though the shifter is left on HI. Now they're out of sync. To resync, the gamer has to know to throw the shifter to LO, then back up to HI again. It's been a while, but I can't recall very many arcade games that have this type of behavior. And I'm reasonably sure no real world car does either. You'll also need to modify the joystick hardware to send a pulsed signal or to include some sort of interface board that does the same.

However, by leveraging the given properties of your joystick interface, you can safely hold the respective buttons down and properly mimic the expected behavior, regardless of whether the HI/LO shifter uses one switch or two. This does several things in one fell swoop. It allows the shifter to remain stock with little or no modification whatsoever, it guarantees existing joystick controllers remain compatible, and lets MAME decide when to poll the joystick for shifter state negating any need to hold a state based driver that isn't going to survive between restarts anyways.

If you're talking about the physical shifter becoming out of sync, here's my logic.....
With the old hi/lo shifter, there was only one switch (on the hi side).
If that switch wasn't closed, it defaulted to low gear.  
Being in low gear is just the normal state of the game, like when no buttons are being pressed.
Think of the high gear switch as a turbo boost button.
Having the shifter in lo means absolutely nothing except that the high gear button isn't being pressed.
Same reasoning would apply to 1st gear on the 3 switch 4 spd shifter.

That is exactly what my proposal encompasses. But keep in mind, you have to restrict the chosen interface. That kind of design will not work with a keyboard, period. A keyboard, within the OS, is designed to be interrupt driven. It has to. The OS needs to respond if something craps out. So by hooking up said shifter to a keyboard based controller and leaving it on HI would appear to the OS (or MAME or any other program) as a rapid series of key repeats. To prevent that, you would have to go in and tweak your OS settings (I believe Windows has it under Access settings) and that's kind of annoying.

The Joystick, on the other hand, is specifically designed to be polled. Leave it up to the program to figure out the state of the joy and it completely bypasses anything the OS might expect.

The whole fake/real scheme that keeps coming up is just nonsense. You're virtualizing the controller. That's it. There's nothing magical about it.

Again, not looking at MAME code at the moment. I think a possible solution would be for MAME to simply expose the interface the game actually expects and allow the individual community to create the necessary MAME drivers between game and UID. However, I believe Haze (in another thread) explicitly mentions that this (or something similar to this) is not what the MAMEDev community wants to do. The advantage to exposing the real game interface means that MAME can switch to a standard interface of dildos and no one will care. Maybe something akin to Windows hooks, I dunno.

I'm not entirely sure how I would want to tackle this. I might look at compiling a proper list identifying the shifter and, exactly, how they function. Without classifying or even trying to figure out how they would all interface in a standard way. Then I would examine the MAME code for each of those games and figure out what they were doing there. Then I would ultimately decided on how best to tackle the problem.

I imagine the easiest would be some form of a callback to external drivers. I can't imagine maintaining so many diffs through so many potential changes would be fun, but slipping call backs into the code might be considerably easier.

I suppose if I can ever get my Hang-On up and running again, I'll probably fabricate something that's somewhat useful.

[SavannahLion]

I'm really just speculating at this point. I don't have any driving games because I don't have a cab with a steering wheel or shifter and I'm not going to fire up my testbed and try it with a keyboard/Mouse/Joy. That would result in ---uvula--- behavior.

[BadMouth]

I'm really just speculating at this point. I don't have any driving games because I don't have a cab with a steering wheel or shifter and I'm not going to fire up my testbed and try it with a keyboard/Mouse/Joy. That would result in ---uvula--- behavior.

I think I've wrapped my head around what you were saying about the analogue joystick interface.

Speculation isn't all bad.  Sometimes it leads to a revelation. 
(and sometimes I guess it doesn't amount to anything more than people talking about things they know nothing about  )

I downloaded a ton of manuals.  I have to go be social for the rest of the evening, but tomorrow I'll try to put together a fairly complete list of games and organize them in a spreadsheet.  It will be useful.  If not for this, for other projects.

[jennifer]

   
         The steering/shifter [or a mockup] would have to be obtained, or this will become yet another mouse hack. This should be in the interest of
 preservation.... drop in replacement, But will it still need a patch for the mousers.
       Would this not require a starting over point?.....OS, Dumps, compatiblily for the future, every aspect?   

[ntk]

i add another microswitch to my high/low shifter and i can turn on and off the second microswitch by pressing a button and now i can play all games with high/low shifter

before

after

[abaraba]

Something would have to keep track of what gear you are in, so it would know which "fake" gear switch to throw when you press GEAR UP.

That 'something' is called "variable" in programming, nothing you should concern yourself with, obviously. You misunderstood what Derrick said there, it's comical you are trying to re-do what he already has done, and solve problems that do not exist.

Derrick's stated his concern clearly, he is worried someone might forget toggle switch in ON position and mess UI input. Huh.

[saint]

Abaraba - last warning. Tone your attitude down. If you can't post without belittling people don't post.

[abaraba]

Yeah, that's pretty much it. It's not hard to realize. Let's say we create an virtual shifter using keyboard buttons A and Z. Press A, we go HI, press Z we go low. Our imaginary player leaves the shifter on HI and exits the game for some reason (any reason, it doesn't matter). Then the gamer reenters the game at some point. The game driver has to make a choice about what state the shifter is in. Is it HI or is it LO? Since the game driver itself did not receive the last state of the shifter it sees that there is no signal and defaults to LO even though the shifter is left on HI. Now they're out of sync.

If you are using keyboard that would be no-issue, and if all HI/LO shifters are made with only one switch, perhaps to solve the problem you mention, then that makes it irrelevant there too.

As BadMouth corrected me before, Derrick does not map HI/LO shifters to two inputs, but only one, and I do not see any point of adding UP/DOWN set of inputs for this type of shifters at all. However, if required, it can be added like all the other hacks, which should be separate from proper function and therefore no-issue again.

If you're talking about the physical shifter becoming out of sync, here's my logic.....
With the old hi/lo shifter, there was only one switch (on the hi side).
If that switch wasn't closed, it defaulted to low gear.  
Being in low gear is just the normal state of the game, like when no buttons are being pressed.
Think of the high gear switch as a turbo boost button.
Having the shifter in lo means absolutely nothing except that the high gear button isn't being pressed.
Same reasoning would apply to 1st gear on the 3 switch 4 spd shifter.

That kind of design will not work with a keyboard, period. A keyboard, within the OS, is designed to be interrupt driven. It has to. The OS needs to respond if something craps out. So by hooking up said shifter to a keyboard based controller and leaving it on HI would appear to the OS (or MAME or any other program) as a rapid series of key repeats. To prevent that, you would have to go in and tweak your OS settings (I believe Windows has it under Access settings) and that's kind of annoying.

I agree with BadMouth here, as I explained above. That is not supposed to work with a keyboard. It's not like you are going to put a brick on top of some key to lock it down, while authentic shifter only need to be put in neutral, or 'switch-off' position and everything will be just fine.

The whole fake/real scheme that keeps coming up is just nonsense. You're virtualizing the controller. That's it. There's nothing magical about it.

I agree.

I'm not entirely sure how I would want to tackle this. I might look at compiling a proper list identifying the shifter and, exactly, how they function. Without classifying or even trying to figure out how they would all interface in a standard way. Then I would examine the MAME code for each of those games and figure out what they were doing there. Then I would ultimately decided on how best to tackle the problem.

Everything is already there except "toggle switch" classification as a type of input device on its own.

Old devices:
- Analog stick
- Digital stick
- Paddle
- Dial
- Button switch
...

New device:
- Toggle switch


With that sorted out what remains to be done is the same thing as for 720, i.e. modify each driver to identify input device currently mapped/enabled and execute corresponding function accordingly. Nothing else needs to be done and this is really a minor modification/addition to core MAME, while modifying drivers for each game using shifter is where majority of work is.

[SavannahLion]

Nothing against NTK, but that's actually something I want to avoid doing. I'd rather construct a small circuit that virtualizes that behavior rather than modify the actual hardware itself. That's why RAM Controls yoke interface is a HUGE plus and, what I feel, is a step in the right direction.

i add another microswitch to my high/low shifter and i can turn on and off the second microswitch by pressing a button and now i can play all games with high/low shifter

before

after

[BadMouth]

First step of the spreadsheet I've been talking about making is attached.
No controls are listed yet, but all the driving games supported by MAME (according to MAWS).

They are sorted by manufacturer and year.  The drivers loosely follow that for the most part..
They are separated into 3 sheets based on their emulation status; good, imperfect, & preliminary.

I apologize for it being done with Excel XP, it's what I have and what I'm familiar with.
When it's more complete, I'll try to convert it to google docs or something.

It will give you an idea of how many different drivers there are.

I'm still pondering exactly how much information to include about the controls.  It needs to be kept somewhat simple.
Right now I'm thinking-
Wheel: 360, 270, 900 or other
Pedals: Number of pedals, pot or switch based
Shifter: Number of gears, number of switches
Outputs: Lights, FFB, etc.  This will probably be a fairly long description that you'll have to click on the cell to see.

I'll enter the controls haphazardly, starting with the most popular and the games that interest me.

[jennifer]

       Concern:  Any colaborative efforts would be impeded by crossing OS"s.... I mean do we need to sync to one platform?
In another thread it was said 99% of dev"s use windows,.... Well considering the "bloat" maybe Lin\xp would be a better option.

[Paul Olson]

I don't quite understand the bloat argument anymore. 1TB hard drives are less than $70, and computers in general are dirt cheap. A $200 computer will run > 90% of the games in MAME and it will come with Windows 7.

Accurate emulation is always going to be slower than the hacks. I would never consider accuracy as bloat. XP is almost 10 years old. There is no reason to write software with XP as a target, and Linux is covered in SDLMAME.

BadMouth - controls.dat and Howard's output project should help with your list. The official controls.dat required verification from the manuals, so should be pretty accurate.

For the optical controls, I think tooth count and encoder wheel diameter would be good to list.

For Analog, the travel range in hex would be nice. Most of that info can be found in the manuals.

Converting to Google Docs might be best. If I edit it with word 2010, it might mess it up for you. I think it is just one click to convert it. The more people that see it will allow for better error checking. MAWS will be wrong in a few cases most likely, but it is a great place to start.

[BadMouth]

BadMouth - controls.dat and Howard's output project should help with your list. The official controls.dat required verification from the manuals, so should be pretty accurate.

Thanks.  I forgot about controls.dat
It's going friggin' slow using KLOV & barely readable manuals.
Most of the manuals aren't as comprehensive as I thought they'd be.

All I have so far is most of the old atari games.  (atarisy2 & sprint2,4,8 drivers)
The sprint games are cases where we have a 4 speed shifter with only 3 switches in it.
4th is the default gear this time when nothing else is pressed.
The current mame UI shows 4 gears to map.
Thought I'd mention it if you want to look at the driver and get a feel for how it was handled.

For the optical controls, I think tooth count and encoder wheel diameter would be good to list.

For Analog, the travel range in hex would be nice. Most of that info can be found in the manuals.

  you for making sense & making more work.
I wanted to do the tooth count, but had forgotten about it.

Not sure how much I'll accomplish this evening.  
I'll convert it to google docs & post a link later tonight when I've had enough.

EDIT:Not going to bother uploading anything tonight because I didn't get much more done.  No sense in posting it in 1/8th increments.
       

[huygens]

Tooth count for some of them is on the wiki.

[SavannahLion]

       Concern:  Any colaborative efforts would be impeded by crossing OS"s.... I mean do we need to sync to one platform?

Since the use of a USB interface to any hardware involved is virtually guaranteed, I see this point as nearly moot. It may have been an issue if we were still talking about serial and parallel interfaces, but there is practically 0 expectation any modern PC will even have such an interface.

In short, as long as the interface follows standard HID convention, it won't matter what OS we're on.

[ntk]

Nothing against NTK, but that's actually something I want to avoid doing. I'd rather construct a small circuit that virtualizes that behavior rather than modify the actual hardware itself. That's why RAM Controls yoke interface is a HUGE plus and, what I feel, is a step in the right direction

I do not understand what is the problem, currently this is the easiest and best solution for all games and emulators ( also pc games ), there is no significant change in hardware,just added a microswitch to the shifter

also this is what I did with my brake pedal, I have HAPP pedal with pots and i added a microswitch for brake lights,when i touch the pedal the lights go on and i not have to press it all the way, and just like with the shifter there is no noticeable change in feeling when you press the pedal or move the shifter, and of course it works in all games and not just in mame

[SavannahLion]

Nothing against NTK, but that's actually something I want to avoid doing. I'd rather construct a small circuit that virtualizes that behavior rather than modify the actual hardware itself. That's why RAM Controls yoke interface is a HUGE plus and, what I feel, is a step in the right direction

I do not understand what is the problem, currently this is the easiest and best solution for all games and emulators ( also pc games ), there is no significant change in hardware,just added a microswitch to the shifter

also this is what I did with my brake pedal, I have HAPP pedal with pots and i added a microswitch for brake lights,when i touch the pedal the lights go on and i not have to press it all the way, and just like with the shifter there is no noticeable change in feeling when you press the pedal or move the shifter, and of course it works in all games and not just in mame

I never said there was one. That's why I said not to take offense at it.

I'm saying that, for myself personally, I would prefer to avoid modifying the original arcade hardware whenever possible. It goes against my philosophy. And in a project that would collate control data (eg shifters) for the purposes of creating an easy interface, I truly believe that one of the goals should be to not modify the hardware at all. Move the heavy lifting to a control board. This would give people a true plug-n-play experience and reduce the hackery and different standards that may arise from all the different modifications. This is why I think the Ram Controls Yoke control is a step in the right direction.

However, I can accept that there may, or must, be exceptions to this ideal of mine.

[Paul Olson]

I don't think there needs to be exceptions. Additions, certainly, but I want to work for 100% compatibility with the unmodified controls. I think we should be able to get accuracy for controls, and build a system that is flexible enough to allow for different control options. I wouldn't mind a hardware interface for this either, but I am not sure it would be needed. It would be fun to try to design one board that would take care of all inputs and outputs. I am going to start shopping for shifters again. I am not sure how many different ones there are out there, but it would be nice to have them all to test. I have 6 of them now, so that will at least be a start.

I still need to upgrade my MAME cab. I just ordered an AVGA so I can finally get rid of XP 64. Once that comes in, I will get Win7 installed and get everything set up again. My 720 controller should be here by then, so I will get that testing done, then move on to the shifters. My contributions will be slow with school starting back up, but I am really looking forward to helping out with this project as much as I can.

[ntk]

Nothing against NTK, but that's actually something I want to avoid doing. I'd rather construct a small circuit that virtualizes that behavior rather than modify the actual hardware itself. That's why RAM Controls yoke interface is a HUGE plus and, what I feel, is a step in the right direction

I do not understand what is the problem, currently this is the easiest and best solution for all games and emulators ( also pc games ), there is no significant change in hardware,just added a microswitch to the shifter

also this is what I did with my brake pedal, I have HAPP pedal with pots and i added a microswitch for brake lights,when i touch the pedal the lights go on and i not have to press it all the way, and just like with the shifter there is no noticeable change in feeling when you press the pedal or move the shifter, and of course it works in all games and not just in mame

I never said there was one. That's why I said not to take offense at it.

I'm saying that, for myself personally, I would prefer to avoid modifying the original arcade hardware whenever possible. It goes against my philosophy. And in a project that would collate control data (eg shifters) for the purposes of creating an easy interface, I truly believe that one of the goals should be to not modify the hardware at all. Move the heavy lifting to a control board. This would give people a true plug-n-play experience and reduce the hackery and different standards that may arise from all the different modifications. This is why I think the Ram Controls Yoke control is a step in the right direction.

However, I can accept that there may, or must, be exceptions to this ideal of mine.

Not offended at all, there is no reason, if I did not want to hear other's opinions  I would not publish it, I just wanted to know for what reason you do not want to change the hardware (now I understand)

of course I would also preferred to have a single interface of just plug & play but for now this solution is the best I've seen (at least until there is something else ready) I had no problem changing the hardware because it is not something permanent, just remove the microswitch and go back to original hardware

[BadMouth]

Transferred the spreadsheet to google docs and I'm working on it there now.
If I understand correctly, if I make it available to anyone, anyone can edit it.  
If I "publish" it, then nobody can edit it.  Anyone use google docs?  
Is there any middle ground where everyone can see it while it's still in progress, but only a few can edit it?
(I'd rather make progress on the spreadsheet than spend time figuring out google docs)

Anyways, I came across another interesting driver we can probably learn something from.
In Max RPM (mcr3.c driver), the game was a 4 speed, but the MAME hack is two buttons for SHIFT UP/SHIFT DOWN.

Having a hard time finding info on this one.  I may end up with question marks for the number of switches in the shifter.

[Paul Olson]

I think you can set viewing to public and then select who can edit it. I will look later tonight. I haven't used google docs all that much, but it does work well for collaborations like this.

Transferred the spreadsheet to google docs and I'm working on it there now.
If I understand correctly, if I make it available to anyone, anyone can edit it.  
If I "publish" it, then nobody can edit it.  Anyone use google docs?  
Is there any middle ground where everyone can see it while it's still in progress, but only a few can edit it?
(I'd rather make progress on the spreadsheet that figuring out google docs)

Anyways, I came across another interesting driver we can probably learn something from.
In Max RPM (mcr3.c driver), the game was a 4 speed, but the MAME hack is two buttons for SHIFT UP/SHIFT DOWN.

Having a hard time finding info on this one.  I may end up with question marks for the number of switches in the shifter.

[BadMouth]

Here is the link to view the spreadsheet so far:

https://spreadsheets.google.com/ccc?key=0ArE1chsgHXQodDd2ckdjLVY3Ujlad2tZWUpteDNtcXc&hl=en&authkey=CIrIhMwE

You have to click on some of the cells to read the contents.  (contents will show up in the formula bar at the top)
I used Pot instead of 270 for potentiometer based wheels because it stood out among the 360's more.  I'm open to changes.
  
I'll probably color code it eventually.
It will be a slow process to complete it (I'd rather be doing other things), but I think it will be a good resource when done.

[jennifer]

        The idea of a blackbox circuit got me thinking about interface..... most of the games on this list use common molex, 2,4,6,...etc. with different
pinouts, so choppin" off plugs or repining plugs will become the new hardware mods. A couple different paths could be taken here, leading to microprocesser,
or RAM. controled by the cpu. Easy enough I guess, but once off the breadboard and protoed, OMG it becomes a project for your local professor. I think
I"d better sit this one out.  PS./ SavannahLion, sorry about the X/B thing.
         

[BadMouth]

I don't think an external interface would be necessary.  The shifter hacks in various drivers already handle everything we want to accomplish.  
It's just a matter of seeing how they work and applying that to a standardized way of handling shifter input (says the non-coder).

We have different segments of the user base that want different things.  It's important not to alienate any of them.
The preservationists want the way MAME handles shifter input to be representative of the way the game actually functioned.
In addition to being a more accurate record of the game, it will also allow for the original controls to function as they should.
I agree with that.

But if only the original controls work, nobody new is ever going to discover the game or be able to enjoy it.
So an alternative is needed that will cover the bulk of the user base.
Be they keyboard keys, gamepad buttons, paddle shifters, sequential shifters.  
They are all just momentary push buttons and would function the same way.

The only real need for a toggle is for someone with an old single switch shifter who wants to use it for a game that had more than one switch in the shifter.
Personally, I think it would be pretty cool to give someone with an old Pole Position setup the option to play california speed on it.  
I don't think people using the keyboard or gamepad would have a problem with two separate keys for shift up/shift dn instead of one that toggles.

Wanted to say more, but I gotta run, I'm late for work......

[Paul Olson]

Wanted to say more, but I gotta run, I'm late for work......

I hate that. Every time I have something really interesting or intelligent to say, I have to leave and can't finish the post.   

[BadMouth]

I hate that. Every time I have something really interesting or intelligent to say, I have to leave and can't finish the post.    

I can't guarantee it would have been either.  

Wanted to say more, but it's time to leave work now!  

EDIT: added a link to the spreadsheet to the first post so it would be easier to find
Progress will probably be slower on the imperfect and preliminary pages.

[BadMouth]

The only real need for a toggle is for someone with an old single switch shifter who wants to use it for a game that had more than one switch in the shifter.
Personally, I think it would be pretty cool to give someone with an old Pole Position setup the option to play california speed on it.  
I don't think people using the keyboard or gamepad would have a problem with two separate keys for shift up/shift dn instead of one that toggles.

Does anyone see an absolute need for the toggle?
It would simplify things to abandon it.
As NTK has stated, there are workarounds if someone has a hi/lo shifter with only one switch.
(you could also use the NC tab on the switch for the other position without modifying the original equipment)

If we ditched that option, it knocks it down to only two ways of doing things:

1. Input behaves as original would, including the game going into a default gear or neutral when no gear switches are closed.
    With this option there would be no latching or "holding gears" because the physical shifter stays in place and keeps the switch closed.
    You wouldn't necessarily need an original shifter, just one that has enough gears and stays in gear.

2. Shift Up/Shift Dn should work for people with a gamepad, keyboard, or paddle shifters.  These would be momentary presses, so the gears
    would have to latch and something would need to keep track of the current gear.  This option could also be used by people with 2 switch
     hi/lo shifters to play games that had more gears.     Not sure how neutral would fit in there, if it at all.

I know I'm repeating myself, but hopefully also clarifying my vision of how I think it should work.
So, back to the original question.

Is the inclusion of a "Toggle" or "Cycle Gears" even needed?

[jennifer]

        Original hardware is not really needed. Or supported for that matter. Its fact that you COULD use it. A more comprehensive overveiw is needed
here,  What games are going to live together in one cab? A hi/lo shift wont have the same feel as a 4 speed, not to mention not everyone has/wants
a old shifter on their new cab.
        So what are the options then? SAME [Single/or/ Similar].... use a hi/lo for hi/lo games... etc.
Or a 4 way, somthing everyone has acess to, yet replacable to the original. And maybe use a restrictor plate, [similar to a jukebox selector latch]
to block two gears... or not and have all four.
       

[Xiaou2]

NTKs Hack is gross and is not a tenth of the durability of the original.

 A standard size micro will outlast those smaller sized ones by over 2x.
Looks like Hot glue, which is going to give out eventually.  Should have been bolted in.
Hardware mods like this, are not always simple, possible, or good.  (IE: Just because Happs Cheezy generic shifter is easy to mod... does not mean a Sega Turbo, Spy Hunter...etc.. shifter will be easily modded.

 Its also going against preservation - by physically changing original arcade hardware... which should not be done.