Namco Pac-Man/Video

Namco Pac-Man uses a rotated screen, such that the top of the frame starts in the top-right corner. However, all the hardware documentation still refers to the now-vertical beam in terms of horizontal counts, and the scanline number in terms of vertical counts.

The video timing divides the screen into 384 pixels by 264 scanlines. The pixel clock is the 18.432MHz crystal divided by 3, or 6.144MHz. The Z80's clock is half of that, or 3.072MHz.

Internally pixels are numbered from 128 to 511. 144-239 are blanked and are when sprite tiles are fetched. 240-511-128-143 are the active area, and sync is from 176-207. Scanlines are numbered from 248 to 511. 496-511-248-271 are blanked, scanlines 272-495 are the active area, and sync is from 248 through 255.

The 384 pixels are divided by 2 to yield 192 memory access slots per scanline. Half of these are for the Z80, and half are used for the video hardware to render the screen.

The Z80 has no-wait access to its own ROM at $0000-$3FFF (and $8000-$BFFF, but that's unused in the base hardware). However, any access to system RAM or MMIO is possibly delayed to align it (using the Z80's /WAIT input) to the Z80's memory access permitted times.

The Video hardware always alternates between reading tile number (and flip, for sprites) and palette selection. This effectively means that the video hardware fetches 48 16-bit words per scanline.

The address bus arbiter (NVC284 and two 74LS367s) chooses between four addresses depending on the current Y coordinate:

• when 2H is low: the Z80
• when 256H is high: the center 32x28 tilemap at $4040-$43BF and color table at $400 higher [ 0 4H 128VP 64VP 32VP 16VP 8VP 128HP 64HP 32HP 16HP 8HP ]
• when BLANK is low: the top and bottom 2 lines, at $4000-$403F and $43C0-$43FF and color table at $400 higher [ 0 4H 64HP 64HP 64HP 64HP 8HP 128VP 64VP 32VP 16VP 8VP ]
• when BLANK is high: the sprite attributes at $4FF2-$4FFC and color at $1 higher [ 1 1 1 1 1 1 1 64H 32H 16H 4H ].

Notice 8H is not in the sprite address list above! Sprite attributes are fetched repeating each pair twice: 2, 3, 2, 3, 4, 5, 4, 5, etc. This is because each fetch only draws 8 pixels, regardless of whether sprites or background. To build 16x16 sprites, each is fetched twice.

There is a 256 pixel linebuffer. During pixels 144-239, the fetched sprite attributes are drawn into the linebuffer. During pixels 256-511, the linebuffer is both replayed and cleared.

During either blanking, all fetches and drawing proceed as normal. The only difference is that the final output stage that feeds the color ROM is disabled.