Buddabing's LED controller

[Buddabing]

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.

[Buddabing]

Idle animation during a game's attract mode - very good.

[gl.tter]

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.

[gl.tter]

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.

[gl.tter]

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.

[Lilwolf]

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

[gl.tter]

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.

[gl.tter]

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!

[RayB]

For the P1/P2 blinking when ready - Let's say 2 credits are added P1/P2 both blink and the player presses P1 start.

[gl.tter]

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.

[Buddabing]

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.

[gl.tter]

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.

[Lilwolf]

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!

[gl.tter]

As

[Popcorrin]

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.

[gl.tter]

(download updated to latest version)

OK, I've got something for you all to play with here.

[gl.tter]

There was a bug that stopped the flashing working correctly after a game had finished.

[millercentral]

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 base (which a lot of BYOC'rs use for their arcade-monitor cabs already) and enable integration with their script 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...

[gl.tter]

I don't want to be limited to AdvanceMame.

[gl.tter]

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!

[HoopstarsGarage]

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 

[gl.tter]

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.

[gl.tter]

New version is out - download it here.

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.

[gl.tter]

Anybody tried this yet?

[EndTwist]

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)

[gl.tter]

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?

[EndTwist]

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. 

[gl.tter]

Anyways, it'd be really cool to add this to other MAME versions.

[EndTwist]

Anyways, it'd be really cool to add this to other MAME versions.

[gl.tter]

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

[EndTwist]

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

[EndTwist]

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:

Code: [Select]

0:E02F:COPY : 0:CREDITS
Edit: Just got the address for Crush Roller (rom name: crush)

Code: [Select]

0:4C1E:COPY : 0:CREDITS
Burger Time (rom name: btime)

Code: [Select]

0:001D:COPY : 0:CREDITS
Now can I PLEASE have the changes you made so I can apply them to my copy of MAME? 

[gl.tter]

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.

[Buddabing]

Now can I PLEASE have the changes you made so I can apply them to my copy of MAME?

[gl.tter]

Dude, he hasn't even given them to me yet!

Dude, you haven't even asked .

[EndTwist]

C'mon! I'm not that patient! 

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

[ahofle]

This is absolutely awesome!

Can you make it flash the LED of the correct button to press in Chicken Shift?

[gl.tter]

Can you make it flash the LED of the correct button to press in Chicken Shift?

[gl.tter]

C'mon! I'm not that patient!

[EndTwist]

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.