My official MAME output wip thread.

[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.