wrote in message
oups.com...

Also, another idea involves aiming for the larger 27/60th of a second
window that the prizes do have an equal chance of occurring, thereby
effectively cutting out the register numbers of 28 to 31. This of
course would be much easier to do, and automatically adds about 31,000
points to one's average score.

What would occur to me first is to replicate the game on a PC and build
whatever timing or scoring you need into the PC software.

N

[Perhaps drop the newsgroup that isn't sci.electronics.design]

wrote:
[snip scoring and anomaly stuff and prize %'s]
patterns that run from before the appearance of the first prize to
after the appearance of the second, the exact time the first prize
appears, what it is,and possibly it's travel pattern will make it the
reference for determining what adjustment/s will have to be made before
the second prize appears.

***So the last joystick movement before the dot that triggers the
second prize will be the key.

Since our maze patterns have a lot of pauses, the possibility of
resuming motion at the exact same time a particular second on the
display clicks over is doable with some accuracy above and beyond
rolling the dice.
....
As far as drift in the game's hardware timimg, this has already been
considered. But still adjustments can be made by noting the first
specific prize, and then making adjustments for the second prize.
....

I didn't see where game hardware timing drift was considered.
Did I overlook something about drift in what you wrote?

Anyhow, this timing problem looks complex enough -- it looks like the
timer may need to slightly speed up or slow down, or to keep track
of scoring and joystick events -- that the best approach would be
a PC- or micro-based timing program. Let PTP="PC timing program".

You want PTP to provide a seconds metronome, to signal the Banana
zone of each second. To make it actually work, I think PTP would
need to know timestamps and values for your joystick inputs and
for scoring. (See * re getting this info.) With that data, PTP
can get syncronized and accomodate for drift. For example,
suppose you do some joystick movement x and then 5 cycles later
the score goes up 500 points; this tells PTP Orange was on the
bonus timer 5/60 seconds ago. After a while PTP can figure out
where Ms.Pac-man is in its 0...31 bonus timer cycle. If, 123
seconds later, Orange is showing up a cycle early relative to PTP,
then PTP increases its per-second delay count by 1 part in 60*123.
PTP should have an adjustable reaction-time offset for different
players. PTP probably should start with a half-minute or so
synchronization phase, and re-sync whenever player tells it to.

* Getting event data: Of course you could set up a board with
several pushbuttons on it and enter data that way, or have an
assistant do so. This might work if you don't have to sync very
often. Also you could attach mercury-switch sensors to wrists
or perhaps to an elastic band that fits on the joystick. For
definitive scoring detection, aim a TV camera at the screen
area where score appears, and decode it in real time. Or if
the game is running on the same computer as PTP, your program
can monitor some bytes of screen memory.
-jiw

Incidentally, regarding the $49 ebay item
http://cgi.ebay.com/ws/eBayISAPI.dll...tem=7526393893
(Datum bc620AT ISA time and frequency counter card) that I
mentioned a few days ago, there is a manual for it at
http://www.symmttm.com/pdf/Bus/um_bc620_627at.pdf .
This card looks fairly involved to program, and if you were
to use it I'm not sure whether it would be better to use
the programmable frequency output (pp. 38-39, p. 51) or the
time coincidence strobe (p. 31) or the 1 pps output (p. 11).
Stability is listed as 2 ms per hour; long term accuracy
can be improved by inputting a 1 pps signal from a GPS unit.
-jiw

James Waldby wrote:
[Perhaps drop the newsgroup that isn't sci.electronics.design]

wrote:
[snip scoring and anomaly stuff and prize %'s]
patterns that run from before the appearance of the first prize to
after the appearance of the second, the exact time the first prize
appears, what it is,and possibly it's travel pattern will make it the
reference for determining what adjustment/s will have to be made before
the second prize appears.

***So the last joystick movement before the dot that triggers the
second prize will be the key.

Since our maze patterns have a lot of pauses, the possibility of
resuming motion at the exact same time a particular second on the
display clicks over is doable with some accuracy above and beyond
rolling the dice.
...
As far as drift in the game's hardware timimg, this has already been
considered. But still adjustments can be made by noting the first
specific prize, and then making adjustments for the second prize.
...

I didn't see where game hardware timing drift was considered.
Did I overlook something about drift in what you wrote?

Yes you did. Whent you mentioned drift five days ago, I said, "I'm
aware of the consistency of the game hardware. And this project can't
involve tapping into the games clock."

Anyhow, this timing problem looks complex enough -- it looks like the
timer may need to slightly speed up or slow down, or to keep track
of scoring and joystick events -- that the best approach would be
a PC- or micro-based timing program. Let PTP="PC timing program".

You want PTP to provide a seconds metronome, to signal the Banana
zone of each second. To make it actually work, I think PTP would
need to know timestamps and values for your joystick inputs and
for scoring. (See * re getting this info.) With that data, PTP
can get syncronized and accomodate for drift. For example,
suppose you do some joystick movement x and then 5 cycles later
the score goes up 500 points; this tells PTP Orange was on the
bonus timer 5/60 seconds ago. After a while PTP can figure out
where Ms.Pac-man is in its 0...31 bonus timer cycle. If, 123
seconds later, Orange is showing up a cycle early relative to PTP,
then PTP increases its per-second delay count by 1 part in 60*123.
PTP should have an adjustable reaction-time offset for different
players. PTP probably should start with a half-minute or so
synchronization phase, and re-sync whenever player tells it to.

* Getting event data: Of course you could set up a board with
several pushbuttons on it and enter data that way, or have an
assistant do so. This might work if you don't have to sync very
often. Also you could attach mercury-switch sensors to wrists
or perhaps to an elastic band that fits on the joystick. For
definitive scoring detection, aim a TV camera at the screen
area where score appears, and decode it in real time. Or if
the game is running on the same computer as PTP, your program
can monitor some bytes of screen memory.
-jiw

Incidentally, regarding the $49 ebay item
http://cgi.ebay.com/ws/eBayISAPI.dll...tem=7526393893
(Datum bc620AT ISA time and frequency counter card) that I
mentioned a few days ago, there is a manual for it at
http://www.symmttm.com/pdf/Bus/um_bc620_627at.pdf .
This card looks fairly involved to program, and if you were
to use it I'm not sure whether it would be better to use
the programmable frequency output (pp. 38-39, p. 51) or the
time coincidence strobe (p. 31) or the 1 pps output (p. 11).
Stability is listed as 2 ms per hour; long term accuracy
can be improved by inputting a 1 pps signal from a GPS unit.
-jiw

Thanks for the advice but this has to be a "real world" experiment. As
I mentioned it involves going for the world record on Ms.Pac-man, so
the gaming hardware cannot be tapped into to or changed in any way. The
player is the only interface, and info can only be received visually
from the games monitor screen and the the timer's display. This all
comes down to human timing.

BTW Here is some info I uncovered on that acrd you mentioned: "When
DM2000 was first released in 1996, the time synchronization hardware
used was a Datum BC620AT card and time synchronization software from
the Windows NT* Server Resource Kit. The hardware had a potential
problem with the GPS week rollover issue. This time synchronization
software has not been tested by the vendor for year 2000 issues. As a
result of these issues, and because the system was difficult to set up,
we no longer offer this solution."

Darren Harris
Staten Island, New York.

First, I should admit that my rant may have been a bit harsh. This may
also have been caused by some ignorant people looking for free help on
some illegal stuff (so their questions were very vague and ill defined)
in another newsgroup that I read. I should have only tried to make the
point the input you get is as detailed as the description of the
problem. There was some suspicion your problem being not exactly as you
described, so you would be looking for another solution to solve it in a
proper way. I was just trying to explain the way people react to the
question, I suppose.

Anyway, on topic, I'd like to explain why I stated you should be
sampling at least 120 times a second if you really want to detect
changes that could be occuring 60 times a second. Suppose you take a
sample 60 times a second. Worst case scenario is that a change occurs
immediately after your sample and a next change occurs exactly before
your next sample. You've missed the entire event in that case. The
second-worst case being that a change occurs immediately after your
sample and you record it almost 1/60th of a second after it really
occured.

---
Met vriendelijke groet,

Maarten Bakker.

On Fri, 01 Jul 2005 01:49:14 +0000, NSM wrote:
wrote in message

Also, another idea involves aiming for the larger 27/60th of a second
window that the prizes do have an equal chance of occurring, thereby
effectively cutting out the register numbers of 28 to 31. This of
course would be much easier to do, and automatically adds about 31,000
points to one's average score.

What would occur to me first is to replicate the game on a PC and build
whatever timing or scoring you need into the PC software.

Thanks for the judicious snip. :-)

You can get the source code he http://www.mame.net/
but you have to have a license for the ROMs. I think I have
a de facto license for game ROMs, since I used to repair them
for a living, and the company copied them routinely so the owners/
operators could have spares.

Pac-Man, however, for some reason, is almost impossible to find, unless
you have an actual physical game that you can pull the ROMs from - and if
you have that level of access, just solder a wire onto the nearest clock,
and clock your joystick sniffer in sync, or whenever you want to.

Lessee....
http://www.google.com/search?q=MAME+roms

Have Fun!
Rich
(I also once had to fix an NSM jukebox... ;-) )

On Fri, 01 Jul 2005 09:29:44 -0700, Searcher7 wrote:

Thanks for the advice but this has to be a "real world" experiment. As
I mentioned it involves going for the world record on Ms.Pac-man, so
the gaming hardware cannot be tapped into to or changed in any way. The
player is the only interface, and info can only be received visually
from the games monitor screen and the the timer's display. This all
comes down to human timing.

Then, if you can't hack the physical game, you'll have to do it the
same way everybody else does:

Practice, practice, practice. ;-)

(Although, somebody could probably come up with a little receiver,
that could sniff clock transitions...)

But if you're intending to cheat in a real-live competition, where
there's the possibility of money exchanging hands, I'd venture to
speculate that most of the regulars of s.e.d would shy away from
such shenanigans. )-;

Good Luck!
Rich

Rich Grise wrote:
On Fri, 01 Jul 2005 09:29:44 -0700, Searcher7 wrote:

Thanks for the advice but this has to be a "real world" experiment. As
I mentioned it involves going for the world record on Ms.Pac-man, so
the gaming hardware cannot be tapped into to or changed in any way. The
player is the only interface, and info can only be received visually
from the games monitor screen and the the timer's display. This all
comes down to human timing.

Then, if you can't hack the physical game, you'll have to do it the
same way everybody else does:

Practice, practice, practice. ;-)

(Although, somebody could probably come up with a little receiver,
that could sniff clock transitions...)

But if you're intending to cheat in a real-live competition, where
there's the possibility of money exchanging hands, I'd venture to
speculate that most of the regulars of s.e.d would shy away from
such shenanigans. )-;

You know, you speculate, imagine, and assume way too much...

Darren Harris
Staten Isalnd, New York.

Rich Grise wrote:
On Fri, 01 Jul 2005 09:29:44 -0700, Searcher7 wrote:

Thanks for the advice but this has to be a "real world" experiment. As
I mentioned it involves going for the world record on Ms.Pac-man, so
the gaming hardware cannot be tapped into to or changed in any way. The
player is the only interface, and info can only be received visually
from the games monitor screen and the the timer's display. This all
comes down to human timing.

Then, if you can't hack the physical game, you'll have to do it the
same way everybody else does:

Practice, practice, practice. ;-)

(Although, somebody could probably come up with a little receiver,
that could sniff clock transitions...)

But if you're intending to cheat in a real-live competition, where
there's the possibility of money exchanging hands, I'd venture to
speculate that most of the regulars of s.e.d would shy away from
such shenanigans. )-;

You know, you speculate, imagine, and assume way too much...

Darren Harris
Staten Island, New York.

In sci.electronics.repair wrote:
You know, you speculate, imagine, and assume way too much...

You left room for that ;-) allthough I did enjoy and appreciate your
explanation. Sounds like an interestig project, so good luck!

---
Met vriendelijke groet,

Maarten Bakker.