The NEW Build Your Own Arcade Controls

Main => Software Forum => Topic started by: 1UP on March 07, 2010, 06:47:49 pm

Title: LED control from Mame--in over my head again?
Post by: 1UP on March 07, 2010, 06:47:49 pm
So after many years, I've finally got a hardware combo that works to control a solenoid board from my PC.  Terminator 2 recoil is my goal and last night it seemed so close.  Using LEDBlinky or Mame Hooker I am able to trip the trigger circuit that makes my recoil board fire--awesome!  But now I'm at the last step--getting the LED software to read outputs from Mame lamp status.  This is where I'm stumped.

In Mame Hooker I can manually send a state change with a command like "lws 1 01 1", but a command to have the state passed from Mame like "led0=lws 1 1 %s%" does nothing.  I have tried setting the "led0" part to various values in case led0 does not exist, but nothing.

Is this something that is supported on a game-by-game basis, at the whims of the Mamedevs?  AM I going to have to rewrite the midyunit.c to output an led value based on a state change in the game?  If so, I do have a hack from the old wmsyunit.c that someone did wayyy back to make T2 light the keyboard LEDs, but not sure that will work in this case.

I'm totally not a coder, not even sure what the first step should be, but I'll give it a shot if someone can point me in the right direction.  I would appreciate any help!  Examples would be awesome!  And if someone has info on where I can find a master list of configs to get a bunch of Mame LED supported games to work with LED-Wiz, I think I will cry.

Thanks!

Rob
Title: Re: LED control from Mame--in over my head again?
Post by: smalltownguy on March 07, 2010, 07:58:36 pm
I worked a little bit with the ledutil.exe program in my setup, but it was only to light my Atari volcano LED's. I'm not sure of any other LED output from MAME, but maybe someone like urebelscum could assist?

Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 07, 2010, 08:49:03 pm
In Mame Hooker I can manually send a state change with a command like "lws 1 01 1", but a command to have the state passed from Mame like "led0=lws 1 1 %s%" does nothing.  I have tried setting the "led0" part to various values in case led0 does not exist, but nothing.

Thanks!

Rob

Well that's your first problem.  Look at your example.... in the first one you have "01" which is the proper syntax, but in the second you do not.  Also led0 denotes a led output.  With one glaring exception guns do NOT use the name "led" as an output name.

That aside......  A game must have outputs hooked up.... that's why mamehooker has a debug mode!  Fire up mamehooker and click on the icon in the taskbar to make the debug window appear.  Now fire up the game in mame but in windowed mode (so you can still see the debug menu.)  If a bunch of outputs dont' appear in the debug menu while playing then there aren't any outputs.

With that being said, I can tell you ahead of time that the only positional gun game that has it's outputs hooked up in mame is operation thunderbolt and they are erroneously labeled as "led0" and "led1".... it's on my list of things to fix and re-submit to the mame devs.  And no, terminator 2 and revolution X are NOT hooked up. If you want to send me the hacked source code I can look at it as thunderbolt is included in mame's source and it's a pretty bad hack as well.  I see no reason why it couldn't be added to the mame source. 
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 07, 2010, 09:11:28 pm
Oh and btw... hey 1up long time no type!  Hated to just tear into the issue like that but I needed to get done with the technical details first.   :cheers:  Mr. Do, myself and a few others (mostly me though) are currently trying to document what outputs are in mame and then deal with any issues and try to get other games hooked up.  

To answer your question... yes, they are just hooked up at random at the whim of whoever chooses to do so.  

You've really got five types of games with outputs:

Type #1 was immediately supported upon the creation of the output system.  These are games that were already hooked up to keyboard leds before the outputs system  was created.  Since the keyboard leds are now automatically routed to the output system they work (this is thunderbolt's deal) but of course they are almost always labeled wrong.

Type #2 was also immeditaly supported.  These are games that had "blinking" artwork before the output system was created.  If a game has artwork then it's artwork states are automatically passed on to the output system as well.  These are generally labeled better.  Also these are generally the first to get "fixed" in terms of games that currently don't have their outputs working because lots of people use the artwork system and Mr. Do will generally bug a mame dev to hook them up when he gets a new scan of their bezel or what not.  ;)


Type #3 are games that have known outputs, but they are "complicated" outputs that require precise knowledge of the pcb and a lot of data-manipulation in-driver to be able to send anything to the output system that's useful.  Afterburner and the games that run on it's boards are great examples of this.  Aaron Giles was a great fan of afterburner, so he personally hooked up the lamps when he made the output system but that's as far as it's ever gotten, even though the output addresses are generally known for all the games on those boards.  Open up the source and see all the crap that had to be done just to get INPUTS in these games and you'll soon understand why.  I fear these games may never get hooked up unless a fan of the particular game, who also happens to be a mame dev, gives it a go we are screwed.  I tried working on afterburner and others a few months back and failed miserably.  Because it's a midway board, terminator 2 also falls into this group.  Don't get me wrong, it's not "sega y board" hard, but it's still a little hard.

Type #4 are games that have known outputs but the driver in mame is ANCIENT and the original author, who would be more apt to know the memory address of the outputs are long gone.  These games probably won't ever get hooked up either unless someone takes interest.  As far as most of the mame devs are concerned these drivers are finished and done with, so they are neglected.  Fortunately they aren't that difficult to hook up though, it'd just take a great investment of time.

Type #5 are games newly added to the driver.  We are very fortunate that the output system is also used for artwork because thus far nearly every new game added since the output system was created has had it's outputs hooked up so mr. do can do a bezel for it.  Since the non-artwork outputs are just as easy to hook up, they get fixed as well.  This means at least new drivers aren't going to be a bother.

Anyway.. ramble over.  I'm currently making a list of all mame games with outputs, but it isn't ready and I'm also going to have a go at cleaning up the output system in mame.  So if you wanna help that'd be great and if you have "hacks" send me the drivers.  
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 08, 2010, 01:10:18 am
Well that's your first problem.  Look at your example.... in the first one you have "01" which is the proper syntax, but in the second you do not.

LOL, Howard then you need to clean up your docs...I pasted those examples from the Mame Hooker readme file!   ;)  But that's good to know.

I'll send you the driver hack.  I cant get the Contact link to work on your site, so I'll try your profile email.  I'm perfectly happy to help test stuff in my spare time, but I won't be able to help much on the coding side....

Thanks for the info.  Maybe I'll even try pasting the hacked part into the latest source and see what happens.

Rob
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 08, 2010, 01:25:37 am
Since I posted that I rememberd you had a site (darg!) Downloaded the driver and had a look.  That is not a hack believe it or not, that is the actual output addresses!!  Or at the very least, it's close enough.  (Looks like a little bit of nvram trickery is being used as well.)  I know because there is a whole function in there to activate them you might think it's hackish, but it's really not.  Sure there's a tad bit of trickery in there, but have a look at the afterburner source sometime.  ;)

That's the good news.  The bad news is mame's adress system and some other things have changed since this hack.  We can use it as a base, but it'll have to be modified a lot.  We also want to go ahead and direct the outputs to proper names while were are at it.  I'm still working display files for mamehooker atm, but if you give me a week or so I should be able to get this working in the latest version of mame.  I'll then submit it to the devs.  The worst they could do is reject it and we'd still have the new source for custom builds so it seems like a no-brainer to me. 

Oh.. and also this could be useful for getting outputs to work on revolution X as well.  Not that anybody cares about that game, but hey.  ;)
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 08, 2010, 01:43:55 am
Awesome!  I'll make sure to bug you--I mean check in with you about it now and then...hehe.

So from what I know of the game, here's how the LEDs work.  In the original game, there were 3 outputs for each gun.  One was for the solenoid.  One was for a red LED that meant you were being targeted by a Terminator.  The last was a green LED that meant you had a lock-on with your rocket launcher.  (There were also 2 other outputs I believe, one lamp for each player that would flash behind the mirrored glass when you were hit, but I dont know if these are in that driver.)

Since there were only 3 keyboard LEDs available, I think Dave set this up so either there were 2 gun solenoid outputs and one LED output, or maybe it was just the complete setup for 1 gun (2 LEDs and one solenoid).  It's hard to remember, it was around 10 years ago that I picked this up from him.

Anyway, you should be able to test it by watching what happens when you are being shot at or you're aiming at a vehicle in the background.  The solenoid outputs should pulse in sync with the gun sounds in the game.  I did have this working at one time with a real T2 gun but it seemed like the circuit I'd built was kind of dangerous so it was scrapped...

I hope you can do something with this.  I've certainly been waiting a long time to get this game working, so if you have something you want me to test, I'll be happy to do so.   ;)  I've finally got a dual gun setup that works well, and getting the built in solenoids working is the holy grail that started me into this hobby in the first place.

Thanks for looking at this!

Rob
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 08, 2010, 01:53:05 am
It's kind of odd, how he's done it actually.  If I'm reading it right the solenoid  is hooked up for both guns but the red lamp is hooked up for player 2?  Why not player 1?  To be honest I'll probably have to hook them up first and then figure it out.  Some documentation on t2 would be helpful as well.  I can't find the manual anywhere!

Also... if I remembered right, there was a single red light but I could be wrong on that so I'll take your word for it.
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 08, 2010, 02:12:48 am
It's kind of odd, how he's done it actually.  If I'm reading it right the solenoid  is hooked up for both guns but the red lamp is hooked up for player 2?  Why not player 1?  To be honest I'll probably have to hook them up first and then figure it out.  Some documentation on t2 would be helpful as well.  I can't find the manual anywhere!

Also... if I remembered right, there was a single red light but I could be wrong on that so I'll take your word for it.

I've got the game manual.  Not sure how I would upload the whole thing though...lots of JPGs?

I used to have a couple of the original guns, and I can attest that they both had 2 LEDs just underneath the rear sights.
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 08, 2010, 04:05:35 am
This appears to be the manual.  Couldn't find my copy in the garage, but this came right up on google.

http://arcarc.xmission.com/PDF_Arcade_Manuals_and_Schematics/T2_Judgement_Day_%2816-40009-101-1%29_Dec_1991.pdf (http://arcarc.xmission.com/PDF_Arcade_Manuals_and_Schematics/T2_Judgement_Day_%2816-40009-101-1%29_Dec_1991.pdf)

BTW, the parent folder looks like a treasure trove of arcade manuals:  http://arcarc.xmission.com/PDF_Arcade_Manuals_and_Schematics/ (http://arcarc.xmission.com/PDF_Arcade_Manuals_and_Schematics/)
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 08, 2010, 12:45:59 pm
Thanks... my bad, I think it was the operation wolf service manual I couldn't find.  Regardless, this tells me what I needed to know, mainly the firing order for the outputs when you go into the service menu.  I might be able to hook them up the "right" way with this info as there are already some "unknown" ports defined in mame for terminator 2.  It could be a simple matter of hooking them up and manipulating the data. 
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 09, 2010, 01:57:43 am
That is a really nice manual site, thanks.  I was looking at the operation wolf manuals which they actually have, and noticed that those guns seem to use a different recoil.  It looks like they have a motor controlling a piston as opposed to t2's solenoid that turns on and off rapidly. 

Interesting.....

So for the midway games I'm probably looking for a pulse signal and on the taito ones I'm looking for a simple "on" switch. 

You've owned about all of the guns 1up, can you confirm?
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 09, 2010, 02:26:48 am
Hmm...I've only ever had the T2 guns, which were solenoid based.  Don't know about the Taito ones.
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 10, 2010, 02:34:17 am
I've got great news to report!

Took the day off from mamehooker to experiment with the source code and see what I could do in terms of hooking up outputs from positional gun games.  I started with operation wolf because it is the "simpliest" game to experiment with.  After two or three hours of studying the mame source, I FINALLY understood that the variable I needed to access was being routed to the video driver for operation wolf, which is in rastan.c  Anyway the comments said "0x04 normally, changes when you fire" over in the main driver so it was a no-brainer what was contained in the file.  Setup a simple function that checks in the video function if the varible = 4 and sets the output accordingly. 

Apparently this is correct because the output now behaves EXACTLY like the outputs in operation thunderbolt.... ie the value is zero unless you fire the gun AND it hasn't overheated AND you are playing an actual game. 


I'll submit it to the mame devs after I've made a collection of changes, but for those impatient fellows:

In src\mame\video\rastan.c
Find the function called "WRITE16_HANDLER( opwolf_spritectrl_w )" and after the line "pc090oj_set_sprite_ctrl(state->pc090oj, (data & 0xe0) >> 5);"
add the following bit of code:

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

      if (data == 4)
      {
         output_set_value("Motor0", 0);
      }
      else
      {
         output_set_value("Motor0", 1);
      }
--------------------------------------------------------------


This took me much longer than it should have because, quite frankly I don't know what I'm doing in regards to navigating the mame source, but since nobody else is looking into old games and hooking up outputs I guess I'll have to do.  If anyone wants to help me I sure would be grateful. 


Also note that "motor0" is just a placeholder name for the output... I'm not sure what to call gun recoils in mame, but once we all decide on something I intend to go into the drivers and change them all to the same value. 


Anyway, as it pertains to terminator 2 and the midway gun games, this should be helpful as well.  You see, this is basically the bit of the driver that tells the game when to draw bullets (there's more than that, but I'm simplifying).  Since all these games draw bullets when the solenoid goes off we should be golden. 
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 10, 2010, 02:50:43 am
Wow, nice discovery!  So if you patch the code as you said, would you get an LED-Wiz output from this by doing "motor0=lws 1 01 %s%" in MH?  If so, I'm going to have to try it out in the next couple nights...

This is getting exciting!
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 10, 2010, 03:18:25 am
Yes BUT.... remember as I said in an earlier post, operation wolf and operation thunderbolt use different types of recoil mechanisims than T2 does.  Bascially the output doesn't "flicker" like T2 does.  It will remain a "1" the whole time you hold a trigger down, unless the gun overheats.  It'll turn to a "0" when you release the trigger. 

So if your solenoid is setup to a board that toggles it on and off rapidly when power is applied then you are good to go.... if not then you'll need to make a script and run that instead to get the "flicker" back.  Fortunately that isn't hard to do at all.

I would suggest you try operation thunderbolt first to see what I mean as it works the same way. (I think it uses the outputs "led0" and "led1")
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 10, 2010, 06:25:09 pm
Ok, I don't think I'm gonna get any farther right now as I'll resume working on mamehooker for a while, but just an update. 

Looked at Terminator 2 for ages last night try to determine how to hook up outputs the "right way" and I was totally lost.  I though I'd take a look at revX instead which uses similar, but slightly different hardware.  Anyway, there's a generic 16 bit write function setup for the input/output of that game and basically it says via comments that they know what bits 0-5 do, but not the rest.  Currently it is outputting any additional bits to the debugger.  Since this is the I/O function and there are tons of unknown bits, it makes sense to me that some of those bits are the outputs. 

Now terminator 2 has basically the same 16 bit i/o address, but it isn't parsed the same way in it's driver because the midway y unit is basically for mortal kombat games.  Assuming I can get revX working, and that is a BIG assumption, then I can copy the function used in revx to the y unit driver and use it for terminator 2. 
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 10, 2010, 07:05:41 pm
You owe me 1up... I'm thinking a pony because it looks like I'm gonna be able to figure this out.   :afro:

hooked up a output just to any "unknown" data in the driver and this is what I came up with when in the dip menu testing outputs:

---------------------------
Logging Results for output "Motor0"
rest= 64496
gun 1 recoil =64497
gun 2 recoil = 64498
gun 3 recoil = 64500
p1 led = 64480
p2 led = 64464
p3 led = 64432
---------------------------
The text above is the value of my test output when the various status messages were on the screen.
These changed consistantly in the debug menu so I know that at the very least they have SOMETHING to do with the outputs.... I went ahead and tried inside the actual game and sure enough when I fired the gun the right-most position of the value "flickered" so I think that this is it.  Also to be sure I fired player 2 gun and again, it only changed the data when I fired.  Now of course this is only half of the battle.  Now that I know the general dataspace I have to filter the data into useable outputs instead of the huge 5-digit blob above.  It shouldn't be too bad, but it might take a while. 

Again, terminator 2 is on the midway y board, not the x board, but the x board was basically for RevX only so x and y are VERY similar.  This should help with getting T2 hooked up. 

So I sure am going about it in a round-about way, getting operation wolf and revX running first, but we'll get there. 
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 10, 2010, 07:41:36 pm
 :o  Watching with bated breath...
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 10, 2010, 08:09:47 pm
Ok I figured out RevX... or at least I did mostly.  I DEFINATELY have the individual outputs mapped now, but there seems to be some additional data manipulation needed.  The recoil "flickers" when you fire, but it is really slow... like once every half second.  Either that or my debug window can't keep up, which is also possible. The leds seem to act funny as well.  They are all on (1) by default but seem to turn off when you fire?  Also once you are out of discs (bombs) the light seems to invert.  Revolution X has to be one of the worst gun games out there, but if any poor sap has one let me know so I can see if this is normal behavior. 

Anyway... again, for you impatinet ones....

In src\machine\midwunit.c

Look for the function "WRITE16_HANDLER( midxunit_io_w )" and then after the line "default:" add the following lines of code:

------------------------------------
output_set_value("Debug", data  );
output_set_value("Motor0", (data & 1)/1 );
output_set_value("Motor1", (data & 2)/2 );
output_set_value("Motor2", (data & 4)/4 );
output_set_value("led0", (data & 16)/16 );
output_set_value("led1", (data & 32)/32 );
output_set_value("led2", (data & 64)/64 );
-------------------------------------

Again the "motor" names are just a place holder.  Also note that because I'm not 100% sure that I don't need to do something else, I've put the entire 16 bits of data in the "debug" output.  Maybe somebody else can figure it out.


We are almost there man... almost there.
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 10, 2010, 09:47:38 pm
I wonder if a good substitute for "motor" would be "actuator" since it doesn't matter if it's a motor, solenoid, servo, whatever, just an actuator that moves something.
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 10, 2010, 10:08:06 pm
Not sure.... standardization aside, I wanted to rename the outputs so one would get an idea of how to hook them up and more importantly so that "dangerous" outputs like solenoids were well documented.  Op Wolf and it's sequels use a motor, which is either on or off.... leaving it set on for extended periods won't hurt anything.  Solenoids on the other hand draw a butt-load of power when they are on. 

So I dunno, maybe the taito style games need a different label from the others???

Btw I'm looking at terminator 2 right now... that one is kicking my butt.  I'm not even sure if the memory space for the outputs is even being used in the driver!

Currently hooking up a generic "debug" output to each function that writes ANYTHING hoping I'll get lucky. 
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 10, 2010, 10:53:12 pm
Not sure.... standardization aside, I wanted to rename the outputs so one would get an idea of how to hook them up and more importantly so that "dangerous" outputs like solenoids were well documented.

Good point.
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 10, 2010, 11:25:07 pm
Well I'm tired of messing with this, so I'm done for the night.  I think I've tracked down the outputs in t2... (keyword THINK) and they are hiding amoungst the sound data. 

At least I hope they are because if not I don't have a clue. 

I can go into the debug menu and gets some outputs to flash and they also seem to work in-game.  BUT whenever a loud explosion occurs or something similar, all of the outputs go crazy. This makes sense as a sound is being played.

RevX did something similar in that it had a watchdog bit and everytime the bit was on, all the other outputs went crazy.  All you had to do was ignore the data when the bit was set and you got what you wanted.  The thing is, I haven't found the "this is a sound playing" bit yet.

I'm guessing it would have to be genuine outputs I've got and not just sound data, because they flash in the debug menu and no sounds are played when the debug program is doing it's thing.  Of course I could be wrong.
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 10, 2010, 11:46:47 pm
Ah, right, now I remember David saying something about a link between the sound and the recoil board.  I wish I still had that old email, it might be helpful.
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 10, 2010, 11:55:30 pm
BTW, Thanks for spending so much time on this, I didn't realize you were spending all day on this.  Hope I can get home early enough tonight to check out the other games you worked on.
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 11, 2010, 01:56:06 am
BTW, Thanks for spending so much time on this, I didn't realize you were spending all day on this.  Hope I can get home early enough tonight to check out the other games you worked on.

Well I hadn't planned on it.  The problem is when you make progress it's hard to stop. 
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 11, 2010, 02:32:40 am
Tell me about it.  I end up spending about an hour too long at work every night when I'm making "progress".
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 11, 2010, 03:53:42 am
So I tried a quick othunder test tonight by typing "led0=lws 1 16 %s%" in the test window but no dice.  Will this only work with a script?  May also be the version of Mame (1.03), I'm not sure when the output system was put into place.  In 1.36 I can't even run othunder because it is an outdated rom...
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 11, 2010, 04:11:34 am
So I tried a quick othunder test tonight by typing "led0=lws 1 16 %s%" in the test window but no dice.  Will this only work with a script?  May also be the version of Mame (1.03), I'm not sure when the output system was put into place.  In 1.36 I can't even run othunder because it is an outdated rom...

Not sure when the output system was implemented.  You need to elimate the middle man.... the procedure when first writing commands for a game is to always open up the mamehooker debugger window and run the game in windowed mode.  This ensures the game in question has outputs hooked up.  If that version of mame is older than the output system, the debug window should remain blank the entire time.  If you get [mamestart] and [mamestop] messages then the output system is there but the outputs for operation thunderbolt haven't been added yet. 

If they were added in after the output system was implemented then the person who did it should be ashamed.... those aren't leds!


I couldn't resist looking a t2 a little more and I think I may have taken a wrong turn.  Going into the sound menu makes obvious that all the bits I've hooked up simply create the "track number" for each sound effect to play.  It still doesn't explain why they blink in the output test menu though.
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 11, 2010, 08:34:03 pm
Just wanted to give a quick update.  I tired RevX with my force feedback controller just to see if it was the debug window not being able to keep up and thankfully it was!   The gun fires properly.  One thing that seems odd to me is that when you insert a coin and ONLY when you insert a coin, the gun for the coin slot you used rumbles once.  Is that how the arcade game did???

Anyway, I'll have to install a more robust debugger in mamehooker to figure out terminator 2 as it's now apparent that my debug window is too slow to keep up.  Hopefully this will lead to the answers we are looking for. 
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 11, 2010, 09:44:12 pm
Really cool.  I had no desire to play RevX before but now I'll have to.  Its been awhile since I've recompiled Mame so I'll have to browse the docs a bit so I can try out all this stuff.
Title: Re: LED control from Mame--in over my head again?
Post by: smalltownguy on March 11, 2010, 10:07:02 pm
Just wanted to give a quick update.  I tired RevX with my force feedback controller just to see if it was the debug window not being able to keep up and thankfully it was!   The gun fires properly.  One thing that seems odd to me is that when you insert a coin and ONLY when you insert a coin, the gun for the coin slot you used rumbles once.  Is that how the arcade game did???

Anyway, I'll have to install a more robust debugger in mamehooker to figure out terminator 2 as it's now apparent that my debug window is too slow to keep up.  Hopefully this will lead to the answers we are looking for. 

Yes, as I recall the Rev X guns would rumble when you coined up.
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 12, 2010, 03:25:56 am
Finally got newer roms for these games, will have to test this over the weekend.  So far I'm not seeing anything in the debug.  But I'm sleep deprived and probably doing something wrong.
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 12, 2010, 01:50:23 pm
Again, I'm not messing with the source atm, but I wanted to let you guys know the best way to write a script for operation wolf/ operation thunderbolt

Since the outputs for these games are always on/ always off, you might want to put some strobing in there depending upon your output device.  I had to test to make sure mamehooker was fast enough to work and that the driver updates the state quickly enough but, anyway.....

In the command simply make one action switch the device with the %s% tag and then immediately turn it off again with a ","

For example, on my xinput device I use the command:

motor0=xip 1 %s%,xip 1 0

The state is refreshed every frame, so the script is constantly re-loaded, meaning there isn't a need for a loop. 

Now this is a little weak for my 360 controller and it uses an offset motor for rumble anyway, so you'd just keep it on, BUT if you were hooking it up to a kickback solenoid this would be just right. 
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 12, 2010, 02:38:49 pm
Thanks Howard, I was wondering how to do this.  I should be able to have a good setup to test this weekend.
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 13, 2010, 03:23:55 am
Howard, I tried the example you gave for othunder, but it didn't quite work.  In my othunder.ini, I tried:

led0=lws 1 16 %s%, lws 1 16 0

This causes the LED to light once and immediately go out until the trigger is released and pulled again.  When I just do "led0=lws 1 16 %s%" it will keep the led on steady as long as the trigger is pulled, until you run out of ammo as expected.

I tried also writing the above in a script, then calling the script with "led0=rfs othunder 0 %s%" in the ini file.  Same result--blinks on briefly then goes out until released.

The closest I've been able to get to rapid fire is with this:

led0=lwp 1 16 130,lws 1 16 %s%

This sets the power state to on/off, and it now blinks (slowly) as long as the trigger is held until the magazine runs out.  If I could control the rate of the flashing, I would be golden, but I can't find this in the docs.  Any ideas?
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 13, 2010, 11:38:13 am
Don't tell me you've bought a ledwiz just for your guns.  Mind you if you are also lighting your panel and stuff that's worth it, but talk about overkill.... there are enough outputs in the parallel port to fully control two guns. 


That being said, I never implemented the global pulse speed for my app because... well I always thought it was a silly feature, much like the blinking commands.  I can add it in though easily.... literally takes one line of code. 

That being said the ledwiz isn't really known for it's speed when turning on and off lights rapidly.  On top of that, most leds take a few ms to "warm up"  they are incredibly fast at doing so, but what we are trying to do is even more incredibly fast.  I've got a ledwiz sitting here in the floor so I'll see what I can find out.
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 13, 2010, 11:53:19 am
Hmm... I did all my testing on my custom build of opwolf, and it works fine on it.... opthunder must update only once.  So disregard the other potential issues as I could get the ledw to flash a led fast enough for opwolf, which is quite impressive actually, both for the led and the device.  I'll add the global pulse speed for the next release, but in the mean time, you can make a ledwiz script, not a regular script and set the loop number to a value high enough to where it lasts longer than the overheat time and you should be golden.  The rfs command doesn't support looping (yet)  so it won't help you. 
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 13, 2010, 01:10:01 pm
Ok.. the global pulse speed is still really slow, even set to it's fastest setting (now I remember why i didn't add it, there isn't a lot of difference in the speeds) Also note that you can set the gps in a lwa file and mamehooker supports lwa files. 

That being said... I added looping support to the mhs files and ran the same script with a loop of 200..... works just great on the ledwiz!

It's something I've been meaning to add for quite some time, but it was a pain in the butt and thus far their wasn't a need for it.  I won't release the new mh version for a while though... a few more things to add.  :)
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 13, 2010, 04:49:46 pm
Quote
Don't tell me you've bought a ledwiz just for your guns.

The guns may have been a contributing factor, but I mainly wanted to be able to light the controls for each game, and have attract modes on my cab.

Quote
So disregard the other potential issues as I could get the ledw to flash a led fast enough for opwolf, which is quite impressive actually, both for the led and the device.

Yep, already tested that with a looped animation in LEDBlinky, and it was more than fast enough (with the solenoids even) to replicate the rapid fire in T2.

Quote
I'll add the global pulse speed for the next release, but in the mean time, you can make a ledwiz script, not a regular script and set the loop number to a value high enough to where it lasts longer than the overheat time and you should be golden.

What do you mean by an LED-Wiz script?  You mean something written for Andy's software?  How about a LEDBLinky lwax animation file?  Those are easy to make. :)
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 13, 2010, 05:29:57 pm
Damn, I tried making an othunder.lwa file in the LED-Wiz software, that just flickers on and off.  I put that in my othunder.ini file as led0=lwa othunder 01 %s% but it just crashes MH when I run the game.  What am I missing?  :(
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 13, 2010, 08:02:26 pm
I don't have a clue.... poorly written script??  He changed the format??  I just pass the script along to the device, I don't have a clue in regards to it's format or anything.  I do know that you have to manually add the %s% bits inside the script because his software doesn't support it.  You also need to make sure the file loops.

I wouldn't sweat it man.  Next version I'll have the loop implemented on mamehooker scripts and they are a lot easier to write and I can confirm they work. 
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 13, 2010, 09:02:47 pm
I agree that your scripts are a lot easier to deal with.  I can tell at a glance what is going on now.  I was totally lost with the lwa script syntax...  I did try calling all of his demo scripts from MH and all of them crashed it.  So it wasn't just my poor scripting skills. :)

Any ETA on the next version?  I can hardly wait to start playing with this stuff.  I'm looking forward to any new developments on the T2 front as well.  Figures that the game I really wanted is the toughest to crack.  I mean Revolution X?  Just the intro makes me cringe...

Thanks!
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 13, 2010, 09:49:09 pm
Well I'm currently buttoning up the display files and getting their webpage ready.  Then I need to setup an examples page. 

Right now I'm currently trying to implement proper 7-segment display support for the display files like mame does.  Having issues with the renderer though. 
Title: Re: LED control from Mame--in over my head again?
Post by: headkaze on March 14, 2010, 08:58:08 am
Well I'm currently buttoning up the display files and getting their webpage ready.  Then I need to setup an examples page.  

Right now I'm currently trying to implement proper 7-segment display support for the display files like mame does.  Having issues with the renderer though.  

There are 7-segment fonts you can get for Windows in ttf format. Probably the easiest way to output numbers like that.
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 14, 2010, 08:18:36 pm
Not really.  The numbers mame outputs are the raw bits you would send to a digit controller via serial connection. 

So you Don't get a "0" or a "1" you get a "63" and a "6" respectively.  Now I've already looked at the mame source and figured out the parsing, and like most serial devices it's just a one byte value and increasing powers of 2 indicate the state of led bars 0-6 up until digit 128, in which all of the positions are repeated, but with the decimal point lit.

Now one might say "but isn't 0-9 all you need?" Wel for most games it is and that's why I still managed to release the display files I did, using traditional numbered images, but some games also use letters and even shapes.  I have a dragon's lair scorebaord ready to go, but seeing as how it uses so many shapes and also text in the game it really makes more sense to try to at least make an image generator rather than using a font and a 255 position translation file.

Also I don't like the way fonts look... they look, well, like fonts! I made a very nice digit in photoshop added a subtle glow, and it looks photo-realistic.  I even made it greyscale so that it can be colored, like mame's digits are.  The problem is masking off the individual digits.  Since they have those little points on the edges I can't just use a rectangle.  Now I could make each segment a seperate image and layer them, but the idea was someone could take a picture of a scoreboard displaying an "8" and then take another picture with it off and make a font out of it.  This could be used in the mame artwork files as well, seeing as you can hook the outputs up to a series of numbered images just as easily as you can the built in digit renderer. 


Long story short, yeah you are right there are easier ways to do it, but I want to try to do a really nice job of it.  I might end up puting this to the side for now though. 
Title: Re: LED control from Mame--in over my head again?
Post by: headkaze on March 15, 2010, 11:24:05 am
I'm not sure what drawing API you're using but I would imagine you could use rectangles if you have alpha channel support.
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 15, 2010, 11:55:19 am
Howard, I'm watching your site every day for a new release.  You're going to kill me with this display stuff you know.  Where am I going to find room for a second monitor on my cab?  :D
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 15, 2010, 05:13:04 pm
I'm not sure what drawing API you're using but I would imagine you could use rectangles if you have alpha channel support.

Well I'm trying not to use an alpha channel at all, that way if it's an odd scoreboard, (I've seen some with gel coloring half-way across the numbers ect...) It'll still work well.  I'm still trying to determine the simplest way for the user to make a font, once I figure that out I'll proceed with getting it working.
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 15, 2010, 05:20:25 pm
Howard, I'm watching your site every day for a new release.  You're going to kill me with this display stuff you know.  Where am I going to find room for a second monitor on my cab?  :D

It used to be a pain in the butt to find a small enough secondary monitor for cabs like ours, much less getting them working.  But now:

http://www.thinkgeek.com/computing/usb-gadgets/c609/ (http://www.thinkgeek.com/computing/usb-gadgets/c609/)

Sure the price is a little steep, but considering you don't have to fool it video cards and stuff it's well worth it.  they are small enough to where you can mount them under the marquee area on a folding hinge so that you can flip it up when not in use.  Of course that's a 16:9 display.....  I really need to con some sap... err I mean convince some loyal user to convert all the display files to a 16:9 format as well.  ;)

Myself I'm using a hacked psone monitor in the same manner, but that thing was obsolete before I even got it working. 
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 15, 2010, 06:11:29 pm
Actually....I wonder if there are apps around that will allow you to use a smartphone screen as an output device.  I've got 2 old PC phones and one PDA lying in a drawer doing nothing.
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 15, 2010, 07:01:34 pm
well yes and no...
Static images sure.... all bluetooth enabled phones have a standard hid interface, so mamehooker supports them right this instant.  The only problem is this serial interface is usually limited to sending files to save on your phone (mp3s images, ect), and not real-time streaming.

I doubt the screen resolution would be high enough to make out anything anyway.

But if we aren't worried about readibility, those tiny 1-3" picture frame keycahins are very hackable and it is now possible to stream video to them. If they ever go down to a reasonable price, I intend to make a control panel with a keychain embedded into the panel beneath each button to act as a label, like those fancy 300+ dollar keyboards.
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 16, 2010, 02:39:13 am
How do those PS1 screens look?  At least good enough for an instruction card/pinball DMD?  Looks like you can get a couple for less than that USB screen.  I would probably need 3 with my setup.
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 16, 2010, 03:17:10 am
I did find an app that turns a PDA into a USB monitor.  Have to juice up the old phone to try it out.
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 16, 2010, 03:54:09 am
Aw crap it doesn't work in Win7.  Have to try installing from XP later....
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 16, 2010, 12:18:53 pm
How do those PS1 screens look?  At least good enough for an instruction card/pinball DMD?  Looks like you can get a couple for less than that USB screen.  I would probably need 3 with my setup.

If you hack it for vga yes, if not it's a no on the instruction card.  You can't get a couple for less than the usb screen though because you'll need to get video cards as well, and not only that but compatable video cards (the screens run at near arcade resolutions).  The only card I could get to work is an ancient matrox video card.  It doesn't have any acceleration either so unless used in the right situation it slows your machine to a crawl.  So you can forget about linking three together.  That's why I didn't reccomend them.  ;)
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 16, 2010, 02:15:35 pm
Well, I'll keep experimenting with the PDA screens then.  They are low res (320x240 I think) but at least they're sharp, and small enough to fit in the space around my bezel.  So I would only need one in that situation.  Only question is whether they can be made to just boot up and enter the display app when I turn on the cab.  If I can keep power connected I think this won't be a problem--it'll just stay in memory.
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 16, 2010, 07:07:37 pm
Had another thought on on dual screen front.....  Remember the old school webcam pages that were just a bit of javascript that kept updating the image every few secs?  Well I can easily put a bit of code into mamehooker to save the display screen to a image  (part of it is already there for when I make preview shots.)  Since mamehooker already has a "state change" event I could have it save the image to file on the local machine.  Then all you'd need is a http server setup on your pc.

The DS, PSP cell phones and most pda's all have web browsers, so for the display files and simple things like instruction cards at least, this may be the easiest solution.   As for pinmame... it's so demanding you'd pretty much need a real monitor for that.


-edit-

I actually gave this a try at least on my local machine, and it works pretty well.  I implemented a save image feature for mh and linked it to the state change event in some ini files.  I then setup a html file with a little bit of java that automatically refreshes the image once every half second.  I first tired seawolf with my webpage open and it was pretty much a 1:1 experience with zero drops in "frames"  I also tried turbo, which if you look at it's display file is about as complex as it gets and while it wasn't 1:1 it was still very viewable and didn't stutter or anything.  Of course I can adjust the refresh rate to just about anything, but the faster I make it, the more processing power it takes.  I tried seawolf on every 1/10th of a second and it still did fine though.
There are ways around the process hog as well, like just hosting the image on the webserver and storing the actual webpage itself on the remote device.
Also keep in mind that the lower the resolution, the better the frame rate.  If your pdf only displays 320x240 then you set mamehooker's display size to 320x240 and it'll speed up things dramatically.

But keep in mind I tired it on the same machine as mame, which obviously could load the image really fast.  I have some laptops and netbooks to try it on and I'll do that once I setup a webserver on this machine and/or move the html file to a shared folder.  I want to try it on my DS as it'd be an ideal viewer, but finding a working webbrowser on the ds is more difficult than the coding I just did!


I also think this method might have potential for pinmame as well, but only if the dmd display was set to original size and a REALLY fast form capture routine was used.  Even then the host machine would have to be pretty beefy.
Title: Re: LED control from Mame--in over my head again?
Post by: headkaze on March 16, 2010, 11:00:04 pm
This reminds me of GameEx's Game Extender feature which displays game art to a server or localhost to a secondary screen. I have CPW display to a secondary monitor (video (http://headsoft.com.au/index.php?category=cpwizard)) but I think it would be cool to be able to view controls on a mobile too. Heh if I ever get time to update CPW.. too bad your not a C# programmer Howard I've been thinking of handing on some of my MAME projects to keep them alive. I write games now so don't really have the time.
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 16, 2010, 11:40:44 pm
Yeah... strictly speaking a UDP protocol would be the fastest, most efficient method.  I'll probably implement that anyway, but the webpage thing is more universal as apps that actually do something useful on the DS, PSP, or random portable device are pretty slim.  

I did some more testing on my mom's netbook which, while brand new is a slow pos with even slower download rates in wireless mode.  If I set the refresh rate to once every half second and the image resolution to 320x240, the frame rate is barely acceptable on games like seawolf.  Faster games like turbo do a tad bit worse and super fast games like skydiver kill the poor thing.  

Luckily this was just a test, there are tons of things I can optimize.  First off I'm saving the images to bitmaps cause they are the fastest to save, but they are also the largest files to transfer.  I could cut the download speeds in half just by saving as jpg.  Of course there is a fine line there as it takes longer to save a compressed file as well.

Also the javascript itself seems to be the weak link.  It's a simple script that simply reloads the image constantly.  It would be better to have an intelligent script that checks crc or something but I'm not that talented a java programmer. :(

I can muddle through c#.... I've studied it a little in my time away, but yeah, I don't know if I'm competant enough with it to take over.


What kind of games are you working on?
Title: Re: LED control from Mame--in over my head again?
Post by: headkaze on March 17, 2010, 01:42:49 am
What kind of games are you working on?

My website is in my sig.. we did 3 free games for the DS and now we're making our first indy game for iPhone which is a platformer. This is our first original game aswell all of the other were remakes (albeit written from scratch). Two in arm asm too  :o
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 17, 2010, 01:54:08 am
Eeek... assembly is scary.  Yeah I noticed the site after I posted, you need a bigger sig.  ;)

The ones released look pretty cool.  I'll have to give them a go once I get some time to dl. 
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 17, 2010, 04:34:12 am
Cool stuff Howard.  I was also looking into a free program called ZoneScreen, which is kind of a VNC program with the addition that you can extend the desktop onto another network device--including a pocket pc--not just mirror it.  So you would be able to for example, drag a window off your desktop onto the PDA.  The other one I'd been trying was SideWindow, which apparently needs a very old version of XP to run, and I don't feel like rolling back any of my machines to SP1 for a test...also it was not free.

More stuff to play with this week while I wait for your next release with all the new toys. :)

(Still hoping for a brainstorm on the T2 stuff though...)
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 17, 2010, 05:28:37 am
I've got good news, but I need help......

I implemented a new class file for my gdi  handling that works much better and I'm now saving the display file as a jpg file with medium compression.  That seems to have done the trick speed-wise.  I can run a 640x480 display file off the net remotely.  BUT, there is still one issue.  Every now and again the javascript tries to load the image as it's being written and of course it errors.  The webpage keeps running but you get that classic red x for a second.  The script needs to be modified so that it uses the last image if there is an error, which will prevent this flickering.  Here's my script:


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

<html>
<body>
 <IMG src="test.jpg"  border="0" name="refresh">
      <script language="JavaScript" type="text/javascript">
      <!--
      var t = .1 // interval in seconds
      image = "test.jpg" //name of the image
      function Start() {
      tmp = new Date();
      tmp = "?" tmp.getTime()
      document.images["refresh"].src = image tmp
      setTimeout("Start()", t*1000)
      }
      Start();
      // -->
      </SCRIPT>
</body>
</html>
-------------------------------------------------------------


Any takers on putting some error handling in there? 

Except for real simple stuff, like above I'm lost with javascript so I don't really know how to fix this issue. 
Title: Re: LED control from Mame--in over my head again?
Post by: headkaze on March 17, 2010, 06:11:05 am
Not sure but perhaps you could try this webcam java class? http://www.worldofjon.com/java/java5.html (http://www.worldofjon.com/java/java5.html)
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 19, 2010, 02:13:08 am
I believe, at least in HTML, there is a way to set a default image that appears in place of any missing image on a web page.  I think this can be set at the head of the script along with the background color etc.  Maybe if you wrote the frame to both places, it would be unlikely that both would be unavailable at the same time.  If the main image is not available, the default one would still be there from the previous write, and if the default image is the one being written, it doesn't matter because the main image is loaded.  At least that's how I think it might work...

Another possibility would be to have the image inside a frameless table, and set the background image of the table to be the duplicate image.   But either of these would create some additional overhead.

I think you're on the right track with this.  I've been playing with the virtual monitor stuff, and it does work, the frame rate and color depth is adequate, but so far I've yet to find a way to get it to log in to the server on bootup, or even handle the server shutting down when you power down the PC without having to interact with the device.  But it would be simple to get Pocket IE to launch full screen on startup, and load up the default web page which could be set to this page that Mame Hooker is writing to.
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 19, 2010, 02:45:24 am
I tried the script you linked to hk... it's not much help.  I did modify my script to have a bit of error handling, but it only helps the problem so much.  It seems that ie sometimes (not often but maybe once every 20 secs) is able to open an image file as it's being written.  There are, of course other alternatives.

It would require somene else to do the webpage end, because I suck at javascript, but a more bandwith saving technique might simply be to re-create the display file in html with the individual images in tact and incorporate a bit of javascript to constantly read a file that tells the status of each output.  It's easy in javascript to rapidly display/hide an image... that's how mouse-over events work.  I'm guessing it could take a while to load more complex displays, but once they are loaded everything should be in real time.

Of course this is all for animated display files.  Static displays like a marquee, instruction card, command.dat, ect.... that'd be child's play.  You wouldn't even have to constantly refresh the image.  (Mind you, you could.)  Instead the best bet would be to have a generic webpage with REALLY simple navigation.  The javascript, instead of constantly re-loading the image, would re-load the html files body, which would update the links.  It doesn't take any time to reload text and since you aren't refreshing the actual images, they wouldn't get constantly reloaded unless their address changed. 

I intend on adding generic file operations support to mamehooker tonight.  What you'd do is designate a folder where your webpage will be stored. You'd then keep all the non-generic stuff in a seperate sub-folder  Upon mame startup, you'd delete everything in that folder, copy the artwork from all your folders (marquee, flyer, cards, ect) into the folder and re-edit the html to the new link names.  So long as the link's have different names, the page should re-load them. 


Anyway, I FINALLY got my digit creator working just the way I want it, so a release is immenant.  Should be out by this weekend.
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 19, 2010, 02:50:27 am
 :applaud:  :cheers:
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 19, 2010, 05:27:21 am
Well, I would like to test the new image output with my ds, but I need help. 

The ds's webbrowser can't see networked files, so I need a webserver.  I need a SIMPLE webserver, that'll run on windows 7.  Any suggestions?
Title: Re: LED control from Mame--in over my head again?
Post by: headkaze on March 19, 2010, 12:03:27 pm
The DS should be able to download the image using DS Wifi (which is included in devkitArm). There is an app to display jpg images on my website in the DS section.

What you could do is upload two images Eg. Image1.jpg, Image2.jpg and swap between them If you used a perl cgi script you should be able to attempt to lock the file before displaying, and if that fails display the other. Flash would be even better as you wouldn't need to refresh the whole page.

For a web server IIS is the native web server for Windows although not sure if all versions of Winows 7 would include it (XP Pro had it but XP Home didn't for example). You can always try the most popular web server Apache. I believe you get perl/cgi support as standard.
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 19, 2010, 04:52:07 pm
Well, that would mean I have to write an app for the ds though, which I'm not willing to do.  Html, only solution is best because it'll work on any portable. 

I don't know if perl is supported on the various ds browsers out there.  I think you can lock the file in javascript, or at least determine if it's corrupted or not, but again, my web-design skills suck. 

IIS and apache aren't simple.....  I want simple.  As in run an app and boom that folder is a webpage, no settings, no installation, no frills.  I downloaded one similar to this last night but it had win 7 issues. 

Thanks for the help though.
Title: Re: LED control from Mame--in over my head again?
Post by: headkaze on March 20, 2010, 02:28:27 am
A browser doesn't need to support perl, the server executes it and displays html.

Apache is pretty much install and go.. IIS is more complicated to setup (suprise suprise). Not sure about a web server with no installation but I'm sure there are apps that can serve a simple picture to port 80. Perhaps something like Resin (http://www.caucho.com/resin-3.0/install/httpd.xtp)
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 20, 2010, 03:15:20 am
I'm not going to worry about it.  I've added functions to mh to both output the current image and output the current states to a text file.  That should be enough for somebody else to design a webpage we can all use.  I have to add the new gdi classes to the digit generator and then this puppy is ready for release.  Then barring udp support for daphne this will probably be the final version.  Of course the display files need updated and such, but that's not related to the app itself. 
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 20, 2010, 05:53:02 pm
Howard, will it be possible to have it write two images each time, if I wanted to try the route I described above?
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 20, 2010, 06:52:52 pm
I don't see why not.... any scripting even tcan have an infinate number of commands... that's what the commas are for
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 21, 2010, 05:16:51 pm
Well I've started on the mame source again....

I honestly don't know how I'm gonna figure this out.  Terminator 2 strobes the data I need so quickly, even with logging it to txt it just turns out to be a incoheriant mess.
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 21, 2010, 05:22:40 pm
I thought the hacked driver already had the memory addresses needed.  Are you just trying to add the other outputs now?

Ah, just saw that you posted the new release.  Gonna do some playing now. :)
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 21, 2010, 05:55:07 pm
I thought the hacked driver already had the memory addresses needed.  Are you just trying to add the other outputs now?

Ah, just saw that you posted the new release.  Gonna do some playing now. :)

The hacked driver isn't quite accurate as I found out.... doesn't get the exact data needed... had to try it before I discoverd that.   Besides that the addresses have changed since the driver got re-worked.   On top of that knowing that address XXXX is the output data and parting those two bytes into 16 bits and then deciferign said bits are two different things.  I'm currently working on the ladder.

I have made progress though!  You are the t2 expert so I'll ask you to confirm....  T2 had strobe lamps inside the machine and when a terminator got close and fired at you they flashed right?  Because I have those hooked up!  It seems that their status, the sound file status, and the status of the guns are all strobed into the same 16 bits.  There is a rather complicated bit sequence fired for each one prior to setting the bits, to make this possible.  Basically the data gets changed once to say "here comes this type of data" and then it's send again with the actual data. 

The strobe lamps were the easiest as all you have to do is read the data when bit 11 (2 to the 11th or 2048) is off.  This bit is on for all other data reads, so I get to cheat a little on that one.  They fire in the proper order in the driver board test in the dip menu and when I played a game I let a terminator fire away at me on the right side and the right strobe values flashed like crazy, so I'm guessing I have those completely figured out. 

Now the guns will be more difficult.  There seems to be two chunks of data that come with them, and I'm not sure what to do with it.  I'm also having trouble sorting it out from the sound data as yes, even the sound is sent through this same 16 bits.  Once I can find the magic bit setting to say "this is gun data" then I shouldn't have any problems finishing the hookup. 
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 21, 2010, 06:40:37 pm
Lol this must be frustrating for you.....

I think I just figured out the gun leds (not recoil, just leds) as well.  The problem is I don't know what they do.  They seem to flash in the correct order in the driver test menu, but in-game I occasionally get the green led to flash, and that's about it. 

Still not any close to figuring out the actual recoil though....

I think it's break time.....
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 21, 2010, 06:47:01 pm
I believe that is how it works.  However, I don't remember ever seeing this in the arcade so maybe the flash lamp fuse was prone to blow out.  That output might also be hooked up to the red LEDs, since it is supposed to provide the same function.  According to the manual, it comes on when the player is being targeted and shot at.

The green LED should come on when your cross hair is over a target.

No worries, I'm glad to see any progress on this game.   :D
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 21, 2010, 09:45:20 pm
Arrrgh!  Been playing with MH 3.6 and othunder, and after trying various combinations of loop, wait, and rfs commands, I just can not find a way to get it to flash the LED while the led0 status=1.  The results I get are always either: a) nothing, b) Mame Hooker crashes, c) solid LED when the trigger is pulled until ammo runs out, d) LED flashes on briefly on trigger pull, stays off while trigger held, then on briefly again when trigger released/ammo runs out.  "lop #" seems to do nothing different in any of these scenarios.

With the new commands, what would be the recommended way to simply have the LED flash on/off while the led0 status is 1, then stop the flicker and turn off the LED when led0 status is 0?  I thought I understood the examples in the docs...I figured something like the "whiteorred" example would do the trick, but no luck...

Thanks
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 21, 2010, 09:54:10 pm
You are probably over thinking it. 

here are the contents of my "360strobe.mhs" file:

-----------------------------------------------------------------
xip 1 %s%
xip 1 0
lop 200
-----------------------------------------------------------------

That's it.  200 cycles are enough to keep it going until an overheat.  Also note the %s% command is used because this script will still be loaded when the value of led is 0, only it won't do anything because the state is 0.  It'll work for the ledwiz as well (with different commands of course) because that's how i tested the script at first.

so your command is

led0=rfs 360strobe 1 %s%

Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 21, 2010, 09:58:06 pm
Btw... I think what you weren't getting about the rfs command is that once a script starts, it doesn't stop until it finishes.  LFS is a little more flexible, but then again, it's an infinate loop.
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 22, 2010, 02:33:01 am
Aw snap, that works perfectly!  I knew there had to be a simpler way.  I was trying to have it call separate scripts based on the state.  But this is awesome.  It looks to be almost the perfect speed to go with the sound effects too.

Alright, I've finally got something I can test with my guns.  Time to have some fun.  8)

BTW, for anyone else who wants to try this, here's what I've got:

In the ini folder, I have othunder.ini which gets called when Mame loads Operation Thunderbolt.  Inside it is the following (without the -------------------------------------- ):

--------------------------------------
[General]
MameStart=lwp 1 16 49
MameStop=
MameHookerStart=
MameHookerStop=
StateChange=
Pause=

[Output]
led0=rfs lwrapidfire1 1 %s%
led1=rfs lwrapidfire2 1 %s%
led3=
led4=
--------------------------------------

Then in the scripts folder, I have two scripts that handle the rapid fire:

inside lwrapidfire1.mhs
--------------------------------------
lws 1 01 %s%
lws 1 01 0
lop 200
--------------------------------------

inside lwrapidfire2.mhs
--------------------------------------
lws 1 02 %s%
lws 1 02 0
lop 200
--------------------------------------

Now when each gun fires, the corresponding output flickers on the LED-Wiz until the trigger is released or the ammo clip runs out.
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 22, 2010, 03:34:43 am
Let me know how it works, and be sure to make pictures/videos.  I'm building an examples page once I figure out wtf is going on with terminator 2.
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 22, 2010, 04:29:34 am
OK, I now have the recoil board hooked up to Operation Thunder!  And boy is it loud!  First time I powered up the board I thought something blew because I heard a loud POW.  After that the LED-Wiz was not responding so I was sure I'd fried it.  Then I realized it was because I had suspended my laptop and Mame Hooker was not seeing the LED-Wiz.  Restarted MH and it was all good.

The kickers are frigging scary now that they're back inside the gun.  It's about as loud as a .22 going off.  Might have to get some rubber bumpers to put inside to tone it down, as well as protect the gun shell and the Aimtrack from shock--the metal plunger just whacks into the plastic shell!  I was counting on some shake and a little noise, but with these the whole house knows I'm playing.  :o

Now I just need to splice the USB cable back together.  Had to cut the end off to run it down the hose.  Should have a good test with the Aimtrak and recoil working together in the next couple nights.  As soon as I have videos, I will post them.

Thanks again Howard for building this neat little program.  I really can't wait to get both guns going in T2.    ;D
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 23, 2010, 02:46:37 am
holy crap I think I've got it... Or at least I've gotten it enough to be playable.   ;D

in src\drivers\miidyunit.c

at the function "static WRITE16_HANDLER( term2_sound_w )"  immediately after the first "{" add the following monstrosity of code:

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

   if  ( ((data & 2048) != 2048) and ((data & 1024) == 1024 ) )
   {
   
   output_set_value("Left_Flash_1", (data & 1)/1 );
   output_set_value("Left_Flash_2", (data & 2)/2 );
   output_set_value("Left_Flash_3", (data & 4)/4 );
   output_set_value("Left_Flash_4", (data & 8)/8 );
   output_set_value("Right_Flash_1", (data & 16)/16 );
   output_set_value("Right_Flash_2", (data & 32)/32 );
   output_set_value("Right_Flash_3", (data & 64)/64 );
   output_set_value("Right_Flash_4", (data & 128)/128 );
   }


if  ( ((data & 2048) == 2048) and ((data & 1024) != 1024 ) )



   

{



   if  (((data & 16) == 16) and ((data & 32) == 32) and ((data & 64) == 64) and ((data & 128) == 128) and ((data & 1) == 1) and ((data & 2) != 2))
   {
   
   output_set_value("Left_Gun_Recoil", 1 );
   
   }
   else
   {
   output_set_value("Left_Gun_Recoil", 0 );
   }



   if  (((data & 16) == 16) and ((data & 32) == 32) and ((data & 64) == 64) and ((data & 128) == 128) and ((data & 2) == 2) and ((data & 1) != 1))
   {
   
   output_set_value("Right_Gun_Recoil", 1 );
   
   }
   else
   {
   output_set_value("Right_Gun_Recoil", 0 );
   }



   
   if  (((data & 16) == 16) and ((data & 32) != 32) and ((data & 64) == 64) and ((data & 128) == 128))
   {
   
   output_set_value("Left_Gun_Green_Led", 1 );
   
   }
   else
   {
   output_set_value("Left_Gun_Green_Led", 0 );
   }


   if  (((data & 16) != 16) and ((data & 32) == 32) and ((data & 64) == 64) and ((data & 128) == 128))
   {
   
   output_set_value("Left_Gun_Red_Led", 1 );
   
   }
   else
   {
   output_set_value("Left_Gun_Red_Led", 0 );
   }

   if  (((data & 16) == 16) and ((data & 32) == 32) and ((data & 64) == 64) and ((data & 128) != 128))
   {
   
   output_set_value("Right_Gun_Green_Led", 1 );
   
   }
   else
   {
   output_set_value("Right_Gun_Green_Led", 0 );
   }

   if  (((data & 16) == 16) and ((data & 32) == 32) and ((data & 64) != 64) and ((data & 128) == 128))
   {
   
   output_set_value("Right_Gun_Red_Led", 1 );
   
   }
   else
   {
   output_set_value("Right_Gun_Red_Led", 0 );
   }

}
--------------------------------------------------------------------------


I don't think I have it 100% right as sometimes the recoil seems to slow or be a little un-responsive, but it is as far as I can go with it.  I'll clean up my code and send it to mamedev within the week.  I can say this, the problem is NOT with the improper bit-address(es).  I NEVER get a false mis-fire now.  The problem is I think my conditions are a tad too strict, and every once in a while a fire gets missed, but as I said, this is as far as I can go without hardware schematics, the actual hardware to send data to, ect.... 


On a side note, how do you like my output names??  I couldn't decide on a propr standardization, so I simply took the text that appears in the "driver board test" menu.  I pretty much had to use these names as I was debugging because it became too confusing to keep track otherwise.  I think this might be the way I need to do revX as well.  As for operation wolf and thunderbolt, they don't have a debug menu, so we can name them whatever we deem appropriate. 
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 23, 2010, 03:23:50 am
That's awesome Howard!  I wish I had time to patch that in and recompile tonight but it will probably have to wait a couple days.

Regarding the recoil slowing down...are you sure that's not the game itself?  Your gun periodically gets low on power/overheated which slows the rate of fire, and you need to get the power ups (ammo or coolant) to get it going again.

Your naming makes perfect sense, so I say keep it!

BTW, that manual I posted on page 1 has full schematics of the system I think.  You should check it out if you haven't.

I just got done blasting some terrorists in Thunderbolt with the Aimtrak and recoil hooked up for the first time, and I think I need to slow the repeat rate to half.  The recoil is actually affecting my aim.  The gun is also getting pretty warm and I'm worried about eating through its life cycle too soon...
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 23, 2010, 05:54:27 am
I would be careful using the guns in opwolf/thunderbolt period. 

Judging by every pic I've seen of the inside of a opwolf gun, those guys work with a 12v motor rotating a piston.  This of course explains why we have to use our strobing script but also keep in mind that a piston doesn't have any constant resistance and thus is very hard to overheat. 

I can also tell you that the strobe on the terminator guns is MUCH quicker.  It's so quick that I had to artifically lengthen it via scripts for it to work well with my force-feedback controller.  So that might explain why you are getting such a hard, loud knock with your guns.

I would definately install some padding btw, that's just a good idea all around.
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 23, 2010, 07:53:18 am
There we go.... I got it fixed completely this time.  I sware I looked in the t2 manual 1000 times but didn't notice the little note about how you can repeat a firing by holding the service button until this morning.  Putting the output in an infinate loop sure makes it easier to understand the data being sent. ;)  Forgot to take away all the insaine multi-conditional flags for each output after I found the "magic flags" to let me know which report it is.  I'm still not 100% sure on the gun leds, they seem to flicker an awful lot, but the recoil and lamps at least, are working perfectly. 

ok let's try this again... in src\drivers\midyunit.c  under the function  "static WRITE16_HANDLER( term2_sound_w )"  immediately after the first bracket add the following code:

-------------------------------------------------------------------------------------------------------
   if  ( ((data & 2048) != 2048) and ((data & 1024) == 1024 ) )
   {
   output_set_value("Left_Flash_1", (data & 1)/1 );
   output_set_value("Left_Flash_2", (data & 2)/2 );
   output_set_value("Left_Flash_3", (data & 4)/4 );
   output_set_value("Left_Flash_4", (data & 8)/8 );
   output_set_value("Right_Flash_1", (data & 16)/16 );
   output_set_value("Right_Flash_2", (data & 32)/32 );
   output_set_value("Right_Flash_3", (data & 64)/64 );
   output_set_value("Right_Flash_4", (data & 128)/128 );
   }


   if  ( ((data & 2048) == 2048) and ((data & 1024) != 1024 ) )
   {
   output_set_value("Left_Gun_Recoil", (data & 1) / 1 );
   output_set_value("Right_Gun_Recoil", (data & 2) / 2 );
   output_set_value("Left_Gun_Green_Led", 1-((data & 32)/32) );
   output_set_value("Left_Gun_Red_Led",  1-((data & 16)/16) );   
   output_set_value("Right_Gun_Green_Led", 1-((data & 128)/128) );
   output_set_value("Right_Gun_Red_Led", 1-((data & 64)/64) );
   }
----------------------------------------------------------------------------------------------------------------------


See, now that's much less insaine.  What was throwing me off is the gun leds are apparently active low (0 is on and 1 is off) so I had to invert them by subtracting the value from 1.  Remember when I mentioned that the leds in RevX seemd funky?  Well I can pretty much confirm now that they are active low as well, so I've fixed revx by figuring this out. 

This code is a lot cleaner and seems to give much more stable results.  Tried it with my ff controller and it now rumbles as I remember it in the arcade.  I can't really comment on the leds though because they were broken on our local t2 machine.  The lamps worked but I can't remember what they did exactly.  I know that Mr. Do would love to know so he could update his T2 bezel, so if anyone has a working t2 machine, take some video of when a terminator is wailing on you in the foreground so we can figure it out.  I've scoured the net looking for pics of the flash lamp assemblies, but I can't find them anywhere... they aren't even listed in the manual!!

Now I need to go back and fix revx and also Put better names in for opwolf/opthunder.

Assuming I can still remember how to make a diff file, I should be able to send all of this onto the mame devs by late tonight.   
Title: Re: LED control from Mame--in over my head again?
Post by: headkaze on March 23, 2010, 08:22:47 am
Looks like it's mainly bit shifting.. easier way to swap bits (0 <-> 1) is to NOT them (~) and your divides are really bit shifting right. This is clearer to a C coder..

Code: [Select]
if ((data & 0x800) != 0x800 && (data & 0x400) == 0x400)
{
output_set_value("Left_Flash_1", data & 0x1);
output_set_value("Left_Flash_2", (data & 0x2) >> 1);
output_set_value("Left_Flash_3", (data & 0x4) >> 2);
output_set_value("Left_Flash_4", (data & 0x8) >> 3);
output_set_value("Right_Flash_1", (data & 0x10) >> 4);
output_set_value("Right_Flash_2", (data & 0x20) >> 5);
output_set_value("Right_Flash_3", (data & 0x40) >> 6);
output_set_value("Right_Flash_4", (data & 0x80) >> 7);
}

if ((data & 0x800) == 0x800 && (data & 0x400) != 0x400)
{
output_set_value("Left_Gun_Recoil", data & 0x1);
output_set_value("Right_Gun_Recoil", (data & 0x2) >> 1);
output_set_value("Left_Gun_Red_Led", (data & 0x10) >> 4);
output_set_value("Left_Gun_Green_Led", (~data & 0x20) >> 5);
output_set_value("Right_Gun_Red_Led", (~data & 0x40) >> 6);
output_set_value("Right_Gun_Green_Led", (~data & 0x80) >> 7);
}
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 23, 2010, 08:52:21 am
Looks like it's mainly bit shifting.. easier way to swap bits (0 <-> 1) is to NOT them (~) and your divides are really bit shifting right. This is clearer to a C coder..

Code: [Select]
if ((data & 0x800) && (data & 0x400))
{
output_set_value("Left_Flash_1", data & 0x1);
output_set_value("Left_Flash_2", (data & 0x2) >> 1);
output_set_value("Left_Flash_3", (data & 0x4) >> 2);
output_set_value("Left_Flash_4", (data & 0x8) >> 3);
output_set_value("Right_Flash_1", (data & 0x10) >> 4);
output_set_value("Right_Flash_2", (data & 0x20) >> 5);
output_set_value("Right_Flash_3", (data & 0x40) >> 6);
output_set_value("Right_Flash_4", (data & 0x80) >> 7);
}

if ((data & 0x800) && (data & 0x400))
{
output_set_value("Left_Gun_Recoil", data & 0x1);
output_set_value("Right_Gun_Recoil", (data & 0x2) >> 1);
output_set_value("Left_Gun_Red_Led", (data & 0x10) >> 4);
output_set_value("Left_Gun_Green_Led", (~data & 0x20) >> 5);
output_set_value("Right_Gun_Red_Led", (~data & 0x40) >> 6);
output_set_value("Right_Gun_Green_Led", (~data & 0x80) >> 7);
}


Yeah, that looks a lot better I'll change it before I submit it. 

There was a reason I was doing it the other way though and for the life of me I still can't explain it.  Back when I first started, I had the bitshifting and had nixed the "==" stuff, which is redundant, and every now and again I got false mis-fires.  So I installed a bit of debugging code and bit 4 occasionally came up as some odd-ball value like 27.  I never could figure out why it was doing it so I assumed it must have been the syntax.  So I changed it to the style of syntax above and it went away.  Of course that was last week and it was 3am when I was coding it, so who knows what I was doing.   ;D

Just for the record though, the decimal numbers, as opposed to the hex was on purpose.  I HATE hex.  Nobody thinks in hex so why write in it? I've noticed mame uses hex almost exclusively for addresses and it drives me mad having to whip out a calculator to convert it into something I can understand.  But hey, that's just me.

Oh btw... afterburner uses a very similar flagging technique of strobing the data all through the same two bytes.  I might be able to use what i've learned on t2 to get the motors hooked up.  Of course, that's a BIG might. 
Title: Re: LED control from Mame--in over my head again?
Post by: headkaze on March 23, 2010, 09:03:57 am
It make sense to work in hex when doing bit manipulation. You probably still need to do the ((data & 0x800) == 0x800) etc. sorry my mistake. The reason is, it works if you are testing a single bit because (1 & 1) is true, (1 & 0) is false.. but if you are testing a bunch of bits which is what I think you're doing here you really need to test it back with the value. This is because even if one bit is true and two arn't it's still true, and I believe you're testing for a bunch of bits, not just one. So yeah my bad, just add back

Code: [Select]
if ((data & 0x800) != 0x800 && (data & 0x400) == 0x400)
..

if ((data & 0x800) == 0x800 && (data & 0x400) != 0x400)
..
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 24, 2010, 03:50:06 am
Ok, still not ready for submission (need to put .137 on and make a diff file), but I've cleaned up all the extra code I've added.  I've also commented as much as possible explaining my thought process inside the drivers so if I have something a little off, someone more familiar with the drivers can come along and clean it up.

Concerning output names:

For the midway games, I simply used the name the output was in the debug menu.  It makes "official" midway gun output name "Gun_Recoil" (With a left/right/player prefix added) This tells you immediately what I output for and, imho should become the standard for all gun games with a solenoid-based recoil. 

For the taito gun games, which use a motor-driven pistion, I came up with the name "Recoil_Piston" (with a player prefix added).  This makes the most sense to me personally.  While the newer gun games have a solenoid and it's quickly turned on and off to simulate gunfire, the older ones used a piston on a motor and the motor is simply left on while the gun is supposed to be firing.  Because of this you get a totally different kind of output data and thus a different name has to be used.  I'm trying to apply the same kind of logic we used back in the day when we helped to clean up the input system. 

The one thing that I did that might seem a little goofy is for operation wolf, a one player game I used the name "Player1_Recoil_Piston"  I did it because opwolf 2 (operation thunderbolt) is essentially the exact same game with the exact same gun, only two player.  So is it crazy to do it that way?

I really enjoyed the snipe hunt that was getting t2 working, so I'm thinking of taking time off from my other projects to try and hook up the rest of the gun games in mame.  There aren't that many anyway, so why not give it a shot?
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 24, 2010, 04:55:59 am
I am on a roll tonight!  got zombie Raid's outputs working!

in src\drivers\seta.c  in the function "static WRITE16_HANDLER( zombraid_gun_w )"  after the line:

"default:"

and the following code:
----------------------------------------------------------------------------------
output_set_value("Player1_Gun_Recoil", (data & 0x10)>>4 );
output_set_value("Player2_Gun_Recoil", (data & 0x8)>>3 );
----------------------------------------------------------------------------------


I was simply going down the list of gun games in mame and after I determined that the i/o system in alien 3 is "f'n nuts" I went on to this one.  Embarrassingly easy to figure out, so I don't have a clue why it wasn't at least commented on in the driver.
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 24, 2010, 08:10:40 pm
Ok, I've submitted a diff to mamedev based on the .137 source!

In case anyone wanted to get a head start, or by some stroke of bad luck the submissions wouldn't be accepted, I included the diff file below.  You can use it to patch your build just like any "u" diff file. 

In case this thread was too hard to follow:

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.
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 25, 2010, 02:38:07 am
You are awesome.   :notworthy:

Man this is killing me.  I really want to stay up late testing this but I keep getting in late when I mess with arcade stuff at night.  Looks like I'll have to learn how to use a diff file this weekend.  I need to pad the kicker anyway before any more testing.

Alien3 would be another cool one though... :)
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 25, 2010, 07:31:17 am
Assuming you have your compile environment setup, diff files are easy.

http://mamedev.org/updates.html (http://mamedev.org/updates.html)


Don't get your hopes up on Alien 3.  I looked at it and immediately the "nothankyou.gif" popped up in my head.  Believe it or not the problem with that driver is it's too clean.  In all the other drivers I've looked at the outputs were pretty straight forward because the i/o for each individual game was handled seperately.  The sega 32 driver is so perfect that every single game has the same functions, no deviations.  That means even if I were to find the outputs, hooking them up would create several "ghost" outputs in the other games in the driver.  The proper thing to do, of course would be to make a new function for alien3, but that's a lot of actual coding work, and as hk has pointed out, straight C is not my strongest programming language.
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 25, 2010, 02:37:11 pm
This brings up something I've been wondering.  Is it possible to have MH consider a specific button press as an output?  This would be a useful way for users to add a sort of output on their own.  So for games that never had a recoil, you could add an event that happens when "fire" is pressed.  This could be an led, solenoid or whatever.
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 25, 2010, 03:52:20 pm
I've thought about it before.  I'm not sure if it'd be the best idea to put it into mamehooker itself.  Because some games send data so quickly, I've made a note to make sure that, at idle at least, mh is doing as little as possible.  This ensures that mh is always ready, at least, when data comes in. 

Direct-X controllers, at least, are easy enough to add.  Generally speaking you can setup a passive polling system that send "fire events" whenever data changes. 

Keyboards, however, require active polling.  It doesn't take THAT much time to do it, but it is some. 

It isn't difficult, I already do it for the keyboard led function, but I only poll the current keyboard state when I'm about to toggle the leds (to make sure they aren't already on). 

It would require a significant amount of code to make it nice and neat like the outputs are though.  I'd have to make a whole new section in the ini files and somehow kludge it into the current output state function so that key pressing would behave as an output. 


But I'm rambling.....

My point is, I'm looking into it, but don't expect it anytime soon.  It'd take a solid week of coding for me to come up with a system that I like.
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 25, 2010, 04:32:45 pm
Bah!  137u1 came out this morning!  I sure picked the right time to submit that stuff!  I'll wait another u release, but I may have to re-submit it. :badmood:
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 26, 2010, 02:16:32 am
Quote
Direct-X controllers, at least, are easy enough to add.  Generally speaking you can setup a passive polling system that send "fire events" whenever data changes. 

Does this mean that something already exists in MH to do this, or are you talking about adding code?  Aimtrak buttons can be made to register as joystick buttons....
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 26, 2010, 06:07:34 pm
Quote
Direct-X controllers, at least, are easy enough to add.  Generally speaking you can setup a passive polling system that send "fire events" whenever data changes. 

Does this mean that something already exists in MH to do this, or are you talking about adding code?  Aimtrak buttons can be made to register as joystick buttons....

No, I would have to edit the code. 
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 27, 2010, 08:06:03 pm
Good news for you.  I vaguely remembered doing something similar in the past, so I looked at my old projects.  I had to do exactly the same thing for my zinc config utility.  So I just copy/pasted the code.  Mame hooker can now detect keyboard keys.  Not in the crazy raw mode like mame supports, but for most it should be enough.

I only added it because it seemed like it could be useful though.  No offense but I'm not doing all this to cater to you 1up.   ;)
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on March 27, 2010, 08:26:09 pm
Yeah, I know.  I just got really lucky that a bunch of the stuff I've been wishing for is also stuff you've had an interest in.  Doesn't mean I can't enjoy it though.  :D
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on March 27, 2010, 08:44:50 pm
Agreed....

I used the speak command to make the computer speak to me when I pressed a key (for fullscreen testing).  You haven't lived until you've played digdug with microsoft anna constantly yelling "Control On.....  Control Off"   :afro:
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on April 03, 2010, 10:18:07 am
I woke up WAAAAAY too early this morning and I was bored go I looked at the outputs on the segay board games (rail chase, gloc, strike fighter and power drift) to see how hard it would be to hook up the outputs for these ride-on games.  

My conclusion is very easy AND very difficult.

The first "problem" is that all the games use the same generic output function.  Since they all have VERY different hardware, this would have to be parted out for each individual game.  This isn't difficult per-say but it is a pain in the butt as the driver would have to be extensively re-written.

The second problem, and this is a legitimate one, are the safety switches.  Each motor/piston/whatever in a sega game has a safety switch that trips whenever the actuator goes beyond it's limits to prevent damage to the machine.  Mame has them all forced to "on."  This does two things.  Firstly, it makes the games fail their output tests in the debug menu, making it difficult for me to hook up the right data to the right outputs.  Secondly, depending upon the cabinet, it nullifies all output data, putting the data into an error state.  Now for some games the data is still sent, so we could just ignore the error data, but for games like rail chase and galaxy force, it turns off all piston outputs.  

Of course we could hook the safety switches up to regular inputs and that would allow the motors and pistons to work properly, but then the switches actually have to be hooked up to something or else your motors/pistons could burn out.  This means generic implementation of the outputs might be impossible... I honestly don't know though as I'm not a disney imagineer. ;)

The good news is the data doesn't seem to be too complex.  Powerdrift, in particular is suprisingly easy to figure out and I could probably hook it up right now.  It seems to ignore the errors as well.  Also the non "dangerous" ouputs are not only easy to hook up, but they don't error out, so like afterburner, these could be hooked up to proper lamps easily.  The gun soleniod in the rail chase guns is included in this. :)  

Even the more complex ones have logic to them that make them easy to follow.  Basically you have a byte or so of data, not unlike terminator 2.  (Minus all the annoying strobing) Inside the btye you have 7 or 8 bits reserved for telling the power level of the motor and the rest are for direction/position.  

So the bottom line is, it would be a lot of work, but I could definately hook up most of the outputs for the sega games given enough time and maybe some help.  

I think I would be willing to spend most of my free time on this assuming I could get together a small team of volunteers to help me with the programming and we could gather another small team of hardware-minded individuals that would look into practical applications of the data (in other words, motion sim rigs like you see for racing games.)

Speaking of which, maybe I should start a new thread for this?

Maybe we need a new forum or maybe a new site just for developments on mame outputs and output-related hardware?
Title: Re: LED control from Mame--in over my head again?
Post by: headkaze on April 03, 2010, 04:20:03 pm
Speaking of using MS Speech in a cab, check out this video using my LED Plugin for GameEx ;)

The Ultimate Holiday Gift (http://www.youtube.com/watch?v=DeJfLzxl_jI#)

I'm happy to help out where I can Howard, although quite busy these days. I can help clean up code and stuff. I've written a few HID drivers for Ultimarc products like the UltraStik, U-HID and PacDrive so I can help with things like that. It's unfortunate we don't have a hardware interface like the U-HID for sending data to hardware. What sort of hardware interface do you have in mind? I'm also wondering how many outputs could be supported in a single cab (besides LED's) or are you thinking about dedicated cabs?
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on April 04, 2010, 01:41:04 am
Nice!

Well I don't think the interface at the pc level (usb device) is all that important.  It's the interface between that and the actual hardware (relays, speed controllers, ect) that might need work. 

I was thinking both the dedicated cabinets AND more generic implementations.  None of the machines in the arcades use THAT many outputs, they all just use different kinds.  Generally it's a maximum of 4 motors/rams/whatever and perhaps a motor or pair of motors for the joystick/wheel itself.  Some of the atari games also use "butt thumpers" as outputs as well, but I think that might just be a manipulation of the sound data. 

Then there are lamps.... generally there are only one or two (start buttons) but afterburner and some of the racing games have up to 10.  Since they are digital it isn't out of the realm of possibility though.

For the "buy it and convert it" crowd... the solution is simple... buy a gloc 360 cabinet.  It has enough freedom of movement and rotational axis to simulate any other motion cab ever released as well as a force-feedback joystick.  Make a removable steering wheel panel and you are good to go. 
The trick would be making sure that we can fully support it's hardware.


For the diy crow there are sites out there with various hardware, but I no nothing about them nor how well their stuff works.

This site comes to mind:

http://buggies.builtforfun.co.uk/Sim/ (http://buggies.builtforfun.co.uk/Sim/)


The i/o board they have is actually extremely similar to what they used in games like afterburner.  I didn't mention it in my post above but each motor generally has a pot to go with it... that's how they could use regular dc motors and still know the motor's position.  Generally speaking they are already hooked up in mame though, so it shouldn't be an issue. 

Sega games have an added complexity though.  Generally the motor's have an 8 level power setting so that quick jerky and slow lumbering movements can be simulated.  I dunno how to do with with high voltage/amperage other than perhaps a speed controller?

I think the main thing would be putting it all-together.  At least one prototype rig would need to be built and then when people wanted to build a racing mame cab or a flight-sim mame cab they would have a working example to go by similar to how luscid's plans are used (or over-used) for stand up cabs today.



As for the mame end of things... it isn't difficult, it just takes time and you have to play around with the data.  After messing with those gun games I've found a pretty sure fire method for figuring out the outputs, you just need mamehooker running alongisde mame to help with the debugging. 

1.  Find all the write functions in the game, particularly those already labeled as output data and install an output that constantly send the ENTIRE data string.  Something like      output_set_value("Debug", data );

2.  Compile mame and run it in windowed mode with mamehooker running and mame hooker's debug window open.

3.  Fire up the game and go into the dip/debug menu.  You should get clean "all off" data inside them because the game isn't running.
     If all of your debug outputs are fluctuating, you have data strobing going on and it'll make things more difficult, but you can deal with that later.

3. Now if it exists, go into output/motor/driver menu and let the tests run.  You should see the data change on at least one of your debug outputs.
    If not then mame doesn't even have the memory addresses for the outputs mapped (I've found this to be rare) so you should try a new game.

4. Anyway, now that you know which debug outputs were effected you go to that function in mame and split out the single chunk of data into it's individual bits and give each one an output, just like I did in the revolution X examples.

5.  After that you just keep re-compiling, going into the debug menu and watching the data until you find the pattern and label up the individual outputs.

Some are infuriatingly hard, but many, particularly digit ouputs are real easy.  Zombie Raid took me maybe 15 minutes to figure out because all it did was send a 16 for p1's recoil solenoid and a 8 for p2's along with the rest of the gun data.  Most are like that, you'd be suprised..... There just isn't enough time in the world for me to go through every game with outputs in mame and try them all.  That's why I say we need a team of people.  They don't even have to be competant mame devs, just competant C programmers.  Hell I barely qualify myself. ;)
Title: Re: LED control from Mame--in over my head again?
Post by: headkaze on April 04, 2010, 02:24:45 am
Using DebugView (http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx) is another way to output debug data. You just call the Win32 API function OutputDebugString and it will display in the DebugView window.

Eg.

Code: [Select]
char buf[256];
sprintf(buf, "Data: 0x%08x\n", data);
OutputDebugString(buf);

I'm pretty sure there are standard MAME functions present to output to stdout too since it launches from a console window.

I see what you mean about going through each game would take a long time. So perhaps compile a version of Mame that outputs this data and then host it somewhere and ask people to help out.
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on April 04, 2010, 07:57:46 am
Well mame's debugger has been pretty useless to me, but that's just my experience.  It's problem is it outputs too much data.  It seems that in most drivers there are dozens of debug prints still left in the code.  To get any useful data you'd have to go in and remove them all only to put them back when you are done. 

I didn't realize you could get the debug string externally though. (never found the debug string to be useful personally, I just code with break points)

Personally I still think using mame hooker is the best method.  The main reason is that mamehooker shows you the states of the data in real time instead of constantly printing lines of text.  This makes mamehooker's data more readable in realtime, which is what you really need to correlate data with different outputs.  Also the fact that you can actually hook the data up to something is more useful than you could imagine.  I would have never figured out T2/REVX unless I hooked them up to my gamepad because the strobing speed is too fast to make logging useful (I got a 100 mb text file for 15 secs of gameplay) and also because the strobing is so fast I could never actually read the changes on the screen.... I could sure feel them though.

I don't think a custom build of mame would help.... if anything it would make the process slower.  Unless there's some automated way of adding the functions it would take forever to figure out where to put the debug calls.  And if there is an automated way of doing it you would still have to go in and add more outputs as you go to figure out the data... I've yet to see a game where a full byte of data is used to control an output.


Anyway, I'm out for the day. 

Happy easter everyone!




Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on April 04, 2010, 07:07:08 pm
Dang, I badly want to play with all the gun stuff, but I've been stuck working weekends.  With that and taxes coming up, there might be a new version of Mame with all your changes by the time I get back to this.  Which wouldn't be a bad thing, it's just the waiting that sucks!  :badmood:
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on April 08, 2010, 12:40:28 pm
Just a quick update.  u2 is out and it looks like they've accepted my changes.  This means I don't have to worry about them disapproving of my (ahem) less than standard placement of some of the functions, so I feel confident about working on more games!  I'll download the u2 source and go ahead and work on getting the rest of the guns hooked up.  Then I'll go on to the dreaded sega games. 
Title: Re: LED control from Mame--in over my head again?
Post by: 1UP on May 12, 2010, 09:57:22 pm
Just a thought...it would be awesome to have support for the Parallax usb servo controllers.  I believe they're based on BASIC stamp.  I've used these in my Halloween projects as seen HERE (http://www.youtube.com/watch?v=jGKpl6v_UEs#).  Imagine animated characters or objects around the room responding to outputs from the game!  Sort of like a home version of Chuck-E-Cheese.

Oh yeah, I forgot to mention, this might also be a workable output board for games such as Afterburner or other motion cockpit games.
Title: Re: LED control from Mame--in over my head again?
Post by: Howard_Casto on May 13, 2010, 08:31:55 pm
It's probably already supported.  I added generic HID support to mamehooker a few versions ago, one would just have to get the spec sheets for the device and write appropriate scripts. 
Title: Re: LED control from Mame--in over my head again?
Post by: alinke on January 20, 2024, 01:50:17 am
Wow! Fantastic work here. I'm the creator of Pixelcade active marquees http://pixelcade.org and am thinking to add some in game events to Pixelcade marquees. I read through the various threads on mame outputs and sorry if I missed it, but is there a list of mame outputs by game with a description of the output and when it fires. Like for example in ChaseHQ, lamp0 and lamp1 when the siren triggers. In my case, I use LEDBlinky and then would create some configs and associated artwork in LEDBlinky for mame outputs that would be interesting for Pixelcade Marquees, thanks!