Has anyone ever worked out Force Feedback for San Fran Rush/MAME?

[twistedsymphony]

I own 3 fully working San Francisco Rush Arcade machines I'm debating converting one or all of them into Racing MAME setups and I've been doing a lot of research.

The key for me is I want to be able to continue playing San Fran Rush in these cabs with as near perfect emulation as possible... and that include Force Feedback.

I know the sticky states "Force Feedback - Not supported in MAME", however I was wondering if it's possible to use something like MAMEHooker to get FFB output, or if there is anyone actively working on getting FFB outputs from MAME?

I was also wondering, on a technical level, what exact is missing from MAME that is preventing FFB from working? I do have software development experience, though I spend most of my time writing database applications, I wouldn't mind at least seeing if there is anything I can contribute to a solution.

For me a Racing MAME setup isn't worth doing unless I can get FFB from my San Fran Rush.


FWIW I already have a pair of Global VR Immersion PCBs that I can use to interface the original Arcade system with a PC.

[Howard_Casto]

Before  you get your hopes up, I don't think you understand how mamehooker works.  Mame has an output system that by itself does absolutely nothing.  All mamehooker does is communicate with that output system.  So if it doesn't work in mame, it doesn't work in mamehooker, that's the deal. 

SFR has rather complex FF, I've never attempted to work on it.  Feel free to have a go if you want to though.

[twistedsymphony]

Thanks for the reply. So if I understand what you're saying MAME itself isn't generating any signals that MAME hooker can latch on to?

I thought that outputs in MAME were enabled as of version .110? Is this a problem with the specific drivers for the particular games that feature FFB or is it something else altogether?

[BadMouth]

(was typed before Howard's reply)

There's no workaround.   

No one is working on it as far as I know.  What is missing varies by driver.  Some don't have the ffb boards emulated, some with simple shaker motors and such just need the outputs "hooked up" (I don't really know what that means).
I'll leave any further explanation to someone more knowledgeable about coding MAME.
Check out Howard's MAMEHooker threads in the software forum for a little insight.

There is an obscure PC version of Rush the Rock out there that has force feedback, but it didn't resemble any feedback in the arcade game IMO.
The game is rare because it only worked with one video card on the market when it was released, but you can find it online packaged with a glide wrapper that allows it to run.  It has a bunch of weird quirks where you have to press a key to enable analog control, then another to switch it to steering wheel control.  This isn't done until after the race starts.  I was working on an autohotkey script to automated it, but have had too many other things to work on recently.  With some tweaks to the glide wrapper, you can get it looking like the original arcade game.
In summary, the game is worth checking out, but is a PITA to get working with analog controls and the ffb seems to include engine vibration which gets annoying.   

[Howard_Casto]

Thanks for the reply. So if I understand what you're saying MAME itself isn't generating any signals that MAME hooker can latch on to?

I thought that outputs in MAME were enabled as of version .110? Is this a problem with the specific drivers for the particular games that feature FFB or is it something else altogether?

No the output SYSTEM was enabled as of .110.  Outputs have to be added on a game by game basis.  As Badmouth said, sometimes it's a trivial matter of finding the memory address and linking it to a output function (aka hooking it up), sometimes the data is encrypted and it has to be sorted before we can use it and sometimes, as in the case of SF Rush, the game had a dedicated pcb that was used just for outputs that hasn't been emulated in mame. 

Aside from me, there isn't a whole lot of interest in the MAME dev community in terms of hooking up outputs that do anything complex.  It worked so much on it over a period of 1 year that I burnt myself out on it and haven't returned to work since. 

[twistedsymphony]

Ok, that makes a lot more sense. Thanks for the explanation.

[synonym9]

If I did not get you wrong you ask for racing games in mame in general....not only for your particiular game.

There are many games on youtube that say FFB works, for example (how I stated, I am not sure if I did understand the conversation right):

[twistedsymphony]

If I did not get you wrong you ask for racing games in mame in general....not only for your particiular game.

There are many games on youtube that say FFB works, for example (how I stated, I am not sure if I did understand the conversation right):

I was asking about both the status of FFB in MAME and of SF Rush Specificially...

MAME isn't being used in either of those videos you posted. Daytona is likely being emulated by Nebula's  Model 2 emulator: http://nebula.emulatronia.com/ which does indeed support FFB but it's not part of MAME.

The second video you posted is running a PS3 so it doesn't even have a PC at all.

I know you can get FFB output for many games but I was specifically asking about games that are being emulated by MAME.

[synonym9]

From what I understood is that he had a PS3 AND a PC running on it....but its useless as I now understood now what you are after... sorry.

[twistedsymphony]

So over the weekend I spent a lot of time reading through documentation on how FFB works at an electrical level... specifically the Happ equipment used in SF Rush and other games.

I always assumed that it was a complex system that used a stepper motor and took into consideration wheel position etc. but it's nothing like that.

For anyone that's curious it's really pretty simple...

there are 2 values, direction and intensity.

on the Happ driver board this is delivered as 5 bits: bit 1 signifies left or right, bits 2-5 is just a binary number signifying the intensity in that direction. the actual game hardware itself is responsible for reading the wheel position and then calculating how that factors into the FFB output.

Other systems, (like the FFB used on the Gamecube) have a single numb value 0-255 that signifies both direction AND intensity so 0 is full power left, decreasing with each number until 127 which would be neutral/no force and then increasing with each number until 255 would be full power right.

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

I would suspect that most FFB motors are some variation of this... so looking for FFB output in memory is just a matter if finding values for direction and intensity.

Maybe this is old news to some of you but I'd never seen it explained out anywhere. Now that I actually understand how FFB works it seems like it will be less of a challenge to get it working.

[isamu]

Very interesting info Twisted.

[Sky25es]

Aside from me, there isn't a whole lot of interest in the MAME dev community in terms of hooking up outputs that do anything complex.  It worked so much on it over a period of 1 year that I burnt myself out on it and haven't returned to work since.

First of all, thanks Howard for this indispensable piece of software. 
It was the main reason for me to buy a pair of namco light guns and I still have hopes about seeing the outputs for games like time crisis hooked up sooner or later.
It's really a pity that there are so few devs interested in this Project but I'm pretty sure that a big part of the MAME community (me included)  is really grateful about what you have done.
So please, since you have come so far, don't give up now.

[Howard_Casto]

So over the weekend I spent a lot of time reading through documentation on how FFB works at an electrical level... specifically the Happ equipment used in SF Rush and other games.

I always assumed that it was a complex system that used a stepper motor and took into consideration wheel position etc. but it's nothing like that.

For anyone that's curious it's really pretty simple...

there are 2 values, direction and intensity.

on the Happ driver board this is delivered as 5 bits: bit 1 signifies left or right, bits 2-5 is just a binary number signifying the intensity in that direction. the actual game hardware itself is responsible for reading the wheel position and then calculating how that factors into the FFB output.

Other systems, (like the FFB used on the Gamecube) have a single numb value 0-255 that signifies both direction AND intensity so 0 is full power left, decreasing with each number until 127 which would be neutral/no force and then increasing with each number until 255 would be full power right.

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

I would suspect that most FFB motors are some variation of this... so looking for FFB output in memory is just a matter if finding values for direction and intensity.

Maybe this is old news to some of you but I'd never seen it explained out anywhere. Now that I actually understand how FFB works it seems like it will be less of a challenge to get it working.

Yeah that's pretty standard stuff.  Although they don't get any credit for it, Sega kind of invented FF. The GC stuff you are describing is their method.  It's actually an interleaved byte... with an intensity of 0-9 (sometimes more resolution, sometimes less) and a directional bit.  When I see these in mame I split them into directional outputs and power outputs.

But that's if you have access to the unmolested byte(s) in memory.  This isn't always the case (see my old mame output wip on the software forum and the nightmare to hook up stuff like terminator 2). 

If I remember correctly, the correct bytes to tell SFrush that the FF board is installed aren't even there, so there isn't any way to get to the byte.  That's usually the roadblock we run into btw.  Most arcade games with add-on boards do various checks to determine if the board exists.  If mame has the bootup sequence faked, the output memory addresses are written to and we can hook up outputs.  If they aren't there isn't anything we can do unless we can find documentation on the bootup sequence.

[twistedsymphony]

Yeah that's pretty standard stuff.  Although they don't get any credit for it, Sega kind of invented FF. The GC stuff you are describing is their method.  It's actually an interleaved byte... with an intensity of 0-9 (sometimes more resolution, sometimes less) and a directional bit.  When I see these in mame I split them into directional outputs and power outputs.

But that's if you have access to the unmolested byte(s) in memory.  This isn't always the case (see my old mame output wip on the software forum and the nightmare to hook up stuff like terminator 2). 

If I remember correctly, the correct bytes to tell SFrush that the FF board is installed aren't even there, so there isn't any way to get to the byte.  That's usually the roadblock we run into btw.  Most arcade games with add-on boards do various checks to determine if the board exists.  If mame has the bootup sequence faked, the output memory addresses are written to and we can hook up outputs.  If they aren't there isn't anything we can do unless we can find documentation on the bootup sequence.

Thanks for the insight! I'll check out that thread on Software forum.

I have 3 full SF Rush machines, I'm looking to pickup a logic analyzer in the near future so maybe once I get that in I can see what's going in and out of the FFB PCB during the boot sequence.

It really doesn't seem like anything special. It's just an off-the-shelf Happ Force feedback board. It's got one cable with the pins for intensity and direction, the 2-pin 24V power input and the 2-pin motor output. There is a couple of additional pins on the data cable that could be acting as a signal back to the PCB.

I'll have to see if i can find any more documentation on the Happ PCB, I would suspect that if they have a hand-shake protocol they'd be more likely to have it publicly documented than Atari would from their end.

FWIW this is the same FFB PCB used in Maximum Speed, which is an Atomiswave game (I also have a complete PCB and harness setup for this game) so that might be another avenue to understanding how it works.