Buddabing's LED controller

[posicat]

See, and here I thought I was the only one who felt that many LED's in a home-brew project was justified.

My computer case has 7 vents on the front, that I want to wire up for individual RGB control.
http://www.cattech.org/posicat/computer/purr/

Perhaps I could wire up my car.  The dashboard could dim and brighten, and change colors.
http://www/~posicat/car_computer/

Anyways, I thought I'd share two of my projects.

[richms]

Perhaps I could wire up my car.  The dashboard could dim and brighten, and change colors.
http://www/~posicat/car_computer/

That one doesnt work

[posicat]

Ah, that's the name I use internaly on my network.  Sorry, I work phone support, and we've been extremely busy, my brain is fried.  Here it is...

http://pawz.cattech.org/~posicat/car_computer/

[quarterback]

Ah, that's the name I use internaly on my network.

[Tiger-Heli]

Ah, that's the name I use internaly on my network.  Sorry, I work phone support, and we've been extremely busy, my brain is fried.  Here it is...

http://pawz.cattech.org/~posicat/car_computer/

Still no workie

Works here - just text and a couple pics, though, no cool led dash lights 

[quarterback]

Ah, that's the name I use internaly on my network.

[richms]

Works here - just text and a couple pics, though, no cool led dash lights 

Connection refused from here.

[posicat]

Big storm came though, and power was out long enough to kill all of my UPS's.  Should work now.

The LED's arn't in the dash currently, just an idea what I could do with this controller.

[Buddabing]

Hello,

I have not been idle. While the prototype PCBs are being produced, I've been working on two applications, an animation compiler and an animation simulator. The simulator is a cross between my CPMaker and MAME Movie Maker. You'll be able to see your animations before you actually get your buttons lit.

[scooter]

Video doesn't work for me.

[Santoro]

yep, unknown codec.  What format is it?

[Buddabing]

yep, unknown codec.

[posicat]

Now you're going to make me want to build a MAME box as well, and I already have too many projects to work on as it is.

That looks like it's going to be awesome, I can't wait!

[KevSteele]

Loved the LED's around the joysticks!

I've actually wondered if there wasn't a way to get some LED's into the base of a joystick and then use a frosted "dust disc" instead of the regular black. Could be cool...and it could be a royal pain to get working.

Anyway, I'm eagerly looking forward to tearing my CP apart and replacing all of the buttons, wiring in a new board and LEDs, and changing my software setup. (File this under "things you'll only hear said on the BYOAC forums  )

Kevin

[CJK]

yep, unknown codec.

[Buddabing]

yep, unknown codec.

[CJK]

Right, thanks!

-- Chris

[Gamecab]

Hello,

I have not been idle. While the prototype PCBs are being produced, I've been working on two applications, an animation compiler and an animation simulator. The simulator is a cross between my CPMaker and MAME Movie Maker. You'll be able to see your animations before you actually get your buttons lit.

Yup.... I'm just waiting for the boards as well...  Its like watching paint dry.  Although I'm pretty sure they should arrive this coming week, then the fun will really begin.

[Franco]

Whoop, whoop!

Sooo can't wait for the boards. Im gonna have to sell a kidney but it will be worth it! 

Damn, cant watch the vid at work, ill have to wait until I get home.

[SirPoonga]

Also, gl.tter, you should brush up on the threads on Johnny 5 and CPmaker, which use this file to display what buttons on a CP are used by a game.

I think the light engine would have to use a similar approach to do what Popcorrin (and I) would like.

Here's the approach I've taken:

MAME sends which controls (MAME input codes) are enabled by a particular game to the light driver.  The driver can then choose to light up all the controls used by game.

For this to work, the driver has to supply some mechanism to map lights to controls (usually a text file).  So for example, you edit the file and say 'light 1' is under hardware button X (ie. MAME input code XXX).  That information is then enough to light up the controls used in a game.

That's the basic mapping support I would expect most light drivers to implement.  However, drivers could go much further, and for example could let you associate 3 light outputs with an RGB LED.  They could then allow you to set colours in various ways, either using a global scheme, or even schemes for each game.

So I think the best places to set colours is in the driver control->light configuration file.

BTW, I'm working on a driver that does all this and much more.

Which is the worst way it can be done, hence why controls.dat exists.  You load dotron and it will "light" your tball.  You load some games it will light 4 buttons instead of 3 like it is suppose to.  Driver developers took some shortcuts and made some hacks that get represented when you ask mame for control info.

So, the more ideal solution is to have a FE, when a game is highlighted or selected, read controls.dat and send LSE the right signals.  Of if the game isn't in controls.dat then grab info form mame since something is usually better than nothing for this.

But the basic idea oyu are trying to get across is still the same

[JoyMonkey]

I'm not sure if anyone's aware of it, but I've been playing around with AdvMame lately and realized that there's a lot of information in it's event.dat that might be useful to help create the light.dat files for each game.
AdvMame's event.dat contains memory addresses for attract-modes and credits for quite a few games and Bugfinder (it's author) is in the process of updating it right now.

[gl.tter]

Which is the worst way it can be done

Why?

hence why controls.dat exists.

[Chris]

It also doesn't make sense to add the light layout to controls.dat, because different light drivers will offer different lighting related options that can't all be accomodated in a generic layout format.

The only thing I thought should have been in controls.dat was the original colors of the buttons, so someone using three LEDs could use the lighting board with clear buttons to reproduce the original button colors.  Thus, when a NeoGeo game says to press the red button for a particular action, or when NBA Maximum Hangtime says that the Turbo button is white, you can actually use the correct colored button on the panel.

--Chris

[SirPoonga]

Which is the worst way it can be done

Why?

See the rest of what i wrote, that's why

hence why controls.dat exists.  You load dotron and it will "light" your tball.  You load some games it will light 4 buttons instead of 3 like it is suppose to.  Driver developers took some shortcuts and made some hacks that get represented when you ask mame for control info.

Right, I noticed this in I,Robot (two buttons light but only one is used).  Why exactly does this happen in MAME?  If it's just a matter of fixing a game's drivers, that's the way to go IMO.

Various reason.  In case of dotron the trackball is an up/down spinner hack.  In case of game where mame says 4 buttons but it used 2 is because the driver dev used a generic macro to map the buttons for all games in the driver.  There are various other reasons.

I had a quick look at controls.dat recently, and as far as I can see, it tells you exactly what controls a game originally used, but it doesn't tell you how a particular user's control panel layout actually works or what hardware inputs he decides to map to a particular game's ports.

right, because controls.dat doesn;t need to store that info, it's all readily available.   Hence you need something like the Johhny 5 viewer which combines controls.dat and your ctrlr files to accuratly display the labels and control per your configuration

For example, what if you have two track balls (for argument's sake)?  Which one is mapped determines which one should light up.  Or what if you've mapped a trackball to a lightgun game?  You want the trackball to light up, not the gun.  Then there's the hairy issue of people sharing encoder inputs between sticks/buttons etc.

Again, need something like Johhny5, then you'd have your ctrlr file mapped correctly for that game, it get's presented correctly for that game.

With respect to lights, what if you have an RGB light under a track, or several lights you want to animate in some way?  What if you have lights all around it that show the direction of travel? 

Controls.dat doesn't provide any of this info.  It also doesn't make sense to add the light layout to controls.dat, because different light drivers will offer different lighting related options that can't all be accomodated in a generic layout format.

why would animated lights be part of controls.dat?

You are right, it doesn't make sense to put it in controls.dat, hence why I wrote my ideal solution...

So, the more ideal solution is to have a FE, when a game is highlighted or selected, read controls.dat and send LSE the right signals.  Of if the game isn't in controls.dat then grab info form mame since something is usually better than nothing for this.

I support dynamic control lighting in the LSE - controls can light up when you press/activate them for example, and I'm trying to provide signals for each player's controls to light up when they're up.  This has to happen from inside MAME, and I have to work off the game's input data somehow.

Why does it have to happen in mame?  why can't it happen in an FE that supports controls.dat (and compares controls.dat with one's ctrlr files to get the correct key mappings).  Or if the supprt was in the Johhny5 viewer (and use an FE like Mamewah that cna use the viewer).

[gl.tter]

The only thing I thought should have been in controls.dat was the original colors of the buttons, so someone using three LEDs could use the lighting board with clear buttons to reproduce the original button colors.

[SirPoonga]

It also doesn't make sense to add the light layout to controls.dat, because different light drivers will offer different lighting related options that can't all be accomodated in a generic layout format.

The only thing I thought should have been in controls.dat was the original colors of the buttons, so someone using three LEDs could use the lighting board with clear buttons to reproduce the original button colors.  Thus, when a NeoGeo game says to press the red button for a particular action, or when NBA Maximum Hangtime says that the Turbo button is white, you can actually use the correct colored button on the panel.

--Chris

Budda brought this up.  I don't think it is a good idea for controls.dat.  A very small percentage of the games had specific colors.  The majority of the games in mame are kits or conversions.  It would be a good idea as a  side project.  It will also be hard to verify if the colors for a particular game are correct.  You can't tell from a pic because it might be a conversion or buttons might have been swapped.

[gl.tter]

Various reason.

[SirPoonga]

Various reason.  In case of dotron the trackball is an up/down spinner hack.  In case of game where mame says 4 buttons but it used 2 is because the driver dev used a generic macro to map the buttons for all games in the driver.  There are various other reasons.

I'll have to check out dotron, but again, even if MAME thinks it's a track, I send signals about whatever hardware you've mapped to it, so the correct hardware lights.  ie. I send hardware codes, not input ports.

But dial AND joy8way are defined IN mame which is the controls you use and map.  So with what you are saying it would light a trackball that it should be unless the person plans on using the track ball as the up/down spinner hack.  I don't use a trackball for dotron, but it is still defined since it is a hack.  It would still get lighted up then?  you have to remember hacks are hacks, not the normal way it should work.

Also, what if a person has both a spinner and a 360 steering wheel.  Will both light up for all dial games?

right, because controls.dat doesn;t need to store that info, it's all readily available.   Hence you need something like the Johhny 5 viewer which combines controls.dat and your ctrlr files to accuratly display the labels and control per your configuration

Not familiar with it, link?

http://fe.donkeyfly.com/forum/index.php?topic=119.new#new

why would animated lights be part of controls.dat?

The point was that you have to associate lights with mapped hardware inputs - what the original controllers were doesn't really matter (except for eliminating false buttons) AFAIKS.

Why does it have to happen in mame?  why can't it happen in an FE that supports controls.dat (and compares controls.dat with one's ctrlr files to get the correct key mappings).  Or if the supprt was in the Johhny5 viewer (and use an FE like Mamewah that cna use the viewer).

Because the lighting changes interactively as the game is running, so I have to scan activated input codes and send signals on-the-fly.

Only for the lights that get turned on and off within the game.  But to light what controls the game uses you don't need to do that.
The event signals should still be in mame, however as a user I would trust controls.dat first, but if the game isn't in controls somehow use what mame says instead.  But mame is highly inaccurate.

[SirPoonga]

it's been awhile since I used buddamame, did he put support for controls.dat in there or just support to show a viewer and the viewer displays the info?

If he has support for controls.dat directly in mame then that would be the best version of mame to use for lighting what controls a games uses.  He'd have to generate whatever signals LSE needs based on controls.dat when the game gets loaded.

[SirPoonga]

The point was that you have to associate lights with mapped hardware inputs - what the original controllers were doesn't really matter (except for eliminating false buttons) AFAIKS.

I forgot, that's what the FEDEv package is for.
http://fe.donkeyfly.com/controls/controls_dat.php
combine the  two files in there to get the mame constants the control uses.  This is how Johhny5 works with ctrlr files.  Before the xml ctrlr files Johhny5 would look up the control info in controls.dat.  Then use those table to look up the mame constants.  Then goto the appropiate ctrlr file and see how you have those controls mapped.  Then display the correctly labelled controls.

[gl.tter]

But dial AND joy8way are defined IN mame which is the controls you use and map.

I think you've misunderstood me.

[SirPoonga]

For example, let's say the 1st P1 button on your control panel gets spit out by your encoder as key 'A'.  At the light driver end, a user then associates a light under this button with 'A'.  Whenever I see that 'A' is pressed (wherever it comes from), I signal it.  I don't care what game input it's actually mapped to with this scheme.

I understand now, so you are just watching what gets pressed and sending a certain signal to light a certain LED.  Would it be better as a service running in the background, that way it works for any software?  not put it in mame but have a service that is always running, always monitoring keypresses and other inputs?

To use the trackball analogy, if you map a trackball to a dial, I send that the trackball is enabled, not the dial.

Now tha tI know what you are doing this doesn't make a diffeerence.  But to enlighten you dotron has BOTH tball and dial setup.  you don;t map tball to dial.  It's a hack.

Of course when it comes to signalling which controls are in use, I get false positives as discussed.  I could scan controls.dat and eliminate those game inputs which are bogus, and (working backwards) the lights that shouldn't light.

I have to read about false positives you talked about.  Depending on how it is done it might not be as big of a problem as one might think....  TBC...

[SirPoonga]

Now let's say one doesn't want a button to light up when pressed, but wants to use this LED board to light up the controls a games uses.  Then LSE could be incorporated into the FE or Viewer as I mentioned to correctly light up the contorls used.  right?

[gl.tter]

I understand now, so you are just watching what gets pressed and sending a certain signal to light a certain LED.

Essentially yes - except I send that the input was pressed - the light driver figures out how to represent this in lighting.  The LSE signals are deliberately designed to be descriptive of an event, not specificially about lighting.  This allows light drivers to do whatever they want - want to 'brighten' a button as it is pressed?  Sure.  Or not.  Or maybe change the RGB colour from green (button enabled) to white (button pressed)?  All up to the drivers.

Would it be better as a service running in the background, that way it works for any software?

[SirPoonga]

I have to read about false positives you talked about.  Depending on how it is done it might not be as big of a problem as one might think....  TBC...

I meant the phantom buttons that aren't used for anything (and anything else like that I don't know about yet).

Ahh yes.  The only problem for your end with phantom buttons is if mame says 4, game actually uses 3, you then need to filter that out using controls.dat.

BTW, read above, you might have missed one of my posts because you were typing at the same time.  the FEDEV pzip file I provide has some of the information you thought was missing form controls.dat.  And it has the algorithm suggestion when using controls.dat.  Which is basically check if game is in controls.dat, if not check the game's cloneof, if not check the games romof, if not there is no game entered related to that game, deal with as you wish.

[gl.tter]

Now let's say one doesn't want a button to light up when pressed, but wants to use this LED board to light up the controls a games uses.

[gl.tter]

Ahh yes.

[Buddabing]

it's been awhile since I used buddamame, did he put support for controls.dat in there or just support to show a viewer and the viewer displays the info?

Controls.dat is directly supported.

If he has support for controls.dat directly in mame then that would be the best version of mame to use for lighting what controls a games uses.

[SirPoonga]

it's been awhile since I used buddamame, did he put support for controls.dat in there or just support to show a viewer and the viewer displays the info?

Controls.dat is directly supported.

If he has support for controls.dat directly in mame then that would be the best version of mame to use for lighting what controls a games uses.  He'd have to generate whatever signals LSE needs based on controls.dat when the game gets loaded.

That's the plan.

super sweet

hmm, I might wait for all this to play out befor eI go on with my qbert knocker.  Though doing hte serial route I plan will be simple and cheap, will do it just for the sake of doing it

[SirPoonga]

Thanks, I'll check it out.  I PM you if I need more help on this (it sure is complex ).

That or post a message on the controls.dat forum.