My official MAME output wip thread.

[Howard_Casto]

I have recently made progress hooking up various outputs in mame for use with mamehooker and any other application that takes advantage of the output system.  In english this means that you can hook up games that had output devices (motors, lamps, ect..) to real output devices!

For more detailed info, see this thread:

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

Anyway, I've decided to foucs my attention to getting as many outputs as possible hooked up in mame.  I'll be posting my progress below and I welcome any comments and help anyone can give.  

Also I'm toying around with the idea of putting together a team just for this purpose.  If you would like to help, let me know.  

I'll need people to search manuals and docs to find games with outputs and give an idea of what kinds of outputs they had.  

I'll also need people to help out with the mame source for hooking up outputs.  You don't have to be an expert programmer or familair with the inner workings of emulation or mame.  You simply need the ability to compile the mame source, install mamehooker or a similar debugging tool and understand C.  

Anyway, wip is below, I'll edit this first post with any major announcements or breakthroughs.  


*update*  4/28/10
Outrun Output Hookups: (File is attached below, rename to segaorun.c and compile with latest build of mame.)
=======================
segaorun.c:  Hooked up Start and Brake lights as well as upright vibration motor and deluxe bank motor for all version of outrun.
                     Hooked up limit switches for all versions of outrun.  (Required to get past motor check).
                     Hooked up Start lamp and vibration motor for all versions of super hangon.
=======================


New Outputs already in MAME (.137u2)
====================================
Gun Output Cleanup/Hookup (Part 1) [Howard Casto]
-----------------------------------------------------
drivers\othunder.c:  Changed Operation Thunderbolt output names to something more appropriate. (They were routed to leds.)
video\rastan.c:  Hooked up output for Operation Wolf.
machine\midwunit.c:  Hooked up outputs for Revolution X.
machine\midyunit.c:  Hooked up outputs for Terminator 2.
drivers\seta.c:  Hooked up outputs for Zombie Raid.
=====================================

New Outputs already in MAME (.137u4)
========================================================
Output Cleanup/Hookup (Part 2) [Howard Casto]
-----------------------------------------------------
segas32.c:  Hooked up all digital outputs for all games (radm, alien3, radr, f1en, arescue, f1lap, jpark, slipstrm, orunners, harddunk, scross, titlef)
       Emulation needs to progress more on the analog output data before those outputs can be hooked up.

audio\mw8080bw.c:  Changed output name for desertgn to something more descriptive (Player1_Gun_Recoil)
bbusters.c:  Added new output handling functions and hooked up outputs for bbusters and mechatt
opwolf3.c:  Added gun outputs for opwolf3 (man that game is terrible)
machine\willaims.c:  Fixed existing outputs in tshoot (they needed inverted) and hooked up the rest, including the feather blower. :-D
gunbustr.c:  Hooked up all outputs for gunbstr
namcos12.c:  Hooked up outputs for all system 11 gun games.  (ptblank2, ghlpanic, tenkomor)

segaybd.c:  Hooked up all digital outputs (gloc, glocr360, gforce2, pdrift, rchase, strkfghtr), also hooked up motor/analog outputs for Power Drift and G-Loc/ Strike Fighter
       The remaining games with motors could be hooked up as well assuming emulation can progress enough to get past the error messages.

namcos2.c:  Hooked up gun recoils for golly ghost.  Also noted that the outputs for the remaining gun games are also in that area.  Someone who can find the offsets should be able to hook them up.
segas18.c:  Hooked up gun recoils for lghost.

taito_z.c:  Hooked up outputs for spacegun and made a few prototype functions to help in hooking up the remaining games.  Someone familiar with the driver should take a look.  
            I hooked up a few, but they don't work like they should according to the comments.
=================================================================

[Howard_Casto]

Ok now that I've gotten that out of the way......

I've figured out the outputs for the segas32.c driver!  This driver includes alien 3 the gun, radmobile and other favorites. 

For those following along in their textbooks:

In src\drivers\segas32.c  go to the function "common_io_chip_w" and after the line "case 0x06/2:" add the following two lines of code:

=============================
output_set_value("Player1_Gun_Recoil", (data & 0x4)>>2 );
output_set_value("Player2_Gun_Recoil", (data & 0x8)>>3 );
=============================



Looks a little too easy doesn't it?  Well unfortunately it is.  Sega gameboards have a VERY generic output implementation.  So generic in fact, that every single solitary game in the driver uses that function (thus the "common" in the title) and every single solitary game that has outputs in the driver routes those outputs through the x06/2 offset. 

In english this means that while the above code will add working outputs for alien 3, thsoe outputs will also show up for all the other games.  What's more, those outputs will actually WORK on many of the other games, only they have a different function. 

This leads to an interesting question.  Should I just hook up each bit in that section to generic outputs like "sega_out_1" and keep the uber-efficient mame functions in tact, or should I split out the data into seperate functions for each game?

Thoughts would be appreciated on that one.

In the mean time, I'm going to hook up each and every bit in that section and try to determine the function for each game and list it here.  Hopefully this will lead to answers regarding how to proceeed.

[Howard_Casto]

ok I went through every single game in the driver (UGH) and this is what I came up with:

==================================================================
*edit*
Notes removed to save space!
===============================================================

The numbers indicate the bit (in decimal) that is toggled for the data

As you can see nearly every game with outputs uses one or both of the outputs i hooked up for alien3, usually as start lamps.
Also it's apparent that another offest is also used for aditional data as I could get a response from some outputs.  My guess would be it's offset x05/2 because on the dual screen games the found outputs are always binded to the second screen.
There are two offsets that I've found so far... offset 06 is the "main" offset and it usually used for the start lamps.  Offset 0c is the second offset and it's a tad peculiar.   While it works just fine for games like rad mobile on some games a few outputs are still missing and on outrunners 0c shoots out data so fast that mame hooker can't keep up.  

Also with one notable exception, the feedback motors/pistons aren't going to work because the output board isn't emulated/hooked up right.  

That exception is out runners.  The game used a simple rumble motor attached to the steering wheel, similar to the rumble pack on the old n64.  I've already found the ouput for player 2 and sure enough, if you run off the road it blinks like mad!

So there you have it... most of the outputs for segas32.c  .... now I need to go about sorting it into outputs




EDIT:  I updated the list and the description of what's going on to reflect the new things I've figured out.

[Xiaou2]

Congrats on the work so far.   
Have been looking forwards to this forever.

  You may already know this, but I thought Id mention:

 Original Outrun had come differences:

1) Standup = Single direction motor output (like a rumble motor).
  (motor drives a piston, which slides the steering wheel assembly maybe 1cm
in each direction... which makes for a violently awesome effect. I REALLY want
to build this)

2) Sitdown Simulator = Dual Direction Motor turns a worm driveshaft.  The main
body is attached to the shaft, and as the drive turns, it pushes the body to the
left or right.

 Other Sega Feedback info:

 Super Hangon Standup: A single direction rumble motor is inside the handlebar assembly, and creates vibrational effect.  I believe it is always on during gameplay. I do not believe the speed is regulated... but I could be wrong.

 Afterburner II:

   a) Standup: Flightstick has motors. I do not recall what configuration.
   b) Motion Cockpit: 2 bi-directional motors. One for each axis.

 SubRoc-3D:

   Dual Lens LCD Shutterglasses


 I think you will find the most information in the actual manuals, scoping
out the actual controller diagrams.  I used to work on some of these, which is
why I know certain games feedback setups.  KLOV has many manuals, but others
can be scoped out in other places too.

 Some feedback listed in games may be simply Lights.
For example, The viewpoint switches on Virtua Racing. Or the cockpit lights
on Afterburner II, when a missile was heading your way.  I think Outruns
start button also blinked.  Tho, its been some time, and memory fails me.


 Also, Im curious if you have the ability and or plans to separate sound channels.
For example, Sega Turbo has 3 speakers.  The 3rd is a woofer, which plays
an engine sound.  Daytona USA, and similar games, have a subwoofer stuffed
under the seats.

 Surround sound would be great... but heck, Id install a 2nd soundcard for
4 independent sound channels.

[Howard_Casto]

Yeah, most of the games your are mentioning are on the sega x/y/z boards.  I have a lot of info on them, it's just the data is "funny" I have the opposite problem with segas32, namely the data is fairly easy to get to but I have no idea what it's going to aside from some rather cryptic debug menu labels.  If I can find the lost outputs in the list above though, I should be able to get everything but the motors and pistons working.  Unfortunately for the segas32 board, the "extra" output card doesn't seem to be emulated, or at least it's error switches aren't hooked up I haven't had a chance to check extensively.

subroc's a new one on me though... see this is why I asked for help... I would have missed that one. 

Also I don't know if you are aware, but the lamps at least, on many of the games you've mentioned, including afterburner II are already hooked up and have been virtually since the output system was added to mame.  They are used for the artwork files.  The motor data is in the same general area, but it has to be processed which is a pain in the butt on those drivers.


As for speakers... that might be a bit beyond my capabilities, but I can tell you it is absolutely possible.  Surround sound is probably out as it can't be done on the fly afaik.  By far the easiest option, as you mentioned is to route channels to seperate sound cards.  Mame already splits individual sound channels up before merging them for output so the hard work is already done. This is easily done in windows, you simply shoot the data to a specific sound card instead of the "default sound device".  I don't have a clue how hard it would be to do something like that in a multi-platform sense though.

The sound area of mame definately needs some work as there are some interesting implementations on some games.  Dragon Gun comes to mind, where each gun controller has a built in speaker and your "dragon" talks to you as you play.  I think virtually every atari racing game used the "butt thumper" method you described as well.

[Howard_Casto]

UGH... i feel like and iditot....

The common io function has a "which" variable because it's a 16 bit function and some of the values are 32 bit.
That means that some of the missing values are simply on the second half of the data which is sent seperately. 
I couldn't see them because they use the same address and offset as their "brother" outputs, so they kept overwriting each other.

I should be able to figure out this mess soon and then hopefully I can make a proper function.

[Howard_Casto]

Well I think I've figure most of it out.  

==================================
*edit*
Notes removed to save space!
======================================================================

As you can see, the data is now fairly complete.   I can't figure out hard dunk's player 3 and 6 lamps, but I think that has something to do with the specialized 3 player adaptor each side of the cab uses.  There are extended output functions I haven't explored yet and they probably are hidden in there somewhere.  

Also R. Belmont clued me in on what was happening on Out Runners.  Apparently it had some sort of display that showed the current song playing.  That explains why 0c is polluted with fast changing data.

In other words, except for the motors and pistons (which I am pretty sure arean't fully emulated yet) segas32 is in the bag!...

I'll start writing up a proper function later on.  

[Howard_Casto]

Well, I think I've got the segas32.c driver licked!!!!

I wrote two very lengthy output switches, added a few variables and bam!  All the segas32 games have working, properly labeled outputs. 

Now there is some bad news....  From what I've read in the driver notes jurassic park, and possibly radmobile and rad rally have had their extended driver boards (for motors and pistons) cludged in to get the driver working.  That means unless someone completes the emulation, I can't hook up the motor/piston outputs for those games.   

Also the outputs for player 3 and player 6 start on hard dunk still elude me. I think they are hidden in an extended io function somewhere so I'll keep looking, but they might not even be routed to a write function.  Afaik harddunk is the ONLY game on the board that uses a custom i/o adaptor, so that is definatley the cause. 

Anyway, I had to do farily extensive modifications to the segas32 driver, so my usual practice of simply posting the code you need to change isn't going to work here.  Also a diff seems redundant since I've changed so much.  I'll post the entire C file once I have finished my comments and buttoned a few more things up.

[Howard_Casto]

Segas32.c is done.... see the first post for the new .c file.

[Howard_Casto]

I fixed/ hooked up the outputs for turkey shoot! 

Apparently they were already half-way there with someone hooking them up to the ancient keyboard led system and the remaining outputs just sent to the debug string.  They were broken though as the data wasn't inverted like it should have been. 

This game has a very unique output in that turkey feathers would blow around the screen between rounds!

Again see the first post for info on how to add the outputs for turkey shoot.

[Howard_Casto]

Gunbuster had a prototype output function (general address was known, but nothing else) so I went ahead and hooked it up!

Again, see the first post for more info.

[Howard_Casto]

Namcos system 11/12 driver also had an incomplete prototype function for the gun recoils, so I hooked that up as well.  That gives us support for ghoul panic and point blank 2!!!

Again, look up top.

[bdam]

First, congrats on your progress and thanks for taking up this proverbial torch.  In the 8 or so years I've been following MAME, the setup you've been working on (MAME does the outputs, something else interprets them) has been suggested many times as the only way to get force feedback and the like.  However, without the second part (Mamehooker) existing in the standard build, few devs seemed interested in setting up the outputs.

>You don't have to be an expert programmer or familair with the inner workings of emulation or mame.
You might be well served by writing a simple tutorial of sorts on how to do this.  Just some guidance of what to look for in the driver, how to hook it up to an output, and how to test it with mamehooker.  For instance, I'd be interested in setting up Atari's Drivin' series of games but the driver (src/mame/drivers/harddriv.c) doesn't have any outputs that I can recognize.

[Howard_Casto]

Well, first off, you'd be suprised how many drivers already have the outputs completely or partially figured out, they just aren't hooked up to anything.  The two or three I did today already had the addresses figured out for the outputs... one of them even had each individual output bit address commented in the driver, it's just a matter of hooking them up.

As for the others... so long as the memory addresses we need are being parsed by something then it's realitively easy to hook up. 

Basically you look for any functions or handlers in the driver with a "_w" (for write) extension, particularly ones with comments like "unknown output" or "misc i/o data".  Then in each one you install a generic output call like:

output_set_value("debug", data);

And that's it in terms of coding... that last line is LITERALLY all the code you need to start looking.  The only key is if you are installing multiple outputs at once, each one needs a different name (like "debug", "debug1", "debug2") ect...

Then you compile, fire up mamehooker, open it's debug window and fire up the game in windowed mode and put it in it's service menu.  Generally if the game contains outputs it'll have some method of testing them in the service menu.  You run that test and watch all your installed outputs on mamehooker.  If one of them changes when an output is supposed to fire then you've found it.  Then it's simply a matter of recording the values you get and turning them into individual outputs.  Generally this means checking a bit in the byte (the "data" variable) and using that to set the value. 

for example

output_set_value("output_1", (data & 4)>>3);
output_set_value("output_2", (data & >>4);

will "bind" output_1 to the value 4 and output_2 to to the value 8.  So when "data" has a 4 or an 8 in it, these outputs will fire, otherwise they have a value of 0.

But I can help with the part (it can get hairy sometimes).  The important thing is finding that function that the output data goes though.  After that it's all gravy.

[Howard_Casto]

Well... rail chase is the next gun game to hook up, so I'm working on the dreaded sega yboard driver  (gloc galaxy force 2 ect..)

I've found several of the digital outputs like start lamps, but  this might take a while.....

[Howard_Casto]

the sega y board is actually fairly logical compared to the segas32!

Although I'll have to research deeper to get some of the outputs (particularly the motors) working, i've figured out pretty much all the outputs already.
Also note that with the exceptions of rail chase and galaxy force II, all the motor outputs still work even though they error out, so yes, we will get force feedback on those games!!

The output scheme is very similar to segas32 which is good as I know exactly how to write the functions.  

here are my prelimenary notes:
=============================
*edit* Removed to save space
========================================================================

[Howard_Casto]

Well I THINK i've got powerdrift figured out. 

I'm having trouble because I can't find a manual for the deluxe version though.  Maybe one of you guys know?

I've got two outputs created.... vibration_motor and bank_motor.  Vibration simply is the feedback (on the wheel??) and the bottom three bits are used to create the values 0-7 for a variable vibration setting.

Bank is more complicated.  It's the single motor that leans the entire cabinet left or right. 

After EXTENSIVE data manipulation i get the values -3 to 3 depending upon the intensity of the lean, with 0 being center, -3 full left and 3 full right.  Does this make sense?  Did the bank motor have different power levels??

[Howard_Casto]

I've gone as far as I can go with power drift, so I'm moving on to g-loc and strike fighter. 

The games seem to stobe/multiplex between four values on their output byte.  It was my understanding that there were only two pistons, but I guess there are four??  I've discovered that there is a direction bit for each ram (4 is down and 8 is up... both off is rest) and I'm guessing the rest is speed/ power levels??  The problem I'm having is there doesn't seem to be any way to determine which piston I'm getting data from at any one time.  I might have to setup some crazy counting variables to figure this out. 

[Howard_Casto]

Good news everyone!  I finally got everything hooked up.  The question though is what to do with the data. 

You see the main sega pcb sends data to a secondary board, which then analyzes the data and sends it to individual boards for each piston.  Then these boards finally send the fully filtered data to the various outputs of each piston.

Because mame only handles the primary pcb, the outputs I've got hooked up only send the raw data, before it gets sent along.  Go into the debug menu for g-loc and you'll see what I mean.  The bit offsets for the left and right piston is apparent right there on the screen, it isn't even normalized for the debug menu! 

What I'm thinking is to setup an extra set of normalized outputs for generic used along with the real outputs.  Without this extra step only those who happen to have a g-loc cab and just happen to have every working pcb except the main one would be able to take advantage of the output. 

I'm not going to bother posting my revised notes, because they are too complex and they keep changing hourly. 


Anyway, it looks like I might have the sega y board licked.  Also keep in mind that the board's evil step brother, the x-board uses a similar output system and it is what more popular games like afterburner run on.  ;

[bdam]

Thanks for the explanation; I played around with src\mame\machine\harddriv.c and I'm fairly sure the wheel's force feed back value is coming from the WRITE16_HANDLER( hd68k_wr2_write ) function but I can't make sense of the data.  There's a test menu in the service mode (Special Functions > Main Board Controls > Steering Wheel) that will let you send power to the motor.  Using this I get data that seems to be related but I can't figure out how to interpret it.  I realize you have other priorities but if you get a chance to take a look or give some guidance I'd be most grateful.

[Xiaou2]

If it helps...

 Race Drivin / Hard Drivin  use a special  '10 turn pot'.  It turns much more than
a typical pot.

 The steering wheel itself can turn like 6 full rotations.

 It used a pressure sensitive pad of some sort, for the brake.
 Standard pot for the gas.
 2 pots for the shifter unit. (x & y)   ((sitdown only))

 The Seat has a pot under it, so it can read where the seat is.  It also
has a very powerful electro-magnet, which locks the seat down in place.

 Actually, I believe there is also a shifter lock down coil as well.
(I think it was to make it hard to impossible to shift unless using the clutch.)

  The motor is HUGE. Its like a dryer motor, and weighs like 50lbs.
The force feedback lever can be set in the test menu.  At full strength, it can
almost rip your arms off  heh   

 There is a calibration for all the controls in the test menu.
Controls can be disabled in the test menu.

 I worked on this game a lot in both the arcade, and for a friend who has
two of them in his shop linked up.

[Howard_Casto]

I'll look into it once I get the y-board squared away. 

I've pretty well figured out all the data at this point and I have all of my functions in place I'm just having trouble getting the exact ranges, especially on power drift because the debug menu errors out and won't give me any feedback. 

I think I've gotten it as close as I can though so I'll be buttoning the driver file up pretty soon.

[Xiaou2]

I cant confirm this yet, but I have a feeling that powerdrift had both a
one-way motor for shaking the steering wheel AND had a cabinet tilt motor(s?).

 The shaker motor may have had a speed control on it as well.

 I believe the cabinet motor was always one speed, because I believe it used
a worm drive, which is slow in nature, but very powerful, so wont slip no matter
how much mass is in the seat.

[Howard_Casto]

Yeah I already knew that much, I just couldn't figure out if it used one or two motors for tilting.  I'm pretty sure it's just one now. 

It's much more primative than I would have thought though.  It's a 7 position motor... that's it!  So you have centered and 3 stages of tilt in either direction. 

Now gloc and strike fighter have 27 stages of tilt in each ram (supposedly 32, but in practial terms you only get 27) which sounds more like it. 


I wish I could get the r360 version working.  Somebody mapped the pitch and roll outputs to inputs and I'm having trouble reading them.  On top of that one of them isn't hooked up to the right address anyway.  I could probably fix it, but I'd have to modify mame's address maps and I'm not super comfortable with that.

[Howard_Casto]

Ok, sega y board is done!

I've got a few comments to add for documentation purposes, but I'm ready to take on another driver.  I'll look at the harddrivin driver next since I was asked. 

[Howard_Casto]

Ok.... you were correct in finding the right function for hard drivin BUT I'll tell you straight out.  This is easily the most complicated thing I've ever seen in terms of outputs.  This looks like a drier we should save till last to me.  I could easily spend months on it.

Honestly this one is so complex I don't think we'd be able to figure it out without a harddrivin cabinet and a multi-meter.

Sorry

[Howard_Casto]

Well moving on I've went to the next analog gun game on my list and it led to (suprise suprise) yet another sega driver. 

This time segas18, which driver-wise looks almost identical to segas32.  Hopefully this means it won't take long. 

[Howard_Casto]

Well that was quick!  segas18  is done!  Unfortunately laser ghost is the only game in there with any outputs, but hey... that's one more game!!!

[bdam]

Thanks for looking Howard, I appreciate the effort.   Out of interest, what makes it complex?  Is it finding the right memory address, deciphering the data being sent, or some other such thing?

[Howard_Casto]

Thanks for looking Howard, I appreciate the effort.   Out of interest, what makes it complex?  Is it finding the right memory address, deciphering the data being sent, or some other such thing?

Yes.   

Generally you are only dealing with a byte of data or less (0-255) or at the very least a single, static piece of data.  You have several bytes stobing/multiplexing up to 8 different values.    They aren't stable either... they seem to change without warning.  Also you don't have easily tracked actions.  On/off or even positional change data is fairly easy to understand, but harddrivin seems to be the pre-cursor to directx force-feedback, what with ramps and sin waves and what not. 

[headkaze]

Do you output the data in binary format? Sure would be easier to pick out the chunks of data that way.

[Howard_Casto]

I usually assign each bit to a seperate output yes.....  but there's simply too much data moving too quickly in this case. 

Take the trouble I had with terminator 2 and multiply it by about 10 because it strobes just as quickly as term2, only there is 10 times the data!

[Howard_Casto]

On another note, I think I've finally been defeated.   

Taito_z was the next driver on my list and even though I pretty much know where the data is, my inexperience in writing drivers is keeping me from finshing.  None of the memory addresses are actually hooked up to functions so read write structures would have to be made from scratch.  I thought I had some defianed properly, but I must be doing something wrong because while they work in service menu, they don't in the actual game. 

Someone with more mame-related programming experience should really look at this one.  Many outputs have already been discovered and put in the comments, they just need to be hooked up. 

Oh I did find a single output.... dblaxle apparently has an undocumented rumble motor.  Look for where the chasehq lamps are.  Simply xor for "data & 4" to use it.  A state pointer needs to be installed first though and a custom init for dblaxle so that the state can be set upon startup.  I tried to do this using chasehq as a guide but it broke the entire driver. 

I think I might actually be burnt out. 

I'll try to do a few more of the single game drivers, but I think it might be time to cleanup everything I've done so far and submit it. 

I think I've hooked up around 30-40 games though, so I'd say I'm doing good. 

[Howard_Casto]

Well I hated the fact that a driver got the better of me so I gave taito_z another go.  I managed to get the outputs hooked up that I had originally set out to do (space gun) so I feel like I"m making progress.  It'll just take a bit longer because the memory address are all mapped to the dreaded "noop" function, meaning I have to create everything from scratch. 

Btw just to clairfy about something earlier.... I have every intention of working on EVERY output in mame, including harddrivin.... it's just that it makes since to skip the difficult ones right now and do the easier ones first since there are so many outputs that haven't even been attempted at this point.  Once the pickings get slim, I'll go back to it. 

[Howard_Casto]

I made some more progress with the taito_z driver.  Unfortuantely some of the games still need work emulation-wize but I've done my part. 

Added the output for dblaxle and I also made prototype functions for nightstr.  They work in debug but not anywhere else, so I've went as far as I can go.  I'll button this one up and then it's on to the final game in my "analog gun drivers" list. 

[Howard_Casto]

I went on to namcos2 to hook up steel gunner and steel gunner 2.  I haven't made any progress with those two games but apparenlty golly ghost has outputs as well, they were even in the driver but simply weren't mapped to anything.  So I hooked those up. 

It should be possible to get steel gunner and steel gunner 2 hooked up as well, but I think because they are taito analog gun games the data is probably hidden somewhere wierd like the video driver.  (They use the same guns as operation thunderbolt.)

I'll look into it but at this point I'm done with my initial list.  I'll go back and re-check some of the others (now that i've learned more tricks) but it's mame submission time very very soon. 

[Howard_Casto]

My hunch to go back and look at some of the other games was a correct one. 

I had to write all new functions, in bbusters.c but beast busters and mech attack now have their outputs hooked up!

[Howard_Casto]

I realized that you guys might think I'm crazy jumping around in these drivers seemingly at random, but I do have a plan of attack.  

I thought the best way to get started hooking up outputs was to pick a style of game and go from there.  
I started with all the analog gun games currently in controls.dat

http://fe.donkeyfly.com/controls/gamesbycontrol.php#Analog Gun

As I've went down the list though, I've ran into drivers that support several games including one of my target games, and went ahead and hooked those up as well.  So all of this motion sim games got hooked up quite inintentionally as I was trying to hook up the gun recoils for jurassic park and rail chase.  

here is my current checklist:
=======================

analog gun output checklist

alien 3 = working
zombie raid = working
dragon gun = can't find any evidence that this game had outputs
desert gun = Apparently it already had an output!  It just flashed REALLY fast.  I've renamed it to something more standardized.
beast busters = working
tshoot = working
jurassic park = I checked and there isn't any evidence that this game had any cabinet model other than the deluxe version, which didn't have gun recoil.
mechatt = working
bel = game doesn't work yet
opwolf3 = working*  (Seems to be a few issues, but you could control a gun kickback with what I've hooked up.)
revx=working
othunder=working
sgunner2=can't find data
gunbuster=working
golgo 13=can't find evidence this game had outputs... other gun games in driver hooked up
rchase=working
lghost=working
opwolf=working
spcgun=working
steel gunner=can't find data
term2=working
============================

As you can see the success rate is fairly high.  I'm currently working on steel gunner 1 and 2 in the namcos2 driver. The few that aren't hooked up with the exception of operation wolf 3 aren't hooked up because I just can't prove that they had outputs so I don't know where to start.  Desert gun is particularly perplexing.  It supposedly has recoil but the game is from the 70s and pcbs weren't that complex back then.  The gun recoil on this game might have been soley solid state based, and thus have little or nothing to do with the emulated game.

Once I feel confident that I've done as much as I can to get these target games hooked up all bundle all this up and send it off to the mame devs.  

My next checklist as going to be lightgun games (some of the more modern ones have recoil) but since I've learned so much about sega drivers I might try to tackle all of them first.

[Xiaou2]

 Nice work man.

 Did you already get the Original Outrun feedback working?
(I think its system 16)

[Howard_Casto]

No... outurn has it's own seperate driver.  It's system 16 based though, so when I get to it I shouldn't have any trouble hooking it up.