Software Support > PowerMAME
What's next
Howard_Casto:
--- Quote from: JoyMonkey on February 27, 2006, 06:56:09 am ---
--- Quote from: Howard_Casto on February 27, 2006, 01:20:15 am ---Making blinky lights go off when you insert a coin generically is cool and all but why not use all the light outputs on the ledwhiz to power outputs in emulated games (lights solenoids, actuators, step motors, ect...)?
--- End quote ---
Correct me if I'm wrong, but isn't this what the lighting events engine is for? It only supports the Q*bert solenoid right now, but is still in its early stages.
--- End quote ---
I wouldn't know, but afaik mike just took the old qbert led hack and modified it to work with his interface. I don't know if the original qbert hack actually uses a memory address in the rom's driver or not. If not then it's not arcade accurate and needs fixed. Not that I necessarily know how to do that mind you, I'm just saying.
Howard_Casto:
I think this is my clearest rant/explaination.... check out the last entry:
http://forum.arcadecontrols.com/index.php?topic=41092.0
Silver:
--- Quote from: MikeQ on February 26, 2006, 09:32:36 pm ---Okay, I'm running low on things to do. I've got a lot of what "I" want done, finished. Need help prioritizing our proposed features and expanding the proposed list with new ideas.
Also, on the Wiki, when a proposed feature gets implemented, do we move it to the "next release" section. Once we release it, do we move it again to the current features?
Let me know.
--- End quote ---
You have been busy! Looking at the wiki proposed features, I'm sure different people will want different things implimented next. For example, I am very keen on dual mouse support - this has never working (in windows) in mame, only analogmame/advancemame. Analogmame last worked back in v0.8, and advancemame has other issues (for me). Other peoples view may differ....
However, I have no idea how hard an addition it would be. I'd also give a vote for sorting out the gear change inputs - I suspect they have a high annoyance factor though as it will be looking at individual drivers. As is Offscreen Lightgun Reload I suspect...
EDIT: I think the ssf patch would be pretty easy to add...
JoyMonkey:
--- Quote from: Silver on February 27, 2006, 08:55:09 pm ---EDIT: I think the ssf patch would be pretty easy to add...
--- End quote ---
Speaking of the SSF patch, did you read the article by SA Dev (the guy that originally made the ssf patch) on RetroBlast last week?
http://www.retroblast.com/articles/winmamemon_1.html
He mentions a lot of video tweaking ...er... tweaks that are included in his collection of patches. I wasn't aware of them before and they might be worth looking into. Actually, maybe we should ask SA Dev if he'd be interested in putting a little time into PowerMAME.
Seeing as how Mame is going under some major changes right now, it wouldn't surprise me if the standard ssf patch won't work with the next few builds. And if save states are about to be fixed on all games, ssf will become redundant soon enough anyway.
MikeQ:
--- Quote from: Howard_Casto on February 27, 2006, 06:05:47 pm ---Too many quotes for me to manage let me just go down the list:
I know that it's possible (an output is an output) I meant it's time to start supporting it. Blink patterns would mean nothing for non led output as they would't be linked to gameplay.
Yes it's actually in the driver code, but luckily in many cases it's already linked to set_led_status, a null input (for documentation purposes) or the artwork code (to turn on "lights" on false bezels). Getting the data from the driver is actually quite easy, it's just a function needs to be written to take the data and use it to turn on/off the outputs (just like set_led_status does now).
Heh, you must not know what I mean. What interfaces? I mean direct connections to keybaord lights and the parallel port. The Keyboard leds are easy, the set_led_status function is already written in mame, but the drivers are hardcoded in that they choose which keyboard light represents which game output. That needs to be changed to something generic. As for the parallel port, it's a straight shot. There are 8 pins on the parallel port (I don't have them off hand but it's easy enough to find) each pin represents a different output port that can be turned on and off with a simple write to the parallel port. The "interface" consists of some wire, 8 220 ohm resistors (actually not needed, but for safety's sake) and some sort of terminal block to take the wires from a lpt connector and patch them into your leds/relays/whatever. The cost is about 1.50 to 5 bucks, so that's a non issue.
The beauty of adding solenoid/actuator/whatever support is that you don't need the hardware to write the code. You just need a led to test with as all of these devices are simply digital on/off devices with a few exceptions. Since only people using the actual arcade hardware would be using anything other than lights anyway, they would alredy possess the necessary pcbs to ramp up the signal.
To give you an example: I have a gorf machine with the 6, 12-volt, rank lights. The lights are on their own controller pcb seperate from the game boards. Upon close inspection of the pcb it's merely a bank of 12v relays that are actived by a ~5- volt signal. Most games with output are like this so that high-voltage doesn't have to go through the logic boards. The singal is 5 volts, which means I could wire my gorf light pcb directly to an ledwhiz, parallel port, or even the keyboard led output block on an ipac to the pcb.
Qbert is the one notable exception, but most stick to this low voltage principal.
--- End quote ---
So it looks like each game would need a cfg file for this approach since some games might do a set_led_status(0, on) for a start button but another game might consider led 0 to be some other led/whatever. Is this right?
It seems that they way the set_led_satus is written, the first parameter is just a number that represents an LED. If you considered this a virtualized enumeration, then each game could have a map file that maps this virtualized enumeration to a specific physical ouptut. This way virtual enum 0 could be a start button on one game while being some other light on another game. The only drawback is someone needs to go figure out what all these lights really did.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version