Run Pac-man Game Based on 8086/8088 FPGA IP Core
Authors: Kevin Xie, Michael Ye, Winston Zhu
Last update: 1st, August, 2007
Overview
On this page you will find a simple Pac-man game running on free FPGA IP Core of an 8086/8088 processor. This project consists of a CPU86 Core, three Memory
Units and a VGA Controller Unit.This system consumes 68% of logic slices, 2 GCLKs, 1Mult, 1 DCM and
100% of block RAMs which is 40KB of Spartan-3E500 board, and can
run at a frequency of up to 32.44MHz.License Agreement
The CPU86 source code is licensed under Aladdin Free Public License (AFPL). The CPU86 source code was originally developed by HT-LAB
and then appreciably modified by Winston Zhu so as to be compatible
with Xilinx Tools and Boards. The remaining source files are
released under GNU General Public License.
Download Source Files & Tools
Attention: Downloading the following files means that you have read
and accepted the licenses listed above. Make sure your running a
virus checker on the exe files before executing them!Download Hardware RTL Source Code files (version 1.0, 7.70MB,
zipped);
Download Software C Code files (version 1.0, with comtool and
bin2txt，444KB, zipped);
Function Description
When the CPU resets, it starts from address FFFF: 0000, just as a
real 8086/8088 processor. After cold start, the CPU fetches an
instruction from the RAM in which Pac-man program resides, executes
that instruction, and writes data to the display buffer if needed,
then fetches next instruction iteratively. The VGA controller model
reads data from display buffer, then generates color and
synchronous signals to drive the display terminal such as CRT or
LCD. The data will be continually updated by CPU until Pac-man
program terminated as a result of meeting some given conditions,
thus we can see the game animation changes.
Detailed Hardware Design
Figure 1 Signal Flow Graph of Entire SystemU_0: cpu86
The CPU86 Core consists of an 8088 Processor Core, an 8-bit Bus Interface Unit and a Hardware Debug Unit. The hardware debug unit is used to interrogate the internal
registers during single stepping. The output of the debug
unit is written in a DOS style format to a build-in fixed
frame UART. The CPU86 Core is fully binary/instruction compatible with an 8086/8088
processor, it is however not cycle and timing accurate. For
detailed information about CPU86, please refer to HT-LAB.U_1: superio
The superio model is a build-in fixed frame UART which defaults to 19200 Baud rate, no parity, 8 data bits and 1 stop bit,
no hardware data flow control at a clock frequency of 16.67MHz. It reads what the hardware debugger outputs and writes the
programmer’s commands to the hardware debugger. The Baud rate can
be set to what you want by modifying the clock divider settings. It
is recommended that you replace this model with a 16650 UART model,
which supports interrupts.
U_2: embedded_rom
The embedded ROM is filled with nothing more than a JMP instruction to address
0000:0400, which is the cold start address of the Pac-man program.
As is known to all, any CPU based on X86 instruction framework will
force its CS: IP to FFFF: 0000 when reset signal is active, thus
the JMP instruction mentioned above should be located to FFFF:
0000. The ROM is constructed with 256B distributed memory and is
assigned with address from FFF0:0000-FFF0:00FF. There are 3 pins for the ROM:l clk: system clock input signal, should be synchronous with CPU;l a: 8 bits address input signal which is connected to the lower 8
bits of address bus (abus) of CPU;l spo: 8 bits data output signal which is connected to the 8 bits
data input bus (dbus_in) of CPU;U_5: textram
The single port ram “textram” is constructed with 4 pieces, that
is, 8KB of block RAM, and is assigned with address from 0000: 0000
to 0000: 1FFF. It is divided into three parts. The first 1KB
address space is reserved for interrupt vector table, and is now
filled with NOP instructions. The following address space is
resided by Pac-man program, which takes about 5KB. The last space,
about 2KB, is reserved for stack segment, in which temporary data
of Pac-man program is kept.There are 5 pins for the RAM:l clk: system clock input signal, should be synchronous with CPU;l addr: 13 bits address input signal which is connected to the lower
13 bits of address bus (abus) of CPU;l din: 8 bits data input signal which is connected to the 8 bits data
output bus (dbus_out) of CPU;l dout: 8 bits data output signal which is connected to the 8 bits
data input bus (dbus_in) of CPU;l we: write enable signal, active high, determined by chip select
signal (cs_text) and CPU write enable signal (wrn);U_6: disp_ram
Since the VGA interface of Spartan-3E500 board supports only 8
colors, at least 3 bits should be used to represent one pixel. In
order not to increase the complexity of VGA controller, I choose to
use 4 bits to represent one pixel, that is, 1 byte for 2 pixels.| N/A | Red | Green | Blue | N/A | Red | Green | Blue |
U_7 disp
This VGA controller is designed to interface with CPU via display buffer. The resolution of the VGA interface is 640*480@60 Hz in order to make sure that this controller can drive most CRT/LCD on the market. The following timing parameters can be
referred to when designing such a VGA controller. There are 9 pins for VGA controller:l reset: input signal used to clear the registers of internal
counters, active high, synchronous to clock, must longer than 1 clock cycle in order to make sure reset aptitude.l clk: clock input signal of VGA controller;l addr_out: 15 bits address output signal to display buffer,
connected with disp_addr;l data_in: 8 bits data input signal from display buffer,connected
with disp_dout;l red: output signal, the red signal of VGA interface;l green: output signal, the green signal of VGA interface;l blue: output signal, the blue signal of VGA interface;l Hsync: output signal, the Hsync signal of VGA interface;l Vsync: output signal, the Vsync signal of VGA interface;U_8: DCM
DCM is used to generate proper clock signals for the system. Here
I’d like system clock and VGA clock both to be 25MHz.Top
In this module, not only all sub components are described and
mapped, but also player controller and address bus decoder are
defined. The player controller scans external input buttons
unceasingly and sends what it receives to CPU when there is a
non-zero input. The address bus decoder generates chip select
signals according to the higher bits of address bus.
;){kind=link}