Pacman game

XSV PAC-MAN

Sam Revitch and Quang Luu

Game description:

It’s a Pac-man clone! The mazes are a lot more complicated than the original, there are only three ghosts, and there is no “ghost house.”

Hardware Features

Our Pac-man implementation features the MiniRISC 8-bit microcontroller core for game control. The core was obtained from the opencores.org freeware Verilog repository, and implements a Microchip PIC16C57 compatible CPU.

The video display is managed by a custom VGA control module, featuring:

• 
  VGA 640x480 display resolution, 60Hz vertical refresh rate, 6 BPP color depth
  
• 
  4-stage pixel pipeline
  
• 
  Four 32x32 hardware sprites, with image select/translate/rotate/mirror abilities
  
• 
  Bitmapped image ROMs for Pac-man, ghosts, maze tiles, and pellets.
  
• 
  Image color palette configuration
  
• 
  Custom memory component for maze storage, with external read/write access port
  
• 
  Background maze and pellet display unit
  
• 
  8-bit configuration register interface for CPU
  
• 
  External VBLANK signaling
  

Software Features

Since our game was implemented using the MiniRISC processor, most of the interesting functionality of the game comes in the form of software. Highlights include:

• 
  1536 byte instruction ROM
  
• 
  Random number generation, based on keyboard event timing
  
• 
  Random maze generation and power pellet placement
  
• 
  Simplistic ghost AI
  

Architecture

We connected the MiniRISC processor to the display unit and other I/O devices using its built-in I/O ports. MiniRISC includes three read/write I/O ports and a “tri-state enable” register for each, as to behave like the PIC 16C57 processor after which it was modeled. We found the concept of using a tri-state bus to be overkill, and instead opted to remove the tri-state unit and connect data ports directly to the read and write sides of each I/O port. This provided one readable register (the port read register) and two writable registers (the port write register and the tristate enable register) per I/O port, which was just enough to interface with all devices.

To handle VBLANKs, we connected the video unit’s VBLANK signal to the MiniRISC’s reset wire, which causes the program counter to be reset to 000h when a VBLANK occurs. We also added an interruption enable wire, using a bit from one of the tristate registers, to allow the software to disable interruptions as a precautionary measure.

Our high level design for a screen update procedure includes:

1. 
   Display unit raises VBLANK signal and interrupts CPU.
   
2. 
   CPU disables interrupts
   
3. 
   CPU processes parameters for the next frame, writes changes to the maze memory, and rewrites all video display configuration registers.
   
4. 
   CPU re-enables interrupts and goes into an infinite loop waiting for another VBLANK.
   

The exact I/O port mappings are:

PORT A:

Read: keyboard controller output

Write: maze address register

Tristate: unused

PORT B:

Read: maze cell data

Write: maze cell data

Tristate: write enable bits

PORT C:

Read: video display status byte (contains a bit for hardware reset)

Write: video display configuration register

Tristate: (bit 0) configuration register write enable, (bit 1) interrupt enable

Tools

As part of this project, a custom image manipulation plug-in for The Gimp (GNU Image Manipulation Program) was developed. The plug-in converts any Gimp-readable image to Verilog code for an asynchronous ROM module, with row/column inputs and pixel value outputs. This was great for including very small image ROMs, but because the Synopsys Verilog compiler chose to represent the images as combinational logic, larger images were impractical.

Encumbrances

The MiniRISC Verilog code required a significant amount of tweaking to make it function correctly on the Xilinx FPGAs. Many features remain unoptimized, including the placement of the register file in CLB slices instead of BlockRAMs. The image ROMs were implemented using CLB slices, and made the overall design space-inefficient. Due to the limited memory on the processor, many features of the original Pac-man game were extremely difficult if not impossible to implement, and were left out.

Once the CPU core and display hardware units were working and well-tested, it became a major hassle to integrate new program ROMs into the design. We were unable to find a way to change the initial contents of a BlockRAM without rebuilding the entire FPGA layout from netlists.