Run Pac-man Game Based on 8086/8088 FPGA IP Core. Authors: Kevin Xie, Michael Ye, Winston Zhu Last update: 1 st, August, 2007

Size: px

Start display at page:

Download "Run Pac-man Game Based on 8086/8088 FPGA IP Core. Authors: Kevin Xie, Michael Ye, Winston Zhu Last update: 1 st, August, 2007"

Bruce Cummings
5 years ago
Views:

1 Run Pac-man Game Based on 8086/8088 FPGA IP Core Authors: Kevin Xie, Michael Ye, Winston Zhu Last update: 1 st, 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

2 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 50MHz DCM abus(19:0) 50MHz 8086/ 8088 CPU dbus_out dbus_in abus(7:0) Bootstrap ROM dout_rom cs=abus(19:13) abus(12:0) Program Resident RAM dout_text din_text cs=abus(19:15) din_disp abus(14:0) VGA Buffer RAM UART Debugger disp_addr disp_data keyin VGA Controller Player Controller red green blue Hsync Vsync Figure 1 Signal Flow Graph of Entire System U_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 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 UART model, which supports interrupts.

3 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: 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: clk: system clock input signal, should be synchronous with a: 8 bits address input signal which is connected to the lower 8 bits of address bus (abus) of spo: 8 bits data output signal which is connected to the 8 bits data input bus (dbus_in) of 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: clk: system clock input signal, should be synchronous with addr: 13 bits address input signal which is connected to the lower 13 bits of address bus (abus) of din: 8 bits data input signal which is connected to the 8 bits data output bus (dbus_out) of dout: 8 bits data output signal which is connected to the 8 bits data input bus (dbus_in) of we: write enable signal, active high, determined by chip select signal (cs_text) and CPU write enable signal (wrn);

4 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 For a display buffer of 200 lines with 320 pixels in each line, the size of display buffer is 320*200*0.5=32KB. As a result, the dual ports ram disp_ram, used as display buffer, is constructed with 16 pieces, that is, 32KB of block RAM, and is assigned with address from A000: 0000 to A000: 7FFF. The higher 4 bits of the byte in the beginner of this ram indicate color of the pixel at top left corner, followed by pixels in first line from left to right, then other lines from top to bottom. There are 8 pins for the RAM: For Port A (read and write): clka: system clock input signal, should be synchronous with addra: 15 bits address input signal which is connected to the lower 15 bits of address bus (abus) of dina: 8 bits data input signal which is connected to the 8 bits data output bus (dbus_out) of douta: 8 bits data output signal which is connected to the 8 bits data input bus (dbus_in) of wea: write enable signal, active high, determined by chip select signal (cs_disp) and CPU write enable signal (wrn); For Port B (rean only): clkb: clock input signal of VGA controller, should be synchronous with VGA controller; addrb: 15 bits address input signal which is connected to 15bits address output of VGA controller (disp_addr); doutb: 8 bits data output signal which is connected to the 8 bits data input of VGA controller (disp_dout); U_7 disp This VGA controller is designed to interface with CPU via display buffer. The resolution of the VGA

5 interface is 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: 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. clk: clock input signal of VGA controller; addr_out: 15 bits address output signal to display buffer, connected with disp_addr; data_in: 8 bits data input signal from display buffer,connected with disp_dout; red: output signal, the red signal of VGA interface; green: output signal, the green signal of VGA interface; blue: output signal, the blue signal of VGA interface; Hsync: output signal, the Hsync signal of VGA interface; 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. 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.

XiNES Design Document. XiNES is a Nintendo Entertainment System simulator coded in pure VHDL

XiNES Design Document. XiNES is a Nintendo Entertainment System simulator coded in pure VHDL XiNES Design Document William Blinn (wb169@columbia.edu) David Coulthart (davec@columbia.edu) Jay Fernandez (jjf112@columbia.ed) Neel Goyal (neel@columbia.edu) Jeffrey Lin (jlin@columbia.edu) XiNES is