Determing FPS within another FPS .. How?

[TerryRitchie]

I know I could set up individual frame counters for every object and skip, say, every 9th frame to achieve 85%. However, the original Pac-Man arcade machine had 16K of ROM and 2K of RAM and I can't imagine this was the procedure used with such limited space.

You got me too interested in this That said, 2K RAM is really a fair amount, I suspected they just used a counter, but it's actually much more interesting. Like you mentioned, I managed to find a dissassembled and commented copy of the Ms. Pac-Man code, you can see it here. It sounds like this and Pac-Man work basically the same, and this appears to be the important point. Thankfully I happen to be a bit familiar with z80 assembly:

Code: (Select All)

182f  2a484d    ld      hl,(#4d48)    ; load HL with speed for pacman in normal state (low bytes)
1832  29        add     hl,hl        ; double
1833  22484d    ld      (#4d48),hl    ; store result
1836  2a464d    ld      hl,(#4d46)    ; load HL with speed for pacman in normal state (high bytes)
1839  ed6a      adc     hl,hl        ; double with carry
183b  22464d    ld      (#4d46),hl    ; store result.  is it time for pacman to move?
183e  d0        ret     nc        ; no, return.  pacman will be idle this time.

183f  21484d    ld      hl,#4d48    ; yes, load HL with speed for pacman in normal state (low byte)
1842  34        inc     (hl)        ; increase by one

That code is a bit hard to read, but really all it's doing is shifting the combined 32-bit value in 4d46-4d49 one bit to the left, and if the last bit shifted out (the one shifting out the high part) was a 1 then Pac-Man moves. We also add one to the counter when that happens, basically turning the code into a rotation (so when we shift out a 1 bit, we tack a 1 onto the beginning).

Else-where in the code, that 4d46-4d49 value is preloaded with various bit patterns, and the pattern controls how often a bit is shifted out and thus how fast pac-man moves. Based on some other comments in that code, I think these are the 4 bit patterns for original Pac-Man:

Code: (Select All)

55555555 (16 ones, 80%)
6AD56AD5 (18 ones, 90%)
6D6D6D6D (20 ones, 100%)
6AD56AD5 (18 ones, 90%)

The bit patterns themselves do repeat but the ones and zeros are not always at the same interval, so consequently Pac-Man does not move perfectly smoothly. It does however explain the percentages, as it's all based on the number of one bits that will get shifted out. More ones getting shifted-out will make Pac-Man faster, and the fastest is 20 ones which makes the percentages work out.

The one thing I'm not sure on is how often that actually gets called, but it sounds like it's just once a frame. That leads to some odd speeds per second if you actually calculate it, since there's 60 frames a second but the bit pattern repeats every 32 frames. The 80% speed is 30 moves per second, the 100% speed is roughly 37.5.

Well that's genius. Sort of like a punched paper tape roll. Move if no hole, don't move if a hole is seen. So they did use individual counters, just in a very unconventional but RAM conservative way. No need to involve the stack to get and maintain separate variables/values.

For some reason that number 37.5 rings a bell with me. I'm thinking it had something to do with the refresh rate of the old raster CGA monitors used in those arcade machines back then. According to the Pac-man Dossier the refresh rate of the game was 60.61Hz though. I've been assuming that meant the game ran at 60FPS. Perhaps that's the wrong assumption? Those coders back then would have had to sync their graphics with the video hardware ensuring to draw when the scan line was at the top left corner. Video cards do this automagically now or languages have built in commands to deal with this (_DISPLAY).