Fpga-Based Hardware Emulation Arcade System Final Report

FPGA-BASED HARDWARE EMULATION ARCADE SYSTEM FINAL REPORT

May 11-14

Tony Milosch, Cory Mohling, Danny Funk, David Gartner, John Alexander

Client: Joseph Zambreno Advisor: Phillip Jones

April 27, 2011

TABLE OF CONTENTS List of figures i List of tables ii Definitions ii Executive Summary 1 Problem Statement 2 Operating Environment 2 Intended Users and Uses 3 Assumptions and Limitations 3 Expected End Product and Other Deliverables 3 Proposed Approach 4 Statement of Work 8 Estimated Resources 10 Schedule 10 Detailed Design 11 Testing and Evaluation 25 Acknowledgments 28 Closing Material 28

LIST OF FIGURES Figure 1: NES System Overview 12 Figure 2: CPU Memory Map 13 Figure 3: PPU Memory Map 15 Figure 4: The left side shows what is displayed to the screen, while the right side shows the name tables used to display the image. 17 Figure 5: This image shows how eight sprites are used to create the Mario character. 17 Figure 6: System design for boot loader 19 Figure 7: Base Arcade Cabinet Structure without control panel 21 Figure 8: Detachable Control Panel 21 Figure 9: Screw position will not be visible from outside 22 Figure 10: Opening for light bulb and custom marquee 22

Figure 11: Opening on cabinet for coin door 23 Figure 12: Coin door blue print 23 Figure 13: Control panel is fixed to hinges 24 Figure 14: Control panel layout 24 Figure 15: Final Cabinet Implementation 26

LIST OF TABLES Table 1: Memory mapped I/O 16

Table 2: Monitor Specifications 25

DEFINITIONS  ALU – Arithmetic Logical Unit  CPU – Central Processing Unit  FPGA - Field Programmable Gate Array  I/O – Input / Output  NES – Nintendo Entertainment System  PCB – Printed Circuit Board  PPU – Picture Processing Unit  VGA – Video Graphics Array  VHDL – Very High Speed Integrated Circuit Hardware Description Language

EXECUTIVE SUMMARY

The Iowa State Reconfigurable Computing Lab would like a way to showcase the capabilities of reprogrammable hardware. To accomplish this, our group will showcase that a simple FPGA board can replace the entire NES. This project is the continuation of a past group that created a simple emulation of the NES. Our primary goal was to continue the work done by the past group and improve the presentation of the system by building an arcade cabinet.

We ran into several major issues while improving on last year’s project. The project was not very robust, so we spent some time making the system more robust. Also, we found several online emulation tests that we worked on to get them to pass. As we made these changes, the system wasn’t appearing to improve functionality. Therefore, our client decided to switch the direction of our project to using a software emulator on the FPGA board. We integrated this software emulator into our project, which allowed us to play several more games (over 100). In order to select from this list of games, our team developed a boot loader program. This program simply displayed all the games and allowed the user to use the joystick and buttons to select the game they wish to play. Finally, we built a professional arcade cabinet reminiscent of arcade machines from the 1980’s to house the entire system.

Our team is composed of five computer engineering seniors. We have all taken Computer Organization and Design (CPRE 381), and all have experience with computer architecture. Our group divided tasks between the three main modules: designing the FPGA, building the arcade cabinet, and developing the boot loader.

PROJECT PLAN

PROBLEM STATEMENT

GENERAL PROBLEM STATEMENT We had a partially working emulator from the past group, but it didn’t include audio, side scrolling, or cartridge based memory. The inherited system was not capable of playing multiple games, or a way to select from multiple games efficiently. To make the system more presentable, we need to create a professional looking arcade cabinet to enclose the emulation system that could be used repeatedly in demonstrations.

MARKET / LITERATURE REVIEW We looked into the various other software emulators for examples on ways that other individuals have solved common NES emulation problems. Additionally, we found a similar project (https://rm-rfroot.net/nes_fpga/) that provided very valuable knowledge. Research was performed on other individual’s experiences in building custom arcade cabinets.

GENERAL SOLUTION APPROACH To enable side scrolling, we attempted to further understand and develop the PPU that was implemented last year. To enable audio on the FPGA board, we tried to further develop the CPU. The boot loader and game selection was implemented using C and Xilinx libraries. Research was conducted on other arcade cabinet projects to gain knowledge on ideas and direction to take with the design of the arcade cabinet.

OPERATING ENVIRONMENT

When the system is in its final location, it will be in a climate controlled environment. It will not need to withstand extreme temperatures or physical shock. However, it may encounter small amounts of dust. An example location would be a lobby of a building on campus. The entire system must be capable to be powered up and running for several hours at a time running off of standard 120VAC.

INTENDED USERS AND USES

INTENDED USERS The intended users of the system are anyone that will be visiting the computer engineering facilities at Iowa State University. This includes current and future students, faculty, and visiting family members. For example the system was demonstrated in Coover for VEISHEA for the public.

INTENDED USES The system will be used to showcase the capabilities of reconfigurable hardware and to promote the department and Iowa State University. The system should be representative of the interaction users have with professional arcade machines. We don’t expect people to treat the emulator in such a way that could cause damage to the system. We don’t expect that the entire system needs to be easily portable, but the FPGA board and controls should be.

ASSUMPTIONS AND LIMITATIONS

ASSUMPTIONS  The one semester remaining is an adequate time period to complete the project  The system will be used by one or two users simultaneously  Documentation provided online will provide sufficient information to aid us in solving any unforeseen problems.  We will have adequate funding to complete the project.  All supplies purchased online will arrive in a timely manner.

LIMITATIONS  The one semester remaining time period is a firm deadline.  The system will be powered by a standard 120 volt wall outlet.  Limited budget.  The Xilinx FPGA boards have a limited amount of logical resources that the entire system must fit on.  The system must be designed around the NES ROM files and instruction set.

EXPECTED END PRODUCT AND OTHER DELIVERABLES

The final design includes a FPGA board that runs the entire NES. The emulation includes side scrolling, audio, support for extended cartridge based memory, and boot loader. The boot loader allows the user to dynamically choose games to play while the system is running. The system is housed in a specially designed arcade cabinet that allows others to use the system easily. It includes a new control system that uses joysticks and buttons that are incorporated as part of the cabinet.

We will also have several documents as deliverables as well. These documents are a project plan, a design document, and a report of our implementation and testing. We created a project website containing weekly status reports, project plan presentation, project design draft presentation, and design review presentation, poster, and final review presentation slides.

PROPOSED APPROACH

FUNCTIONAL REQUIREMENTS FPGA FR 1.1 – All NES specific emulation must be performed entirely in hardware. FR 1.2 – Entire emulation system must be contained within the FPGA Xilinx570X board. Emulator FR 2.1 – Emulator must support the instruction set used by the original NES system. FR 2.2 – Emulator must be able to run a NES ROM file from an outside source. I/O Controls FR 3.1.1 – Emulator must accept input from arcade style controls. FR 3.1.2 – Emulator must accept original NES button inputs. FR 3.1.3 – Emulator must respond to controller input with the same latency as the original NES. FR 3.1.4 – Emulator must accept controls for up to two players. Video FR 3.2.1 – System must be able to display images to a connected display. FR 3.2.2 – System must output video to a screen at the original NES frame rate. FR 3.2.3 – Emulator must use a color palette consistent with the original NES color palette. FR 3.2.4 – Must be compatible with VGA Output. Audio FR 3.3.1 – Emulator must generate background music and sound effects for NES games. FR 3.3.2 – Emulator must generate sound effects with the same latency as the original NES. Boot Loader FR 4.1 – Must be able to display a selectable list of games to the connected display. FR 4.2 – Must be able to load the selected ROM file to the emulator without modifying the FPGA. Cabinet FR 5.1 – Cabinet must be able to support a 103 lb. monitor. FR 5.2 – Cabinet must accept a standard 120 VAC source to power the system. FR 5.3 - Cabinet must fit through 34” x 83” door

NONFUNCTIONAL REQUIREMENTS NFR 1.1 – Emulator must be contained within a removable control box. NFR 1.2 – All components of the emulator should be implemented as independent modules. NFR 1.3 – The Cabinet should be sturdy enough to resist collapse under normal usage. NFR 1.4 – Users should be able to easily understand how to play a game without off-screen instructions. NFR 1.5 – Joystick and button layout should be ergonomic.

DESIGN LIMITATIONS LIM 1.1 – We gained all of our knowledge from online documentation of the NES system. LIM 1.2 – We purchased all needed components in our limited budget. LIM 1.3 – Demonstration at VEISHEA is a firm deadline.

LIM 1.4 – The system is powered by a standard 120 volt wall outlet. LIM 1.5 – Xilinx FPGA boards have a limited amount of logical resources that the entire system must fit on. LIM 1.6 – The system was designed around the NES ROM files and instruction set.

ASSUMPTIONS AS 1.1 – Project could be completed in time for VEISHEA demonstration AS 1.2 – The system will be used by one or two users simultaneously AS 1.3 – Documentation provided online provided sufficient information to aid us in solving any unforeseen problems. AS 1.4 – Provided funds were adequate to build system. AS 1.5 – All supplies purchased online would arrive in a timely manner.

CONSTRAINT CONSIDERATIONS Our project had to be completed within a two-semester period. We had to support one or two users simultaneously. We had to gain all of our knowledge from online documentation of the NES system. We had to be able to purchase all needed components in our limited budget.

TECHNOLOGY CONSIDERATIONS We had to be able to synthesize and run our code on the new FPGA board. The NES has many components designed around old technology which had to be reverse engineered to work on our FPGA board.

TECHNICAL APPROACH CONSIDERATIONS We worked as a team to complete this project, so we split the tasks and tried to keep to our schedule. We wanted to complete all our FPGA work by the end of the first semester, but that was too large of a goal with our resources. An SVN server was used to store all the source code for this project. This allowed us to share our work with the rest of the group, and provide good version control.

TESTING REQUIREMENTS CONSIDERATIONS Testing had to be done on every part of the system. We looked into user input and made sure that the system produced the correct output. When necessary we simulated individual VHDL components to ensure that they worked on a low level. During the integration phase we had to thoroughly test the system to make sure the components worked together as expected. The system was tested on a wide range of video games to check for errors in the system.

SECURITY CONSIDERATIONS The system that we are creating had no immediate known security considerations.

SAFETY CONSIDERATIONS The system had to be sturdy enough to avoid unintentional tipping, as to not injure any users. Safety was a top priority during the construction of the arcade cabinet. Many potentially dangerous tools had to be used to construct the cabinet. Proper measures were taken to ensure safety while using these tools.

INTELLECTUAL PROPERTY CONSIDERATIONS Any components that we used were created by our team, or were provided to us as open source software. Nintendo has released the rights on the NES console, and is now public knowledge. This means that there are no intellectual property violations to consider. Our end product is for academic purposes and no money will be made off of this project.

COMMERCIALIZATION CONSIDERATIONS The system that we created is for internal use only, so there are no commercialization considerations to consider.

POSSIBLE RISKS AND RISK MANAGEMENT Our group has limited hardware design experience and even less experience with using FPGAs. We combated this problem by doing extensive research. This included stepping through some of the class work of CprE 583 (Reconfigurable Computing), which our advisor recommended us to work through. These exercises were beneficial to us, because this class used the same FPGA board that the previous semester’s group used and is the same board we used.

Some of the expanded features to the emulation required the old design to be reworked. This would require more work than was originally expected. In order to counteract this risk, we began work immediately in order to complete our expanded features before the end of the semester. This was to allow us time to overcome any unexpected obstacles that may arise.

Only a couple of team members had experience in woodworking. Their experience is limited, so constructing the cabinet could have taken more time and resources than expected. To avoid that issue, outside firsthand experience in arcade construction was utilized.

PROJECT PROPOSED MILESTONES AND EVALUATION CRITERIA

Deadline Milestone

Oct. 1, 2010 Design Complete

Oct. 15, 2010 Side Scrolling Complete

Oct. 15, 2010 Board Selection Complete

Nov. 1, 2010 Boot Loader Complete

Nov. 1, 2010 CAD of enclosure complete

Dec. 15, 2010 Audio Complete

Dec. 15, 2010 I/O Complete

Feb. 1, 2011 Enclosure Construction Complete

March. 1, 2011 Test/C ode Integration Complete

April. 1, 2011 Final Integration Complete

April 15, 2011 Demonstration at VEISHEA and FAN Event

When the project was completed, we evaluated the system to make sure that we have met all of the goals that are stated in this paper. Additionally, we made sure that we have the approval of both our advisor and client.

PROJECT TRACKING PROCEDURES In order to keep our budget and schedule we maintained constant communication through team meetings and email. We met with our advisor and client once per week to make sure that we were meeting our schedule and updating the rest of the team on our individual progress. This was also a good time to get feedback and advice on any challenging problems we were facing individually or in smaller groups. Weekly reports were sent out every Monday to all team members, client, advisor, and the senior design instructor. These reports gave a summary of how much work was done and the contributions of each individual from the previous week.

STATEMENT OF WORK

 Initial Background Research: Initial background research was needed to gather information about the function of the NES system and its components. o Similar Projects . By looking at similar projects, we could better understand the way the system works. We also determined potential ways to solve common problems encountered when dealing with emulation.  Documentation: As required by the class, documentation was a large part of what was required from the project. We created several documents discussing how we accomplished the goals for the project. o Project Plan . The project plan is the outline of how we planned the project. It contains a schedule of tasks and budget plan. o Design Document . The design document details the specific design methods and issues used in the project. o Weekly report . We created weekly reports to document our accomplishments for the week. Additionally, it will have the amount of time each member has put into the project, so that we can track hours of labor. o Other . To document the progress that were making, as well as easily share information with others, we created a website. Additionally, we gave presentations to the class and review board to inform them of our progress.  VHDL Design: This is the original plan for the work that had to be done in each module of the system. Further in this document we explain how our design had to change, and how that affected the work that had to be done. o PPU . We had to modify the PPU to enable the system to use side scrolling games. o CPU/Audio . The CPU had to be modified to allow it to output audio. This was either modifying old VHDL code, or remaking parts of the CPU to enable us to use audio. We also had to research how the FPGA board that we use interfaces with the audio outputs. o Input / Output . The past implementation worked for the original NES controllers. We wanted to allow for the arcade style buttons, so we needed to modify the code to accept this type of input. o Boot loader . The past implementation did not allow for multiple games to be played without re- synthesizing the code. To allow for this, we needed to come up with a system for dynamically loading the ROM files into memory. We planned on using compact flash for this.  Arcade Cabinet

o CAD blueprints were created to show the detailed design of the cabinet. After the blueprints were created and approved by our client, we could begin constructing the cabinet. The cabinet resembles an 80’s style arcade system. This allows for multiple users to use the system, and give the department a way to show what reprogrammable hardware can do.  System Block Diagram

 Testing o To make sure that we created the highest quality product, we tested each component separately. We also did testing as we integrated components together. After all components were integrated together, we tested the system as a whole to make sure that it functions as expected.

ESTIMATED RESOURCES

LABOR COSTS We anticipated having to put 10 hours a week into the project. With 5 members on the team, and at an hourly rate of $20, the expected labor costs were around $30,000.

MATERIAL COSTS Arcade controls are inexpensive, but we needed quite a few for a full control panel. All controls were supposed to cost about $100 in total. Cabinet construction was expected to be the most expensive part of the project. Wood and screws were estimated at $130, decorations such as paint and marquees were estimated around $100. Speakers for the cabinet were estimated to be $60. We knew monitor costs would vary based on what size and technology we decide to use as well as what kind of deals we can find. With these considerations in mind, we expected a monitor to cost about $500.

OTHER RESOURCES We had to use the computing labs within the Computer Engineering facility at Iowa State University. This included lab equipment so we could compile and download code to the FPGAs. Additionally, we needed the development FPGAs that were available for other classes at the university.

SCHEDULE

PROPOSED DELIVERABLE SCHEDULE

Deadline Task

Oct. 12, 2010 Project Plan Complete

Nov. 9, 2010 Project Design Presentation

Dec. 3, 2010 Design Document Complete

Dec. 14, 2010 FPGA VHDL complete

End of April Project Complete

PROJECT SCHEDULE

S N D e F O o J A p e a e M u c v c b A M t t e e n g e o u r a p m m u r a u m a r b a c i y s e b b r h l t b y r e r e e y r r r Requirements Design Side Scrolling S/S Audio Audio Board Selection Board I/O I/O Boot Loader Boot Loader CAD CAD Test/FPGA Integration Test/Code Integration Box Construction Box Construction Final Integration Final Integration Document/Present Document/Present10

DESIGN DOCUMENT We will first cover the design as we originally planned. Towards the end of the project we radically changed the design due to client request. This changed design will be covered second.

DETAILED DESIGN

ORIGINAL NES EMULATOR DESIGN Overall, the NES system consists of a few major component blocks. The two largest (and more significant) blocks are the CPU and PPU. These handle the major processing and function of the system on the Xilinx board. The other, smaller components are the different RAM blocks, the input/output control, boot loader, and the data and control buses. The components are described below in detail, as well as illustrated in Figure 1.

CPU: This component handles all of the instructions from the gaming module. In other words, each game instruction must pass through and be decoded and processed by the CPU in order to pass that information to other components of the system. Each instruction tells the NES system how to change the game that is currently being played. It consists mainly of an instruction and control logic decode, arithmetic logic unit (ALU), branch logic, registers, and specific output to other components, like the PPU. The CPU accesses a shared memory with other components to do its calculations, and also uses user input to determine how to proceed.

PPU: The PPU controls all of the visual aspects of the NES. The PPU receives its instructions of what to put on the screen from the PPU. From there, it processes that information and accesses its own memory to retrieve the right images and colors to display. The PPU has its own RAM that stores all of the sprite data and other video processing data.

Boot loader: The boot loader is first initialized when the system is powered on. A GUI will display the available games located on a compact flash drive. Through the GUI, the user will select which game they would like to play. Then the boot loader will initialize the appropriate memories in the NES emulation from the file on the compact flash card.

RAM: There are several different memory modules in the NES system. As previously discussed, the PPU has its own RAM to access and store visual data in. There is also a more general memory block, in which the CPU can access and store the data it needs for its calculations. The memory blocks are 2KB in size.

Data and Control Bus: The data and control buses provide a very important link between each component. The data bus is able to be read and written by each component, but the control bus can only be written to by the CPU as it computes its instructions. The data bus is the method in which the CPU and PPU share data. The CPU will write data to the data bus, of which certain data will indicate that the PPU will start processing.

VRAM 2KB

PRAM SRAM

PPU C D o a n t t a 16 bits 6502 CPU r o

B l

B u s u s

RAM 2KB

Input/ 8 bits Output 8 bits

Game Cartridge

Figure 1: NES System Overview

CPU The CPU handles all the instructions from the gaming module. All instructions from the games ROM file must go through the CPU where it is decoded and then executed by sending the relevant information from that instruction to the other modules in the system. This is required for the system to be able to update itself as the game is played. The CPU requires a way to communicate via shared memory with the other components such as the PPU and user input.

Figure 2: CPU Memory Map

PPU The PPU controls all the video output for the NES. The PPU will receive instructions from the CPU indicating what Name Table, Pattern Table, Palettes, and Attribute Tables to use for each picture. It will store all of these pixels into a video buffer that will then be sent to the VGA component to be displayed.

Functional States

Memory Loading (VBlank): During this stage, the PPU just finished rendering on screen and will be retrieving data from the CPU via special access registers in the PPU. This data is used by the PPU to determine the pixel colors, sprite position, and/or background colors.

Image rendering: During this stage the PPU uses a state machine to generate the video buffer to be displayed by the VGA. Each picture that gets displayed is first sent through this state machine retrieving all the attributes it requires including background color, sprite information, and location. These pixels will be processed starting in the upper left corner going row by row until it reaches the bottom right corner. At this point, another VBlank will occur.

Components

Sprite-RAM: 256 byte set of memory used to store the position and color information of each sprite Video Ram: 4KB set of memory used to store screen information, background details, and additional sprite related data Access Bus: The PPU has two access buses one is used only for accessing dedicated PPU memory. The other is a common shared bus that allows the CPU to pass data to the PPU I/O Registers: 8bit registers used for the CPU to interact with the various components of the PPU Rendering Logic: The part of the PPU that will actually create and render the screen image

Top Level PPU_Control Component

The top level PPU component along with each of the input and output signal descriptions is provided below.

COMPONENT ppu_control PORT( cpu_clk : IN std_logic; ppu_clk : IN std_logic; ppu_reset : IN std_logic; dma : IN std_logic; dmaaddr : IN std_logic_vector(7 downto 0); dmadata : IN std_logic_vector(7 downto 0); busdata_in : IN std_logic_vector(7 downto 0); busaddr_in : IN std_logic_vector(15 downto 0); busread_write : IN std_logic; busdata_out : OUT std_logic_vector(7 downto 0); NMI : OUT std_logic; VBUF_we : OUT std_logic; VBUF_DATA_OUT : OUT std_logic_vector(7 downto 0); VBUF_ADDRESS : OUT std_logic_vector(15 downto 0) );

PPU Control Signals cpu_clk: the clock signal used by the CPU. ppu_clk: the clock signal used by the PPU. ppu_reset: this signal resets the PPU if it is set to one. dma: Direct Memory write enable. This is set to one when initializing the sprite ram from the NES ROM file. dmaaddr: the address in sprite memory to be written or read from for the current sprite. dmadata: the data to be stored into the sprite memory on initialization. busdata_in: this holds the data coming from the CPU to the PPU busaddr_in: the address corresponding to the data coming in busread_write: this signal indicates if data is being written from the CPU to the PPU or vice versa busdata_out: contains the data coming from the PPU going to the CPU NMI: is a non-maskable interrupt used to signal the CPU of a VBlank VBUF_we: is one when writing to the video buffer VBUF_DATA_OUT: contains the pixel data to be written to the video buffer

VBUF_ADDRESS: the address for the VBUF_DATA_OUT data to be written to in the video buffer

Figure 3: PPU Memory Map

The figure above shows how the PPU Memory is allocated and mapped. The VRAM has 16bit address space, but doesn’t contain enough memory to use all of those addresses. Therefore, some of the addresses are mirrored to other memory addresses. Later on, some of these addresses were no longer being mirrored, but rather were referencing additional memory space added to the game cartridges themselves. This allowed more complicated games to be developed and played.

Register Descriptions The PPU has 9 I/O registers that are accessed via memory mapped I/O at the CPU memory locations $2000-$2007 and $4014.

Table 1: Memory mapped I/O

2000 Control Register 1 PPU related control settings

2001 Control Register 2 PPU related control settings

2002 PPU Status Register tells the CPU of the PPU’s status

2003 SPR-RAM Address Specifies the address of the SPR-RAM to write

2004 SPR-RAM Data Specifies the value to write in the SPR-RAM

2005 Scrolling Offset Used in screen scrolling to offset the background

2006 VRAM Address Specifies the address of the VRAM to write

2007 VRAM Data Specifies the value to write in the VRAM

4014 Sprite DMA Used for Direct Memory Access to the SPR-RAM

Note: $2006 requires two writes for each address, because it is only an 8 bit register. However, VRAM has 16 bit addresses.

Pattern Table The Pattern Table stores 8x8 tiles which are available to be displayed by the PPU to the background of the screen.

Name Table Name Tables store a matrix of 32x30 tiles or 256x240 pixels. There are four name tables stored. One name table is sufficient to display an entire screen. However, parts of multiple name tables can be displayed at one time. This is how side scrolling is used in games. Even though only part of a name table is being displayed, the whole name table is generated. This is done, so that the game can simply slide the already generated tiles in the name table onto the screen to be displayed by using address $2005 as an offset.

In figure 4 below, shows how name tables are used to display the image background to the screen. On the left side of this figure is what will be displayed to the user as they are playing the game. The right side shows the four name tables generated by the NES system. The top two name tables are mirrored to the bottom two name tables. The red circle indicates where new pixels are being generated by the NES and the image on the outside of the two black lines is what is actually being displayed.

Figure 4: The left side shows what is displayed to the screen, while the right side shows the name tables used to display the image.

Palette The Palette Table stores all the color information used by the PPU. In order for the images to be in color, the tiles in the Name Table reference the Palette table to get the color they need to be displayed. Since the color is stored in the palette tables rather than the Name Tables, it allows tiles to be reused with different colors.

Sprites Sprites are the characters to be drawn on the screen. Most of the sprites are either 8x8 pixels or 8x16 pixels. These sprites are stored in the pattern tables. An example of a sprite is the Mario character in the figure below. In this example, Mario is constructed using eight sprites. You can also notice how Mario doesn’t appear in the Name Table in the figure provided, because that is added on top of the Name Table. Sprites end up getting displayed by writing them one at a time to address $2003 or $2004. To improve efficiency, the whole SPR-RAM can be written to the PPU in one write to $4014.

Figure 5: This image shows how eight sprites are used to create the Mario character.

REVISED NES EMULATOR DESIGN When we got the project from last year’s group, it had a semi working emulator. Our goal was to fix this emulator to work with more games. To accomplish this task, we started by completely changing the way that the clocks were being implemented. We noticed the current clock design wasn’t very robust. There was one clock that was generated with a phase offset, which is poor hardware design. We also changed the clocks, so the whole system was being triggered on clocks rising edge. Before, different components of the system were being triggered on rising, falling, or a mixture of the two. This is also usually bad hardware design. After fixing the clocks to be more robust, we needed to get the ratio between the CPU and PPU to be correct.

The original NES relied heavily on timing between the CPU and PPU. The CPU would essentially stop working for a certain amount of clock cycles to allow the PPU time to render the next frame. The PPU had no way of signaling the CPU to start working again. Therefore, it relied completely on the timing of the clocks.

Due to the lack of engineering man power and the time constraints our client decided to change the path of the project. Midway through the last semester we met with our client and advisor and we determined that we didn’t have the resources that were necessary to meet our requirements in time for demonstrations. The new approach still meets our functional requirements, but required less time to implement and test.

The revised design is more software focused than hardware, but uses the FPGA as glue logic. We were able to find a software emulator that could be easily ported to the PowerPC processor that is on the FPGA. In the diagram below, you can see the comparison between the original project design and the revised design. You can see that in the original design, the NES emulator was written in VHDL and in the new design the emulator is completely written in C and compiled down into PowerPC instructions that run in hardware. We did not make any modifications to the downloaded emulator aside from remapping the inputs and outputs to the ones on the FPGA.

Rom Files

Boot Loader Rom Files

S/W Level Boot Loader NES Emulator

H/W Level NES Emulator Power PC Xilinx A/V

Audio Video Audio Video

BOOT LOADER The boot loader is a program that will run immediately as the FPGA device is powered on. Its task is to provide a graphical user interface (GUI) that is very user friendly. This GUI will provide a list of available games on the system and will load the selected game into the NES implementation on the FPGA board. This will then allow the user to play the game. Shown below is a high-level overview of how the components of the NES work together with the boot loader followed by a description of how the boot loader operates.

PowerPC

Bootloader C Program

NES Emulator

Compact Flash Controller I/O Interface

Figure 6: System design for boot loader

As shown in the diagram, there are several different components that must work together to correctly implement the boot loader and use it to run the NES. The Xilinx tools that are being used provide a fairly straightforward approach to the boot loader. The PowerPC processer will be used to control the different elements of the boot loader.

The processor will then immediately run a C program that we will write. This program will be what provides the GUI for the user. It will display a list of all of the games that are on the compact flash card that is currently plugged into the board. The user will use the arcade joystick to scroll through the list of games and press a button to select the game. Once this occurs, the C program will use the compact flash controller and go into the compact flash card to find the ROM of the game that was selected. The ROM will then be connected to the emulator memories using different C functions provided by the Xilinx tools. After this connection has been made, assembly instructions will be passed through the CPU and the game will begin playing. There will be a reset button that when pressed will stop the instructions from being fed to the NES and will reload the boot loader C program so that the user can choose another game to play.

BOOT LOADER IMPLEMENTATION The implementation of the boot loader began with a lot of researching and learning the tools that were going to be used. We used Xilinx Platform Studio (XPS) because it allowed us to write a software application that we could run on the FPGA board. A lot of research was required to learn how to add memories to our project and to learn how to access these memories with our application. After getting an understanding of how to use the Xilinx tools, we were able to begin development of the boot loader based on the specifications provided by our client.

It was decided that we would store all required images in memory and copy them into the frame buffer whenever we needed them. These images would be copied from the compact flash drive and stored in memory at the start of the program. This causes a delay of a couple of minutes before the actual program begins but it is only a one time delay every time the board is powered on. Once they have all been loaded into memory, the main menu image background is loaded into the frame buffer. When a user scrolls through the list of games and stops on one, a screenshot of that game is loaded from memory and copied into the appropriate location in the frame buffer memory space. The reason we decided to implement the program this way is because copying from memory to memory would be much faster than copying from compact flash to memory, so the startup screen would show up almost instantaneously, as would all screenshots.

In order to implement the list of games that the user could select from, we had to create a bitmap file of all of the letters and characters we needed in a font that we thought would look good. We could then load this into memory and based on the letters we need to display, pull out data from memory locations of those letters and copy them into the frame buffer memory where we wanted to display the letters. To give the scrolling a nice look, when the user presses up or down to select the next game on the list, the text area on the screen is refreshed with the font moved up several pixels. It does this several times until a new game is in the selection box. The last element of the boot loader that was implemented was adding music. What this entailed was loading .wav files into memory and looping through playing these songs using interrupts. This would allow for the song to play in the background while the user is selecting games.

CONTROLS FUNCTION DECOMPOSITION

CONTROLS The control inputs are an important aspect for NES Emulation. The old system used classic NES controllers and an adaptor to interface the controllers with the FPGA board. Since we will be presenting the final project as an arcade, we are moving to the classic arcade joystick and buttons.

DESIGN TRADEOFF The NES controller made it possible to use a more compact 6-pin interface for the controls. This came at the cost of a more complicated implementation that required a synchronous serial protocol.

With the arcade controls, each of the 8 buttons from the controller are controlled by the switches in the joysticks and buttons. In this implementation, each button is mapped to its own input pin. This method requires a 16-pin footprint but is much simpler to implement.

ARCADE CABINET DESIGN Other than a few minor changes, the original arcade cabinet design was the one used in the final product. We will discuss these few changes as we talk about the design of the cabinet. We researched many different design ideas used by the public to build arcade cabinets to develop our original blueprint of the arcade cabinet. The cabinet will took the form of traditional arcade cabinets with the user standing with the controls at a comfortable level and the

20 viewing screen at eye level. The goal of the design of this cabinet was to mimic as much as possible classic arcade systems from the 80’s and 90’s. The cabinet was completely modeled in Solidworks so detailed measurements could be done before cutting pieces. The overall design consisted of two parts and can be seen below in figure 7 and 8: the base cabinet, and then a detachable control box.

Figure 7: Base Arcade Cabinet Structure without control panel

Figure 8: Detachable Control Panel

BASE CABINET STRUCTURE The cabinet was constructed out of ¾” cabinet grade plywood that could be purchased from any home improvement store. The cabinet was placed on a set of wheels to support movement of the cabinet. After wheels were attached, the cabinet stood approximately 80” tall. The base cabinet is 30” wide. Originally the cabinet going to use ledger boards attached to the inside of the cabinet to hide screw holes and nails. Instead Kreg Joints were used to accomplish the same goal in a more simple way . See figure 9 which shows a cross section of the cabinet. All screws will be inserted from the inside to leave the outside of the cabinet clean.

Screw Position

Figure 9: Screw position will not be visible from outside

As seen in figure 10 below, the top front panel of the cabinet is not covered by plywood. Instead a custom marquee made of Plexiglas was ordered from gameongrafix.com. A florescent bulb was placed behind the Plexiglas to light up the marquee.

Figure 10: Opening for light bulb and custom marquee

The original design for the cabinet had a coin door. It was decided to leave the coin door out because we felt it didn’t add value to the cabinet and it could bring up some legal issues with the project. If the coin door is wanted in the future, it can be easily added to the existing cabinet. The design includes a coin door on the front bottom section of the cabinet. Figures 11 and 12 show the placement of the coin door and the actual coin door to be purchased. There will be no logic behind the actual operation and validation of coins to play the games. It is planned that this can be an avenue of expandability for future groups looking to improve upon our system.

Figure 11: Opening on cabinet for coin door

Figure 12: Coin door blue print

CONTROL BOX AND PANEL The entire control box is detachable from the control cabinet. This is for several reasons. One is that this allows for easy access to the bulk of electronic equipment and FPGA board. Second, this allows for the option of transporting the FPGA and game controls to any location that has a VGA monitor and power supply. This has been designed with the idea of allowing for easy demonstration purposes. Moving the entire arcade cabinet is not easy and takes up a lot of room. With this design the Nintendo FPGA emulation can be more easily demonstrated at events where space is limited, but arcade controls are still possible. Figure 13 shows the overall design of the control box.

Figure 13: Control panel is fixed to hinges

The control panel as seen above can be opened like a lid of a box, so the FPGA can be accessed easily for maintenance and so it can be demonstrated to the user that the NES emulation is running only on a FPGA instead of a computer. The original design was to have the control box open up towards the user as depicted in Figure 13. However, we decided to place the hinges on the other side, so it opened away from the user. This allowed the user to more easily see inside the control box. The button layout is consistent with what has been viewed as standard measurements. After researching several different arcade systems the buttons are spaced 3” from the joystick, and the two buttons are spaced 1.5” apart. Figure 14 shows the layout of the buttons and joysticks for the user. The panel allows for two users, each is given one joystick for directional movement and two pushbuttons for input. The original design was to put a pushbutton located at the top of the panel to allow the user to return to the game selection screen. However, we decided to avoid this button. Instead, we require the user to hold both start buttons at the same time to end the current game and go back to the game selection screen. Another minor change in the actual implementation was the addition of a plastic cover on the top of the box and sides. This provided a better look and feel for the users. Also, it is more durable than the painted wood would have been.

Figure 14: Control panel layout

MONITOR

We decided to use the Makvision Tri-Mode 27”/29” Flat CRT Monitor for our arcade system. This monitor was selected to take advantage of the onboard VGA module that is already on the FPGA board. We decided to go with a CRT Monitor because it was the same technology used in old arcades, and will more closely resemble old arcades rather than a LCD monitor. Also our emulation does not support widescreen display and the largest LCD monitor that is not widescreen was to be around 20”. The Makvision CRT monitor does weigh substantially more than an LCD with a weight of 103lbs, but the cabinet structure was designed to support the extra weight. The table below shows the spec available for the monitor

Table 2: Monitor Specifications

CRT Size 29" (27V) Flat Dot Pitch 0.79mm Video Input Analog 0.7VPP (75Ω)/TTL 2.5-5.0VPP (2KΩ) Sync Input TTL Level Positive/Negative/Separate or Composite H-Frequency 15/24/31KHz V-Frequency 47-70Hz Bandwidth 65MHz Resolution 640 x 480 max Power Supply 100-240VAC 50/60Hz Power Consumption 120W Signal Connector 15-pin D-sub male connector Weight 103 lbs. Approvals TUV, S-Mark & UL

FINAL CABINET The final cabinet closely meets our original design ideas. The only small differences were the joints used to hold together the cabinet, and the coin door not being used. The cabinet was a bright spot for our team because it didn’t require any redesign and our time estimations were very accurate. See figure 15 below to see the final cabinet.

Figure 15: Final Cabinet Implementation

TESTING AND EVALUATION

COMPONENTS As we modified the different VHDL components, we tested them on an individual basis. By testing the components in Modelsim before we integrate them, we saved time and ensured that problems didn’t arise later. There were various software emulators that we used to get the contents of various memories. We then could compare the memory from the software emulator with our implementation. This was an easy way to simulate and check the correctness of the design.

As mentioned earlier, the timing between the CPU and PPU of the NES is very important and difficult to get currently. We tried getting the timing ratio between the CPU and PPU right by running a series of tests we found online. There were hundreds of tests available online to test CPU timing, PPU timing, sprites, sprite collisions, every instruction of the 6502 processor, etc. For each test, we would initially run it on a software emulator so we

26 could determine what output we should expect. Also, some of the tests didn’t even pass on software emulators, so we assumed they were not very crucial to get working. Next, we would run the test on the board and check to see if we were already passing it. If we weren’t passing the test, we would simulate it in software using Modelsim to determine exactly where/why the test was failing. Since our system was so large, it took Modelsim along time simulate the design. This is the major problem we ran into when trying to keep on schedule for our project. Next, we would make the necessary changes to the system to ensure the test would pass. We would run the new code through synthesis to ensure there weren’t any syntax errors in the new code. After getting the synthesized code onto the FPGA, we will make sure that the system performs as we expect according to our functional requirements.

CABINET TESTING One of our non-functional requirements was to ensure that our button layout is easy to use. We constructed the control panel first and made sure that the buttons are all easy to use during gameplay. After the cabinet was constructed, we did user testing on the cabinet to ensure that the arcade control and feel were convenient to them. We tested the system for robustness by having many people use the system at both the Friday Activities at Noon event and the VEISHEA event.

BOOT LOADER The first piece of the Boot Loader that we implemented was reading data from a compact flash card. Our main testing tool for this portion of the project was the serial output of the FPGA board. Using the serial output, we were able to print out error messages to give us details about what was happening throughout the reading process. One problem we ran into while reading from the compact flash card was a character limit on filenames. We are using a SysAce IP core provided by Xilinx which requires that the filename be 8 characters or less with a 3 character file extension. Our printouts allowed us to see that only some of the file reads were failing. From there we discovered the 8.3 filename requirement.

The second piece of the Boot Loader is drawing data to the monitor. We used the Xilinx Tft (XTft) module to control the DVI output on the FPGA board. We ran into some issues getting this module configured correctly. To test the XTft functionality we simply wrote a green color value to every pixel in the frame buffer memory space. Once it was configured correctly we could simply download the project and it would display the green frame buffer to the monitor. After solving our XTft issues, testing became very straightforward. The data we want to display are simple .bmp files. We would read the files and dump the data into the frame buffer. The .bmp files would show up on the monitor and the bugs became apparent with distortions.

The final piece of the Boot Loader was the font. First we had to mock up a few simple screenshots to see which font would suit our Boot Loader best. This came down to personal preference of our client. After creating and implemented drawing the font, we had to test the gray scale blending with the background. The first iteration printed a lot of bright colors we didn’t want near the edges of the letters so we refigured our blending math to prevent the saturation that was occurring. The first iteration of scrolling had each line scrolling down then jumping up to the line above. This turned out to be a simple sign error when determining the Y-coordinate for the line in the new frame.

FULL SYSTEM TESTING After the full system was assembled with all the hardware in it we made sure that all of the games worked. We went through every game making sure that it worked well with our emulator.

ACKNOWLEDGMENTS  Senior Design group May10-01 (FPGA-based NES Emulator) o Ashley Good o David Graziano o Tim Meyer o Ben Petersen o Matt Saladin  Philip Jones (Advisor)  Joseph Zambreno (Client)  Mike Steffen  Jim Jensen  ISU ECPE Department

CLOSING MATERIAL

REFERENCES “Cabinet Plans 2: Cutting Side One.” http://www.arcadecab.com/CabinetPlans2/CabinetPlans2_Cutting_Side_One.html

“Custom Designed Marquee.” http://www.gameongrafix.com/products/Customer-Designed-Marquee

Diskin, Patrick. “Nintendo Entertainment System Documentation.” August 2004. http://nesdev.parodius.com/NESDoc.pdf

Donaldson, Jonathan W. “VeriNES Emulator (a.k.a. NES-on-a-Chip)” https://rm-rfroot.net/nes_fpga/

NesDev. http://nesdev.parodius.com/

Senior Design May 2010 Team 1. http://seniord.ece.iastate.edu/may1001/index.html

Suzo Happ. http://www.happcontrols.com/

“Xilinx ML507 Base System Builder Design.” http://www.xilinx.com/products/boards/ml507/ml507_12.1/bsb.htm#ml507_std_ip_pcore_design

TEAM INFORMATION Client: Joseph Zambreno [email protected] 327 Durham Ames, IA 50011-2252 515.294.3312

Advisor: Phillip Jones [email protected] 329 Durham Ames, IA 50011-2252 515.294.9208

Team Members: Tony Milosch [email protected] 2922 West Street Unit 1 Ames, IA 50010 815.978.9972

Cory Mohling [email protected] 2635 Knapp St Ames, IA 50014 319.551.7785

David Gartner [email protected] 1225 Frederiksen Court Ames, IA 50014 651.341.6149

Danny Funk [email protected] 2922 West Street Unit 4 Ames, IA 50010 515.681.8766

John Alexander [email protected] 4536 Twain Circle Unit 2 Ames, IA 50014 515.290.9723

APPENDIX

OPERATIONAL MANUAL Overview created by 491 Team Dec1104

492 Project title: FPGA NES Emulator

492 Project team: John Alexander, Danny Funk, David Gartner, Tony Milosch, Cory Mohling

Advisors: Joe Zambreno and Phillip Jones

1. What is the high‐level objective of the project? (2‐4 sentences)

The main goal of this project was to showcase FPGA technology. This team took over the project, adding more functionality and games to the system. They took the previous system and finished it. From the previous project they integrated side scrolling, sound, implemented more games, boot loader, and constructed a game cabinet.

2. What are the key functional requirements of the system? (2‐4 requirements)

-implement a boot loader that will display and execute the game collection

-implement a graphical use interface for selecting games

-provide physical support for two players

-construct a cabinet to showcase NES emulator and monitor.

-Cabinet must support 100lb monitor and run on standard power outlet

3. What has been actually implemented? (1‐2 paragraphs)

• Provide a brief description of the functioning of the implemented system, the hardware, software, and other equipment’s used in the system.

Hardware:

-FPGA board

-speakers

-CRT monitor

-game cabinet

Software:

-VHDL

-C

-NES Roms

-This group implemented a working boot loader on a micro blaze micro processor

-fetches NES roms from flash memory card

-Software emulator to run NES roms

-Fully functional game cabinet.

-supports 2 players

-2 speakers

-CRT monitor

4. How to setup the system? (~1 page in bulleted list form)

• Provide a step‐by‐step instruction on how to setup/demo and test the operational system

-plug in

-div switches need to be set

-turn on FPGA board

-system starts loading from flash

-menu screen appears with game list

-game is selected by pushing a or b

-at any time the player can return to the main screen by pressing both white buttons

Testing

-Put software emulator on FPGA

-used nesdev.com to test rom files

-test roms had debug information if something failed

-tested roms by playing, sorting out the bad ones

5. Test results observed?

• Specify the tests and associated results

Most of the testing was from the site nesdev.com using test roms. Roms displayed error messages targeting what went wrong. Roms were also tested on student’s computers with software emulators.

If roms didn’t work they simply removed from the game library. It was hard to tell if the rom was faulty or the emulator. They couldn’t fix them since they didn’t right the emulator.

6. Critique of the project

• Provide at least one strength and at least one weakness of the implemented system

Strength:

Cabinet: it was well planned out and implemented with no assistance from outside sources. The cabinet really pulled the project together and displayed their hard work.

Weakness:

project used separate architecture. Project was supposed to be implemented all in hardware but they resorted to some software emulator that was simulated on the FPGA board. So in a roundabout way it was operating in hardware but not everything was implemented in hardware. Since outside sources were used it was hard to test and debug errors for roms and testing the audio.

• Does the implementation meet the specification? In either case, provide a brief discussion.

From the last question this project did not exactly meet all specifications when it comes to how the project was implemented. Not everything was implemented in hardware. That being said everything was accomplished and it worked.

• Suggestions, if any, for alternate designs/implementations/platforms.

After talking with the group I would not change anything with the design. The decisions that were made were for a good reason given time constraints and resources.

Detailed instructions

SET UP

1. Make sure dip switches are set properly a. There are 8 switches on the corner of the FPGA i. Switches 1-3 should be 0 ii. Switches 6-8 should be 1 iii. Switches 4 and 5 control audio volume 4 = 0, 5=0 Volume Muted 4=0, 5=1 Volume at lowest setting 4=1, 5=0 Volume at medium setting 4=1, 5=1 Volume at max setting (recommend against) b. There are 8 switches in the middle of the board

Switch Number Setting 1 0 2 0 3 0 4 1 5 0 6 1 7 0 8 1

2. Make sure monitor, audio, and controls are plugged into FPGA 3. Make sure Compact Flash Card is plugged in 4. Plug power string in 5. Turn power strip on 6. Wait for system to but up (about 5 minutes)

GAME PLAY

1. Buttons a. Joystick: used for movement b. Button immediately to the right of joystick is button A on the original controller c. The next button to the right is button B on the original controller d. The start button for P1 is the white button on the side (left player1, right player2). e. The select button is the green button on the side of the control box. 2. On startup, the game selection menu will be available. Whatever game is highlighted is the selected game. Player 1 can select a different game by moving the joystick up or down. Player 1 can start the selected game by pressing either A or B. 3. In order to go back to game selection screen, both left and right start buttons have to be pressed and held.