The NEW Build Your Own Arcade Controls
Main => Main Forum => Topic started by: Buddabing on April 10, 2005, 01:54:38 pm
-
Hello,
The first phase of implementing my LED controller is complete. I took a couple of pictures......
-
I wrote some software to reproduce some of the bling bling effects of the Arcalux (http://web2.airmail.net/%7Ewestal/photos/arcalux_ad.htm)
control panel. Unfortunately, I've lost the charger for my son's camcorder, so actual video of this controller will have to wait for a few days while I acquire a new one.
I'm planning on putting in support for this controller in my MAME build. I envision two uses at first: one, to light individual buttons on a control panel according to what controls are active at the time, and two, to light up LEDs around each of the eight cardinal directions around a joystick, depending on which directions are active on the joystick.
So far my demo application only runs on Windows 98 or DOS because of the problems that NT based Windows has with directly controlling parallel ports. I'm sure a Linux hacker could get it to work easily with the parport libraries. I do plan to incorporate support for NT windows, however.
-
Cool. So whats your long term plans? Considering making / selling them? Setup kits? Or showing people how to do it?
-
That is very cool. Along with a GP-Wiz49 you could have a really cool setup! As far as Windows XP goes, you can use a DOS program to set (or clear) the bits without any kind of modification to the program. You just have to run the dos program twice. Check out my control program for the GP-Wiz49 for examples of how I control mine. I use a relay board but it really isn't necessary. You just reverse the logic and clear the bits you want for the mode set. You can download the batch files I use to control a DOS app here: http://www.pachislofun.com/setmode/setmode.zip
How are you taking commands to turn the LEDs on? does it correspond to the modes of the GP-Wiz49 by any chance? I am thinking that if the LED board were connected in parallel with the GP-Wiz49 you could have mode changes and LEDs for each.
Thanks!
Toonces
-
I was thinking about trying to do the same thing the other day. Now that I got my gpwiz49's I was gunna try to figure out how to light leds based on what mode was switched and have the panel light up the cp arrows around the stick etc. Also the lights based on controls.dat for buttons etc. I will be very interested to see what you come up with for this. good luck Budda!
-
We should include something on how to take focused pictures in the FAQ...But otherwise it looks good.
How are you controlling the LEDs? Is it just a multiplexor and latch, or a microcontroller too? If it's a microcontroller, you might want to use the serial port for ease of programming.
Am I right in guessing the 555 circuit in the lower right corner is left over from another project?
-
and two, to light up LEDs around each of the eight cardinal directions around a joystick, depending on which directions are active on the joystick.[/quote/
That was one of my ideas, although I was only going to use 4 directions. If anything happens with this board (for a CHEAP price), I may save myself a ton of wiring! Im sure Trimoor remembers this idea beause he practically made the circuit :) Hope it's cheaper than the ArcaLux :P
-
We should include something on how to take focused pictures in the FAQ...But otherwise it looks good.
How are you controlling the LEDs? Is it just a multiplexor and latch, or a microcontroller too? If it's a microcontroller, you might want to use the serial port for ease of programming.
Am I right in guessing the 555 circuit in the lower right corner is left over from another project?
The larger IC is a "constant-current LED display driver" chip, the medium sized one is a standard 74LS05, and the small one, you are correct, is a standard 555 oscillator that is not part of the circuit.
The driver chip runs on an I2C interface. The inverters are part of a circuit which makes the parallel port inputs I2C-compatible. I used the parallel port for simplicity; there may be an I2C serial port solution somewhere as well.
My daughter took the pictures, I really don't know anything about taking "focused pictures". All I did was resize them and resample to 72 dpi. That information would be nice to have.
What I would really want is for someone like GameCab to make a PCB out of this circuit and give me the first one free. It would be easy to put in a way to control 20 more LEDs if necessary.
I haven't looked at the GP-Wiz49 since it is USB.
-
Is the LED driver a MAXIM chip? I tried one once, but I couldn't get the parallel interface to work properly. The only problem is they cost over 5 bucks apiece, which is a ripoff for what little they do. I guess you could sell it with just a chip socket and have everyone order their own free 'samples'.
-
Is the LED driver a MAXIM chip? I tried one once, but I couldn't get the parallel interface to work properly. The only problem is they cost over 5 bucks apiece, which is a ripoff for what little they do. I guess you could sell it with just a chip socket and have everyone order their own free 'samples'.
Yep, MAX6956ANI. They cost something like $5.31 each plus shipping in quantity of 1, but they give discounts for 25 or more ordered. ($4.28) I tried ordering some samples, but they never arrived.
Most of the circuit is in the parallel interface, the LED controller part is just one IC, a .1 uf cap, and a resistor. It was well worth the $5.31 to me to save the trouble. I can get the fade effects, too, and most of the low-level programming was done for me already in the application notes.
-
Am I right in guessing the 555 circuit in the lower right corner is left over from another project?
What I would really want is for someone like GameCab to make a PCB out of this circuit and give me the first one free. It would be easy to put in a way to control 20 more LEDs if necessary.
I'll do it. send me an email at cruvola@gamecab.com and we can go over all of the details. If the schematics and design are good than I think I can have a batch of boards rolled out within 3 weeks.
Thanks
Charlie
-
Am I right in guessing the 555 circuit in the lower right corner is left over from another project?
What I would really want is for someone like GameCab to make a PCB out of this circuit and give me the first one free. It would be easy to put in a way to control 20 more LEDs if necessary.
I'll do it. send me an email at cruvola@gamecab.com and we can go over all of the details. If the schematics and design are good than I think I can have a batch of boards rolled out within 3 weeks.
Thanks
Charlie
YGEM
-
I've got a video of my first prototype, get it here (http://cpmaker.mameprojects.com/files/BuddabingLED.wmv)
I have teamed up with GameCab and we want to produce these boards for the BYOAC community. However, we need to know how many are you are interested.
As I see things there are several different interest levels:
1. I'm buying it, no matter what!
2. I'll buy it if it's not too expensive.
3. Looks interesting, but I could build one cheaper.
4. Meh.
We plan on offering several different choices for what kind of controller you want.
1a. Controller capable of controlling 20 LEDs
1b. Controller capable of controlling 40 LEDs
2a. Wire harness, LEDs, circuit board
2b. Just the populated circuit board
2c. Just the bare circuit board
This board is designed to be inexpensive, thus the interface is through the parallel port. I looked into USB but the only solutions I found would add at least $25 to the cost of the project.
I'm planning on integrating this into my MAME build, and I also plan to offer a configurable standalone application than can run independently, as a screen saver for example, or as part of a front end.
We need to know what level of interest there is in this product. If there isn't any, then I'll just build myself one and change my name to Budda-bling.
-
Hey Budda first time seeing this, VERY COOL :D
Put me down as a #2...with a little re-wiring my Neon CP would be a prime candidate for this thing.
-
I think there will be a lot of interest.
-
I'm in no matter what. I love the idea of when Mortal Kombat loads, buttons 1 thru 5 light up.
-
Count me in too. This looks fantastic!
-
Okay, I'm retarted. How do I see the video (where is the link)?
-
@markrvl:
See this message:
I've got a video of my first prototype, get it here (http://cpmaker.mameprojects.com/files/BuddabingLED.wmv)
-
I'm in for one. Probably the 20 LED one, but it be nice if it was the same PCB and just some parts missing if someone wanted to upgrade.
Definitely in for 2a as well. I'd rather shell the dough then the wireup all those LED's.
-
This project looks great! I fall into camp #2 as well.
-
My interested level would be #2 for product 2a. Will there be an option to setup the joystick directional lights to indicate 4-way/8-way instead of lighting when the joystick is moved a direction as you described earlier in the topic? That would be handy.
-
crap... lost my post...
-
My interested level would be #2 for product 2a.
-
2. I'll buy it if it's not too expensive.
I'm in this boat...
1b. Controller capable of controlling 40 LEDs
...For this controller...
2b. Just the populated circuit board
...For this product... If I do a project like this I will need to have different colored lights for the different player's (green, blue, red, yellow) joysticks, but white for all the buttons. If you provide that as an option (I think that's the most commong 4p setup) then I'll definitely be down for "2a" (as long as it's not too expensive). Do we have a ballpark price yet?
-sab
-
2, 1a, 2a.
C o o l
-
Can you hot swap the LEDs?
-
Being that I haven't even built anything, count me in. I'd love to have a little bling in the cab. Any chance this could also work with the Atari Volcano buttons? I'm not sure how those are wired, but there could be some interesting possibilities there as well.
I'm down with #2 for 2a.
-
I'm definitely intrigued, I'd put me at 2 depending on how easy itd be to set up, but having red arrows light up around my joystick to say 8 way or 4 way would rock.
-
Being that I haven't even built anything, count me in.
-
The board will flash start buttons. The start button flashing will only work in BuddaMAME, however, not with a standard MAME build, since it doesn't use the num lock/scroll lock/caps lock code.
Excellent... this means that KeyWiz users now have a chance at start button lights!
Of course, with this being completely dependent on BuddaMAME, you can never, ever stop updating it now...
[Edit out request for external app; didn't read the thread carefully enough to see one is planned.]
Sounds like I need to find a way to support this in WinCab Jukebox... if I could make individual LED's respond to messages, you could have control panel indicators for anything a WinCab icon can respond to, like making a button flash as it's pressed or having LED's to indicate the Popular list display, Radio mode, Pause, etc. Or actually have light-up instruction panels like the default skin currently simulates... anyone interested in this?
(Sorry for the semi-hijack...)
--Chris
-
The board will flash start buttons. The start button flashing will only work in BuddaMAME, however, not with a standard MAME build, since it doesn't use the num lock/scroll lock/caps lock code.
Excellent... this means that KeyWiz users now have a chance at start button lights!
Of course, with this being completely dependent on BuddaMAME, you can never, ever stop updating it now...
[Edit out request for external app; didn't read the thread carefully enough to see one is planned.]
Sounds like I need to find a way to support this in WinCab Jukebox... if I could make individual LED's respond to messages, you could have control panel indicators for anything a WinCab icon can respond to, like making a button flash as it's pressed or having LED's to indicate the Popular list display, Radio mode, Pause, etc.
-
I am definitely in.
1b and 2a.
-
Thanks for the link Felsir.
Buddabing:
LilWolf probably wants swappable LED harnesses so he can mount the controller in the cabinet and still be able to swap multiple panels that all have their own LED harness. There would be a connector (like a DB25) that the LED harness is wired to that would then mate to another DB25 connector wired to the controller.
Lilwolf, am I correct? I would want this capability as well.
-
I would like to commit to having a fully decked out 40-LED controller with LEDs and wire harness for less than a hundred bucks.
Yikes. This is the primary thing that would depend on if I buy one or not. I'll have to look at the prices of your different options when you have them finalized. Hopefully there will be one in my range. I too misunderstood your $25 comment in the USB post.
-
I'm definitely in for 1b and 2a. Looks great!
-
I'm in.
-
I don't speak for Gamecab, but I would like to commit to having a fully decked out 40-LED controller with LEDs and wire harness for less than a hundred bucks.
Personally, I would forget about the harness and LED's.
-
I imagine that you would just need an extra resistor for the non super bright LEDs.
-
I imagine that you would just need an extra resistor for the non super bright LEDs.
I think the ones I have are 120 MCD, running off a hacked keyboard controller now....
-
Thanks for the link Felsir.
Buddabing:
LilWolf probably wants swappable LED harnesses so he can mount the controller in the cabinet and still be able to swap multiple panels that all have their own LED harness.
-
I'm definitely interested, but if it's going to be ~$100, then I don't think I can commit to buying one.
-
Couple of comments/questions.
Lighting controls for current game and P1 & P2 blinking - great ideas.
Lighting of control directions/buttons when hit - I personaly wouldn't use it.
-
Couple of comments/questions.
Windows XP support for ALL modes?
-
I'm in
-
2,1b,2b
Looks like a great accessory for the GP-Wiz49's. Just think of having 49 LED's to indicate 49 Way mode :)
-
2, 1b, 2a...
I would surely buy it if it costs less then $40... Otherwise, i'll see if i really have a use for it, and then decide, lol...
Looks awesome! I think that these kinds of "comunity created products" are exactly what this community needs... Thumbs up!
-
I use Windows XP and would need to have all functions working within XP before I would actually purchase.
Thanks,
JD
-
I've been following this thread and am very excited to see this project starting to take off.
I'm in for 2 boards if the costs are not too high. I'm leaning towards the 40 led version.
I prefer 2a or 2b
XP support is something I need.
-
Funny, I've been looking to do the same thing (1/2 player/pause blinking, lighting up supported controls).
-
2, 1b, 2a
XP support; however, is a must for me
-
Im out...100 bucks is out of my reach :P If it's anything over 40 bucks without LEDs then Im definately out.
-
I'd be in for a 40 LED controller. I will buy one regardless. ;)
ooooh flashy lights
-
I am in for the 40 LED controller at almost any price
-
I would go for:
2. I'll buy it if it's not too expensive.
1a. Controller capable of controlling 20 LEDs
2a. Wire harness, LEDs, circuit board
I'm hoping you can keep the cost under $50. (Is this unreasonable?)
My only concern is that many of us have to use AdvanceMAME. Will BuddaMAME be based off normal MAME or off AdvanceMAME?
~Ray B.
-
Funny, I've been looking to do the same thing (1/2 player/pause blinking, lighting up supported controls).
-
I would go for:
2. I'll buy it if it's not too expensive.
1a. Controller capable of controlling 20 LEDs
2a. Wire harness, LEDs, circuit board
I'm hoping you can keep the cost under $50. (Is this unreasonable?)
My only concern is that many of us have to use AdvanceMAME. Will BuddaMAME be based off normal MAME or off AdvanceMAME?
~Ray B.
BuddaMAME is built from normal MAME, not AdvanceMAME. I'll look at the AdvanceMAME and I'll see if it's easy to create AdvanceBuddaMAME.
-
Im out...100 bucks is out of my reach :P
-
Im out...100 bucks is out of my reach :P
-
Im out...100 bucks is out of my reach :P
-
I am in for a 40 led model. Pretty cool!
Todd
-
im in
-
3, 1a, 2c
I like soldering, and I think I already have one of those MAXIM chips laying around somewhere.
Linux/DOS support is a must for me. I really hate windows.
-
BuddaMAME is built from normal MAME, not AdvanceMAME. I'll look at the AdvanceMAME and I'll see if it's easy to create AdvanceBuddaMAME.
I think if we can come up with a generic Mame light API, we could get this integrated into the main Mame source and get it rippled into all the ports eventually.
-
BuddaMAME is built from normal MAME, not AdvanceMAME. I'll look at the AdvanceMAME and I'll see if it's easy to create AdvanceBuddaMAME.
That would be awesome.
-
Im out...100 bucks is out of my reach :P
-
LEDs and a wire harness can't possibly cost too much. If you mass-buy LEDs, you can usually get them at around 30 cents each. 0.3 * 40 = 12. Wires are a few cents, so that shouldnt really be an issue.
Oh and sage, BANG, look for a hole in your hat. (Just for fun, I dont disagree)
-
LEDs and a wire harness can't possibly cost too much.
-
LEDs and a wire harness can't possibly cost too much. If you mass-buy LEDs, you can usually get them at around 30 cents each. 0.3 * 40 = 12. Wires are a few cents, so that shouldnt really be an issue.
Oh and sage, BANG, look for a hole in your hat. (Just for fun, I dont disagree)
Plus labor to put together the harnesses, and connectors, including the parallel ports.
Although the connectors may boost the price, looks like the harnesses won't add too much to the cost as AmericanDemon may be working with them to do it cheaply-
http://forum.arcadecontrols.com/index.php/topic,35268.0.html
-
Concerning cost of LED controller board:
The $100 I mentioned is a cap figure, only for the fully decked out 40-LED version which includes everything. The pricing will certainly be less on the final product. Maybe I should have said $99 instead of $100.
-
This is really an optional add-on for extra WOW factor. Those looking into it should be able to afford it, certainly not a necessity for any cab. If you think it's too much then you don't need it.
It really annoys me when people start picking apart the price on things like this.
Charge what you want Budda, do not shortchange yourself.
-
Charge what you want Budda, do not shortchange yourself.
I agree and, like I noted in my reply, it's nothing personal from my end of things, I just can't personally rationalize paying that amount.
I think part of the 'issue' is that we're all accustomed to buying mass-produced inexpensive electronics where the labor costs drop due to the production facilities and/or due to the large numbers produced. It's easy to think "Hey, it's just a small board and some wires" and when you can get a KeyWiz ("just a small board and no wires") for under $20, that becomes the ballpark we're thinking in.
I don't think anybody meant any disrespect Budda. I think it's just a natural reaction from a group of people who only spend $400 total on their cabs.
-
I fall into the #2 category. Very interested, but depends on price and what else is / becomes available.
-
Would this controller be able to support Bi-Color LEDs (ie, LEDs that can display 2 or more colors from the same diode?)
-
Would this controller be able to support Bi-Color LEDs (ie, LEDs that can display 2 or more colors from the same diode?)
It's more a question of the software being aware of this use. In hardware terms, you just wire 2/3 outputs to your two-colour/RGB LEDs, and set each output's brightness to get the shade you want.
-
It's more a question of the software being aware of this use.
-
From what I have read, the two and three color LEDs require voltage to be reversed across them in order to display a different color. The circuit does not allow this.
-
From what I have read, the two and three color LEDs require voltage to be reversed across them in order to display a different color. The circuit does not allow this.
I always thought the colors switched based on how much voltage was being supplied, but after your post I did some searching and found this:
http://www.superbrightleds.com/TriColor%20LED.htm
These just have one lead for each color in the LED (and use a shared anode or cathode)
-
Most bi and tri color LEDS that I have used are just like quarterback said.
-
My understanding of the way these bi-colored LEDs work is you get one color by applying + to one of the leads, and then you get the other color by reversing the polarity (so the + is going to the other lead)... Sound risky.
That type may exist, I haven't come across them personally. Most are just multiple LEDs in a single package, as was mentioned.
-
I think less then 99 for a 40 with wiring is VERY worth it.
But it won't fit my current home machine (I would have to remove two control panels to get enought inputs in my hotswap setup).
So don't put me down for one. But it DOESN'T mean I don't want one... or thing its not worth the money... I just can't figure out how to use it... :(
I do have a friend at work who is building one (but not for MONTHS). But he doesn't have a big budget... but if he saw it...
-
My understanding of the way these bi-colored LEDs work is you get one color by applying + to one of the leads, and then you get the other color by reversing the polarity (so the + is going to the other lead)... Sound risky.
That type may exist, I haven't come across them personally. Most are just multiple LEDs in a single package, as was mentioned.
Take a look at the standard Radio Shack Bi-Colored LEDs. Last I knew, polarity reversal is how they work.
If you think about a 2-color, it makes sense electronically to do it this way. If you hook up an LED backwards, it doesn't work, but also doesn't hurt it. So, if you hook up two different colored leds with their respective Anodes and Cathodes opposite each other, you give them power polarized in one direction and one lights but not the other. And vice-versa. That;s what happens in these and allows the case to use only 2 leads to get the job done.
But, they are a pain to implement, as they require more circuitry and logic to support them. They also don't allow you to "mix" colors like the multiple discreet ones can.
RandyT
-
Most bi and tri color LEDS that I have used are just like quarterback said.
-
Oooh, ever since LAME Arcade disappeared I've hoped for something like this.
-
Take a look at the standard Radio Shack Bi-Colored LEDs.
-
Ok, I've got to chime in now ;D
I'm about 80% done with the CAD's for this board. I may need a few days to improve the PCB's design. The next step for me is that I am going to make a prototype board from my CAD design and test it. Once the testing is done I'll take the next step and have these produced. Buddabling and I are working out most of the details, at this point but I am pretty sure this board is something that can be on the market before the end of May.
Charlie
-
I'd be in for the 40 LED version. If this project starts to go the way of the Dodo bird though (as so many LED driver proj's have)...I'll start looking into the ArcaLux! 8)
One question though: Will there be a way to drive the lights via .txt file or something for "GAME-AWARE INDICATOR ILLUMINATION"? (ie: knowing which buttons work in which game)
mrC
-
I'd be in for the 40 LED version. If this project starts to go the way of the Dodo bird though (as so many LED driver proj's have)...I'll start looking into the ArcaLux! 8)
One question though: Will there be a way to drive the lights via .txt file or something for "GAME-AWARE INDICATOR ILLUMINATION"? (ie: knowing which buttons work in which game)
mrC
BuddaMAME will have that built in, and I plan to put that functionality into an external application for those who use Advance or other variants.
-
You all are working so fast on this that it looks like I may not of asked quick enough. Anways, Is it possible if you are not using all the output pins from the Parallel Port to route the extra output pins (and a GND pin) so people who purchase the board can use them?
-
I'd be in for the 40 LED version. If this project starts to go the way of the Dodo bird though (as so many LED driver proj's have)...I'll start looking into the ArcaLux! 8)
One question though: Will there be a way to drive the lights via .txt file or something for "GAME-AWARE INDICATOR ILLUMINATION"? (ie: knowing which buttons work in which game)
mrC
BuddaMAME will have that built in, and I plan to put that functionality into an external application for those who use Advance or other variants.
(http://forum.iamnotageek.com/images/smilies/smiley_notworthy.gif)
mrC
-
Put me down for 1 possibly 2 (my neighbor wants me to hep him build a machine after I finish mine) but definitely 1 no matter what. This is crazy sick and I agree with you Budda when you say that I am definitely someone who does not want to solder anything let alone 80 wires for 40 LEDS.
-
Before the end of May?
-
Hey Budda.... Its awsome that you will be able to provide the software build into mame but.... Is there a way that you will be able to provide the source for this that people can add to their mame source and compile on their own?
-
Hey Budda.... Its awsome that you will be able to provide the software build into mame but.... Is there a way that you will be able to provide the source for this that people can add to their mame source and compile on their own?
-
Just another oddball thought...
Image your attract mode doing its thing and someone steps up to the machine to choose a game. Shouldn't the attract mode subside at that point? Shouldn't it act like a screen saver (sort of).
After no activity the attract mode goes on... Then when a key is pressed, it goes off (or some other mode). I just think it would be incredibly annoying choosing a game with your entire CP flashing like crazy.
Just wondering if this will be part of the attract app/build?
JD
-
It looks sooooo cool! :o
2, 1a, 2a ;D
-BobBorakovitz
-
2, 1b, 2a
Very nice.
-
2, 1a, 2a
-
I looked into the other kind of tricolor LEDs, the one with four leads. This kind of LED should work with the controller. However, software to control these is a secondary priority for me at this time.
The kind of bicolor or tricolor LED that depends on polarity of voltage will not work.
There have been more than thirty people interested in getting the controller. Thank you all for your support.
If you are reading this thread and you are interested in getting one of these controllers, you need to respond to this thread. I normally avoid bumping threads, but I'm going to pimpmarket this controller to you guys until I have an accurate estimate as to how many people will buy it.
And thanks to Kevin for the exposure on Retroblast.
Regards,
Buddabing
-
And thanks to Kevin for the exposure on Retroblast.
Hey, I'm just doing it to help out the volume discount. :P
Seriously, I think it's a great project and I want to see it succeed.
BTW, I don't know if this has been asked yet, but will the board support the "keyboard lights" feature of MAME, i.e. the blinking player 1 and 2 lights? Or will we still need to wire those up to an IPAC?
Kevin
-
2, 1b, 2a
This is amazing! Thanks for all your great work!
-
BTW, I don't know if this has been asked yet, but will the board support the "keyboard lights" feature of MAME, i.e. the blinking player 1 and 2 lights? Or will we still need to wire those up to an IPAC?
Kevin
BuddaMAME will support this.
-
Love the project! I was looking to do somehting along the lines of this on my cab, but went with a different approch, didn't need all the flashy bits. (rethinking that now though...)
One "Bling" thing I was looking for and never found, so I build using discrete components, and after looking at your system might be fairly easy to impliment was a trackball fading circuit.
I haven't gotten the avi's hosted yet, but basically, when the trackball is idle, a couple of superbright leds under the trackball fade on and off about once every 4 seconds, then depending on the frequency of the pulses from the Y axis encoder, it ramps up to a max of about 10 "fades" a second.
I've had a lot of remarks on my other cab lighting, but the biggest response I've had is during a game of golf when you whack the trackball, it's flash rate varies in proportion to how hard you spin it.
Just an idea, that might add some additional "bling" to a great design!
SD
-
Thank goodness. Now my lazy butt won't have to figure out how to do it on my own. :) Count me in.
-
Buddabing, can you share the software API design for the board that you are planning?
-
Buddabing, can you share the software API design for the board that you are planning?
EDIT:
I removed everything that was here since it has been completely overhauled since this post.
-
1, 1b, 2a
great project...
-
Wow this puppy sounds pretty sweet. My interest level is 2/1b/2b
Good Luck!
-
I'm interested in this project and will watch it. I like the little I have read so far.
-
BTW, I don't know if this has been asked yet, but will the board support the "keyboard lights" feature of MAME, i.e. the blinking player 1 and 2 lights? Or will we still need to wire those up to an IPAC?
Kevin
BuddaMAME will support this.
That raises my interest. I'm finishing up a cab now and was planning to buy an Ipac just to control the lights for player 1 and 2. Nothing more. Already have other boards doing everything else. ETA?
-
BTW, I don't know if this has been asked yet, but will the board support the "keyboard lights" feature of MAME, i.e. the blinking player 1 and 2 lights? Or will we still need to wire those up to an IPAC?
Kevin
BuddaMAME will support this.
That raises my interest. I'm finishing up a cab now and was planning to buy an Ipac just to control the lights for player 1 and 2. Nothing more. Already have other boards doing everything else. ETA?
GameCab says May for the hardware. I say "when it's done" for the software. :D
I think that MAME v0.96 will be out before too long and I plan to put the first LED support into it then. I've coded up the start LED part and I'm currently working on the other features which will be in the first release.
I'll probably retrofit BuddaMAME for purchasers of the GameCab LED controller, for selected key versions. (probably .56, .78, .92, maybe .36 or .37 something)
I've looked into AdvanceMAME and it is a pain to compile. I wish there was some zip files I could just download and it would work. So it is uncertain if there will be AdvanceBuddaMAME at this time.
-
Like I was asking before.... Is there a possibility that you will release the source additions that you do for the LED board so others that use variants of mame can combine and compile their own?
-
I am very curious how you guys are designing the circuit. IMO It would be a little shortsighted to persue a parallel port based control design for a production device, especially when building an alternative interface is very easy.
The TLC5920 LED driver From TI has a 16 bit and 8 bit shift register internally so it can drive 128 LED's on its own, which isn't too bad for a $3 part. You could couple one (or more) of these with something like the Atmel AT90S and some simple power circuitry to build a 128-LED driver for an insanely reasonable parts cost. For small applications, power could be taken from the USB also, making using this for something like a 2p control panel even less expensive.
I have been looking at building a large LED matrix controller for a different project recently and this type of design is probably what my approach will be. If you guys are willing to share any details about your design approach, I would be interested.
BTW you could probably mark me down for one anyway, as no matter how you design it, if it works and you take the time to write support for it into MAME, then I'd probably be all about it :)
-
I want one!!!! :D :D :D
2,1b, 2b.
-
I'm in all the way...
$100 bucks or so for a 40 LED system with all the wiring.
Also I'd like the option for a 20 LED system at a lower price.
So...
1
1a+1b
2a
My only concern would be the software - regular updates to BuddhaMAME or better yet an external application would be nice.
OK, maybe I'd want one without the LEDs. I've got 50 superbright babies now that I'm using to communicate with aliens.
"Owww! My retinas!" :o
-
2, 1b, 2b
Couldn't you just make this a standalone program and have the FE call it before launching the game? I think some of the popular FEs already support this anyway (running a program before launching).
-
I am very curious how you guys are designing the circuit. IMO It would be a little shortsighted to pursue a parallel port based control design for a production device, especially when building an alternative interface is very easy.
The parallel interface consists of a 7405 inverter, a couple of pull-up resistors, and a .1 uf cap. It can't get much easier than that.
What alternative interface are you referring to? USB?
The TLC5920 LED driver From TI has a 16 bit and 8 bit shift register internally so it can drive 128 LED's on its own, which isn't too bad for a $3 part. You could couple one (or more) of these with something like the Atmel AT90S and some simple power circuitry to build a 128-LED driver for an insanely reasonable parts cost. For small applications, power could be taken from the USB also, making using this for something like a 2p control panel even less expensive.
I looked at a few of the TLC59xx data sheets. It's very interesting and you could definitely build a LED controller from them. The only problem is that these chips are all QFP packaging, which I am not equipped to deal with.
I have been looking at building a large LED matrix controller for a different project recently and this type of design is probably what my approach will be. If you guys are willing to share any details about your design approach, I would be interested.
BTW you could probably mark me down for one anyway, as no matter how you design it, if it works and you take the time to write support for it into MAME, then I'd probably be all about it :)
Having a matrix design allows larger number of LEDs. But, you have to worry about making sure all the LEDs have enough power, and you have to have a PIC in there to drive them. I chose a simpler design, which I believe will ultimately be cheaper, easier to use, more expandable, and more reliable.
In fact, with a bit of hacking, up to eight of these 40-LED boards can be daisy-chained together and all run from the same parallel interface. I don't recommend this,
-
Im interested in the following:
1 1a 2b
-
It looks like you've put in a ton of work into this project. Thanks for all the updates.
This is what I'm interested in.
2. I'll buy it if it's not too expensive.
1b. Controller capable of controlling 40 LEDs
2a. Wire harness, LEDs, circuit board
-
btw, instead of creating a version of mame for each version...
why not just create a middleware piece?
IE
updateLED mame.exe pacman
This would find the take the second input and setup the leds... Then it would launch the 1st with all parameters?
Or something similar.
-
btw, instead of creating a version of mame for each version...
why not just create a middleware piece?
-
btw, instead of creating a version of mame for each version...
why not just create a middleware piece?
-
I haven't finalized any kind of API. I posted what I have on the third page of this thread. The API will likely evolve as the software evolves.
I don't think the MAME devs give a hoot about this project, since it doesn't add anything to the accuracy of the emulation.
I've no experience with the Mame devs - but they have added the keyboard light option, right?
-
That is so very cool -- I am in, and I want it now!
#2, 1B, 2A, 2B whatever!
-
btw, instead of creating a version of mame for each version...
why not just create a middleware piece?
-
I've no experience with the Mame devs - but they have added the keyboard light option, right?
They added that in support of the old Atari games that used illuminated and flashing player start buttons. So, that said, they DID implement that in support of accurate emulation. (so that comparison is apples to oranges I think).
-
They added that in support of the old Atari games that used illuminated and flashing player start buttons. So, that said, they DID implement that in support of accurate emulation. (so that comparison is apples to oranges I think).
Well OK, except that it works on other games too - if they were that fanatical, they would have only enabled it for Atari games.
But either way, if you modify Mame to just generate the 'events', then you should be able to create a patch file that can easily be applied to any of the various ports without much work.
-
great project 8), I'm definately interested!!
2. I'll buy it if it's not too expensive.
1b. Controller capable of controlling 40 LEDs
2a. Wire harness, LEDs, circuit board
-
It would be nice if lights could be defined in a flexible external way like artwork, so in addition to player start lights, we could have Weapons Van lights, Lunar Lander skill level lights, etc.
-
Also, it looks like Lunar Lander uses artwork for its skill level lights. What game is the "Weapons Van" from?
Didn't play a lot of Spy Hunter did you?
Actually, I forget if the Weapons Van in Spy Hunter is even working in Mame? Anyone?
-
I'm not sure if this has been asked yet, but could AdvanceMame scripts be used to run the LED controller?
-
In fact, with a bit of hacking, up to eight of these 40-LED boards can be daisy-chained together and all run from the same parallel interface. I don't recommend this,
-
Kev, I completely believe you. I mean..... you could feasibly use this to create an LED field PacMan. Heh that'd rule.
-
In fact, with a bit of hacking, up to eight of these 40-LED boards can be daisy-chained together and all run from the same parallel interface. I don't recommend this,
-
Hey Kevin, if you buy seven boards, maybe GameCab will give you one free!
All you have to do to daisy chain the boards is to bend up one or two pins on one or two of the ICs, solder one or two jumper wires, and tap into the parallel port connection on the second and subsequent boards. Nothing irreversible. :)
-
I would fall into group #2.
I have been wanting something just like this, that can be controlled via a small DOS driver program. I want to be able to cycle them in some sort of pattern while in the FE. Then when launching a game, I want to light the buttons used, and also light a 4/8 way indicator for each joystick (probably will switch to Randy's top-panel switching sticks as well).
I also want to light up the trackball for those games, as well, and perhaps light the Start buttons if possible (might not be for the extra DOS driver version and my own Mame version).
Wade
-
I've got a new video of the LED controller in action. I've hooked the code into MAME and I've got the start button LEDs working.
Here's (http://cpmaker.mameprojects.com/files/MAMELEDdemo.wmv) the video.
I was on the verge of banging my head against the wall in frustration getting this to work, when I found out that someone commented out the pacman LED controller code.
-
Sweet. I was thinking about bumping this and going ....
IS IT DONE YET? IS IT DONE YET? IS IT DONE YET? ;D
Can't wait for this to be finished. Keep up the great work Budda!
-
They added that in support of the old Atari games that used illuminated and flashing player start buttons. So, that said, they DID implement that in support of accurate emulation. (so that comparison is apples to oranges I think).
Well OK, except that it works on other games too - if they were that fanatical, they would have only enabled it for Atari games.
AFAIK, it only works in MAME in the Atari games and some PacMan games and clones. And it worked in these games in the arcades. And yes, they are that fanactical about this area. (Control inputs are a different story).
-
AFAIK, it only works in MAME in the Atari games and some PacMan games and clones. And it worked in these games in the arcades. And yes, they are that fanactical about this area. (Control inputs are a different story).
Actually it works in quite a few more games (just saw it on I,Robot for example) - but looking at the code, you're right, they only support what the original game supported.
-
AFAIK, it only works in MAME in the Atari games and some PacMan games and clones. And it worked in these games in the arcades. And yes, they are that fanactical about this area. (Control inputs are a different story).
Actually it works in quite a few more games (just saw it on I,Robot for example) - but looking at the code, you're right, they only support what the original game supported. Which also means that Budda's board will only support player flashing on those games.
So, from a programming point of view, the real question is whether we can't do better than that. For example, it would be great if you could light the 'throw' button in Mr. Do (one of my favourite games) only when the ball is available to throw.
OTOH, stuff that was supported in the original (like the Weapons Van light in Spy Hunter) probably could be added to the main MAMETM distribution, if we can figure out how to add it and submit it to the devs.
-
OTOH, stuff that was supported in the original (like the Weapons Van light in Spy Hunter) probably could be added to the main MAMETM distribution, if we can figure out how to add it and submit it to the devs.
I'm still getting used to the Mame code, but it seems game drivers can set up to 8 LEDs - for example, Discs of Tron sets one for 'background light' and 'strobe'. So those are already available for quite a few games...
-
For example, it would be great if you could light the 'throw' button in Mr. Do (one of my favourite games) only when the ball is available to throw.
Well, I got it working.
-
For example, it would be great if you could light the 'throw' button in Mr. Do (one of my favourite games) only when the ball is available to throw.
Well, I got it working.
-
That's Really COOL! So if you had a big lighted button for the Super Punch in KNOCKOUT, it could light up once you reach full strength.
This is completely BLING, and not a necessity, BUT I REALLY LIKE IT.
Good going, Glitter.
-
I wonder if we can convince the MAME devs to add a standardized light output routine. It should make them happy, as the emulation will be even more realistic.
Now, if we can only convince them to use the original 12 inputs for the rotary joys instead of the stupid left/right thing...
-
I wonder if we can convince the MAME devs to add a standardized light output routine.
-
That's Really COOL!
-
I wonder if these sorts of changes to add LED features to games that didn't have them can be added as "cheat" files....
Not sure, I'll check it out.
-
I wonder if these sorts of changes to add LED features to games that didn't have them can be added as "cheat" files....
OK, I've looked into the Cheat engine (thanks for the pointer Chris).
-
It seems to me like you would want to hook them up as part of the artwork framework.
why?
because there are already a ton that does this! And you might get others to add support for other games for you.
Look at the spyhunter artwork for an example.
-
because there are already a ton that does this!
-
Quick update, I have the light signal system fully working and integrated into Mame.
-
Take a look at the artwork for spyhunter. Currently when any light goes on/off it changes the artwork.
However is updating the artwork system is probably the level where you would want to catch light / memory changes. Plus for any games that use the animated artwork, you shouldn't have to search for memory locations for those lights.
I don't know how its done. I just know that its already being done.
because there are already a ton that does this!
-
Take a look at the artwork for spyhunter.
-
I've written up a quick first draft outline of what I'm now calling the gl.tter Light Signal Engine (LSE) (http://r-i-l.net/glMAME/gl.tter LSE.htm).
Anybody interested in the details, rationale behind it, and what's going to be possible, check it out.
-
This is outstanding news. gl.tter and buddabing, with your powers combined and the production power of gamecab.... this project is gonna rule.
I cannot wait for this to hit final production and we can have the PCBs in hand and the tools needed to turn every game into a visual escapade. Gonna rule.
-
I've written up a quick first draft outline of what I'm now calling the gl.tter Light Signal Engine (LSE) (http://r-i-l.net/glMAME/gl.tter LSE.htm).
Anybody interested in the details, rationale behind it, and what's going to be possible, check it out.
-
Nice, I will support your code.
Great.
You might want to avoid the mention of Dirty Loser Libraries to the MAME devs. :)
I wondered about that - but it's the only way to separate all the 'not what the original game did' code out from the Mame code, which I'm guessing is the only way to get it into the main distritbution.
-
That's great... Thanks for working on this... It looks great so far.
Having this lighting control external to MAME is THE best idea!
Comments - questions:
Buttons light brighter when pressed - personally, I don't look at the CP while someone is playing a game.
Lighting P1/P2 controls mapped for current game - Super cool, hope you add this in soon.
Idle animation during a game's attract mode - very good.
-
I wondered about that - but it's the only way to separate all the 'not what the original game did' code out from the Mame code, which I'm guessing is the only way to get it into the main distritbution.
-
Idle animation during a game's attract mode - very good.
-
That's great... Thanks for working on this... It looks great so far.
Thanks :)
Having this lighting control external to MAME is THE best idea!
I think so.
-
They don't want any kind of code in their for which the source is not available.
Hmm, well the DLLs would be optional, scanned for and loaded at runtime, so Mame would work without any drivers at all and wouldn't have to ship with any.
-
BTW, in case I wasn't clear, only the driver would be a DLL. Everything else (the messaging engines) are built into Mame, and are platform independent.
-
The driver to the light board?
That should be seperate... but if you can figure it out... it probably should be a real windows driver. Then you don't have to worry about access to the ports in XP
-
The driver to the light board?
Yes.
That should be seperate... but if you can figure it out... it probably should be a real windows driver.
-
BTW, speaking of parallel port access, when I was trying to get my old pport LEDs working on my Win98SE machine (which runs Mame), I kept getting all kinds of signals on the parallel port that I couldn't account for.
Turns out the Act Labs GS driver (the gameport version) is constantly sending data to the parallel port!
-
For the P1/P2 blinking when ready - Let's say 2 credits are added P1/P2 both blink and the player presses P1 start.
-
Most games that support "buy-in" will flash an "insert coin" even during gameplay. Upon credit, it changes that message to "Press Start" (for games where you can join in any time). Maybe you can monitor the addresses related to those messages.
That's an option. I'm not sure which way to go yet. Can anybody think of games that support buy-in's, but don't have some kind of message on the screen?
A 'game has started' signal might be useful anyway, so maybe that's the way to go (one less address to figure out).
As to what to do with the lights during a game... How about imitating what Atari did (for starters). What do they do when you have credits in the machine, but are playing? Does it stop flashing but stay on? Or does it stay off? Or does it keep flashing?
Not sure - anybody?
As I said, one option is to make this configurable, so you could choose which you prefer yourself.
-
The driver to the light board?
Yes.
That should be seperate... but if you can figure it out... it probably should be a real windows driver.
-
I agree with both of you here. Writing a Windows driver for the board would be difficult and more prone to bugs. But it is the Right Thing to do. I should eventually make a driver to the board.
Right, get it up and running first, and then you can play with a real driver until its solid.
-
As for the GL light gun. I wouldn't worry about it. It SUCKS!
you can almost get it working with the beta mouse driver... but touch the mouse and its off. I have one that I bought for 10 bucks and think it was a crap buy for that much.
And about killing the system on a bug... All you new programmers out there get it easy... why I remember when you could kill a system if you didn't have your printf formats correct and you had to type uphill both ways to school!
-
As
-
As to what to do with the lights during a game... How about imitating what Atari did (for starters). What do they do when you have credits in the machine, but are playing? Does it stop flashing but stay on? Or does it stay off? Or does it keep flashing?
Not sure - anybody?
As I said, one option is to make this configurable, so you could choose which you prefer yourself.
I know in pacman that the start buttons keep flashing after a game has started. If just 1 credit left only player 1 start will flash, if 2 or more credits left then they both flash.
-
(download updated to latest version)
OK, I've got something for you all to play with here (http://homepage.ntlworld.com/glitter/_files/gl.tterLSE_0.12b.zip).
-
There was a bug that stopped the flashing working correctly after a game had finished.
-
Another thought: If MameDev rejects adding this to the main core (which unfortunately I expect they will -- not true emulation of the original hardware), you should consider working with the AdvanceMAME (http://advancemame.sourceforge.net) base (which a lot of BYOC'rs use for their arcade-monitor cabs already) and enable integration with their script (http://advancemame.sourceforge.net/doc-script.html) system to wire up the LED events. Note their script system already supports toggling parrallel port bits, and has some rudementary keyboard LED support -- if you added the ability to have RAM watch value "events", and perhaps an info_ property for what buttons are used by the game and you could be there (and multiplatform at that). The only other shortcoming I see for the advancemame scripts is that it doesn't look like you can have a script file per-game, rather just scripts in the global rc file. Seems like that would be worth extending to support script files for roms or rom families as well...
-
I don't want to be limited to AdvanceMame.
-
BTW, I just looked at the AdvanceMame script support, and whilst it's pretty neat, it's also very limited.
For example, with my system you just need to figure out two events to fully support player flashing in any game (I might be able to get that down to 1 or zero!
-
The MameDevs might go for it because it allows them to make use of all the interesting signals some games already generate - I don't see the point of them tracking them (which they do in the code), if there is no way to output them without customising Mame. In that sense, a light messaging system doesn't compromise their philosphy of 'accurate emulation only', it only helps it.
Further to that, without the actual hardware in place (as in Badda's Circuit) the whole addition is pretty well transparent to the accuracy of the emulator..
Even if the MameDev's do go with it, then end-users still have the choice to decide if they want to take advantage of the changes. It's not like they can really claim that what they are doing is accurate anyway otherwise MAME would be a dedicated hardware based system only ::)
-
It's interesting how Mame works internally. Basically it obviously emulates all the chipsets that were used by a particular game. Then it 'virtually wires' your real PC inputs to the places were the game ROM expects to find this information.
Beyond that, Mame doesn't get involved - it merely allows the game 'brain' to do what it normally does. That means that Mame doesn't know if the game is in attract mode or not, or even if credits are inserted or a game is started. It doesn't need to know - the game ROM takes care of everything.
That's why at the moment, you have to supply these signals in the text files yourself. However, I'm trying hard to reduce the amount of events you need, and that those you do need are as easy to find as possible. Fewer (easier) events = more people successfully supporting games.
For example, originally I needed 2 custom signals to show that a 1player or 2player game was started (tricky to figure out).
I then realised that I can I find out if a player start button was pressed from Mame. But that doesn't tell me if the game was actually started (the button could be pressed at any time). Mame doesn't know.
But, together with the ATTRACT_MODE on/off message (which is useful for other things too, eg. idle animations), I can figure out that a game was started, and which button started it. I then use the CREDITS counter to handle the flash logic automatically.
-
New version is out - download it here (http://homepage.ntlworld.com/glitter/_files/gl.tterLSE_0.12b.zip).
I've crammed about as many effects into MrDo! as I can with 3 LEDs at my disposal :).
I'm half-way through getting the virtual on-screen panel working... but now I'm going to kick back and play a little Do with lights.
btw, on my keyboard at least, the fast flashing fx and/or flashing scroll lock seem to occasionally cause keys to stick.
-
Anybody tried this yet?
-
Pretty cool!
Any chance I could get the code changes so I could see if it would be possible to apply them to an older version of MAME? (0.59, for my cab)
-
Pretty cool! Any chance I could get the code changes so I could see if it would be possible to apply them to an older version of MAME? (0.59, for my cab)
The code for the keyboard LEDs is pretty much done, but I need to finalise a few more things first. Should have something soon.
Did you try creating any new signals for other games?
-
I haven't had a chance yet to try making new codes. I think I'll try this afternoon with an old game I like :). Anyways, it'd be really cool to add this to other MAME versions. ;D
-
Anyways, it'd be really cool to add this to other MAME versions.
-
Anyways, it'd be really cool to add this to other MAME versions.
-
I'm using an older version because I have an older PC for my cocktail cab (450mhz). It is customized (skip_startup_frames and some other changes).
Interesting - my Mame PC was a Slot1 Celeron 450 too, but I just upgraded it to a P3 550 (slightly oc'ed) - just enough to play my favourite (older) Mame games smoothly (it doubles up as a DVD player too).
-
Interesting - my Mame PC was a Slot1 Celeron 450 too, but I just upgraded it to a P3 550 (slightly oc'ed) - just enough to play my favourite (older) Mame games smoothly (it doubles up as a DVD player too). What OS are you running on?
Just a simple Windows 98 setup with a GameLauncher-like frontend I programmed as the shell (I wanted the CocktailFE-type thing where the screen flips depending on the player using the controls and the ability to sort things in to "linked folders/categories").
-
Oh, by the way, I just got a chance to try out finding the CREDITS address on another game (Kangaroo - rom name: kangaroa). The LED flashing works beautifully! For anyone that's curious, here is the credits line for kangaroa:
0:E02F:COPY : 0:CREDITS
Edit: Just got the address for Crush Roller (rom name: crush)
0:4C1E:COPY : 0:CREDITS
Burger Time (rom name: btime)
0:001D:COPY : 0:CREDITS
Now can I PLEASE have the changes you made so I can apply them to my copy of MAME? :-X
-
Oh, by the way, I just got a chance to try out finding the CREDITS address on another game (Kangaroo - rom name: kangaroa). The LED flashing works beautifully!
Good work.
-
Now can I PLEASE have the changes you made so I can apply them to my copy of MAME?
-
Dude, he hasn't even given them to me yet!
Dude, you haven't even asked :).
-
C'mon! I'm not that patient! ;D
But really, I'd like to get to working on it ASAP because I'm going to have some free time this weekend to work on my control panels, and would like to get this working as well. This way I can set up my P1 & P2 buttons correctly/nicely. I can't imagine it's very difficult. I'm taking a look at the code (of 0.59) now and it seems like it was pretty simple to implement...except I don't know enough C to do it myself :X
-
This is absolutely awesome!
Can you make it flash the LED of the correct button to press in Chicken Shift?
-
Can you make it flash the LED of the correct button to press in Chicken Shift?
-
C'mon! I'm not that patient!
-
No promises. Do you have lights wired to the keyboard LED outputs, or how are you doing it?
I have an [older (2003-ish)] I-PAC which has the LED outputs for the Caps Lock, Scroll Lock, and Num Lock. I have a temp LED wired up to Caps Lock (using Oscars LED Driver for super-bright LEDs - http://www.oscarcontrols.com/led/). Works nicely in Pac-Man, but I really want to add it to other games.
I mean, if you gave me something like a diff file or just a list of what you changed/added and where, I could probably (hopefully?) figure it out myself.
-
I have an [older (2003-ish)] I-PAC which has the LED outputs for the Caps Lock, Scroll Lock, and Num Lock. I have a temp LED wired up to Caps Lock (using Oscars LED Driver for super-bright LEDs - http://www.oscarcontrols.com/led/). Works nicely in Pac-Man, but I really want to add it to other games.
Cool.
-
Just in case you guys think that this isn't been watched with great interest, I just wanted to say that this is a FANTASTIC project..!!
Awesome project indeed
[/b]
-
Just in case you guys think that this isn't been watched with great interest, I just wanted to say that this is a FANTASTIC project..!!
Awesome project indeed
[/b]
Thank you.
There hasn't been an update on this project lately for two reasons. First was GameCab's unfortunate incident with his disk drive. The second is that I'm working on porting BuddaMAME to 0.96 and integrating gl.tter's code into it. Then I have to write a DLL to interface the LED controller.
Buddabing
-
I cant wait. ;)
-
I have to say, gl.tter's code is very, very nicely done. I got a sneak preview of it (and implemented it into my customized version of MAME) and it is too damn cool to play with.
Oh, and please, don't bother gl.tter about getting the source / etc. It will be released eventually.
-
Quick update, I've got the input controller signals mostly working.
I'm stuck on a cocktail mode related problem right now though - see this thread (http://forum.arcadecontrols.com/index.php/topic,36752.0.html).
(solved)
-
BTW, if somebody really wants to see the source right now, PM me with your email address. It's slowly settling down, but things are still subject to change.
-
Just in case you guys think that this isn't been watched with great interest, I just wanted to say that this is a FANTASTIC project..!!
Awesome project indeed
[/b]
Thank you.
There hasn't been an update on this project lately for two reasons. First was GameCab's unfortunate incident with his disk drive. The second is that I'm working on porting BuddaMAME to 0.96 and integrating gl.tter's code into it. Then I have to write a DLL to interface the LED controller.
Buddabing
Hey Guys,
I'm still waiting on my Hard Drive to ship (You have got to love some Ebay sellers).........
So, If anyone has a Western Digital 80Gig drive (Part Number WD800BB-00CAA1) and would like to sell it then please feel free to contact me cruvola@gamecab.com. The drive was manufactured in 2002-2003.
Other than what I mentioend above, I'm still testing out and troubleshooting the Prototype board and hope to have some of the results real soon.
Thanks
Charlie
-
Do the Volume Up / Down controls (as set in 'Other Controls') work for anybody? They don't seem to do anything here.
-
Buddabing, gl.tter, Gamecab,
Great project put me down for 1b and 2a.
Turns out the Cheat engine is a great way to find game ram addresses to generate custom signals from - I found the lives and credit counters in about 20 seconds each!
-
On a side note, I got my "free" MAX6956ANI samples today from Maxim..
They sent me two which is pretty cool because now I can implement this project on my current (WIP) cab and my next project.. ;)
-
On a side note, I got my "free" MAX6956ANI samples today from Maxim..
They sent me two which is pretty cool because now I can implement this project on my current (WIP) cab and my next project.. ;)
You got free samples from MAXIM? Wow how'd you do it? I read that magazine all the time. I would love for them to send some "free samples" over to my house.
They could help me work on my next cabinet of course ;)
http://www.maximonline.com/girls_of_maxim/
-
Excellent work guys! Sooo cant aford it but am soooo gonna have one! [Must.....Have.......Flashing......Lights......Cant......Resist] ;D
Put me down for 1b, 2a.
This project and the translucent button proj that is underway are gonna go together superbly, cant wait!
-
I Have GREAT NEWS!!! I have recovered ALL of the data from my old Hard Drive!! Of all people: My mom has a "800 Giggawatt floppy disk" (as she calls it) and it happened to be an exact match to my hard drive that died. I swapped the boards and have backed everything up to my network storage hard drives. It's going to take a day to sort out all of the files but i'm just glad the information is back.
Thanks
Charlie
-
Kick the tires and light the fires big daddy! :D
-
If this guy could be contacted I'm sure he could add to this project, apparently Dr Romz has found an automated way to detect the required code.
Thanks for the pointer. I've just spoken with him and he's been giving me great pointers on credits counters - turns out some games use more complex ways of storing the credits than just a simple number.
He did manage to automate detection and found counters for thousands of games. His approach to start button flashing is slightly different though so I'll have to see how best to implement it.
-
Wow, you guys rock! Combining this with Shawnzilla's translucent microswitch buttons is going to be too awesome. Damn the expense! I like the pretty lights!
1. I'm buying it, no matter what!
1a. Controller capable of controlling 20 LEDs
2a. Wire harness, LEDs, circuit board
-UndeadMeat
-
Okay, I played MrDo in BuddaMAME 0.96 over the weekend. Nice Blinky start Lights. Good job!!!
Question 1 - When Two credits are added - the LED's flash in SEQUENCE. I fired up Asteroids and they flashed ALTERNATELY. (But in Centipede, they flash in Sequence). Does anyone know of a way to set this to one of the other? And/or does anyone know which one is correct for the actual machine?
Question 2 - I am having a hard time seeing how to make this work or how to set it up. Specifially how to enable/disable functions on a per-game basis.
From the files, I see keybled.cfg which only contains the following two uncommented lines:
PL1_START_LIGHT->0
PL2_START_LIGHT->1
And Mrdo.dat which contains the following lines:
0:E006:COPY : 0:CREDITS
0:E097:COPY : 0:PL1_LIVES
0:E11C:COPY : 0:PL2_LIVES
0:E000:<= :60:ATTRACT_MODE:1
0:E000:> :60:ATTRACT_MODE:0
0:E1AF:!= :LAST:HIGHSCORE_ENTRY:1
0:E1AF:== :LAST:HIGHSCORE_ENTRY:0
0:E1B0:== :03:HIGHSCORE_ENTRY_LETTER:0
0:E1B0:== :00:HIGHSCORE_ENTRY_LETTER:1
0:E1B0:== :01:HIGHSCORE_ENTRY_LETTER:2
0:E1B0:== :02:HIGHSCORE_ENTRY_LETTER:3
0:E1CC:ISSET :80:MRDO_BALLREADY:1
0:E1CC:NOTSET:80:MRDO_BALLREADY:0
0:E30F:> : 20:MRDO_DIAMOND:1
0:E30F:== : 20:MRDO_DIAMOND:0
0:E1E6:> :LAST:MRDO_BALL_ANIMATION:1 // exploding
0:E1E6:< :LAST:MRDO_BALL_ANIMATION:2 // returning
0:E1E6:>= : 2B:MRDO_BALL_ANIMATION:0 // animation off
0:E1E6:== : 03:MRDO_BALL_ANIMATION:0 // animation off
But none of the values in mrdo.dat seem to match the variables in keybled.cfg . . .
And there is a commented reference to (see 'lights\docs\Inbuilts.txt'), but I don't see any docs files anywhere.
Could someone point me in the right direction?
-
Okay, I played MrDo in BuddaMAME 0.96 over the weekend.
-
Okay, I played MrDo in BuddaMAME 0.96 over the weekend.
-
Do the Volume Up / Down controls (as set in 'Other Controls') work for anybody?
-
I'm looking to include Dr.Romz' excellent credits counter database, which should eliminate the need for a CREDIT signal completely for over 3000 games!
I'm glad you contacting Dr.Romz' paid off, 3000 games is a lot of hard work.
BTW, in my version of mrdo.dat, I also map the MRDO_BALL_READY signal to the Scroll Lock LED to demo a watchpoint generated signal.
-
There are so many possibilities with this bit of kit, I cant wait!!
I remember talk of multicolur LEDs, did it get decided whether or not these would be able to be used/controlled?
-
Asteroids P1 and P2 lights flash alternately.
Darryl
-
Just a thought ive had.
As discussed it will be awesome to have default and custom light sequences. I assume these would be easy to set up for an event such as a set period of inactivity etc.
It would also be cool to be able to set the next sequence by using the I-Pac shift function. This could be used to set the next squence used at the set period or to set one off instantly.
A red Knightrider sweeping fade would look just toooo cool
-
I'm glad you contacting Dr.Romz' paid off, 3000 games is a lot of hard work.
Yes, nice guy too.
-
I remember talk of multicolur LEDs, did it get decided whether or not these would be able to be used/controlled?
That's up to the light driver writers.
Asteroids P1 and P2 lights flash alternately.
OK, I'll make it an option (in the .dat file).
As discussed it will be awesome to have default and custom light sequences. I assume these would be easy to set up for an event such as a set period of inactivity etc.
It would also be cool to be able to set the next sequence by using the I-Pac shift function. This could be used to set the next squence used at the set period or to set one off instantly.
Again, up to the driver, but possible in theory.
A red Knightrider sweeping fade would look just toooo cool
-
I really like this feature, though some people will say that you don't look at the buttons when you play, but I still
think it's cool.
-
Speaking of which, are there any programmers out there willing to go through the game driver files, and replacing the set_led_status() calls with LSE signals?
-
BTW, the signals don't have to be restricted to lights.
-
I don't know about adding it to Visual Pinmame. It's been done before with Q*Bert and a special build of mame as can be seen here (http://members.cox.net/brado426/QMAME).
-
I don't know about adding it to Visual Pinmame.
-
If you're talking about a global replace there are IDE's to take care of that.
-
So would it be possible to put one of those pinball hammers that make that noise when you get a free game into your cabinet and have that trigger off if you get a free game in Visual Pinmame or I think I read somewhere here that Q*Bert used one them aswell.
Yes, as long as you can find the address in memory that triggers this, just create a signal for it with a watchpoint file, and then trigger the circuit in some way (eg. via the keyboard LEDs).
I don't know about adding it to Visual Pinmame.
-
So would it be possible to put one of those pinball hammers that make that noise when you get a free game into your cabinet and have that trigger off if you get a free game in Visual Pinmame or I think I read somewhere here that Q*Bert used one them aswell.
Yes, as long as you can find the address in memory that triggers this, just create a signal for it with a watchpoint file, and then trigger the circuit in some way (eg. via the keyboard LEDs).
The problem is many recent machines don't have a knocker; they make the sound electronically.
We shouldn't have to actually modify PinMAME, though: tables are controlled through VBScript, so as long as VBScript can talk to the singal engine, all that needs to be changed is the script. This will also give knocker access to any VP table, not just those dependent on PinMAME. Theoretically, you could use that engine to drive solenoids and lamps on a real pinball table, using a PC running VPinMAME and/or VP....
--Chris
-
The problem is many recent machines don't have a knocker; they make the sound electronically.
Oh really?
-
Right, that should work in theory (not familiar with VBScript).
-
Pardon the newb question, but in order to hook up LEDs to this board will I need the resistors too (a la shawnzilla's offering) or will the board take care of all this?
-Steve
-
Pardon the newb question, but in order to hook up LEDs to this board will I need the resistors too (a la shawnzilla's offering) or will the board take care of all this?
-Steve
No resistors will be required. The board will put out 24 mA max per LED.
-
Pardon the newb question, but in order to hook up LEDs to this board will I need the resistors too (a la shawnzilla's offering) or will the board take care of all this?
-Steve
No resistors will be required. The board will put out 24 mA max per LED.
Are you sure???
Most LED's operate off of 2.1 V. The ones that are labelled for 12V operation have internal resistors to allow them to handle that voltage. With an I-PAC or Hagstrom, you have to add a resistor to allow the 2.1V Led to work at 5 V.
Are you saying your controller will output at 2.1V? Will it be selectable for other voltage outputs?
-
Pardon the newb question, but in order to hook up LEDs to this board will I need the resistors too (a la shawnzilla's offering) or will the board take care of all this?
-Steve
No resistors will be required. The board will put out 24 mA max per LED.
Are you sure???
Most LED's operate off of 2.1 V.
-
I know there's been plenty of talk about getting the player 1 and 2 start buttons to light, but I'm curious if any logic will be in place to implement the player 3 and 4 start buttons?
-
I know there's been plenty of talk about getting the player 1 and 2 start buttons to light, but I'm curious if any logic will be in place to implement the player 3 and 4 start buttons?
Hopefully yes. The more games I experiment with, the more complicated things are getting. For example, I just noticed that in Galaxian, the player1 and 2 lives counters swap when the players swap!
-
Just an update - Buddabing has given his BuddaBlessing (tm) ;D to the 40 LED driver board's PCB design. I have just placed and order for the test boards and expect everything to arrive in about 2 weeks. I expect to have the production boards ready to run very shortly after that.
When the test board is ready I will be more than happy to post the pics and results on the gamecab website, along with ordering info and all the rest. I am sure that Buddabing will also post his results here and on the GameCab website too.
Gotta run
Thanks again!!
Charlie
-
Woo hoo! Can't wait! :-)
-- Chris
-
Will this allow dimming or just switching of the LEDs, also, are they direct driven or matrixed?
-
Will this allow dimming or just switching of the LEDs, also, are they direct driven or matrixed?
There are 16 brightness levels. They are direct driven, not matrixed.
-
Will this allow dimming or just switching of the LEDs, also, are they direct driven or matrixed?
There are 16 brightness levels. They are direct driven, not matrixed.
Did support for four-lead tri-color LED's get in there, or do we just wire them as three separate LEDs?
--Chris
-
Will this allow dimming or just switching of the LEDs, also, are they direct driven or matrixed?
There are 16 brightness levels. They are direct driven, not matrixed.
Did support for four-lead tri-color LED's get in there, or do we just wire them as three separate LEDs?
--Chris
They have to be wired as three separate LEDs.
-
I don't know if this has been mentioned before but with buddabing's led controller and shawnzilla's clear transluscents it will now be possible to not only light up the buttons used by the game but with multiple colored led's in each button I don't see why we can't light up the button with the correct colors.
-
I don't know if this has been mentioned before but with buddabing's led controller and shawnzilla's clear transluscents it will now be possible to not only light up the buttons used by the game but with multiple colored led's in each button I don't see why we can't light up the button with the correct colors.
-
Cool! I thought maybe it had. Has anything been done to implement the functionality?
-
Cool!
-
It's a project started by SirPoonga to properly list what controls are used by each game. There was a need for it mainly due to the fact that the info output by mame is incorrect a good part of the time.
-
http://fe.donkeyfly.com
-
http://fe.donkeyfly.com
That was my next question, thanks.
-
It's a project started by SirPoonga to properly list what controls are used by each game. There was a need for it mainly due to the fact that the info output by mame is incorrect a good part of the time.
Partly due to the fact that MAME output is incorrect. Also b/c even if it is correct, MAME tells you
"This game uses Button 1, Button 2, and Button 3." Controls.dat tells you "Button 1 is FIRE, Button 2 is GRENADE, Button 3 is SUPER ZAPPER".
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 a request:
In Pacman & MsPacman, when you eat a power dot and the ghosts turn blue, I would like the button & joystick LEDs to flash in random patterns (to mimic the chaos of running ghosts).
-
When are these things going to be avaible :(
-
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.
-
When are these things going to be avaible :(
Well, I'm out of action with a tooth infection at the moment, but I hope to get back to it fairly soon.
-
In Pacman & MsPacman, when you eat a power dot and the ghosts turn blue, I would like the button & joystick LEDs to flash in random patterns (to mimic the chaos of running ghosts).
From the LSE point of view, you would need to find the memory address that signifies the ghost change & set this up in the watchpoint (.dat) file. This will send a signal to the light driver. That part is already possible.
It's then up to the driver to provide the effect, and let you associate it with the signal.
-
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.
It also needs to take into account the controller mapping for the particular game.
Example - Let's say I have buttons mapped as
4 5 6
1 2 3
7
For classic game I use the lower row of buttons, but for Neo-Geo, I use 7, 4, 5, 6. So for Neo-Geo, Button 1 = V, Button 2 = L Shift, Button 3 = Z, Button 4 = X.
Either the LSE or the driver needs to know how I have this mapped so it lights buttons 7, 4, 5, 6, instead of 1, 2, 3, and 4.
-
It also needs to take into account the controller mapping for the particular game.
-
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.
I thought Buddabing was taking care of this, but haven't been following in depth. One thing that would put a slight wrinkle in your logic is this scenario and it's pretty common.
I have button 1 wired up next to my 8-way, 4-way, and let's say trackball. They are all mapped to the same button. Either by configuration or parsing of controls.dat I would want the appropriate button lit for that game.
i.e. When playing centipede the button next to my trackball, Donkey Kong the button next to my 4-way, and for 8-way games the button next to my 8-way.
Just something to think about. The controls.dat is the reason I'm getting this, the rest is just icing for me.
Although, I think the rest is harder to implement, but it is pretty cool what you've been able to do. gl.tter I know you've posted some info on how you are discovering and figuring out some of this, have you thought about posting more info on this and how the other guy(Dr. Romz?) figured out his stuff? I thought you had mentioned he took a different approach. Obviously, I'm not talking about your implementation more of how you used MAME to figure out the signals.
-
I thought Buddabing was taking care of this, but haven't been following in depth.
-
Actually, I thought Buddabing was doing this since he has basically a controls parser and it's right up his alley. Plus I thought he mentioned. Sorry just talking to myself on this one. :)
As for the button mapping, I think I may have confused you. In my example all of those are physically connected to let's say the '7' key. In your example LSE mapping you said light one goes to button '7'. I would have three lights going to '7', but I wouldn't want every '7' to light up. Does that make more sense or do I need to go reread your posts?
-
Actually, I thought Buddabing was doing this since he has basically a controls parser and it's right up his alley.
-
Exactly and yes this is pretty common. I believe most people who have an additional 4-way do this, every slickstick controller, and more. I added the additional trackball just to make you think a little more and didn't hardcode it to 2 instead of one.
-
Hang on - are you saying that you in effect 'share' encoder inputs between several controls?
-
I think making each control light separately depending on the game is outside of the scope of your project. Anyone wishing to use the LSE would probably need to redo their wiring to fit. There are simply too many variations of control panels to try and make a product work "right out of the box" for each one.
I wouldn't give up on that yet - but it will depend on how the driver's get defined.
For example, let's say the 4-way and 8-way joysticks are connected to the same encoder inputs. MAME won't know which stick I use, but it does know (from controls.dat if not from -listinfo) whether the game is 4-way or 8-way.
There should be some way to put 4 LED's around the 4-way (numbered 1-4) and 8 around the 8-way (numbered 5-12), and tell the interface board to light LED's 1-4 for 4-way games and light LED's 5-12 for 8-way games, without re-wiring the panels.
But it's hard to tell how this is all going to play out.
-
Argh, just lost my reply.
Thanks for the info guys, I'm still new to the scene and assumed encoder inputs are never shared.
Saying that, the signals are fine - basically you need another set of instructions in a driver's light map file, specifying your panel layout. The driver can then work out which light to trigger.
For example, let's say the 4-way and 8-way joysticks are connected to the same encoder inputs.
-
That's the basic mapping support I would expect most light drivers to implement.
-
So correct me if I am wrong.
-
So correct me if I am wrong.
-
I know it contributes in no way to the technical discussion going on here (which is somewhat over my head), but I just wanted to thank both gl.tter & buddabing for their work on this amazingly cool project -- one which will be used by many, if not most, of the folks here on BYOAC!
Guys like me (lots of ideas but few electronics skills) really appreciate guys like you!
-- Chris
-
I just found this post, almost by accident today. I'm very interested in this controller for my computer case (It's for the case mod, but I play mame!)
Put me on the list as :
2. I'll buy it if it's not too expensive
1b. Controller capable of controlling 40 LEDs
2b. Just the populated circuit board
I did have a question however about 4-lead RGB LED's, these have a common ground line, will these be possible for use with the controller. From what I can tell the ground is what varies for the controller not the +5v side. I'd hate to scrap the LED's I already have.
Posicat
-
I just found this post, almost by accident today.
-
Hum, that might complicate things a little bit, I'm sure I can figure something else out. I'm looking forward to seeing the finished project, and the price.
I imagine I will pick one of these up, as I was going to spend the summer designing the same thing with a PIC chip. I'd be happy to keep the free time and spend some money :)
Also, you might want to look into alternate markets for these boards, I can see them fitting into more markets than just MAME consoles.
- Model Train layouts (to control building lights, and even sky-lighting effects for sunrise sunset.
- Case Modders, being able to control 40 individual LED's would make them smile (It will me)
Those are just the first 2 that came off the top of my head. I'd love to see a serial or even USB model of these controllers, my Linux machine has a 6 port-serial controller. I could decorate a whole christmas tree with individually controllable LED's.
-
I'd love to see a serial or even USB model of these controllers, my Linux machine has a 6 port-serial controller.
-
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.
-
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
-
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/
-
Ah, that's the name I use internaly on my network.
-
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 8)
-
Ah, that's the name I use internaly on my network.
-
Works here - just text and a couple pics, though, no cool led dash lights 8)
Connection refused from here.
-
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.
-
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.
Here's an example video. (http://cpmaker.mameprojects.com/files/output.avi)
-
Video doesn't work for me.
-
yep, unknown codec. What format is it?
-
yep, unknown codec.
-
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!
-
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
-
yep, unknown codec.
-
yep, unknown codec.
-
Right, thanks!
-- Chris
-
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.
Here's an example video. (http://cpmaker.mameprojects.com/files/output.avi)
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.
-
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.
-
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 :)
-
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.
-
Which is the worst way it can be done
Why?
hence why controls.dat exists.
-
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
-
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).
-
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.
-
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.
-
Various reason.
-
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.
-
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.
-
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.
-
But dial AND joy8way are defined IN mame which is the controls you use and map.
I think you've misunderstood me.
-
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...
-
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?
-
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?
-
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.
-
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.
-
Ahh yes.
-
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.
-
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 :)
-
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.
-
hmm, I might wait for all this to play out befor eI go on with my qbert knocker.
-
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 :)
There are some DLLs out there that make parallel port access transparent on any Windows OS - you could easily write a tiny light driver that just looks for the knocker signal, and sets a pport pin. I've written a light driver skeleton that makes this very easy - let me know if you want the code and binary to test with.
I know, but the reason they aren't transparent in NT based OSes is because it introduces security holes. And there are ways to access the port in both 98 and NT worlds, just a pain to do :)
Like I said in the qbert thread, not going parallel port since legacy ports are moving out and serial to usb convertors are cheaper than parallel to usb convertors, so in the future when my arcade computer doesn't have legacy ports it can still work.
I just realized the LED board is parallel porT? argh. I guess I am not getting that. Parallel port does not fit in my future plans. Especially since the mobo I am looking at only has USB and Firewire.
-
I know, but the reason they aren't transparent in NT based OSes is because it introduces security holes.
-
If you run Daphne, you are already running one of the DLLs which open up the parallel port. :)
After much experimentation, I decided to use the same DLL that Daphne uses. Why re-invent the wheel? Plus, Daphne includes the source code.
Sirp you must be looking at a small form factor box. Every motherboard I've looked at in recent memory has a parallel port on it. I'm using the parallel port for ease of design, ease of programming, and low cost.
If you want a USB controller, get Randy's. He hasn't said so, but I would be willing to bet that he will make his controller work with gl.tter's LSE code.
-
Any news on the prototype boards? I'm anxious to see how they turn out.
Some questions:
I read up on the controller chip, and I2C bus communication. I now have some projects of my own in mind.
Will these boards have an exposed I2C connection where other boards will be able to be attached?
Could these plug directly into the SMBus on a motherboard, instead of using the paralell connection?
-
Any news on the prototype boards?
-
Budda and I have pretty much gone over the prototype boards and picked out a few things that need to be changed.
-
Any new news on these boards? I'm anxiously waiting to see this working together with mame to light up the buttons a game uses, attract mode, etc on a cab... so I can finish designing my next cab and integrate this wonderful, wonderful toy.
-
Any new news on these boards?
-
Any new news on these boards?
-
For my part, I have done a lot of work on the LSE and my own driver for it (gl.tterFX!), but I've had a v. busy summer so it's been slowed down lately.
-
Hey, I'm still interested in the LED board and gl.tter's LSE. Are there any updates?
Thanks,
JD
-
Nothing yet. We didn't forget about you guys.
-
Still tied up in other things. I'm waiting on some parts for my panel though, when they come I'll be back on it.
-
Hey gl.tter,
Not that I'm impatient or anything, but would your LSE control other LED boards, like this one -
http://industrialcomponent.com/phidgets/philed64.html (http://industrialcomponent.com/phidgets/philed64.html)
-
I've been looking at this one, it looks great on paper and might be perfect for my driver. If it pans out I will probably support it myself.
The way the LSE works is that it spits out signals about things that have happend, eg. 'key a was pressed'. Then there's a 'light driver' that converts this info into actual light output. So a light driver has to be written for every board. I wlll provide code for anyone wanting to do this once I do a public release.
-
My own project hasn't gone so well, so I'm hoping your project is going better. It looks like it's been a few months since anything was posted, and I was just curious if there was any news.
-
There haven't been enough pre-orders to justify my ordering the parts as the board exists now.
I've redesigned the board in Eagle to make it smaller and cheaper. It's just a matter of getting some prototypes made. Once that is done, I'll announce something.
Price target on the redesigned boards is $49. Anyone who has already prepaid for their board will get a crisp twenty in with their package.
-
I didn't even know you were taking orders.
What do we need to do to order one? ???
-
I didn't even know you were taking orders.
What do we need to do to order one?
-
Do you have any eta on when it'll be done?