Main Restorations Software Audio/Jukebox/MP3 Everything Else Buy/Sell/Trade
Project Announcements Monitor/Video GroovyMAME Merit/JVL Touchscreen Meet Up Retail Vendors
Driving & Racing Woodworking Software Support Forums Consoles Project Arcade Reviews
Automated Projects Artwork Frontend Support Forums Pinball Forum Discussion Old Boards
Raspberry Pi & Dev Board controls.dat Linux Miscellaneous Arcade Wiki Discussion Old Archives
Lightguns Arcade1Up --- Bug Reports --- Site News

Unread posts | New Replies | Recent posts | Rules | Chatroom | Wiki | File Repository | RSS | Submit news

  

Author Topic: LED control from Mame--in over my head again?  (Read 15370 times)

0 Members and 1 Guest are viewing this topic.

1UP

  • Token Junkie
  • Trade Count: (+4)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2081
  • Last login:November 11, 2014, 01:37:18 am
  • Yes, that is a joystick in my pocket.
    • 1UPArcade
Re: LED control from Mame--in over my head again?
« Reply #80 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
« Last Edit: March 21, 2010, 06:50:03 pm by 1UP »

Free resource for building your own rotating control panels!

My other job...


1UP

  • Token Junkie
  • Trade Count: (+4)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2081
  • Last login:November 11, 2014, 01:37:18 am
  • Yes, that is a joystick in my pocket.
    • 1UPArcade
Re: LED control from Mame--in over my head again?
« Reply #81 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

Free resource for building your own rotating control panels!

My other job...


Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19073
  • Last login:Today at 05:07:49 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: LED control from Mame--in over my head again?
« Reply #82 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%


Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19073
  • Last login:Today at 05:07:49 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: LED control from Mame--in over my head again?
« Reply #83 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.

1UP

  • Token Junkie
  • Trade Count: (+4)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2081
  • Last login:November 11, 2014, 01:37:18 am
  • Yes, that is a joystick in my pocket.
    • 1UPArcade
Re: LED control from Mame--in over my head again?
« Reply #84 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.
« Last Edit: March 22, 2010, 02:56:34 am by 1UP »

Free resource for building your own rotating control panels!

My other job...


Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19073
  • Last login:Today at 05:07:49 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: LED control from Mame--in over my head again?
« Reply #85 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.

1UP

  • Token Junkie
  • Trade Count: (+4)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2081
  • Last login:November 11, 2014, 01:37:18 am
  • Yes, that is a joystick in my pocket.
    • 1UPArcade
Re: LED control from Mame--in over my head again?
« Reply #86 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

Free resource for building your own rotating control panels!

My other job...


Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19073
  • Last login:Today at 05:07:49 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: LED control from Mame--in over my head again?
« Reply #87 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. 

1UP

  • Token Junkie
  • Trade Count: (+4)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2081
  • Last login:November 11, 2014, 01:37:18 am
  • Yes, that is a joystick in my pocket.
    • 1UPArcade
Re: LED control from Mame--in over my head again?
« Reply #88 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...

Free resource for building your own rotating control panels!

My other job...


Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19073
  • Last login:Today at 05:07:49 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: LED control from Mame--in over my head again?
« Reply #89 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.

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19073
  • Last login:Today at 05:07:49 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: LED control from Mame--in over my head again?
« Reply #90 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.   

headkaze

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2943
  • Last login:April 13, 2021, 12:42:41 pm
  • 0x2b|~0x2b?
Re: LED control from Mame--in over my head again?
« Reply #91 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);
}
« Last Edit: March 23, 2010, 09:06:01 am by headkaze »

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19073
  • Last login:Today at 05:07:49 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: LED control from Mame--in over my head again?
« Reply #92 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. 

headkaze

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2943
  • Last login:April 13, 2021, 12:42:41 pm
  • 0x2b|~0x2b?
Re: LED control from Mame--in over my head again?
« Reply #93 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)
..
« Last Edit: March 23, 2010, 09:06:31 am by headkaze »

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19073
  • Last login:Today at 05:07:49 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: LED control from Mame--in over my head again?
« Reply #94 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?

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19073
  • Last login:Today at 05:07:49 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: LED control from Mame--in over my head again?
« Reply #95 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.

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19073
  • Last login:Today at 05:07:49 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: LED control from Mame--in over my head again?
« Reply #96 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.

1UP

  • Token Junkie
  • Trade Count: (+4)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2081
  • Last login:November 11, 2014, 01:37:18 am
  • Yes, that is a joystick in my pocket.
    • 1UPArcade
Re: LED control from Mame--in over my head again?
« Reply #97 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... :)

Free resource for building your own rotating control panels!

My other job...


Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19073
  • Last login:Today at 05:07:49 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: LED control from Mame--in over my head again?
« Reply #98 on: March 25, 2010, 07:31:17 am »
Assuming you have your compile environment setup, diff files are easy.

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.

1UP

  • Token Junkie
  • Trade Count: (+4)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2081
  • Last login:November 11, 2014, 01:37:18 am
  • Yes, that is a joystick in my pocket.
    • 1UPArcade
Re: LED control from Mame--in over my head again?
« Reply #99 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.

Free resource for building your own rotating control panels!

My other job...


Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19073
  • Last login:Today at 05:07:49 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: LED control from Mame--in over my head again?
« Reply #100 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.

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19073
  • Last login:Today at 05:07:49 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: LED control from Mame--in over my head again?
« Reply #101 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:

1UP

  • Token Junkie
  • Trade Count: (+4)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2081
  • Last login:November 11, 2014, 01:37:18 am
  • Yes, that is a joystick in my pocket.
    • 1UPArcade
Re: LED control from Mame--in over my head again?
« Reply #102 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....

Free resource for building your own rotating control panels!

My other job...


Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19073
  • Last login:Today at 05:07:49 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: LED control from Mame--in over my head again?
« Reply #103 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. 

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19073
  • Last login:Today at 05:07:49 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: LED control from Mame--in over my head again?
« Reply #104 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.   ;)

1UP

  • Token Junkie
  • Trade Count: (+4)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2081
  • Last login:November 11, 2014, 01:37:18 am
  • Yes, that is a joystick in my pocket.
    • 1UPArcade
Re: LED control from Mame--in over my head again?
« Reply #105 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

Free resource for building your own rotating control panels!

My other job...


Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19073
  • Last login:Today at 05:07:49 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: LED control from Mame--in over my head again?
« Reply #106 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:

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19073
  • Last login:Today at 05:07:49 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: LED control from Mame--in over my head again?
« Reply #107 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?
« Last Edit: April 03, 2010, 10:20:58 am by Howard_Casto »

headkaze

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2943
  • Last login:April 13, 2021, 12:42:41 pm
  • 0x2b|~0x2b?
Re: LED control from Mame--in over my head again?
« Reply #108 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 ;)



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?

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19073
  • Last login:Today at 05:07:49 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: LED control from Mame--in over my head again?
« Reply #109 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/


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. ;)

headkaze

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2943
  • Last login:April 13, 2021, 12:42:41 pm
  • 0x2b|~0x2b?
Re: LED control from Mame--in over my head again?
« Reply #110 on: April 04, 2010, 02:24:45 am »
Using DebugView 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.

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19073
  • Last login:Today at 05:07:49 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: LED control from Mame--in over my head again?
« Reply #111 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!





1UP

  • Token Junkie
  • Trade Count: (+4)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2081
  • Last login:November 11, 2014, 01:37:18 am
  • Yes, that is a joystick in my pocket.
    • 1UPArcade
Re: LED control from Mame--in over my head again?
« Reply #112 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:

Free resource for building your own rotating control panels!

My other job...


Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19073
  • Last login:Today at 05:07:49 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: LED control from Mame--in over my head again?
« Reply #113 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. 

1UP

  • Token Junkie
  • Trade Count: (+4)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2081
  • Last login:November 11, 2014, 01:37:18 am
  • Yes, that is a joystick in my pocket.
    • 1UPArcade
Re: LED control from Mame--in over my head again?
« Reply #114 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 .  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.
« Last Edit: May 12, 2010, 10:17:11 pm by 1UP »

Free resource for building your own rotating control panels!

My other job...


Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19073
  • Last login:Today at 05:07:49 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: LED control from Mame--in over my head again?
« Reply #115 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.