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.

[Howard_Casto]

If you'll look at my checklist on the last page, I've updated it.  

Sometimes when I'm doing this a feel a little stupid and this is one of those times.  When you fire up desert gun there is an output present ("KICKER")
but it's seemingly inert during gameplay.  I didn't think anything of it because on some of these older games the outputs are hooked up badly and the output shows up for every game in the driver.  

This isn't the case, it's a working output made just for desert gun hidden over on the audio driver (not uncommon unfortuantely).  The thing fires blindingly fast, so fast that unless it's hooked up to something you'll never notice.  Once I discovered the output was desert gun specific I binded it to my 360 controller and sure enough it rumbles... it's a tiny, almost inpercievable rumble, but it's there.  I've been trying to give the guns a farily standardized name so I've renamed it to "Player1_Gun_Recoil" but it was there all along.  

Also I did some more research on jurassic park.  It seems that the deluxe, rail-chase like cab is the only one it was available in and that means no gun outputs.  If anyone has seen a conversion kit version in the wild (with force-feedback) please let me know, but for now we'll consider that game's driver complete.  

So I'm left with operation wolf 3, a game so bad with such poorly powered hardware that I'm convinced it sprang from the loins of the devil himself, and the namcos2 games.  

[Howard_Casto]

After what seems like an eternity of constantly playing the first level of op wolf 3, I finally found the outputs!

May mercy be with any poor soul who actually wants to play this crappy game though.  I can honestly say I'll never want to play it again!

[Huggybaby]

lol Keep up the hard work Howard_Casto.

[Howard_Casto]

Well I think I've went belly-up with namcos2 as far as the steel gunner games are concerned. 

Namcos2 is beautiful hardware-wise.  6 cpus with none of them hard-wired to any particular function meaning that the board can be adapated to run just about anything.  And it has... everything from racing games to beat em ups to gun games all run on it. 

You would think that with such a flexible system namco would have graced us with a adequate service menu to test outputs.  How wrong you are.  There isn't any way to test outputs on the system.  Whoever hooked up golly ghost must have been a genius because we have a switch that checks the offset to a processor and splits it out into processes.  Do you know how many potential offsets that is?  I gave up after hooking up around 50. 

Long story short, I have the function the outputs should be in, but I don't have the offsets.  If you can find info on it send it to me and I'll work on it. 


Before I start packaging this up for submission I want to look at segas32 again because I couldn't get any analog outputs to work on that driver.  Knowing now what I learned with the other sega drivers, I might be able to fix it a little. 

[Huggybaby]

I'll bet Haze could write something to quickly go through all the offsets looking for a specific condition.

[Howard_Casto]

OK I went through all my changes and I'll make them into one big old diff tonight.

For the curious this is what I've done so far, not including my previous run that is already in the u2 build of mame:
==========================================================================================================
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.
==========================================================================================================

I don't think I'm done this build cycle though... I'm just done with the analog gun outputs for a while.  There are around 20 or so hooked up now, so that should be enough to get people interested in adding recoil to their mame cabs

I want to work on the remaining sega drivers next. 

Now that I've done a few, I'm beginning to understand the strangeness that is sega hardware design and all the "segas" boards work similarly. 

I would also like to finally hook up afterburner and friends assuming the emulation has the output data doing something.  Those games use a similar drive system to gloc, so if we are lucky we'll still get output data despite the fact that the motor test screens give error messages.

[Howard_Casto]

Ok... I cleaned everything up and sent it along to the mamedevs. 

I'll update the first page accordingly.

[Howard_Casto]

I'm currently looking at the sega x board driver.  (Afterburner and friends) 

Now that I'm strating to understnad how the mame source works it becomes apparent to me why my previous attempts at getting the remaining outputs connected have failed.  Aaron installed a custom memory write handler for afterburner2 during it's startup.  This is a much cleaner way to do things.  (I wish I had thought of it when I was doing these other games... oh well).   The problem is it only parses the single 16 bit line where the lamp data is held, and thus I will NEVER find the motor data in there.  Fortunately the generic io function is still in place, and I can install outputs there to snoop around.  I can make more custom io handlers once I find the data though. 

I'm probably not going to attempt this atm.... I want to dig up some info on how the deluxe aburner cab worked.... pretty sure it's just a single motor on a worm gear for up/down movement and then the standard joystick feedback you see on the upright. 

[Howard_Casto]

I couldn't resist so I took a look at the xboard....

all-in-all a lot more has been figured out on this board than the y board.

I've already found all the digital outputs, including the vibration motor for super monaco gp.  Can't figure out the air brake motors thought (for the deluxe cabinet) basically they error out in the service menu, meaning I don't have an easy way of figuring it out. 

I haven't found the motor outputs for afterburner yet, but I have figured out why the output lamps don't work right for afterburner but they do for part 2... basically the outputs are shifted down a byte for the original, so it should be an easy fix. 

[Howard_Casto]

Well I've got good news and bad news.  The good news is I fully figured out the outputs for afterburner.  The bad news is it doesn't matter because we can't use them. 

Ever noticed where all the limit switches for afterburner are forced on?  They are that way to keep the game from erroring on boot.  If you turn them all off you also get an error. 

The only proper way to pass the motor test on boot is to hook all four switches up to inputs and rapidly toggle the left and right limits until left and right show "good" on the screen and then do the same thing for up/down. This simulates the motors running to their full limits. 

This will give us positional data as an output.  But not speed.

The only way to get speed is to hook up the positional reads for both motors.  This really isn't the correct way to do it.  This is, however how gloc is hooked up... I might look at it to figure out how to get this working. 

That motor test on boot is the problem though.  With all the limits off you error out.. with them all on you don't get any data. 

Any ideas??

[Xiaou2]

With your Hook program, there could be a checkbox option to auto-calibrate
motors... which would then have to go thru game specific procedures that
you have stored as some sort of  .ini data text file...?

 In reality, if one were to build an actual simulator, they would most likely want to
hook up all the limit switches, so that the thing didnt over-grind when it reached
end-of-travel.

 But for a rumble-pad or test situation, it would be different, and thus a false
calibration would work fine.


 

[Haze]

Well I've got good news and bad news.  The good news is I fully figured out the outputs for afterburner.  The bad news is it doesn't matter because we can't use them. 

Ever noticed where all the limit switches for afterburner are forced on?  They are that way to keep the game from erroring on boot.  If you turn them all off you also get an error. 

The only proper way to pass the motor test on boot is to hook all four switches up to inputs and rapidly toggle the left and right limits until left and right show "good" on the screen and then do the same thing for up/down. This simulates the motors running to their full limits. 

This will give us positional data as an output.  But not speed.

The only way to get speed is to hook up the positional reads for both motors.  This really isn't the correct way to do it.  This is, however how gloc is hooked up... I might look at it to figure out how to get this working. 

That motor test on boot is the problem though.  With all the limits off you error out.. with them all on you don't get any data. 

Any ideas??

I imagine you'll run into similar problems with things like GTI Club.  I believe the 'wheel error' you get on startup is because the game is using the force feedback control to move the wheel, then expecting data read back from the wheel position to show that the wheel has moved and reached it's limits (within a defined range).  There is no way this can be hooked up using MAME's current systems, and it will be even harder to map to anything except the original device if you want FF to work (because every non-original device will have very different behavior)

For simple cases, as you've found, it can be pretty simple to hook up lights and outputs, but for others the solution isn't really obvious.

Sorry, I don't really have any good solutions for you, but there is no generic 'right' answer here from what I can see.

[Howard_Casto]

I'm less worried about making a generic solution than I am breaking the game.  MAME is primarially a documention project as you know and by that path all the limit switches I've found should be hooked up.  But that would "break" the game.  Is that really a good idea?  I mean it isn't like afterburner would be unplayable....  changing the cabinet type dip to "upright" will disable the motor check and allow the game to play normally I can imagine the backlash of hooking it up though and the unending questions of "Why isn't afterburner working?"  ect... ect...


I didn't bother to hook up the limit switches on the yboard for this reason and because most of the games worked anyway.  I figured that would be the way to keep it because anyone attempting to hook it up to a simulator rig would have hard-wired limit switches that have nothing to do with the game's feedback anyway. 

Generally the game is still playable even if the motor test errors out though, it's just the motor test takes MUCH longer than it normally would.  So I don't know, I just need advice on how to proceed. 

[bdam]

Would this be a situation where a default NVRAM would help?

[Howard_Casto]

Not really......  a savestate might work though that starts the game after the motor check has already passed. 

See like I said, a generic solution isn't that much of an issue, I just don't want people getting up in arms on how I "broke" afterburner. 

I'm going to hook up the motor read values tonight and map them to the joystick to see what kind of data I can get.  That'll let me know if it's even worth pursuing. 

[headkaze]

So in order to turn on the dip switches you need to simulate the motor test input sequence? So I guess that would have to be the goal, to see if you can get it to past the test?

[Howard_Casto]

No they aren't dip switches... they are regular switches.  On the game they would be mounted at the beginning and end of the track the motor moves on.  They are there just in case the motor got out of sync so that it wouldn't strip the gears trying to move further than it can.  I can pass the motor startup test, but the motors still don't have their read pots hooked up. Those need to be hooked up so the game knows the motors are moving, and thus the game will adjust the motor speed accordingly. 

It should be noted that now that I'm sure that the hacked up limit switches are the only thing fouling up outputs on the sega games, I would be able to go back and fix the games I couldn't get working on the yboard as well.  They would also be more forgiving since they don't have motor startup tests. 

[Howard_Casto]

Well I hooked them up and what I get is similar to the output I get for gloc.  The problem is afterburner didn't really work that way.  The joystick resisted your movement when you got hit, that was pretty much it.  Of course the y-axis was mapped to the motor that made the cockpit tilt on the deluxe model, but the principal is the same. 

Speed and position seem to be mushed together as well.  On gloc you would get 4 distinct sets of values... motor 1 speed, motor 1 position, motor 2 speed and motor two position.  On afterburner they appear to be the same. 

(all the below is in base-10 for readibilities sake)
Left and right direction is determined by a single bit  at the "1" speed.... 136 = no movement...... 135 = moving left......  137 = moving right.  This is multiplied by 5 to get the speed, so on speed "5"  131 = moving left and 137 = moving right.  So basically to get x-axis data we do a (data & 11)

Up and down direction is determind by 16 bit intervals.  136 = no movement  120= moving down   152=moving up.....  again you multiply the 16 bit shift  by 5 to get the speed.   Making the speed "5" values   56 = moving down  and 216 = moving up.  So I guess a (data & 161) would give us a y value and speed.

So to get all of our values we would first do a (data & 11), if it's less than 6 we are moving left, more than 6 moving right and then subtract from 5 to get the speed.

Then we would subtract (data & 11) from the main data and compare what's left..... anything less than 81 would be down movement, anything greater than 81 would be up movement.... we'd then divide the difference by 16 and subtract 5 again to get the speed. 


Does that sound about right?  I'm really good at the other bits but when I have to do math, that's when I tend to make a mistake. 
 
Even if all that is correct, there is still a missing piece of the puzzle.  At the end of the first stage the feedback stops for no apparent reason and it never starts again.  My guess would be a reset bit is in there somewhere, but I don't have a clue as to how to find it. 

[Howard_Casto]

Well, after a bunch of tedious math operations I think I finally got the thing to work pretty much like it did in the arcade.  The motors follow your joystick movement as you are flying around (which is normal) but when you get hit the x-axis flickers like crazy.... at least if you let go of the joystick. 

I'll have to get one of those fancier force-feedback flight sticks to test more, but it looks like the output freeze I mentioned is caused by moving the stick while a "rumble" is occuring.  The machine gets confused because on an afterburner machine when the "rumble" happens that stick slings your arm back and forth like you are nothing (or at least it did when i was and there's no way the stick could be moving opposite of where it's moving it. 

It also looks like afterburner 1 has a bigger problem with motor freeze than afterburner 2 does. 

Again I'll need to get ahold of a true force feedback joystick to do further testing. 

But anyway, crisis of conscience over because now that I have the data filtered out, I can see methods for using it with a standard force feedback  "rumble" controller as well as a full-fledged ff flight stick. 

I'll look into smgp as well.  It looks like it sends motor data regardless of the error status, but it's quite a lot of data.  I'll have to read up on a smgp manual to see what kind of stuff I'm dealing with.

[Howard_Casto]

Early this morning I poked around for limit switches for super monaco gp and managed to get the error messages to stop in the air drive test in the service menu.

As you can see from the attached pic, we are presented with a rather descriptive debug menu.  The different motor icons light up as you try them too.  
If it were only as simple as that though.  Unfortunately, much like power drift, the data values you get in the service menu don't seem to have anything to do with the actual values you get during game play.  

This game also strobes/multiplexes it's output data like gloc does.  I think I've found about 4 values in there so far, maybe more.  Hopefully it'll be lilke gloc in that each motor's data is presented in a range of values, making it easy to determine with bit fo data we've gotten ahold of.  

But the good news is, the newly working test menu lets me know how many motors we are dealing with and the things they are supposed to do.  Before it was spitting out seemingly non-sensical data, but now that I have something to compare it to I should be able to figure it out.  


And that will do it for the xboard!

I can also go back and apply what I've learned to the yboard, which will hopefully get galaxy force and rail chase working, or at least in a state where that they would work with the original hardware.  

Also segas32's jurassic park and a few others look very similar to this, so I can probably get them working as well.  


In case you are all wondering the key is the limit switches.  On sega games buttons are generally active low (1 is off 0 is on), but for whatever reason, the limit switches on all the games appear to be active high.  Since the natural state of the driver is to run "1s" through all unmanaged io addresses, if limit switches are not defined they are stuck in the on position, and the game gets scared and sometimes shuts down the motor data all-together.  

Fortuantely they aren't terribly hard to find.  They tend to be hiding out in "0A" (you'd have to see the driver) and in the lower bits at that.  Generally you can just hook up the first 4 or 5 bits to buttons and figure it out that way.

My guess is this is less of a "we don't know how to hook it up" issue as to why they've never been binded to buttons and more of a "why bother hooking them up" one.  Well now we have a reason, so I guess it's time to hook them all up.  

[Howard_Casto]

Well smgp has me puzzled a bit.  I get data and it's quite readable, I just can't see any corolation between it and the data i get in the debug menu. 

If someone has and air drive cabinet, knows someone who does, or has video of it in motion and/or pics of the inner-workings, they need to contact me. 

Also of note 137u3 is out and my latest submissions aren't in it.  Not suprising because I turned it in kind of late, but I did have to do some extensive changes to a few of the drivers so we'll see if it gets accepted or not. 

I think for now it's break time.  I'll continue to get the kinks out of the xboard, but with the 1 U version delay on getting my stuff in the official build, it wouldn't hurt to slow down a bit so I don't get confused.  \

On a slighty related note, if anyone wants to sell me a force feedback flightstick (usb only please) then let me know.  It's for testing afterburner and similar games.

[Howard_Casto]

I got bored today and since xiaou2 requested it, I took a look at the outrun driver. 

It took me less than 20 minutes to find the digital outputs for hangon, outrun and turbo outrun.  This includes the vibration motors for both game. 

As for the more advanced feedback for outrun, I unfortuantely can't find the limit switches and this is one of those games where if you don't have the limit switches hooked up properly the game doesn't give you any feedback data. 

There are several prototype ports in the outrun driver than aren't hooked to anything.  I'll attempt to hook those up and see what I can discover later on. 

Assuming I can ever find it,  outrun should be fairly easy to get working because it's motor system is rather primative. 

[Xiaou2]

You Da Man!    

[Xiaou2]

 I have to say, Im amazed to see a Simulator chair for Super Monaco GP.  The
game itself isnt very good.   Ive only ever seen the Standup in person.

 I finally saw the other Enclosed cabinet (picture) ,which looks like it does not move.
And a full car version, which looks like it might be the moving cabinet.

 Id be willing to bet that only a handful of those full car versions actually exist at all.

 Sadly, a lot of larger games like this got destroyed, because the ops changed
games, and had no room for it.   They part them out usually, cause the typical home
buyer does not even have room for them.

[Huggybaby]

I have a force feedback joystick I could use to test with...I can't sell it though.

[Howard_Casto]

 I have to say, Im amazed to see a Simulator chair for Super Monaco GP.  The
game itself isnt very good.   Ive only ever seen the Standup in person.

 I finally saw the other Enclosed cabinet (picture) ,which looks like it does not move.
And a full car version, which looks like it might be the moving cabinet.

 Id be willing to bet that only a handful of those full car versions actually exist at all.

 Sadly, a lot of larger games like this got destroyed, because the ops changed
games, and had no room for it.   They part them out usually, cause the typical home
buyer does not even have room for them.

Yeah... I just wanted to finish it for completeness, but to be honest the game is really really terrible, right down to the girls with the akwardly painted on bikini's. 

[Howard_Casto]

I have a force feedback joystick I could use to test with...I can't sell it though.

Heh, well that doesn't really help me.  I need one myself so when I find problems I can go into the code and fix it. 

[Howard_Casto]

Ok... I've found that one or all of the prototype functions in the outrun driver contain the limit switches.  It's now a matter of painstakingly hooking each bit in all four ports up to keys so i can figure out where they are. 

[Howard_Casto]

Well I got outrun working....... 

The bank motor has a speed/voltage setting of 1-7 and of course forward and reverse voltage. 

It is an unruly pain in the butt to get past the intial motor test though.  But that's what save states are for afterall


I'll have to clean this up a tad to make it more generic, but it's ready and I'll post the entire C file later.

[Huggybaby]

The idea of OutRun working with a force feedback wheel is mind boggling. You're giving mame a real shot in the arm Howard.

[Howard_Casto]

Thanks...

Oh btw, I forgot to mention that turbo outrun is in that driver as well and I also hooked it up.  Of course nobody cares because turbo outrun sucks, but hey. 

[headkaze]

Perhaps it's worth making an Output.dat project with a file describing the outputs?

[Howard_Casto]

Absolutely.  The problem though is if we are gonna do that then ALL of mame's outputs, not just the ones I did, are going to have to be renamed. 

Right now they have rather ambigous names like "led0" or "lamp0"  and this just won't do.  They have no baring on what they are in relation to the actual game.  I understand why they were done that way, namely because it takes less lines of code and because it was a quick and dirty way of converting all games that used to blink the keyboard leds into the new system. 

The fact of the matter is that they aren't even labeled that way by the games themselves.  You go into the debug menu, or even look at the schematics in the games manual and they are labeled quite understandably.  All the specific names I've been using, for example, are taken directly from the debug menus from these games.  The only one's I standardize are anything pretaining to wheels or gun solenoids because most of these games are japanese and they use terms that when translated into english don't make any sense to us.  (For example wheel is often directly translated, which ends up as "handle" and recoil or kickback usually get butchered to "blowback")

But even assuming we can fix all of that, and output.dat of some sort would still be useful to explain some of this.  Just as an example, most sega games have both digital and analog force feedback, depending upon the cabinet.  I have both hooked up obviously, so it would be nice to explain which is which.  I think it would be less like controls dat because you are already realitively sure what an output does, but perhaps something to explain what kind of data you are going to get adn how it pertains to the original hardware.

[Howard_Casto]

Going along those lines, I've already got sort of a working name standardization I've been going by when I tear though these drivers hooking up outputs. 

Basically it's this:

1.  If it's an incredibly common type of output (like a gun recoil) and the in-game/in-manual description of the output is too vague, or non present, use a standardized name.  My solitary example of this is the use of "Player#_Gun_Recoil" in most gun games.

2.  If it's a lamp, give the description (each word capitalized), followed by lowercase "lamp".....  for example, my outputs aren't labeled lamp0, lamp1, ect... they are Start_lamp, Warning_lamp, ect....  This also applies to other generic devices like motors, rams ect....

3. If it's an unusual type of output like a ff device, use the manuals description if at all possible, if not be as descriptive as possible to ensure people have some idea what it is.  For example, I never give an un-named force feedback motor a generic name like "motor"....  i'll tak on what it was used for, like "Bank_motor".

4.  As it pertains to force-feedback outputs.....  if the debug menu uses raw, unmanaged ranges (see gloc) keep those in as the official outputs, but also add managed outputs, because these numbers are useless to most people.  Also keep the values integers.  Also if a motor direction needs to be set as an output, don't ouput strings but rather numbers.... 0 = stopped, 1 = left/up, 2=right/down

And that's all I have for now. 

Also something of note is that my recent source changes have affected the INPUTS of mame as well, since I've had to hook up limit switches.  These should be ignored by controls.dat becasue we never added any buttons into cotnrols dat that the user didn't have access to and these are no different. 

[Howard_Casto]

I wanted to give a quick update.... I haven't released the outrun driver yet because I want to re-arrange the limit switches so they are easier to trigger.  I'll do that tomorrow.  I will probably clean up the x board driver and post that as well.  As much as I would like to get smgp working, it just isn't worth it to me.  I can leave all my prototype functions in place and someone else can fix it.

[Howard_Casto]

Ok the outrun driver is done and I've attached the c file so you can try it yourself.  For thsoe using gamepads, you can use the vibration motor with the cabinet in upright mode.

To get past the motor test simply roll your fingers along the keys for the limit switches over and over until it passes.  If it fails restart the game and try again.

Next I'm going to tackle the hangon driver because it runs on similar hardware.

[Howard_Casto]

I took a look at segahang.c .....  the lamps were generically setup which caused two lamps to show up for all games even though space harrier is the only game with two, so I fixed that and gave them less generic names.  I also hooked up the limit switches for space harrier so that I can begin to understand it's output system.  I get output data now, but only for right/down and not for up/right.  Could this be a calibration issue?

I'm not sure but I'll keep working on it. 

[Huggybaby]

Ok the outrun driver is done and I've attached the c file so you can try it yourself.

I don't see the attachment...

[headkaze]

I don't see the attachment...

First post...

[Huggybaby]

Gotcha, thanks.

[Howard_Casto]

137u4 was released and it contains a big bunch of my updates.... I'll update the first page accordingly.

I had taken a break from submitting to give mame a chance to catch up.  Now that the latest are in I'll clean up those two drivers I'v been working on and revisit the ones I've already did to try to fix their limit switches and get games like galaxy force 2 working.

[Huggybaby]

Cool! Did OutRun make it, I can't see it on the list, maybe I'm overlooking it. And are there any games you want rumble/Force Feedback tested on?

[Howard_Casto]

Just a quick heads up.... Mame version 138 is out so all of the things listed on the first post except outrun and a few others I haven't submitted yet are included in a stock build of mame.  So no compiling necessary!  Go play!

I'm still "out" though so it'll be a while before I can get those later bits of code submitted and out the door.  I also intend to add examples of some of the additions to my homepage, but again, not right now.

[headkaze]

Great work HC 

[Howard_Casto]

Thanks....

I found this while searching ebay for parts, and it seriously puts into question my understanding of how the "standard" sega racing cabs do force feedback.

http://cgi.ebay.com/SEGA-OUT-RUN-SOLENOID-FORCE-FEED-BACK-CONTROL-PANEL-/120486275850?cmd=ViewItem&pt=LH_DefaultDomain_0&hash=item1c0d8aab0a

Solenoids are digital, so this HAS to be for the standard version, but I'm curious as to how it would work.  My guess based on the mounting bracket and teh kind of data I get on the standard version output is that this thing rapidly gets turned off and on "clamping" it to to shaft of the wheel momentarily to make it hard to turn.  It's an interesting yet strange technique. 

I had erroniously assumed that a dc motor was used in a similar manner to achieve the same effect.

I would buy it for testing, but in all likely hood it would only work well on an outrun wheel and the solenoid alone is nearing 50 bucks already, so I'll pass. 

[Xiaou2]

 I can assure you the the standard OutRun wheel is NOT digital. Its a
one way motor.  I Have one, and can send a pic later.

[Xiaou2]

Camera batteries are dead for now.  Heres the next best thing:

http://cgi.ebay.com/Out-Run-Sega-Game-Control-Panel-Steering-shaft-Assembly-/350330943929?cmd=ViewItem&pt=LH_DefaultDomain_0&hash=item519159f9b9

 This is the wheel without the motor.  You can see clearly on the 4th pic down,
on the right side, is a bar with bushings on it.  This is what the motor hooks on to.

 You can also see the oval holes in the metal base.  The complete assembly
you see here, will slide back and forth.  The mounting pins go through those oval
holes, and mount to the main control panel.  The oval allows the inch of travel back
and forth.

 http://cgi.ebay.com/outrun-steering-shaker-motor-and-gear-box-shaft-/290436129132?cmd=ViewItem&pt=LH_DefaultDomain_0&hash=item439f57a16c

 There is the motor, with its crank drive on the shaft.  The crank fits into the
wheel assembly's bushing.  The motor itself mounts to the main control panel.


 I have no idea where that vibration thing came from.  Ive Never seen a vibration
device on a sega game.  Ive seen plenty of arcade machines.  At one time, I was
trying to get an outrun upright to work, but after several bad boardsets, I gave up
and sold the game as is. I still have the extra wheel assy.

[Endaar]

Awesome work Howard! Thanks for all your efforts.

Endaar

[Popcorrin]

I haven't checked to see how mamehooker was coming along in quite awhile and it looks like there are number of cool additions.  Nice work Howard.
 I'm guessing the force feedback on the newer driving games is going to be fairly complex to hook up?

[sslakkerr]

Thanks for the Outrun work Howard_Casto!

Quick vid of Outrun MAME cabinet with blinking Start and steering feedback:


Compiled your segaorun.c with mame0137 (0138+ wouldn't compile)
using parallel port output control with mamehooker

Awesome work, much thanks!

[Howard_Casto]

Ah it lives! 

Looks great man! 

I've taken the summer/winter off from software projects to work on a hardware one.  (No I'm not telling yet. ) 

Once I'm locked in for the winter I'm sure I'll get back to this though. 

popcorrin:  well it depends on what you mean by "newer" driving games.  Most still use real simple ff outputs like outrun but atari driving games in particular have a complexity similar to force feedback, so those will be a long shot to get working.

[Popcorrin]

Yea, I was referring to the driving games on the seattle.c driver and games like crusn usa. 

[isamu]

WOW!!!!

MAME finally gets forec feedback HOLY ---steaming pile of meadow muffin---!!!!

Howard you rock!!!

OK so a lot of the technical talk in the previous posts about compiling all that went right over my head. So basically what I want to know in a nutshell is....

1)Can I use my PC force feedback wheel that is just a typical Windows 7 DirectInput device, with these games now? Or is this meant only for the actual arcade cabinet wheels like the one on the OR cab?

2)Anything else required to use it in mame or is it straight forward?

3)Can you please make an FFB config menu that will allow us to tweak the strengths of the ffb effects and other variables(ie spring, ramp, constant, sine, etc)?

4)Are the Namco System 22 games such Ridge Racer and Rave Racer working with FFB yet? please please PLEASE make this happen I will die!!! 

[Howard_Casto]

Well my first suggestion would be to read this thread, the whole thing... it will explain a lot of your problems/questions.

The main thing you need to understand is that force feedback isn't in mame nor will it ever be in mame.  I have, however, added output broadcasting (used by led blinky and the like to control lights via mame games) to the drivers of many games that have forcefeedback.

Mamehooker supports output reading and it also supports forcefeedback/xinput  so in a round-about way we have forcefeedback in mame, but not technically.

1.  Yes... but you have to use mamehooker
2.  Yes... mamehooker
3.  For some things yes... again see mamehooker.... for others, (spring ramp ect..) this is unlikely.  The forcefeedback games that are currently hooked up are simple... like on/off simple.  I don't see a need to support advanced ff effects when the games themselves can't.  At least not right now.

4.  Nope... and they won't for some time.  I'm on a mission to get all the sega games (the coolest ride-on games) hooked up because they are less complex and give back useable data.  Ridge Racer barely works in mame and it's stuff is complex.  Those types of games will be last on my list.

[Howard_Casto]

Just an update: 

I've enjoyed my break a lot, but I'm very afraid that if I keep putting it off, some of these "half completed" drivers will never get submitted or mame will go through yet another major source change and I'll have to start from scratch.  Starting next week I want to button up what I've already done. 

My goals are:

1.  Get the outrun driver modified and submitted (there's just some minor tweaking that needs done to get it working on the current build.)
2.  Finish up the sega y and sega x boards.
3.  Figure out where the hell I left off on the misc drivers I was working on and see if anything useable can be submitted. 


I'll have to get my build environment back up in sync with the latest version of mame, but after that I shoudl be able to get outrun submitted within the week.  #2 might take a bit longer and I don't even know if #3 is salvageable I've been away so long. 

Wish me luck!!

[bdam]

>Wish me luck!!
Good Luck HC.  I've been waiting to see when you would pick this up again.  Hopefully it catches on and we see some other devs join in.

[isamu]

Well my first suggestion would be to read this thread, the whole thing... it will explain a lot of your problems/questions.

The main thing you need to understand is that force feedback isn't in mame nor will it ever be in mame.  I have, however, added output broadcasting (used by led blinky and the like to control lights via mame games) to the drivers of many games that have forcefeedback.

Mamehooker supports output reading and it also supports forcefeedback/xinput  so in a round-about way we have forcefeedback in mame, but not technically.

1.  Yes... but you have to use mamehooker
2.  Yes... mamehooker
3.  For some things yes... again see mamehooker.... for others, (spring ramp ect..) this is unlikely.  The forcefeedback games that are currently hooked up are simple... like on/off simple.  I don't see a need to support advanced ff effects when the games themselves can't.  At least not right now.

4.  Nope... and they won't for some time.  I'm on a mission to get all the sega games (the coolest ride-on games) hooked up because they are less complex and give back useable data.  Ridge Racer barely works in mame and it's stuff is complex.  Those types of games will be last on my list.

Hello Howard, Happy Holidays and thanks for the reply:

I understand....I will check out mame hooker.

Disappointed to hear the RR games are very complicated and are not working well in mame yet. I am however, extremely excited to hear that you're eager to get the OutRun drivers working properly. I am especially excited to know you will have OutRunners working soon, as that is one of my favorite OutRun games and is criminally overrated IMHO. Plus, there are other old 2D sega racing games that I'll be looking forward to playing once you have its driver working.

So yes, please keep us posted on your progress.

P.S. Regarding the Ridge Racer games...I know they don't work too well in Mame, but I'm sure you're aware of the fact that they do run quite well in VivaNonno. Would it be possible to get into the source code of Viva Nonno and add some kind of Hooker app so that it allows the RR games to deliver FFB via Xinput or DirectInput?

[matsadona]

This was news to me, but it is really something I have been looking for. Just a simple thing as a blinking start-button makes the experience so much greater. And with gun recoil and FF there is so much more to get from a MAME multi-game (driving or shooting) cabinet.
Thanks a lot. I do understand how much time your efforts consume and the whole community is in debt to you. Keep up the good work.

Now I will begin with the download of MAME Hooker and see what that leads to

[Paul Olson]

I haven't been on here much lately, but just finally found this thread. thanks for all the effort Howard! It is definitely appreciated. I will check into it more over the next few days. I haven't even fired up the MAME cab in months, but I am looking forward to messing with it again. What do you need help with the most right now? I'll try to help out a bit if I can.

[Howard_Casto]

Well guys, I've been a bit under the weather (caught my annual cold just after posting BAH!) so I haven't started getting things back up to speed yet, nor have I submitted anything.  I think I'll wait a bit longer to start again, mostly because I got a metric ton of games for xmas and I'm currently playing through them.  I'm about halfway through them so probably by the end of this month I'll feel much better and be bored enough to start again.


In terms of help, I just need people to play with the drivers and find output data.  It doesn't really matter if you can't make sense of the data, but rather finding the addresses is what's important.  I've had pretty good luck with sorting out garbage from the data to make it useable.  I would prefer anyone who looks to start on multi-game drivers that are known to have multiple games with outputs.  This is only because if we figure out one game it will be much simplier to get the others working so we get more bang for our buck.  Also the earlier the game the better.  Early games are easy to figure out, especially those released around or prior to the "16 bit era". 

[milhouse]

I'm a little confused.  I have MalaHooker up and running with my LedWiz (controlling a Q*Bert knocker).  Now I am trying to get force feedback controllers (Direct Input) working.  Do I need a separate controller to read the MameHooker output and control the motors?  Or is it built-in to 142 roms?

Thanks.

[Howard_Casto]

I think if you would read isamu's question and my reply which is literally just above what you posted, you would get your answer. 

[milhouse]

I did, but since its not working for me, I wanted to make sure I had everything I needed.  Thanks.

[Howard_Casto]

Well I still don't have a clue what you are asking. 

Obviously for force feedback to work you must have a controller (gamepad, joystick ect...) that supports force feedback.  The "show supported devices" option in the mamehooker menu will let you know if it's supported. I have no clue what you mean about "142 roms".  The mame driver must have feedback hooked up to an output and the ones that do are prety much the ones listed in this wip. 

[Howard_Casto]

I'm having bouts with insomnia again, so my loss of sleep is your gain!

I'm looking at the outrun driver that hasn't been submitted yet.  Everything is in working order, but I have to alter it before I submit it for a couple of reasons.

1.  The outrun driver has changed since I wrote this, so I'll have to alter it slightly to get it working.
2.  The mame devs decided that we should handle the giant case statements of outputs differently, and I tend to agree. 

They altered my last submission before approving it last spring and I'm going over the changes.  What they did was create two generic callbacks, one for each byte and then make custom init functions for each game with outputs.  In their individual inits, the various games re-direct the generic callback to a specific one for each game, which transforms a giant case statement for 12 games into 12 tiny functions.

Outrun.c only had a few games in the driver so it shouldn't take long.  I just want to make sure that I fully understand what they did (memory managment is crazy to wrap your head around sometimes) before I start work.  We should get the outrun.c at least, out before the next build cycle if all goes well. 

Then I want to put up a tutorial on the mamehooker website about how to actually use this stuff.  Those of you who have sent me vids/pics of your cabs running, if you want to make a little writeup of what you did (both software-wise and hardware-wise) then please do so and I'll put it on the site. 

[bdam]

So over the last month or so I've been working to find and decipher outputs in the MAME source.  A few questions arising out of that.

I've been working through a very old list Stiletto posted that you can find here: http://groups.google.com/group/rec.games.video.arcade.collecting/browse_thread/thread/b3067b3125c5987f/b1c20350a1a5dc9d.  It seems that early last year you were working on generating a more complete list (http://forum.arcadecontrols.com/index.php?topic=82987.40) and I'm wondering if you ever got a chance to make any headway with the CHDs.  I'm almost finished going through Stiletto's list so if there's something more complete I'll start hacking away at it.  I'm not sure how you're putting the info together but, if possible, it would be nice to have the name of the driver and the driver status.

Some of the outputs are pretty straightforward so I'll probably submit source changes directly.  To that end, had you worked out for yourself some sort of standard way to name these?  From your submissions it would seem to be name_type such as Start_lamp.  Things get a bit foggier however when there are things like a seat and steering wheel that shake or vibrate.  I'm thinking vibration_seat_motor and vibration_wheel_motor.

What have you been doing with the existing led calls?  Should they be left in for backwards compatibility or replaced with the newer output system?

The namcos22 driver has some motion cabs similar to the ones you worked on in segaorun.  You linked the motor position to the steering wheel and connected the limit switches; I'm assuming in order to pass motor tests.  I was wondering if it might be worthwhile/possible to virtually track the positions in situations like this.  Then, kick off the limit switches at the extremities of the ranges.  I just seems that if the motor outputs and limit switch inputs are implemented that it would be nice to have them interact similar to how a real machine would.

[Howard_Casto]

So over the last month or so I've been working to find and decipher outputs in the MAME source.  A few questions arising out of that.

I've been working through a very old list Stiletto posted that you can find here: http://groups.google.com/group/rec.games.video.arcade.collecting/browse_thread/thread/b3067b3125c5987f/b1c20350a1a5dc9d.  It seems that early last year you were working on generating a more complete list (http://forum.arcadecontrols.com/index.php?topic=82987.40) and I'm wondering if you ever got a chance to make any headway with the CHDs.  I'm almost finished going through Stiletto's list so if there's something more complete I'll start hacking away at it.  I'm not sure how you're putting the info together but, if possible, it would be nice to have the name of the driver and the driver status.

Some of the outputs are pretty straightforward so I'll probably submit source changes directly.  To that end, had you worked out for yourself some sort of standard way to name these?  From your submissions it would seem to be name_type such as Start_lamp.  Things get a bit foggier however when there are things like a seat and steering wheel that shake or vibrate.  I'm thinking vibration_seat_motor and vibration_wheel_motor.

What have you been doing with the existing led calls?  Should they be left in for backwards compatibility or replaced with the newer output system?

The namcos22 driver has some motion cabs similar to the ones you worked on in segaorun.  You linked the motor position to the steering wheel and connected the limit switches; I'm assuming in order to pass motor tests.  I was wondering if it might be worthwhile/possible to virtually track the positions in situations like this.  Then, kick off the limit switches at the extremities of the ranges.  I just seems that if the motor outputs and limit switch inputs are implemented that it would be nice to have them interact similar to how a real machine would.

The names I use are quite similar to those.... check out some of my previous drivers to get an idea of how I name them.  For the gun games I used terminator 2's outputs (which have actual, clear, names in the test menu) as a base and modified them as needed.  I try to use descriptive names when possible.... for example, I rarely use lamp0, lamp1, ect... I would rather use Brake_Lamp, Start_Lamp, ect....

Generally speaking, if a driver only needs to be touched to change the actual names of the outputs I ignore it.  The only exception would be if the name doesn't make sense..... for example if it's galaga and led0 and led1 are hooked up to the start lamps I leave it alone... that's close enough for now.  It's not that they don't need changed, it's just that the devs might get kind of pissy (and rightly so) if we submit 30 some odd driver changes that are nothing more than renames.... once we get a good standardization going we can go back and change all the "legacy" inputs in one fell swoop.  If on the other hand it's operation wolf and the solenoids are hooked up to led0 and led1... I need to go ahead and change it.  Also, if I'm hooking up a motor input and the lights are already hooked up but have a generic name like led0 I go ahead and give them a proper descriptive name.... the driver is being re-submitted anyway, so we might as well and get it 100% up-to-date.

I'm pretty sure I worked on the namcos22 driver... you might want to check...
It's been over a year though, so my memory is a little fuzzy. 

The good news is that the new mamehooker comes out this weekend, which means I can help with this again.... really need to get that outrun driver sent off as well as afterburner and a few others. 

[bdam]

I'm pretty sure I worked on the namcos22 driver... you might want to check...It's been over a year though, so my memory is a little fuzzy.  

You did some work to the namcos2 and namcos12 drivers but not namcos22 ... at least nothing that I found in the current MAME source.  It's a heck of a driver with no less than 16 games with outputs although not all of them boot and some of them have input problems that make the test menus unnavigable.

The good news is that the new mamehooker comes out this weekend, which means I can help with this again....

That is indeed good news; when you get that far let me know.  I hope to wrap up work on Stiletto's list in the next week or so and have a whole whack of relevant memory addresses, offsets, and bits documented.

[bdam]

I've made my initial run through the original list Stiletto came up with about a decade ago to try and find the outputs.  I marked those that have already been implemented as done.  Those that are done which aren't mentioned already in this thread are based on my submission for which the diff (142u4) is attached.
https://docs.google.com/document/d/1k5GSS9l264KzBuYguQwt3PWY5spPAk6tFjsr_R46nvE/edit?hl=en_US&authkey=CJe-tdUG

[Howard_Casto]

Great Job! 

It's nice to finally get some help. 

Assuming the source changes are accepted, I would like you to let me know which drivers have been changed and I'll add them to the front page.  Generally speaking unless it's a lamp or led, any outputs added to mame are done by me, so if we add yours as well then people will have easy reference to which drivers are beign worked on. 

[bdam]

Below is a list of what I submitted.  It was primarily binary stuff that I was certain of.  I'll probably take a break for a bit and then see if MAMEdev will accept a submission where the motor outputs change the state of the machine which in turn will trigger limit switches.  In certain machines this is a matter of manipulating an existing input (if that's even possible) that tracks position and in other cases it will mean simulating a position value since the machine didn't track it.

(cischeat) Lamps and wheel vibration, bigrun, cischeat, f1gpstar, and f1gpstr2.  Seat vibration for f1gpstr and f1gpstr2.
(megatech) Lamps
(taito_z) Wheel vibration for sci and clones.
(undrfire) Lamps, gun recoil, and wheel vibration for undrfire and cbombers
(weclemans) Lamps, wheel vibration, and tentative cabinet motions for weclemans and hotchase.  DIP switches for hotchase based on manual.

[BadMouth]

bdam, thanks for helping howard out!  (especially on the driving games   )

Wild Pilot had vibrating guns (I have a gun from one).  It's just has a single motor with a lopsided weight on the end.
There was also a deluxe sit-down version that had motion base.  
The flyer mentions three safety sensors and an emergency button that stop the movement.
Looking at the flyer it's hard to tell if it was full motion or just pivoted up and down.
I've never been able to find a manual, but if I do I will buy it and pass it along.


Howard, I bought a cheap wheel off fleabay to hack, but the one I received is not the one that was pictured or described.  It's not worth sending back and losing out on shipping both ways.  I haven't tested it out yet, but if it works, it's yours if you want it.  PM me your address.

I'm just a dumb end user and am assuming directx wheel feedback works the same on all wheels, but the fact that some newer wheels have 2 or 3 motors has me wondering if that is the case?

I'll be reading your tutorials at work today.  

EDIT: Howard, the links to tutorial 2 and 3 both take me to tutorial 2.

[Howard_Casto]

Below is a list of what I submitted.  It was primarily binary stuff that I was certain of.  I'll probably take a break for a bit and then see if MAMEdev will accept a submission where the motor outputs change the state of the machine which in turn will trigger limit switches.  

If this is what you are doing then even if it's accepted we need to change it.  The mame's goal is to be a drop-in replacement for a pcb, you are hacking the lsw inputs to work better with a directx ff device.  We shouldn't do that.  

I have all the limit switches in the sega boards hooked up to inputs.

You hook limit switches up as regular old inputs.  If you are concerned about a ff device not working because of this let me assure you that limit switches have next to nothing to do with operation (except the bootup test) and regardless I will write and app and/or device that will read the joystick data and send keystrokes when needed.  

If nothing else, the easiest solution is to just crack open the wheel you are using and add some physical limit switches. 

[bdam]

>you are hacking the lsw inputs to work better with a directx ff device
Not quite, this doesn't have anything to do with the output from MH or my input device but rather simulating how the limit switches and motors interact on the actual machine.  The cabinet motors would move something and at certain positions that something would trigger certain limit switches.  DirectX doesn't come into play; my input device doesn't come into play; I was thinking of handling this all within MAME.

>You hook limit switches up as regular old inputs ... read the joystick data and send keystrokes when needed
Agreed, but how do you trigger those outputs in a manner similar to the actual machine?  If I understand you correctly you suggest triggering the limit switches based on the value of an input device such as a joystick or wheel.  I don't think that would work either; the limit switches on the machine aren't tied to the limits of their input devices but rather the positions of something the motors were moving.

Here's another idea.  In MAME, add outputs for the position of whatever the motors are moving; that something.  Output its position left to right, front to back, up and down.  Then use MH to read those positions and at certain points trigger a key that MAME has tied to that input.  The only problem I could see is that people who don't have it all set up will now get warnings on initialization.  Sure, it's more accurate to the machine but it sounds like a support nightmare for MAMEdev.  Also, some machines don't seem to track an exact position so how do we simulate that?

[Howard_Casto]

How every single solitary arcade ff device that I've ever looked at works is this.  Limit switches are just that, switches.  i.e. either an optical gate or plain old cherry switch that gets tripped when the motor/wheel, ect goes to far and physically passes through it.  In other words, it's just an input, like a pushbutton or anything else.  It isn't built into the motor/piston or anything, it is a stand-alone switch.  If youa re doing anything other than hooking up the limits switch bits to inputs then you are hacking it. 

Your problem is you are trying to equate directx force feedback and how it operates with how the arcade hardware operates.  They don't operate in the same way at all, so somewhere there has to be a hack.  It can't be in mame, so we do it on our end.  Directx ff devices don't have the same kind of limit switches.  They have fail safe switches in case something goes crazy wrong, but in general the limit is determined in software by the pot value. 

I think you are confused about limit switches.  There is the limit (holy crap we are at the end, turn it off!) and there is a motor/ram position.  Motor/ram positions are inputs as well, we hook those up to an analog input port.  We don't bind them to the wheel position though, it is a seperate input.  This gives the user the freedom to do any kind of force feedback arrangment possible and more importantly, hook up the original arcade hardware as intended. 

For an end user to use a ff wheel (which let's face it, is a gross hack) they would do the following:

Bind the steering wheel's axis to the wheel axis in mame. 
Also bind the steering wheel's axis to the motor position value in mame. 
Allow some middleware app (probably mamehooker) to trigger any limit switches via code whenever the wheel's axis is at it's limit OR when the pot hooked up to track the motor is at it's limit OR skip all of it and simply have physical limit switches already binded inside mame. 

I don't need the position of the motors vai outputs in mamehooker because on a dx ff wheel, the position of the motor is the position of the wheel.  And if it's the arcade hardware or some sort of custom rig, the motor will be hooke up to a pot to track position, and I simply read that value instead.  Also you are forgetting, The motor position in mame is the virtual one.  Since I read the joystick anyway (how do you think I make it rumble? )  I can simply read any analog value there. 

[bdam]

>I think you are confused about limit switches.
Nope, I have always understood them exactly as you describe.

>Motor/ram positions are inputs as well
Ah, that's it, that's where our lines of thinking are different.  I have been thinking of these as a machine state, not an input.  That the position is a state which changes based on motor output and causes limit switches to trigger.  When you put it that way however, I'll agree, they can be thought of as inputs and treated like any other.

That being said, they are not user inputs.  So how would the MAME team like them handled?  You suggest MAME's goal is to be a 'drop-in replacement for a pcb'.  I'm not quite certain that's the case.  If you're right then I find it odd that the developers don't already have the limit switches and motor positions set up as inputs.  My look through various drivers makes it clear that they knew where most of them were and that setting them up as such would have been trivial to do.  They didn't; which makes me wonder why not.

[Howard_Casto]

>I think you are confused about limit switches.
Nope, I have always understood them exactly as you describe.

>Motor/ram positions are inputs as well
Ah, that's it, that's where our lines of thinking are different.  I have been thinking of these as a machine state, not an input.  That the position is a state which changes based on motor output and causes limit switches to trigger.  When you put it that way however, I'll agree, they can be thought of as inputs and treated like any other.

That being said, they are not user inputs.  So how would the MAME team like them handled?  You suggest MAME's goal is to be a 'drop-in replacement for a pcb'.  I'm not quite certain that's the case.  If you're right then I find it odd that the developers don't already have the limit switches and motor positions set up as inputs.  My look through various drivers makes it clear that they knew where most of them were and that setting them up as such would have been trivial to do.  They didn't; which makes me wonder why not.

Well considering Nicola Salmoria, the founder of mame, recently put an article on his website describing how to use mame as a drop in replacement for a pcb and how this is one of mame's goals and primary uses considering many pcbs are tricky to repair I"m fairly sure that it's a goal of mame.    Also  I talked to Aaron Giles about this when he was implementing the output system and that is along the lines of how the output system was setup. 


Limit switches were hacked/turned off to get the games running... it's as simple as that.  The mame team got sick and tired of people complaining that afterburner didn't work when all the user had to do was set the dip to upright....ect.  At the time it didn't make a lot of sense to hook them up considering there wasn't any sort of output system in place to use them for anything.  You'll also remember that in some points in mame's history hack were included for inputs to make some games easier to play on a joystick... and those have been removed over time as well.  Long story short, mame evolves.

Also because mame is such a huge project, submissions are given a decent amount of leeway.  So long as it doesn't break the game, they might allow a bit of hackery as long as it's understood that it will be removed later. 

In terms of handling these sorts of input seperately, the only examples we have to go buy are the very few games in which the output positions are already hooked up (g-loc and a few others) in those they are treated just like any other input, but are hooked up with the labeling macro so that the user knows what they are.  This is the method I use.  If they have a problem with that then we can use the special "driver configuration" setup used by 720.  It allows mutiple control schemes to be used for a single game.  We could have one scheme where the limit switches and pots are hidden (and hacked to be on, so that they pass the startup tests) and one where they are exposed.

I'm sorry that I didn't reply sooner, but I'm busy with real-life stuff at the moment.  I'm also in a holding pattern atm.  BadMouth was nice enough to send me out a wheel and once it comes in I want to get a ff wheel game up and running with mamehooker and see how everything is going to work.  Then it should be easier to determine how to go about this.

[Howard_Casto]

Ok working on the outrun driver again now that I have some actual hardware to play with. 

It looks like I need to do a driver configuration for maximum compatability and that goes for all sega games with limit switches, not just outrun....

Let me explain:

If all the switches are forced to be "ON" (how it is in mame now) then the game errors out of the test sequence quickly, BUT it disables the force feedback signals on the pcb.  Obviously they can't be left as-is, but for those not interested in FF, this would be a nice OPTION to leave in. 

If all the switches are forced to be "OFF" then the game displays an error BUT if the game can successfully move the wheel/joystick (which if you are using mamehooker it can) it will accept the motor as working anyway and send force feedback signals.  This is the best setup for official force-feedback enabled controllers in windows. 

If all the switches are hooked up to inputs, and you have all the necessary hardware (e.g. a real outrun deluxe cab and all the driver boards for the motor) the game should run error free.  In the case of the actual hardware the limit switches DO serve an important purpose as the motor driver hardware doesn't have any limiting circuitry to stop the motor from going past it's limit.  Those switches keep the pcb from shaking the motor to bits!

So I don't really see any other option than to implement all three methods.

I'm looking at how it's done in 720 right now and once I get a handle on how they are manually processing the inputs, it should be fairly easy to do.  MAME has made adding menu items and turning on/off items fairly easy, it's just a matter of actually doing something with the settings. 

Things in the real world have slowed down for the time being... I'll try to make a new test driver this weekend.  I'll also try to release a new version of mamehooker that plays nice with wheels so you guys can help me test. 

[retrorepair]

I'm tidying up my sega sit down racer at the moment so I can help with any testing you need done.

Any plans to hook up lamp outputs for Virtua Racing? Feedback is probably a bit too complicated for the moment but lamps would be great. Are lamp outputs currently possibly with model 2 emulator?

Also, outrun outputs seem to be missing in the latest mame version?

[jurulz]

Do you have any plan for Arm champs 2

[isamu]

Seems Howard hasn't poste since late June, but Howard in case you read this and are still looking for users with ffb wheels I will be more than happy to test out a beta version for ya

Any new progress with the Sega driver lately?

[bdam]

I'll take my turn to bump this thread.  Any word on ffb progress?  It's obvious the code I submitted to MAME wasn't accepted.  Rather than ask about it I figure I'll wait until the next full release and base another code submission of that.  However, it'd be great to be able to use mamehooker to test the outputs more directly with working ffb.

[Howard_Casto]

Sorry guys... the real world has kept me busy lately.  I haven't had time to program for anything as of late.  Right now I'm in "halloween mode" and won't be cure till sometime this november.  I'll see if I can at least get a new version of mamehooker out by then.

[BadMouth]

I'll take my turn to bump this thread.  Any word on ffb progress?  It's obvious the code I submitted to MAME wasn't accepted.  Rather than ask about it I figure I'll wait until the next full release and base another code submission of that.  However, it'd be great to be able to use mamehooker to test the outputs more directly with working ffb.

I'm glad to hear that you're still working on it.

[headkaze]

Right now I'm in "halloween mode"

I remember last year you were making stuff to scare people. Got anything you're working on this year?

[Howard_Casto]

Right now I'm in "halloween mode"

I remember last year you were making stuff to scare people. Got anything you're working on this year?

Unfortunately, since I posted that there has been a death in the family.  My great Aunt passed away and she lived right next door.  I decided not to put up a lot of my stuff, including two caskets, one that shook like crazy and another with a pop-up corpse. 

But on the bright side they will be ready to go next year... just have to put them out. 

[headkaze]

Sorry to hear that Howard

[sslakkerr]

Very sorry to hear about your loss Howard

[Howard_Casto]

I appreciate it.  She was old and had a lot of medical problems though so it wasn't completely devistating or anything. 


I did manage to get the yard setup fairly good this year though.  I'll see if I can put up some pics later this week. 

[Dudeman]

I'm a little late to the party, so sorry if I'm asking a question which has probably been asked before, but I guess my search skills suck because I can't find it.

What version of mame started implementing outputs? I've got .106 and MameHooker shows nothing for DigDug or Q*Bert (my main goal). Or i might be that I"m just a brick shy of a full load.

[Howard_Casto]

I'm a little late to the party, so sorry if I'm asking a question which has probably been asked before, but I guess my search skills suck because I can't find it.

What version of mame started implementing outputs? I've got .106 and MameHooker shows nothing for DigDug or Q*Bert (my main goal). Or i might be that I"m just a brick shy of a full load.

The tutorials on the site are based around digdug.  Qbert is similar.

I'm not sure what version of mame started implementing outputs, but if you are on 106 you might as well upgrade to the most recent version, there shouldn't be any noticable speed hit. 

[retrorepair]

New year bump!

 

[bdam]

Howard, wondering if you could weigh on something I'm working on.  I wrote a quick vb app to implement FFB just so I could continue working on implementing outputs in MAME.  The first major driver (namcos22) I'm working on has an interesting quirk that I'd like your input on.  The wheel vibration magnitude is based on 6 bits of a 32 bit integer.  However those bits first need to be flipped (001111 to 110000) and then reversed (110000 > 000011) in order to get a meaningful value.  The flipping is straight forward enough but reversing the bit order takes a loop and I'm wondering if the MAME devs are going to accept that.  If they don't then Mamehooker would have to handle that somehow.  Any thoughts on how to hanlde this ... which is to say ... how feasible it would be to support bit reversal in Mamehooker?
   

[Howard_Casto]

I think I would have to understand, the actual values you are getting a little more.

Could you show me the minimum and maximum values unaltered? 

Btw... mame might have a LSB (least significant bit) function because it's often necessary to reverse data. 


Adding bit reversal would be trivial, I can add it to the math functions.....  but let's see if we can fix the data in mame first.

[isamu]

The first major driver (namcos22) I'm working on

   

Thank you bdam you ROCK!! Good luck and keep us posted 

[bdam]

Here's the data unaltered except for me zeroing out the bits we're not interested in and surrounding the values with pipe symbols.  The Min and Max values aren't particularly useful to show the reversal that's needed so I added a more descriptive example.
Min(0): 00000000|111111|000000000000000000
Max(63): 00000000|000000|000000000000000000
Other (5): 00000000|101000|000000000000000000

Good idea, I'll look around and see if I can find an existing function in MAME.

[demeth]

http://graphics.stanford.edu/~seander/bithacks.html -- Study until you know them all by heart ;-)

[bdam]

Yep, that's where I got my solution.  To be clear, the 'problem' is easily solved; it's just a matter of where we solve it.  In MAME or in the program that reads the output from MAME.

[Howard_Casto]

http://graphics.stanford.edu/~seander/bithacks.html -- Study until you know them all by heart ;-)

Yeah, like bdam said, the "problem" here isn't that we don't know how to fix it... it's that fixing it could slow down the mame driver and/or introduce sloppy code.  Mind you the speed decrease would almost definately be unnoticable, but he system 22 drivers aren't exactly speedy to begin with.

Personally I think that so long as it's only being reversed when the value is changing it should be ok. 

[demeth]

Ah, that wasn't obvious (to me) from reading the related posts.

Looking at the driver in question, that kindof operation we're talking about shouldn't even register on the scale considering all the other things that's done in there indicative on the cleanup need for mame-3d overall,
heck, even just restrict keywording the A / B in matrix3d_Multiply should save that driver a whooole lot more (not considering the ~20-25ish% gain on using SIMD- intrisics..) than you could purposefully waste

[bdam]

This is less about performance and more about what  the MAME devs will accept.  They will just ignore submissions without feedback so I'm trying to come up with what they would 'want'.  I found an existing but not universal reversal routine in SSEM so I'm going to just ape that.

[Howard_Casto]

Yeah those guys are just picky.

[bdam]

Indeed.  I went with another routine that's just a one-liner ... we'll see what happens.  

I've attached a diff for 145u1 which implements outputs for acedrvrw.  In my quick 'n dirty ffb app it works but the fast magnitude updates for the steering wheel cause the feedback to be significantly delayed and really jerky.  It could be a whole factor of things but I thought I'd post this so you'd have a test case for Mamehooker.  Maybe you already have something setup with wheel forces beyond just rumble but just to be safe, there you go.

[Howard_Casto]

I'll look at it thanks. 

Without getting into it too much: 

It turns out that "true"  ff devices like wheels often have this deal where the effects are physically loaded inside a chip on the device.  This takes a while and there is a significant delay.  The solution I found is to always have a generic effect active within the device and to simply tweak the magnitude/direction/whatever values instead.  It's one of the reasons I've kind of put off the next release.... to give you guys full control I've basically got to make an ini system that lets you bind a output value to 1 of the 80 or so potential variables in a ff effect.  It's tedious and time-consuming work. 

[isamu]

I'll look at it thanks. 

Without getting into it too much: 

It turns out that "true"  ff devices like wheels often have this deal where the effects are physically loaded inside a chip on the device.  This takes a while and there is a significant delay.  The solution I found is to always have a generic effect active within the device and to simply tweak the magnitude/direction/whatever values instead.  It's one of the reasons I've kind of put off the next release.... to give you guys full control I've basically got to make an ini system that lets you bind a output value to 1 of the 80 or so potential variables in a ff effect.  It's tedious and time-consuming work. 

Very interesting bit of info there Howard. That feature sounds awesome and I'm hoping you'll be successful in implementing it properly!

True force feedback for Namco's System 22 driver would be....*sigh*...a dream come true!!! bdam you don't know how I happy I am to hear the progress you're making on that! Thanks so much to you and Howard for doing this.

I can't wait to play Ridge Racer and Rave Racer with proper and TRUE ffb on my wheel! That is going be just AWESOME!!!!!

Keep up the fantastic work guys, your work is greatly appreciated! 

[bdam]

I just played with it some more and part of the problem seems to be that MAME attempts to get exclusive access to the device.  From what I can tell, that means any other program that needs exclusive access, which you need for FFB, will need to un-acquire, acquire exclusively again, and re-download the effect anytime it wants to make start or change an effect on the device.  That three step process created stuttering; at least for me.  If I change src\osd\windows\input.c so that MAME acquires non-exclusive access this problem goes away, you don't need to reacquire, and things work well.  Except for one thing; MAME start complaining that it is 'Unable to create the Direct3D device (88760868)'.  Everything seemed to work fine ... it just complained.

Maybe this is all piss in the wind, you know this, and have a solution.

[Howard_Casto]

We'll just have to see.  I know that outrun was pretty responsive, but then again the resolution of the ff in outrun is pretty low.  Like I said... the trick is you never start/stop the effect.... you leave it running.  A ff effect with a magnitude of 0 doesn't do anything, so it's essentially the same as turning it off.

Mame shouldn't be aquiring in exclusive mode.... at least it didn't before because I specifically complained that there's no reason for mame to need exclusive mode and it causes issues for other apps.  I haven't looked it it in quite some time though.

But enough shop talk. I've got a pinball wrapper to finish and the next thing on the agenda is mamehooker.     

[bdam]

Yep, it works smoothly as long as it doesn't loose exclusive access which is most definitely is:
http://mamedev.org/source/src/osd/windows/input.c.html - line 1510

Code: [Select]

DWORD cooperative_level = DISCL_FOREGROUND | DISCL_EXCLUSIVE;
MAME gets non-exclusive access to the mouse and keyboard but the joysticks are exclusive.  I'll mention it on mameworld and see if anyone speaks up.

[baritonomarchetto]

EDIT: just seen that the code i was asking for is (bdam work) is still attached

[yellowmustard]

interesting!