my first post here.
For quite a long time I've had an idea of making a game that would run on an original arcade hardware and I finally started to write the code for Pac-Man hardware. I've set up a toolchain using SjASMPlus so I can compile the test code and produce pacman.6e ROM file for pacman.zip ROM set in seconds and that works well. I already did initializing, print string (to both central and top/bottom area and in both horizontal and vertical direction), print hex, read joystick, scroll sprite, ... routines and I set up the interrupt (IM 1) routine to update the tick counter, move the sprites, read the input etc. I am not modifying existing ROM files, I am creating the ROM files from scratch by compiling the code I write in assembly.
Everything until now worked as expected until I noticed sprite scrolling is a bit choppy - looking as the moving speed is not 100% constant at every moment. Since I am updating the sprite coords inside interrupt routine and changing the coords 1 pixel at a time - the moving speed of the sprites should be perfectly steady.
I then used MAME debugger trying to figure out the reason for the imperfection in sprite movements. My interrupt routine being too long to fit between two interrupt requests was out of question because there should be 50684.7 T-states between the two interrupts (Z80 @ 3.072 MHz, screen refresh @ 60.61 Hz) and my interrupt routine needed only about 200 T-states (it now needs about 570 T-states but that is still just about 1% of the available time window). I used the command Run until next VBLANK (F8) and was surprised the interrupt routine is executing on every 2nd VBLANK and not on every VBLANK!?
I thought I do not know something about the Pac-Man hardware so i did't do something that should be done for the hardware to run properly (maybe to output some value on some port or something) so I went to check the interrupts in the original Pac-Man ROMs and the results were exactly the same - the interrupt routine is entered on every second VBLANK impulse and not on every and it can be clearly seen the sprite movement is choppy as well :-/ Pac-Man (Midway) which is pacman.zip is BTW using IM 2 and Pac-Man (bootleg on Namco hardware) which is puckmanb.zip is using IM 1.
I then tried to examine cycles, beamx, beamy and frame valus in MAME debugger trying to find out why the interrupt is not triggered on every VBLANK and I am not sure I understand how cycles and beamy values work. I notice cycles are after each Z80 instrucion decreasing, counting down T-states taken by the instruction. But towards which value are cycles decreasing? Are they decreasing towards the moment when VBLANK signal will be active?
I tried to observe cycles, vblank, beamx and beamy values and I can see beamx goes up to about 380 and then returns back to zero. Visible part of the Pac-Man's screen is 288 px wide so 380 does not correspond to the screen width.
On the other hand, cycles reaches zero when beamy reaches 224 which is the visible height (in pixels) of the Pac-Man's screen - meaning cycles really do count down towards the moment wher VBLANK will be active?! After cycles reaches zero it sometimes jumps to about 7600, sometimes to about 43000, sometimes to about 3060, sometimes to about 39900 so the pattern is not so obvious :-/
So what I would like to know is:
Why is interrupt triggered on every second VBLANK and not on every VBLANK? Does it have something to do with the fact the picture is interlaced so it is drawn in two half-frames? But if the refresh rate is 60.61 Hz then interrupt should be triggered by every VBLANK :-/
Why are cycles in MAME debugger counting towards zero and what is the value the counter jumps to upon reaching zero? How to measure the number of T-states (cycles) between two breakpoints or between two interrupts if the cycles counter in the meantime reaches the zero and then jumps to some value?
I would BTW prefer to use Scramble hardware (because Pac-Man HW doesn't support background scroll, doesn't have 8 way joystick and doesn't have fire/bomb buttons) but couldn't find any documentation. I thought it would be easier to find the Scramble documentation because i read:
Apparently, Scramble's board was especially easy to re-use; several games were hacked to play on it. A long-running joke with MAME enthusiasts is that anything can be run on Scramble hardware - N64 games, your toaster, your automatic garage door, etc. :?) (Ironically, Scramble itself was hacked to play on Galaxian hardware!)
here on the FAQ pages :-/ But the only Scramble HW docs I could find were not even nearly as detailed as the docs I found for Pac-Man HW.
I know I could decipher the hardware info from the MAME driver for Scramble hardware but I am assuming there is some documentation similar to these docs for the Pac-Man hardware.