Main > Software Forum

Triggering a real knocker for Q*bert SOFTWARE SOLUTION

<< < (5/5)

RandyT:

--- Quote from: Howard_Casto on August 19, 2006, 10:25:52 pm ---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. 

--- End quote ---

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:

--- Quote from: Howard_Casto on August 19, 2006, 11:19:18 pm ---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.

--- End quote ---

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:

--- Quote from: Howard_Casto on August 20, 2006, 12:14:38 am ---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. 

--- End quote ---

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

Navigation

[0] Message Index

[*] Previous page

Go to full version