Triggering a real knocker for Q*bert SOFTWARE SOLUTION

[Level42]

Sorry 'bout that wacky title but this covers it...

In another thread Howard_Casto proposed for a software solution for triggering a real knocker for Q*bert.

Here's what he wrote:

Well I played around with a solution today... it's either extremely smart, o extremely stupid, I'm not sure, but it works.

What I do is setup an external program that samples all open sound channels.  What it's doing is "listening" for the knocker.wav sample to be played. When it's played the event fires.  Considering how it shouldn't work at all (sound is too variable)  I was suprised to find it worked 100% of the time with my tests.  It seems that the knocker sound has a very flat ending (all the sample levels are complete 0's) which is very odd, so odd that this the is only noise in the game that does it.   I could easily crop the sample as well so that only the flat part is played (which is inaudible).

Of course you wouldn't want this running all the time, but my app will support more than qbert and check for the current running rom, so it would only run when qbert is active.

pm me and i'll send you a test app later on in the week to play with.

My response:

So if I understand correctly you won't actualy hear the knocker.wav through your speakers ? That would be essential.

And how do you manage the output signal ? Personaly I would still like to see the Caps lock led triggered. Since I'm using a J-pac it's the easiest way to get the trigger signal out of the PC for me.


Also, would it be possible to cut-off some of the other sounds. Apparantly coily and Q*bert scream "too long" in mame.

Check out http://members.cox.net/brado426/QMAME

Here it is mentioned that:"Coily and Q*BERT now stop screaming the minute the knocker triggers

[Howard_Casto]

The scream isn't an issue anymore.  How mame does it now is the "fall" sample is played, immediately followed by the knocker sound.   Qmame was made ages ago... the sample timing was cleaned up around .101


I'll have to supply a custom sample, but it should be possible to make a silent sound that still cna be detected.  Right now I'm actually checking for teh absence of sound at the beginning of the sample, so crop it and it'll be good.  See this thing works by "recording" a stereo mix of all the sounds going on in your computer.  What a lot of people don't know is that when nothing is playing, your pc has a great deal of "white noise" floating around.  On my pc it's around 145.  But when a sound is played it cuts off all the chatter, so even a blank sound is real easy to detect from bg noise as it gives off a value of 0.  Also since I'm looking for "dead air" volume and sample rate don't matter.  0 is still 0 

Right now I'm whittling down the sample rate so that it'll even work on low end computers.  I started at 44100khz and I keep lowering the rate and testing.  So far I haven't ran into an issue of it not working so I'll keep going until it breaks.

Output is your choice.  The next release of j5 (which will hopefully come out this wekend) will have support for multiple-ledwizzes, two parallel ports and the keybaord leds.  I've made it in module form, so I can just drop it into this proggie. 

I wouldn't reccomend the keyboard keys though especially the caps lock... let me explain:  As you know lots of games use the keyboard leds.  Their order is numlock, capslock, scroll lock. Numlock and capslock are used a ton, as insert coin lights.  While I can technically block a key quite easily, I don't reccomend it.  If you hook up your knocker to the capslock key you'll have to disable all led input for all other mame games as the least any led-enabled game uses is two.  You might want to eventually wire your coin door lights to these leds.  Scroll lock... not used so much so if you are going that route, use the scroll lock key.  It's only used for some daphne games warlords, and maybe two others.    Plus the scroll lock key is useless for typing as well.  I don't even think it's used for anything anymore.  So if you need to plug in a keyboard for maitenance you aren't going to be accidentally firing your knocker. 

[AaronGiles]

Wow, you sure are going to a lot of trouble to make this work.

I'd propose instead that you consider opening up a discussion about how to handle outputs from MAME in a more generic fashion. I've been thinking about how to support outputs both in the artwork (for visual ones) and for external support. The idea is to enhance what is already present in the rendering system and use names for outputs, and have values that they can be set to. For on/off type things, it would be set to 1 or 0. For items with variable values (like lamps that can have different brightness values), it would be some number from 0..65535 or something.

For external support, it would be OSD dependent obviously. On Windows, I would probably do the simplest thing and register for a new event and then just broadcast that event each time the output changes (perhaps throttled to same maximum rate). An external program could just listen for that event and do what it needs to do in response.

The goal would be to remove the keyboard LED crap from MAME proper and just post outputs this way. Someone else could write a standalone program that replicated the keyboard LED behavior (would be simple to do) if that's what was desired, or those LEDs could be routed to proper LEDs. There would be generic names for these ("led1", "led2", etc.) so they are easily tracked.

For Q*Bert, you'd just need to pick some name (like "knocker") and listen for the event that sets the "knocker" value to 1, and trigger your external item there.

Does this seem reasonable? It would also help MAME better document outputs in general. Right now, it doesn't do a good job because there is no common routines to call within MAME to signal the value of an output, so most of the outputs are just left dangling.

[Buddabing]

The goal would be to remove the keyboard LED ---meadow muffin--- from MAME proper and just post outputs this way.

There have already been attempts at this. A BYOAC user named gl.tter (he has since left) contributed some code called the "Light Signal Engine". It was very elegant. I incorporated his code into BuddaMAME.

Basically, the core or game drivers define "events", which get triggered during the course of program execution. An event can be a light turn on, flash, an animation playing, or the Qbert solenoid firing.

You could even define "triggers" which happen when a memory location meets certain criteria.

The code is able to control the keyboard LEDs or the custom LED controller that I designed. It is abstract enough so that any LED controller can be used, or a remote control solenoid for Qbert, or whatever.

I would be very happy if the keyboard LEDs were abstracted to the OSD, even if the LSE was not put into MAME. It's a big pain to hack the various points where the keyboard LEDs are used.

[Level42]

Guys.......I just want my knocker to work 

Don't care about all the other stuff....

I'm not into the blinky-blink Led-wizz stuff (yet)......

[Dav]

Wow, you sure are going to a lot of trouble to make this work.

I'd propose instead that you consider opening up a discussion about how to handle outputs from MAME in a more generic fashion. I've been thinking about how to support outputs both in the artwork (for visual ones) and for external support. The idea is to enhance what is already present in the rendering system and use names for outputs, and have values that they can be set to. For on/off type things, it would be set to 1 or 0. For items with variable values (like lamps that can have different brightness values), it would be some number from 0..65535 or something.

For external support, it would be OSD dependent obviously. On Windows, I would probably do the simplest thing and register for a new event and then just broadcast that event each time the output changes (perhaps throttled to same maximum rate). An external program could just listen for that event and do what it needs to do in response.

The goal would be to remove the keyboard LED ---meadow muffin--- from MAME proper and just post outputs this way. Someone else could write a standalone program that replicated the keyboard LED behavior (would be simple to do) if that's what was desired, or those LEDs could be routed to proper LEDs. There would be generic names for these ("led1", "led2", etc.) so they are easily tracked.

For Q*Bert, you'd just need to pick some name (like "knocker") and listen for the event that sets the "knocker" value to 1, and trigger your external item there.

Does this seem reasonable? It would also help MAME better document outputs in general. Right now, it doesn't do a good job because there is no common routines to call within MAME to signal the value of an output, so most of the outputs are just left dangling.

Yes, I'd like to see something like that.  I'd like to be able to hook up all the outputs of T2: gun recoil,guns LEDs, and artwork lights if I wanted.  They're all kind of the same thing, so grouping them together makes sense to me.

[Howard_Casto]

Wow, you sure are going to a lot of trouble to make this work.

I'd propose instead that you consider opening up a discussion about how to handle outputs from MAME in a more generic fashion. I've been thinking about how to support outputs both in the artwork (for visual ones) and for external support. The idea is to enhance what is already present in the rendering system and use names for outputs, and have values that they can be set to. For on/off type things, it would be set to 1 or 0. For items with variable values (like lamps that can have different brightness values), it would be some number from 0..65535 or something.

For external support, it would be OSD dependent obviously. On Windows, I would probably do the simplest thing and register for a new event and then just broadcast that event each time the output changes (perhaps throttled to same maximum rate). An external program could just listen for that event and do what it needs to do in response.

The goal would be to remove the keyboard LED ---meadow muffin--- from MAME proper and just post outputs this way. Someone else could write a standalone program that replicated the keyboard LED behavior (would be simple to do) if that's what was desired, or those LEDs could be routed to proper LEDs. There would be generic names for these ("led1", "led2", etc.) so they are easily tracked.

For Q*Bert, you'd just need to pick some name (like "knocker") and listen for the event that sets the "knocker" value to 1, and trigger your external item there.

Does this seem reasonable? It would also help MAME better document outputs in general. Right now, it doesn't do a good job because there is no common routines to call within MAME to signal the value of an output, so most of the outputs are just left dangling.

Well I didn't know you were willing to add it.  I can throw around ideas for you guys, but I'm not good enough with the mame source to actually make a universal function.  Of course I've noticed that with the recent changes the source is almost read-able.    I have a few thoughts:

There's the "do it right" method and the "do it now" method from where I'm thinking.  

The "do it now" is fairly easy.  All ports of mame have a caption right?  Well just tack the light status onto the caption of the window and let the people writing output interfaces deal with the rest.  

So MAME:  Gorf[gorf]  would become

MAME:  Gorf[gorf] outp:0,0,0,0,0,0

or possibly

MAME: Gorf[gorf] outp:0   with the values 1-6 representing the six lights and 0 being off.  

"Dangerous" outputs, like knockers could even be given a different heading like MAME: Q*Bert[qbert] sol:0


Getting a caption from mame is really easy because it has the window class of "MAME" so just have an app read the caption periodically and you are done.  This might have benefits over an event message in that you could use the same code regardless of the os port.  Of course it'll probably be slower.  


It would be easier to code on the mame end because it wouldn't matter what type of output it is or even what format it's in.  For that matter, set_led_status could simply be replaced/rerouted to set_caption_status.
If course this isn't the most documentation friendly solution I'm sure but if the hassle is in the coding, it's an option.  

Another way to do it would just be to do the ctrlr files in reverse and have them bind to output ports (which from my understanding would just be memory addresses just like input ports defined in a driver, just read instead of write) the same way.  Then you could use the event handling method, exactly as you described.  The key would be to modify listxml (yet again) to output all possible output names so external programs aren't in the dark on what they are supposed to be looking for.  


I think we can all agree that aside from maybe controlling the keyboard leds directly the actual app/dll/ect to control the device needs to be externalized.  There are just too many options on how to output data from a computer and to say "this device and this method is supported, but this one isn't"  would merely limit outputs again.  People wanting to do something insaine like mame a galaxy force cab, wouldn't be able to unless there was a method presented that would allow them to do whatever they want with the data, not just fire it through the parallel port or turn on some ledwiz outputs.  

Constants shouldn't be hard if that's the route you wish to go:

Start1-Start6 for games like digdug that blink the volcano buttons.  

Coin1-Coin6 for games that flash the coin door lights.

Rank1-10 for games with rank lights.

Light1-60 (purposefully really huge amount) for misc lights

Solenoid1-10 for knockers, blowers, ect... anything that could be damaged (or annoying) if it were left on for more than a second.

Analog1-60 for anything like linear actuators, hydraulics, ect.

Digital1-60

And possibly a constant for stuff that is known to do something, but nobody knows how it does it.  

like

Raw1-60

Raw could be used initially and as more about the data is learned, it can be split out into individual outputs.  

You might want to get a little fancy too.  You've got games like turbo that have digit displays.  You could make a output for each individual line segment, or even each individual digit but it might make more sense to have text constants, where the event just sends the score.  

Of course you have the mahjong pron games with the lcd screens.  You could probably do something with that too, I just don't know why you would want to

The only issue I see with this is if you are going for accuracy, the only constant you really need is raw in most cases.  Gorf for example is just an 8bit array, not different addresses for each light.  On the machine I guess there's a chip that slipts out all this data into the 8 output signals (yes I said 8, have no clue what the other two do but there are even pins  and relays on the light board for it).  A function would have to be made for every single game with outputs that splits the data into chunks the output function can use (similar to how it's done in the artwork code now).  We'e got a lot of games like afterburner, where we sorta know where the data is but don't have a clue what it does or how it does it.  


Just random thoughts.  


Level42, sorry for hijacking here.  I'm still more than willing to make you a little app just for qbert.  The thing is my proggie was going to be a universal solution and you brought up qbert so I mentioned it.  

Budda.. can you send me specs on your parallel interface (forgot to ask, sorry)?  I'm trying to get j5 to support frikkin everything and I'd like to add code for it.  

[AaronGiles]

Basically, the core or game drivers define "events", which get triggered during the course of program execution. An event can be a light turn on, flash, an animation playing, or the Qbert solenoid firing.

Sounds like an abstracted form of what I am proposing. I don't want to go that abstract, though (meaning the whole watch a memory location stuff). Only legitimate outputs should be exposed this way. And I won't expose coin counters, though that's a common output.

I would be very happy if the keyboard LEDs were abstracted to the OSD, even if the LSE was not put into MAME. It's a big pain to hack the various points where the keyboard LEDs are used.

They are already abstracted to the OSD layer today. But the goal would be to move them outside of MAME entirely, and handled by a separate application that just listens for the events. Which means no more hacking MAME to get the info.

[AaronGiles]

There's the "do it right" method and the "do it now" method from where I'm thinking.  

Skip "do it now" -- it's not that urgent, and not that hard to do right, so let's just do it right, shall we?

I think we can all agree that aside from maybe controlling the keyboard leds directly the actual app/dll/ect to control the device needs to be externalized.

If I do this, even the keyboard LEDs will be externalized. I'm tired of maintaining that hack in the main build.

There are just too many options on how to output data from a computer and to say "this device and this method is supported, but this one isn't"  would merely limit outputs again.  People wanting to do something insaine like mame a galaxy force cab, wouldn't be able to unless there was a method presented that would allow them to do whatever they want with the data, not just fire it through the parallel port or turn on some ledwiz outputs.  

Agreed. Each event that is fired should have 2 parameters: output name and output value. These are defined by the driver, though common things like LEDs should have standardized names. External apps can listen for these events and perform some action based on the name of the output. How that particular output maps to connected hardware would be completely up to the external application. There are just too many specialized possibilities that it would only create an insane clutter to try and handle that in MAME directly.

Constants shouldn't be hard if that's the route you wish to go:

These are good starts for standardization of the names. I would also want to include the internal LEDs on PCBs in the list, as well as digital score displays (like Turbo). You guys have been trying to hack into MAME so long that you seem to keep thinking about how to get the raw memory bits and convert them yourself. There needs to be support in the driver to send you the outputs. This is all to the good, as that is the best way to document what is happening.

[horseboy]

I also have very strong opinions on this....


















 

[Howard_Casto]

I also have very strong opinions on this....



 

ROTFLMAO!

Man I must be tired cause that came off as hilarious to me. 

Aaron I think this is one of the few times were are in complete agreement.  Everything you are talking about sounds good to me. 

I often wondered about the keyboard led support myself.  It seems like an awful lot of work (what with the three possible methods to do it depending upon the os/ect) to light 3 lights, especially considering the only way to do anything "mameish" with the lights is to use a keyboard encoder and output em.  Which basically means if you aren't using an ipac, you aren't going to have access to those outputs anyway unless an external app is sniping for em.  It's real easy to do externally anyway, if people complain I can have a windows app for em in a day that'll do it. 


I forgot about pcb lights... are those documented in mame?  I know I've seen em on the actual boards but I don't recall running across them in the drivers. 

[horseboy]

I also have very strong opinions on this....



 

ROTFLMAO!

Man I must be tired cause that came off as hilarious to me. 

No, it wasn't cause you were tired, it is because it was hilarious.

[Dav]

I forgot about pcb lights... are those documented in mame?  I know I've seen em on the actual boards but I don't recall running across them in the drivers. 

Like most things in mame, some are and some aren't.  Ideally they all will be.

[AaronGiles]

On Windows, I would probably do the simplest thing and register for a new event and then just broadcast that event each time the output changes (perhaps throttled to same maximum rate). An external program could just listen for that event and do what it needs to do in response.

The goal would be to remove the keyboard LED crap from MAME proper and just post outputs this way. Someone else could write a standalone program that replicated the keyboard LED behavior (would be simple to do) if that's what was desired, or those LEDs could be routed to proper LEDs. There would be generic names for these ("led1", "led2", etc.) so they are easily tracked.

For Q*Bert, you'd just need to pick some name (like "knocker") and listen for the event that sets the "knocker" value to 1, and trigger your external item there.

So I went ahead with this plan and implemented it the other day. It got a little more complicated than I initially thought because you are pretty limited in what you can pass between applications using Windows messages, but I got it working pretty well. The LED code is no longer in MAME. Instead I created a sample code application called ledutil.exe that you can run in the background. It listens for the "led0", "led1", and "led2" outputs, and controls the keyboard LEDs that way. You can also use that code as a starting point for more complex output management.

Any lamp or other item that is currently controlled by artwork will be output this way, for free. So the Gorf lamps, the Turbo score LEDs, the Atari Football lights, etc. all will be available immediately. I wouldn't mind getting input on what the names of the outputs should be. Howard had some good suggestions for standardization that would be a good starting point, but we should visit each game that uses them currently and make sure they are being output consistently. Anything that controls the LEDs using the old mechanism also works for free with the new system.

Oh, and I went ahead and added an output for the Q*Bert knocker, since that's what triggered this discussion. When it fires, you should be able to get a notification from an external app and do whatever wizzy thing you wish.

[Howard_Casto]

Sweet man!  Keep us posted and let me know if there is any way I can help.

[RandyT]

So I went ahead with this plan and implemented it the other day. It got a little more complicated than I initially thought because you are pretty limited in what you can pass between applications using Windows messages, but I got it working pretty well. The LED code is no longer in MAME. Instead I created a sample code application called ledutil.exe that you can run in the background. It listens for the "led0", "led1", and "led2" outputs, and controls the keyboard LEDs that way. You can also use that code as a starting point for more complex output management.

Aaron,

I'd like to start by saying the usual, "Thanks for all that you do" and this applies in spades for this addition.

But I'd also like to make the observation that the communication scheme seems a little unnecessarily complex.  If I understand correctly, the following is approximately what happens (CAUTION: I'm big on metaphors. )

1: MAME broadcasts an "open for business" message to everyone in the world.
2: MAME waits for interested customers to subscribe to the service
3: MAME then sends a "gizmo" without telling the customer what it is.
4: The customer then asks MAME what the "gizmo" is.
5: MAME then identifies the "gizmo"
6: The customer then remembers the name of the "gizmo", in case MAME sends another one.
7: If the customer doesn't want anymore "gizmos", it can "unsubscribe" at any time.
8: When MAME closes shop, it sends an "out of business" message to everyone in the world.

So, I guess my question is: why so many steps?  Why not use the following (more metaphors);

1: MAME looks for customers who have already expressed interest when it "opens for business"
2: MAME sends them the "gizmo", with everything the customer needs to know about it.
3: The customer can lose interest at any time.
4: MAME can inform only it's interested customers that it is "out of business."

or, in less abstract terms;

1: Use the FindWindow API function to find open (but most likely hidden) windows  with a very specific name. IE. MAME Output Receiver
2: Use the FindWindowEX API function to get the handle of the only textbox on that form and use the SendMessage API with WM_SETTEXT to send the output name and state information to it.  This will trigger a text change event so that the the outputs can be acted upon by the 3rd party software/hardware.
3: The client can close the "MAME Output Receiver" window when it is no longer interested in receiving output data from MAME (or just stop acting on it.)
4: MAME can send a "MAME Exit" command to all open "MAME Output Receiver" windows to allow them to reset, if required.

Is there some major functional disadvantage to the simpler approach that I'm not seeing?

Thanks,
RandyT

[AaronGiles]

Is there some major functional disadvantage to the simpler approach that I'm not seeing?

Yes, you will lose signals with your proposed approach. What happens if multiple outputs are changed at the same time? We will try to change the edit box text twice and lose the first input. Or what happens if the listener app doesn't get around to noticing the change before another change happens? Without any kind of acknowledgement cycle, you will lose inputs your way. And adding an acknowledgement system will just complicate it back to about the same level the current system is.

You could argue that the problem might be avoided by using SendMessage, which waits for the message to be processed, but I deliberately don't want to do that because then MAME would be stuck waiting for some other application to do something. The current model from MAME's perspective is very easy: fire and forget, completely asynchronous except when an ID to string mapping is requested, which should only be the first time a signal is reported.

Also, FindWindow only has a means for you to locate one window. What if multiple clients want to be supported? That's why I prefer that clients contact MAME to register when they come up. The current implementation supports multiple clients.

[Howard_Casto]

Agreed.  I can see the people complaining when they can't get "application x" to work only to discover that they installed your ledutil in the startup folder.  This way lots of stuff can interface at once. 

Still having trouble with the copymemory part though, it might be vb thing, I don't think it likes the dataformat you've saved the string in. 

I've gotta agree with randy on the settext thing.  I don't think it should be used constantly, but immediately upon bootup mame should send registered clients all the output names followed by their id numbers.  Since the game hasn't started yet, it shouldn't effect emulation.  Also remember, that you can also send settext to the commandline string, so no textbox necessary. 

As-is it seems to cause some minor issues. For example, say you are handling warlords.  All the lights flash at once, so when you get the first light you ask mame for the name and it seemingly "forgets" about the rest.  So for the first flash or two you don't get a totally accurate output.  This only happens with games that flash stuff quickly, unfortunately most do flash stuff quickly.

At the very least, when mame sends that startup call it would be nice to get the total number of outputs along with that hwnd message, then an array to store the data can be built and filled as input changes come in. 

[RandyT]

Is there some major functional disadvantage to the simpler approach that I'm not seeing?

Yes, you will lose signals with your proposed approach. What happens if multiple outputs are changed at the same time?

I had thought that perhaps a single string representing multiple outputs could be used, somewhat along the lines of what Howard had suggested earlier.  This approach allows for output changes to be reported in parallel, rather than serially.

We will try to change the edit box text twice and lose the first input. Or what happens if the listener app doesn't get around to noticing the change before another change happens?

I can understand that concern, but I would hope that the listener app would be fast enough to catch the commands and perhaps spool them if it was necessary.  If the app were slow enough to miss commands, I'd have to wonder if the output states would continue to have relevance due to the lag in the app actually being able to act upon them. 

Also, is it possible for an application to receive a system message so quickly that it fails to execute the code that is programmed to fire when the event is triggered (IE.a Text_Change event?)  Are these not queued as well?

The current model from MAME's perspective is very easy: fire and forget, completely asynchronous except when an ID to string mapping is requested, which should only be the first time a signal is reported.

I agree that whatever the solution, it should be "fire and forget" from the perspective of MAME.  I would also like to second the idea of getting the ID definitions out of the way before game time.  I had thought that perhaps MAME could generate a file on demand with all currently defined outputs and their associated ID's for import into the listener software ahead of time.  I don't really know if that approach is tenable, but there would be no surprises or need to interrupt flow.

Also, FindWindow only has a means for you to locate one window. What if multiple clients want to be supported? That's why I prefer that clients contact MAME to register when they come up. The current implementation supports multiple clients.

This is true.  I suppose each listener app could use a specific prefix to identify it and a unique suffix (app name) to differentiate it, but it might be a trick to get all of the window names and find the ones of interest.  I'm not well versed in low level OS function, so I don't know for certain what is even possible there.  Just thinking out loud in case anyone finds any value in it....

RandyT

[Howard_Casto]

Randy I've been testing and some of the games send data insainly fast.  I mean insainly fast, like 1ms, possibly less fast.  Particularly the games with flashing coin lights like digdug.   I think making an app that would be too slow to keep up, even with buffering is more likely than you think. 

Which is why I was concerned about the current method of getting the id tag after the fact. 

I'm wondering if this step is even necessary.  I know nothing is standardized YET but might it make more sense to have the idnum for led1 be the same for every game and just include a id3tag-like list of all the possible names based on the idnumber?  You are using a 5 digit number, so it isn't like we are going to run out of tags.  More could be added as more types of labels are added. 

[RandyT]

Randy I've been testing and some of the games send data insainly fast.  I mean insainly fast, like 1ms, possibly less fast.  Particularly the games with flashing coin lights like digdug.   I think making an app that would be too slow to keep up, even with buffering is more likely than you think. 

Crazy.  Why would a flashing coin light need to be updated 1000 times a second.  Are we talking PWM here?  And, how long is it going to take for buffers to overflow when that kind of data starts backing up (IE. comes in too fast to handle it in real time?)

I'm confused, but it won't be the first time.

RandyT

[Howard_Casto]

It isn't.... it's more like once every half second the light is turned on and then immediately turned back off.  That isn't exactly as fast as 1 ms, but you've got the other light, which apparently has approx a 1ms offset from the first so that they blink out of sequence.  So it isn't going to kill the buffer, but it's too fast to doddle with extranious functions going on in the background.

[RandyT]

It isn't.... it's more like once every half second the light is turned on and then immediately turned back off.  That isn't exactly as fast as 1 ms, but you've got the other light, which apparently has approx a 1ms offset from the first so that they blink out of sequence.  So it isn't going to kill the buffer, but it's too fast to doddle with extranious functions going on in the background.

Ok, I'm seeing what you are saying, but now it doesn't seem so fast anymore.  If MAME limited outputs reporting to 5ms intervals, that quick transition would be eliminated by reporting both events in parallel.  But in the grand scheme of things, this may not be acceptable.  I don't know because I don't have a clue if there are outputs that require timing that is so critical.

I guess I was a little fuzzy about whether MAME would actually be allowed to overwrite the last WM_SETTEXT before the event that it triggered was serviced.

But, I can see the advantage of the current method in that the messages are queued and that each process has it's own queue (except in the case of  WM_COPYDATA, which apparently talks directly to the process.)

RandyT

[Howard_Casto]

Well there are games like afterburner and stuff.  They aren't hooked up yet but they are constantly spewing out data.  Of course that data would have to be translated into ff anyway, so I dunno.  If a person was willing to merely direct stream the data into the individual motors then it would probably be ok as no processing would be involved. 

One that I'm interested in personally is rail chase.  Apparently it had two hydrolic pistions on either side of the bench that fired in rapid succession to simulate going over train tracks.  I could see a person making a smaller scale version by taking some hi-powered solenoids and mounting them to the bottom of a stool or chair.


Of course there is terminator 2 as well. I think those pins are actually documented, they just aren't hooked up yet.  You've got the kick back on the guns, the flashing lights, and something else, I can't recall.  Anyway, it works plenty fast. 

[RandyT]

Well there are games like afterburner and stuff.  They aren't hooked up yet but they are constantly spewing out data.  Of course that data would have to be translated into ff anyway, so I dunno.  If a person was willing to merely direct stream the data into the individual motors then it would probably be ok as no processing would be involved. 

One that I'm interested in personally is rail chase.  Apparently it had two hydrolic pistions on either side of the bench that fired in rapid succession to simulate going over train tracks.  I could see a person making a smaller scale version by taking some hi-powered solenoids and mounting them to the bottom of a stool or chair.


Of course there is terminator 2 as well. I think those pins are actually documented, they just aren't hooked up yet.  You've got the kick back on the guns, the flashing lights, and something else, I can't recall.  Anyway, it works plenty fast. 

I would say that in relative terms, everything but the direct streaming of FF data to motors is really slow.  However, the time between when Piston A and Piston B change directions is probably instantaneous.  Again, I think this underscores a possible disadvantage with a sequential system.  Most data will be of an On - Wait - Off variety, with the Wait being a fairly managable period of time.  The difficulties seem to be more related to reporting single states sequentially, as the very short time requirements seem to be between outputs that change simultaneously with the real hardware (like an 8-bit register that gets a value written to it and it affects 8 outputs all at one time.)

RandyT