LED control from Mame--in over my head again?

[1UP]

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

[smalltownguy]

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?

[Howard_Casto]

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. 

[Howard_Casto]

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

[1UP]

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

[Howard_Casto]

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. 

[1UP]

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

[Howard_Casto]

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.

[1UP]

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.

[1UP]

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

BTW, the parent folder looks like a treasure trove of arcade manuals:  http://arcarc.xmission.com/PDF_Arcade_Manuals_and_Schematics/

[Howard_Casto]

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. 

[Howard_Casto]

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?

[1UP]

Hmm...I've only ever had the T2 guns, which were solenoid based.  Don't know about the Taito ones.

[Howard_Casto]

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. 

[1UP]

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!

[Howard_Casto]

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")

[Howard_Casto]

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. 

[Howard_Casto]

You owe me 1up... I'm thinking a pony because it looks like I'm gonna be able to figure this out.   

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. 

[1UP]

   Watching with bated breath...

[Howard_Casto]

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.

[1UP]

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.

[Howard_Casto]

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. 

[1UP]

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.

[Howard_Casto]

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.

[1UP]

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.

[1UP]

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.

[Howard_Casto]

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. 

[1UP]

Tell me about it.  I end up spending about an hour too long at work every night when I'm making "progress".

[1UP]

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

[Howard_Casto]

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.

[Howard_Casto]

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. 

[1UP]

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.

[smalltownguy]

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.

[1UP]

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.

[Howard_Casto]

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. 

[1UP]

Thanks Howard, I was wondering how to do this.  I should be able to have a good setup to test this weekend.

[1UP]

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?

[Howard_Casto]

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.

[Howard_Casto]

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. 

[Howard_Casto]

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.