Multi-Arcade Emulation System

(1)

Multi-Arcade Emulation System

Final Report

Group Members

Jonathan Henze Kevin Moore Brandon Otto Richard Rojas Marvin Toeung

Client and Advisor

Joseph Zambreno

May 12-14 4/27/12

(2)

SD May 12-14 Final Report 1

SD May 12-14 Final Report 2

6.1.4 Emulator Setup ... 17

6.1.5 LED Controller Setup ... 17

6.1.6 Game Selection Interface ... 18

6.1.7 Cabinet Work: ... 18

6.1.8 System Integration ... 18

6.1.9 Testing ... 18

6.2 Project Schedule ... 19

6.3 Risks ... 20

6.4 Statement of Work ... 20

7. Bill of Materials ... 22

8. Design Document ... 24

8.1 Original Design ... 24

8.2 Collaboration... 24

8.3 Front End Software Design ... 24

8.4 Game Lists ... 27

8.5 Control Box ... 28

8.6 LEDs ... 28

8.7 Cabinet Design ... 31

8.8 Cabinet Construction ... 32

8.9 Display ... 38

8.10 N64 Game Implementation ... 38

8.11 Results ... 43

9. Testing and Evaluation ... 44

9.1 Testing... 44

9.2 Evaluation ... 47

10. Closing Materials ... 49

10.1 Contacts... 49

11. Appendix ... 50

12. Standards ... 54

Figure 1 - The Control Box ... 8

Figure 2 - The Cabinet ... 9

Figure 3 - Hardware Block Diagram... 10

(4)

SD May 12-14 Final Report 3

Figure 4 - Software Block Diagram ... 11

Figure 5 - Project Schedule ... 19

Figure 6 - SDEC In Action ... 25

Figure 7 - Sorting options in SDEC ... 27

Figure 8 - Original CAD design of the control box ... 28

Figure 9 - LED configuration for N64 ... 29

Figure 10 - Mapping of buttons & LED colors to N64 controller, shown when launching a N64 ROM ... 30

Figure 11 - LED setup while running SDEC ... 30

Figure 12 - Original CAD design of the cabinet (front) ... 31

Figure 13 - Original CAD design of the cabinet (side) ... 32

Figure 14 ... 32

Figure 15 ... 34

Figure 16 ... 34

Figure 17 ... 34

Figure 18 ... 35

Figure 19 ... 35

Figure 20 ... 36

Figure 21 ... 36

Figure 22 ... 37

Figure 23 ... 37

Figure 24 ... 37

Figure 25 ... 37

Figure 26 - Early test of build environment, reading controller input, font and 3D rendering ... 39

Figure 27 - Test of team developed model and texture conversion tools ... 40

Figure 28 - Pong64 in action ... 41

Figure 29 - ISU Football players playing Super Smash Bros on MASE during VEISHEA ... 43

Figure 30 - LEDs running all white ... 45

Figure 31 - LEDs running SDEC diagnostics ... 45

Figure 32 - SDEC Diagnostic screen ... 46

Figure 33 - RCA & S-Video connection ... 50

Figure 34 - Motherboard ... 50

Figure 35 - Locked Cabinet Arms... 51

(5)

SD May 12-14 Final Report 4

1. Glossary of Terms

Console: A machine designed to play video games for home use CprE: Computer Engineer

CPU: Central Processing Unit CRT: Cathode Ray Tubing

DInput: Direct Input, Microsoft’s API for interfacing with game controllers DirectX: Microsoft’s API for interfacing with 3D graphics hardware DMA: Direct Memory Access

DVI: Digital Visual Interface EE: Electrical Engineer

FPGA: Field Programmable Gate Array

GC: Nintendo GameCube, Nintendo’s competition for the PS2 GPU: Graphics Processing Unit, a video card

GUI: Graphical User Interface

HDMI: High Definition Multimedia Interface

HLSL: High Level Shading Language, the shading language using by DirectX ISU: Iowa State University

LCD: Liquid Crystal Display LED: Light Emitting Diode

MAME: Multiple Arcade Machine Emulator

MASE: Multi-Arcade System Emulator, refers to the entire system built in this project N64: Nintendo 64, Nintendo’s first system to feature a 3D graphics processor NES: Nintendo Entertainment System, a console created by Nintendo in 1985

OS: Operating system

OSHA: Occupational Safety and Health Administration

PSX: Sony PlayStation, a CD based console featuring 3D graphics PS2: Sony PlayStation2, Sony’s successor to the PlayStation

(6)

SD May 12-14 Final Report 5

RCA: Radio Corporation of America, created standard audio/video cables for composite RGB: Red, Green, Blue

ROM: Read only memory. Console games are loaded into emulators from ROM files RTOS: Real Time Operating System

SDEC: Senior Design Emulator Conglomerator, refers to the custom front end software SDK: Software development kit

Shader: A GPU executable program that determines how objects are displayed SNES: Super Nintendo Entertainment System, Nintendo’s successor to the NES VEISHEA: An ISU festival in April celebrating the different colleges

VGA: Video Graphics Array

XInput: Microsoft’s API for interfacing with Xbox 360 compatible controllers

XNA: XNA is Not an Acronym, a .NET game development framework written by Microsoft

(7)

SD May 12-14 Final Report 6

2. Problem Overview

2.1 Executive Summary

Iowa State University draws students from all over the world. Because of this, there must be interesting, and challenging problems for the students to work on. One field that students commonly work in is embedded systems. Some systems include: cell phones, video game consoles, robots, and other small, mobile electronics. Each of these systems involve minor input, if any, from the user, require relatively small hardware, have a low power consumption, and are associated with having a low overall cost for the system.

The project idea of creating an embedded multi-arcade system was given to the computer and electrical engineering faculty to display skills that make Iowa State University a leader in technological

advancements, as well as to advance the learning of the students.

A team of five members, consisting of three computer engineers, one software engineer, and one electrical engineer was given the task of completing this project. From designing the cabinet of the arcade system, to fully fleshing out the wiring, programming of the emulators, and setting up the system controls, this team had to do it all. The students have had enough previous experience in their coursework to complete this task.

This project is a continuation of a previous Senior Design project. In the previous iteration, a team of engineers created a hardware emulation of a Nintendo Entertainment System, using a FPGA(Field Programmable Gate Array) board, essentially recreating the system with hardware. While the current team is doing something similar in appearance, it is fairly different in essence. The previous group approached the emulation with hardware, making it a fairly costly solution. The current team is

expanding the project, approaching this from a software perspective, making the project smaller, and less expensive. On the system level, the team is doing something completely different than the previous group.

In this document, the team will go over the design of the project as a whole, and each of the systems required to complete the final project.

2.2 Market and Literature Survey

Technology is always getting better. Because of this, there will always be old technologies and in this case, games that will be left behind. However, there are some classics that a generation will find nostalgic and will want to play later. That is why emulation is still big today, some example platforms being Xbox Arcade, PlayStation arcade, WiiWare games and PC emulation software. There is a multitude of

emulation software simulating all kinds of hardware as far back as the ATARI 2600 (released in 1977), and as current as the Nintendo Wii (released in 2006). Typically, these emulators are open source projects written by a team of dedicated enthusiasts. Many of the emulators have been ported to run on a

(8)

SD May 12-14 Final Report 7

variety of different systems, most notably the x86 platform.

2.3 General Problem Statement

We had last year’s completed project in hand, a hardware based complete NES emulator with game selection options. However, that system was expensive and incapable of emulating more than a single console. To make the system further presentable we needed to upgrade to a software emulation to allow for multiple consoles and create our own graphical front end to handle the variety of consoles and games we wanted. Furthermore, since we upgraded to allow for systems with up to 4 possible players, we needed to create a new arcade cabinet to house our entire system.

2.4 General Solution Approach

To enable more emulators, we needed a powerful enough CPU to handle our most intensive video game console, which in our case was roughly a tie between the PS2 and the Nintendo Wii. We researched processing requirements versus costs to determine an efficient yet affordable system. To handle the new playable consoles we researched how many buttons at most would ever be necessary and we created several prototypical designs that could comfortably handle 4 players and all their necessities. Then in order to create a single graphical front-end to handle everything, we used the XNA framework with access to a basic database of everything stored in simple csv files.

3. System Overview

3.1 System Description

The system will be presented as an arcade cabinet featuring a sturdy frame, a large LCD or CRT display, a set of built in speakers and an area for player controls, which will contain a joystick and eight buttons for each player. The player control area will feature an LED display under the buttons which will light up only the buttons that are valid for the player configuration and game selected. At the core, the system will be powered by a small, affordable ARM-based embedded platform which will perform all of the

emulation in software. The ARM board will be connected to the display via HDMI or DVI and will provide audio to the speakers via an 1/8th inch audio jack. Users will be able to view the embedded system and other hardware components by lifting a lid under the control area.

The ARM board will run a Linux based OS. Upon starting the system, the OS will load our custom

(9)

SD May 12-14 Final Report 8

software to provide a user interface to select games to play. When the user chooses a game, the application will launch the appropriate emulator program to run the game. The player will be able to return to the selection program via a button, at which time the emulator program will be terminated.

3.2 Concept Sketch

The original sketch was based off some original arcade machines with a few alterations to make it fit the specifications. With following some of OHSA’s recommendations on sizing and standard accessibility, we came up with a basic concept that uses four players. The design for the button layouts was also designed specifically to fit the normal structure of the hand. This design can be seen in the figures below:

Figure 1 - The Control Box

(10)

SD May 12-14 Final Report 9

Figure 2 - The Cabinet

(11)

SD May 12-14 Final Report 10

3.3 Block Diagrams

3.3.1 Hardware Block Diagram

Figure 3 - Hardware Block Diagram

(12)

SD May 12-14 Final Report 11

3.3.2 Software Block Diagram

Figure 4 - Software Block Diagram

3.4 Operating Environment

The primary operating environment of the system will be indoors, such as in Durham and Coover halls.

These environments have relatively controlled temperatures of roughly 20 - 25 degrees Celsius, which will provide adequate cooling. The board itself will operate within a protective enclosure that fits inside the cabinet.

3.5 User Interface

The system will boot into a start-up screen and then proceed into a game-selection menu. The game- selection menu will allow the user to sort the games in a number of different orderings including game system, release year, number of players, and alphabetically. Once a game is selected, the proper emulator is launched to play the game.

(13)

SD May 12-14 Final Report 12

The user control of the system will be a series of buttons and joysticks on a horizontal panel. Each player will have a single joystick and eight face buttons to control. Since not all of the buttons will be used for every game, the software will light up the buttons that are used for a particular game, following a color coding scheme to match the original console. In addition to the face buttons, each user will also have two control buttons, primarily used as start and select buttons. Pressing both of these buttons at the same time will drop the user back into the game selection menu.

3.6 Intended Users and Uses

3.6.1 Intended Users

The intended users are prospective students visiting the ISU College of Engineering as well as members of the general public who are interested in gaming technology.

3.6.2 Intended Uses

The system will be used as a demonstration of an interesting project made by ISU ECE students that prospective students could look forward to working on. It will be showcased at different events such as VEISHEA for members of the general public to enjoy. While not in use, the cabinet may be kept in storage, but the control box must be removable and be able to operate independently. When the system is brought out of storage, the control box must be removed and transported separately in order for the cabinet to fit through doors.

(14)

SD May 12-14 Final Report 13

4. Proposed Approach

4.1 Functional Requirements

FR1 The system must be able to emulate at least four different consoles.

The emulated consoles will be chosen from the following list: Atari 2600, NES, SNES, GameBoy, Sega Master System, Sega Genesis, Sega Saturn, N64, PSX, Sega Dreamcast, PS2, Nintendo GameCube, Wii.

The decision of which consoles to include will depend on the ease of implementation and integration of the publicly available emulators for each system, the popularity of video games available on the platform and the current emulation state of the art available for the system.

FR2 The system must implement a MAME system.

MAME will allow us to run almost any classic arcade game we choose to install. Since our cabinet is designed to look like a classic arcade system, these games will be a huge asset for the attraction of the system.

FR3 The system will allow for input for up to four players simultaneously.

Not all games are made for four players, but any games that are made for four players should be playable for four players. The cabinet control box will have controls for four players to play simultaneously.

FR4 The input control scheme will provide enough buttons to map to all of the required buttons in all emulated games.

The N64, with six face buttons and three shoulder buttons would likely require the most buttons, but it is not necessary to support all three shoulder buttons because only two were ever used at a time. For newer consoles with dual analog stick controllers, it may not be possible to include all required controls for every game, so only games that can function with the provided control setup may be admitted to the system.

FR5 The system will follow all the OSHA wiring requirements listed here:

http://www.osha.gov/pls/oshaweb/owadisp.show_document?p_table=STANDARDS&p_id=9881.

These requirements are titled ‘Wiring design and protection’. Following these requirements will keep up safe from harm when assembling the electrical components of the system. They will also make sure that the end product is safe for the users.

FR6 The team will be following the recommended OSHA safety regulations involving computing device stations as noted here:

http://www.osha.gov/SLTC/etools/computerworkstations/checklist.html

These safety guidelines are recommendations for making our system ergonomically safe and comfortable for the user.

FR7 The core system must be removable and be able to run connected to a separate display and speakers.

(15)

SD May 12-14 Final Report 14

The ‘core system’ is the control box and all of the electrical components contained within. This should be all of the components except the TV, speakers, and cabinet.

FR8 The team must have a product completed enough to demonstrate at VEISHA.

Most of the project should be complete by this time, but the team may not have all of the emulators completely working or all the games added that will be included in the final deliverable.

4.2 Non-functional Requirements

NR1 All provided games must run at a playable frame rate, defined as at least 90% of the frame rate the original console would provide for the given game.

In order to provide a satisfactory experience, the games must not run excessively slow. Some of the games experienced slowdowns on the original consoles which may be accurately emulated. This is still acceptable, as it recreates the original experience.

NR2 The input devices must respond to user actions within an acceptable time frame, defined as within 50 milliseconds.

Many video games require relatively precise timing in order to complete certain objectives in the game. A maximum delay of 50 milliseconds will have a negligible impact on game play.

NR3 All emulated games must be fully playable with no game breaking glitches.

A game breaking glitch is any glitch that prevents the player from progressing in the game or completing a game objective. A player should be given the same game completion experience that they would have playing the game on its original system.

4.3 Testing Requirements Considerations

Every game on the system must be individually tested to ensure no serious problems are present as to satisfy NR1 and NR3. Emulators are highly configurable, so it may be that some games work better under specific configurations. If a failed game is popular enough, additional testing may be needed to try different configurations that may allow the game to be permitted.

4.4 Safety Considerations

The cabinet must be structurally sound and be able to withstand common abuse from simple use. The cabinet must not collapse under the weight of the TV, control box or from users leaning slightly on it while playing.

(16)

SD May 12-14 Final Report 15

4.5 Commercialization Considerations

The system is intended for educational, nonprofit use only.

4.6 Possible original risks and risk management

1. Emulators either run too slowly, take too much time to implement on our own, or have too many glitches. This could cause us to be unable to implement our intended number of emulators by the delivery date. This was solved by hand picking games that would not overextend the most powerful emulators as well as buying a powerful quad-core system to process all the information.

2. Using a CRT is a risk in itself. The monitor is very heavy and required multiple people to just move it.

3. While the cabinet is built to be fairly stable and under normal circumstances no risks should occur, a significant amount of effort (such as running and falling into it) can knock it over and cause severe damage not only to the cabinet but also any bystanders as it is very heavy.

(17)

SD May 12-14 Final Report 16

5. Deliverables

D1 We will implement a software emulation of at least four different classic video game systems as well as a MAME system.

D2 We will create a custom control scheme for at most four different possible players at once on our system.

D3 Each individual player’s control scheme will support all possible emulated systems by simply disallowing the use of the unneeded buttons of each system.

D4 Each player’s control scheme will have eight buttons that light up according to the system button configuration, as well as a joystick.

D5 This will all exist on a custom wood-built cabinet frame, with a detachable control unit box that can show the internal workings within.

D6 A custom graphical front-end will be created for simple and quick access to any console/game.

(18)

SD May 12-14 Final Report 17

6. Work Plan

6.1 Work Breakdown Structure

6.1.1 Research Every group member

For this part, the team is doing the main planning and design of the project. The embedded board, the systems to emulate, and the structure of the cabinet are all chosen and deliberated during this phase. This portion of the plan was contributed by all members of the team.

6.1.2 Parts Requirements Every group member

Each of the parts consisting of the final design for the cabinet was chosen here. The team then ordered the parts that were required. The team was able to receive a free Panda Board, so there was no purchase made for that item.

6.1.3 Panda Board Setup Jonathan

This includes the setup of the OS, drivers, packages and application software that the team will require. It must be validated that the OS and application software are functioning correctly and with adequate performance.

6.1.4 Emulator Setup Jonathan

The emulators will be compiled from source to run on our embedded system. The required libraries will be downloaded as needed. There will be a lot of debugging to make sure that it works with the system, and displays correctly.

6.1.5 LED Controller Setup Kevin and Marvin

Every button uses a configurable intensity of light from three LED’s. The LED controller will change the intensity of the light to match the colors of the system controller, for easier recognition for users. This will need to be controllable at run-time by the Game Selection Interface so it can be set to match the currently running emulator. The PacLED64 controller used has an open-source, Windows based SDK to allow this, but it will need to be ported to Linux for use on the Panda Board. In order to test the port and the functioning of the LED controllers, demo programs should be written that light up the LEDs in different patterns. One or more of these demo programs may be used to set up an interesting display while the arcade unit is idle (“attract mode”).

(19)

SD May 12-14 Final Report 18

6.1.6 Game Selection Interface Brandon, Jonathan, Kevin and Marvin

The Game Selection Interface is a single GUI that will control and give access to all games across all available emulated systems. All games will be sorted based on a variety of different options, including alphabetically, date of publishing, console system originally made for, etc... From the GUI, any game should be able to be started and playable with as few button presses as possible.

6.1.7 Cabinet Work: Richard

This task involves the design, construction and wiring of the cabinet and control box. The control box houses the Panda Board, joysticks and buttons, and must be detachable from the rest of the cabinet. The cabinet must have a sturdy wood frame capable of supporting the weight of the TV and other components.

Decoration of the cabinet is also included, such as painting the sides, adding decals and adding a lighted marquee. Richard will be primarily in charge of the cabinet design, but other team members will help as needed with the construction and wiring.

6.1.8 System Integration Every group member

After the cabinet construction is finished and wired, the system must be fully integrated into the cabinet.

This means that the control box must be finished and housing the Panda Board, the software must be configured to accept input from the buttons and joysticks instead of a separate keyboard and the TV must be placed in the cabinet. It should be validated that the system as a whole is in a functioning state at this point.

6.1.9 Testing Every group member as well as outside participants

We will have each component tested by each respective team member. Once that is verified, we will then testing each game’s compatibility with the emulators, and will admit or reject games based on how well they function. This phase will involve outside assistance to help test every game proposed.

(20)

SD May 12-14 Final Report 19

6.2 Project Schedule

Emulator Setup: December - January LED Controller Setup: January - February Game Selection Interface: January - March Cabinet Building: January - March

Full Game Rom: February - April Systems Integration: March – April

Figure 5 - Project Schedule

However, we faced difficulty in compiling the libraries on the board, as well as making the board work with our TV, which was our output to the user. The signal wouldn’t work with our converter box, and with the budget we were given, we had already spent too much on the materials, and the option of having to go through costly converter boxes to find one that works didn’t bode well for our team. Therefore, we

(21)

SD May 12-14 Final Report 20

moved the project in a different direction. We decided to use a Windows 7 machine on a miniITX board, and moved from the full emulator port to a N64 Rom image that would play on the N64 emulator, with a interface GUI that would handle all of the emulation processes.

6.3 Risks

Emulators either run too slowly, take too much time to implement on our own, or have too many glitches.

This could cause us to be unable to implement our intended number of emulators by the delivery date.

Emulators are large, complex pieces of software that often mix C and assembly routines, commonly written x86. Porting one of these programs to ARM is no simple task and will require intimate

knowledge of both x86 and ARM. There may be many unforeseen problems encountered with the port that we may not be able to overcome in two semesters. In this case, we would likely replace our ported emulator with one ported by the emulation community.

6.4 Statement of Work

There will be a new wooden cabinet created for this project. The cabinet must be able to hold at least 250 pounds, the majority of which will consist of a 36” Sony Vega Television screen used as our display monitor. The cabinet will use a detachable control unit box, which will consist of four player controls, each one having one joystick and ten buttons per player. The buttons used by the players will all have three LEDs of red, green and blue colors. This is done so that each button can light up any color within the same possible spectrum as the monitor to specify system configuration and button controls of the current game. Richard is designing and building the cabinet, and the whole team is working together on the wiring of it. The team will wire all the required electronics in a manner such that the wires will be hidden within the cabinet to prevent all possible safety risks according to OSHA standards as well as to remove the majority of the visible evidence of the wires to reduce the amount of eye-sores created by the wires. Wiring will take place after the cabinet frame is built.

The system will include custom front end software created by the team to handle selection of games. The front end software must be able to be controlled entirely by the joysticks and buttons. Selecting a game must switch the display and control over to the appropriate emulator. The user must be able to quit the game and return to the front end software by a special button press combination. The front end must also be able to regain control if an emulator crashes without any additional input needed from the user. At no point should an end user ever need to use a keyboard or mouse to control the system. The system will be running Windows, but this fact should be hidden as much as possible. New games and emulators should be easy enough to add to the software without needing to recompile it. The front end software should be fast and responsive.

(22)

SD May 12-14 Final Report 21

In addition to the front end software, the team will also develop an N64 game to showcase embedded development. Much research will need to be done on how to implement this, as well as creating any additional required tools or libraries. Additional games made by the team may also be featured on the system to interest prospective students.

These deliverables need to be completed by VEISHEA, a festival on the Iowa State campus, for demonstration purposes. This will be held April 21st 2012.

(23)

SD May 12-14 Final Report 22

7. Bill of Materials

Item Description Individual Cost Quantity Cost

3 Ply Pine Sheathing** 15/32” x 4’ x 8’ $11.96 6 $71.76

Pine stud (frame)** 2’’ x 4’’ x 8’ $1.97 10 $10.97

Hinges** 2.5” $2.28 5 $11.40

Casters 225 lbs $6.46 4 $25.84

Motherboard Intel H61 Chipset, Socket LGA 1155, Mini ITX

$50.00 1 $50.00

CPU Intel Core i3 Sandy Bridge $130.00 1 $130.00

RAM 4GB DDR3 1333 $20.00 1 $20.00

USB Hub 10 port, powered $26.00 1 $26.00

Power Supply 380W $17.00 1 $17.00

Hard Drive 500GB $80.00 1 $80.00

LED Controller PacLED64, can drive 64 LEDs $59.00 2 $118.00

Joysticks UltraStik 360, can also drive 8 buttons per stick

$59.00 4 $236.00

Buttons Electric ICE 2 Lightable

Pushbuttons, includes RGB LEDs

$6.50 32 $208.00

(24)

SD May 12-14 Final Report 23

Button Controller IPAC2, drives control buttons (other buttons are controlled by UltraStik 360 units)

$39.00 1 $39.00

Wires Est. $20.00 Est. $20

Screws 2-3” Est. $0.05 Est. 128 Est. $6.40

Display Sony Wega 36” TV, second hand $50.00 1 $50.00

VGA to S-Video Converter

Allow display from our host platform to the TV

$39.92 1 $39.92

Speakers Built in to Sony Wega N/A N/A $0

Table 1 – Bill of Materials

**Many of the construction materials may be obtain through personal pricing.

Total Cost: $1160.24

(25)

SD May 12-14 Final Report 24

8. Design Document

8.1 Original Design

Originally, the project was to be implemented on an ARM based PandaBoard. After much research and experimentation during the fall semester, it became clear that continuing with the PandaBoard posed a serious risk of the project not being complete on time due to numerous software and driver

incompatibilities and an excessive amount of time spent troubleshooting. At the start of the spring semester we conferred with our advisor and decided to scrap the PandaBoard in favor of an Intel based design running Windows. This freed up the team to put much more time and effort into creating a polished front end as well as develop and debug software from home on our personal computers, and the increased power of the system allowed GC, PS2 and Wii games to be emulated. The move also caused the project to lose some of the technical appeal it originally had, since the backend was now essentially off the shelf desktop PC components. In order to keep the technical appeal of working with embedded systems, it was decided that the team would also write an N64 game. The N64 was chosen because of its use of a MIPS processor (MIPS assembly is taught in CprE 381), simple 3D graphics and the ability to program in C instead of pure assembly.

8.2 Collaboration

The team used an SVN server to share software work for both the front end program and the N64 game, as well as include useful additional documentation about the N64 and external libraries for interfacing with the joystick and LED controller hardware.

8.3 Front End Software Design

The front end software, SDEC, is written in C# using XNA. Using a managed language like C# allows the team to quickly implement code without worrying too much about memory management, while still maintaining good performance on a modern system. Using XNA provides a managed DirectX interface without needing to go through the arduous task of making all the OS calls to create a window with a graphical context while avoiding the ugly DirectX API. It is important to note that XNA is not a game engine, instead it is merely a framework providing a clean API to interface with DirectX along with some useful math functions and content importers.

(26)

SD May 12-14 Final Report 25

Figure 6 - SDEC In Action

The display of the front end was done entirely in 3D to increase visual and technical appeal. In order to render 3D text, a 3D model was created for each character that could be used. Some game titles could be quite long, so it was necessary to measure the world space size of the string and word wrap it to prevent it from clipping with other display components or running off the screen. All characters had to be drawn suitably large to look nice on the TV display, as thin lines can cause flickering on CRT displays. Lighting in the scene was carefully tuned to enhance the 3D effect and draw attention towards the center item.

Some visual flair was added when a game is selected with matching audio cues. All shaders used were written by the team in HLSL.

The main program execution alternates between updating the scene based on received input and drawing the scene in a tight loop. In order to maintain maximum performance of 60 frames per second, this loop must have a period of no larger than ~16 milliseconds. In order to meet this performance goal, the main update loop is treated as a soft real-time task that takes priority over all other tasks in the front end. Any task that cannot be completed within a couple milliseconds is offloaded to a different thread to be handled asynchronously. Such tasks include loading game box art, loading the next video to play, checking for joysticks that have been lost due to nonshared use by an emulator or a disconnected cable and safely terminating a previously launched emulator. Additionally, all audio processing is handled on a separate thread. SDEC uses a Thread Pool to handle dynamically creating and destroying threads based on

(27)

SD May 12-14 Final Report 26

application requirements using up to one software thread for each hardware thread supported by the CPU, rather than needing many threads that spend most of their time sleeping. Our CPU is a quad core with hyper threading to support 8 hardware threads. SDEC is always running the main game thread and the audio thread, but depending on the load can run up to 8 additional threads for a total of 10. Generally, the usage falls between 2-4 threads, which has great performance on our quad core system.

Sometimes it is useful to be able to model behavior over an extended period of time, such as the simple case of activating an animation, animating it and then waiting for it to finish before proceeding to the next step. Since all functions called from the update loop must terminate in a timely manner, this can be somewhat of a hassle to implement using traditional programming styles. It can be done through the use of a state machine, but as more details are added the state machine becomes very large and complex. To better handle these scenarios, SDEC uses a coroutine engine written by the team to allow individual tasks take turns executing on the main thread. This allows complex behaviors to be modeled simply as separate tasks that execute and then wait for an event, without the extra overhead or thread safety concerns of giving a separate thread for these tasks.

When a game is selected from the menu, the front end makes some WinAPI calls to give up control of the display. It then launches the emulator process using the necessary arguments to start it executing the desired ROM. The code then enters a waiting state where very little processing is done other than checking on the execution status of the emulator. It is important that the front end does not use excessive CPU or RAM resources in order to leave those available to the emulator. The user can signal that they want to quit the active running emulator by pressing both the Start and Select buttons of player 1 at the same time. These buttons are mapped to the iPAC2, which are then encoded as keyboard presses and sent to the host machine. SDEC cannot read the keyboard input directly when it is not the active window, so in order to receive the keystrokes it must add a hook into the WinAPI keyboard event routines. When the key combination is received, SDEC closes the emulator and regains control of the screen. Some

emulators may take a while to close down fully, so control is returned to the display quickly while the emulator can continue to close in the background, effectively hiding this extra delay from the user.

(28)

SD May 12-14 Final Report 27

8.4 Game Lists

Figure 7 - Sorting options in SDEC

All games are stored in csv files for ease of access and simple capabilities for editing in any manner. As SDEC loads, it reads in both “consoles.csv” (the list of all available consoles) and “games.csv”. The consoles.csv holds the pertinent information about where the emulator is stored and in what folders all the relevant files are stored, such as the ROM files and box art for every game as well as a logo to be

displayed in SDEC and the LED configuration used. Some emulators required different command line arguments to start as desired. To handle this, “CallingConventions.ini” was added as a means of

specifying the format of command line arguments in a generic way. The games.csv contains information about every game such as its name, genre, year made, maximum allowable players, the system its on, and the exact name of its ROM and cover image files. For more information, see the “Adding New

Emulators” and “Adding New ROMs” sections in the Operational Manual, attached as an appendix to the end of this document.

It was considered for a while to instead use a database system as opposed to csv files, but in the end it was determined that the advantages were too few and it would be far more difficult to ever edit the lists in any manner for further extensibility. The database version would be easier to read into the SDEC and

methods of sorting would have been far easier to implement. However, as good as those pros are, the

(29)

SD May 12-14 Final Report 28

easy extensibility and editing was far too good to pass up the csv option.

8.5 Control Box

Figure 8 - Original CAD design of the control box

The controller console consists of 4 unique player slots, each having access to a single joystick, 8 main buttons, and 2 additional start/select buttons as well as plenty of room to maneuver around without bumping into neighboring players. In addition the controller console is removable for ease of transport as well as simple hookup to other monitors and ease of display of the inner workings of the entire system.

8.6 LEDs

All 8 of the main buttons for each player is outfitted with RGB LEDs so they can light up in most any conceivable color depending on what is needed for any chosen console. The 2 secondary buttons only have a single white LED that is always on. All LEDs are controlled by PacLED64 devices that are

(30)

SD May 12-14 Final Report 29

attached on the inside of the console.

Figure 9 - LED configuration for N64

Each console has its own LED configuration file to help define how each of the main buttons should light up, as well as in what color. These are configured in such a way that is most similar to the base console system. In addition to the order the buttons are setup to attempt the greatest match (or simplest in the case of an inability to match), all buttons also light up to be the same color as their console controller

counterparts. For additional verification, as any game is selected, a comparable display is shown to view how the original controller looks versus how the buttons on the controller box are setup.

The config files themselves that display which buttons should light up as which color is quite simple. A plain text file labeled as a .led contains comments (signified by double left slashes, “//”) and buttons are configured based on a simple method of declaring which button should light up as which color. “P#B#: “ is the template with the first pound sign signifying which player number (1-4) and the second pound sign signifying which button number (0-7). After this, the color is signified by 3 separate space delimited integer values, 0-255. The first value represents the red value, followed by green and then blue.

(31)

SD May 12-14 Final Report 30

Figure 10 - Mapping of buttons & LED colors to N64 controller, shown when launching a N64 ROM

Figure 11 - LED setup while running SDEC

(32)

SD May 12-14 Final Report 31

8.7 Cabinet Design

The cabinet was designed to mimic old arcade cabinet designs, with slight modifications. The controller console encases the buttons as well as the computer that runs the machine. The controller console is removable for transport as well as testing at a different location. The part of the cabinet that houses the CRT, has four caster wheels for easy transportation.

Figure 12 - Original CAD design of the cabinet (front)

(33)

SD May 12-14 Final Report 32

Figure 13 - Original CAD design of the cabinet (side)

The controller console can fit up to four players with 10 buttons each. The eight main buttons for each player is outfitted with RGB LEDs and the two secondary buttons have a white LED. These LEDs are controlled by PacLED64s that are attached inside the console.

8.8 Cabinet Construction

The main construction of the cabinet was done during the break of this semester. The cabinet consists of a basic 2x4 structure and has half inch plywood on the outside.

● The basic structure that holds the CRT is a stand that has two set caster wheels and two rotating casters with brakes.

Figure 14

(34)

SD May 12-14 Final Report 34

● Panels of the plywood were cut and fitted to the sides of the cabinet and later altered a bit for the final product. The side panels were cut to allow the project to travel through a standard sized door.

Figure 15

Figure 16

Figure 17

(35)

SD May 12-14 Final Report 35

● The bottom half of the controller console using the second half of the board from the top piece as well as trimmed of parts from the side paneling. These were initially nailed together and then screws and 2x2 pieces were added for stabilization.

● The controller console has holes drilled through it using a 1⅛” spade bit, for the

buttonholes, and ½” spade bit, for the joysticks.

After that the joysticks were inlaid into the board by cutting out a section and removing the layers that were need to get the desired depth.

Figure 18

Figure 19

(36)

SD May 12-14 Final Report 36

● Since we were unable to find an artist to create side art for the cabinet, we choose the color red as the main color because of it being an ISU ECpE recruitment device.

● We started adding paint during some of the construction for the parts that were ready for painting. We used Olympic Paint’s Paint and Primer.

Figure 20

Figure 21

(37)

SD May 12-14 Final Report 37

● Two triangles on a hinge was place on both sides of the front of the cabinet to hold the controller console.

● The top of the controller console was attached to the rest using European style hinges.

Figure 22

Figure 23

(38)

SD May 12-14 Final Report 37

● The final product with the console unattached

● The final product with the console attached

Figure 24

Figure 25

(39)

SD May 12-14 Final Report 38

8.9 Display

For the main display of the arcade machine we decided to find something to be able to support four players. Now finding a large CRT in this size is hard to find brand new these days, with LCD and LED screens becoming the standard and because CRTs are very heavy and gain immense amount of weight by just increasing the diagonal a few inches, but we were able to acquire a Sony WEGA secondhand for cheap. We had gone with this model and brand because we were able to get a large enough size, 36”

diagonal, and that it was able to support a 480i input. Even though our current board can output even higher implementations, we needed a 480i for the 4:3 displays. The 4:3 ratio is used in many of the emulated games that we implemented into the system.

8.10 N64 Game Implementation

In order to develop a game for the N64, much research work was required. Research began in January and continued through February and into March. A build environment was set up using a combination of official Nintendo and open source community tools, all running on a virtual Windows XP environment.

A large amount of documentation was gathered to help learn about the programming environment.

N64 games can be written in any combination of C, C++ and MIPS assembly. For the project, it was chosen to develop primarily in C, as was common by N64 developers. In particular, all code was required

to conform to the ISO C90 standard implemented in the N64 compiler. A sample starting project written by members of the N64 homebrew community was used as a base point to handle the initialization logic,

allowing the team to focus more on the actual code implementation.

(40)

SD May 12-14 Final Report 39

Figure 26 - Early test of build environment, reading controller input, font and 3D rendering

Developing a game for the N64 is far different from developing a standard PC game. In particular, the N64 game needed to contain all of its assets into its ROM image, which can be addressed and read by the CPU with only a couple cycles latency, leading to the near instantaneous load times observed on cartridge based games compared to their CD based competitors. This also means that at runtime, there is no file IO at all, assets can either be accessed directly on the cart or DMA transferred to system RAM for faster accesses. There also is no concept of file formats then, as any asset loaded is added by the developer as a binary object in the linker file, and can be in whatever format the developer wants. For our use, it was simplest to use all of our assets as data defined in C header files. Tools were developed in C++ to convert model and texture files into our custom C header format that could tie in directly into our custom data types in the N64 code.

(41)

SD May 12-14 Final Report 40

Figure 27 - Test of team developed model and texture conversion tools

N64 games also typically utilized a threaded architecture where threads could be preempted to handle more immediate hardware needs. The N64 supports a simple RTOS where threads can be given different priorities, swap execution and yield when they have performed enough work. Communication is

provided via message queues. Since both audio and video processing are handled on the same

coprocessor, special scheduling is needed to ensure they work correctly. Audio is considered to be a soft real time task and is generally given the highest priority. It is important that the audio buffers are kept full or popping and hissing or other audio corruption may occur. The end user can easily tolerate a missed video frame, as this will just be viewed as minor choppiness and is not uncommon in many video games, but the audio glitches are more noticeable and will interrupt the gameplay experience. A typical N64 game may be running a thread dedicated to filling the sound buffers with audio data, a thread creating graphical display list commands for execution by the video processing unit, a game logic thread that updates all objects in a scene, a thread for fetching data from the controllers and other peripheral devices, an idle thread and one master scheduler thread to tie them altogether.

(42)

SD May 12-14 Final Report 41

For our use, we opted for a simpler architecture consisting of just the game and idle threads. All of our update and draw logic for one frame is executed, then audio data for one frame is sent to the audio buffers and finally the thread sleeps until a hardware interrupt signaling the vertical retrace is received. While this model is simple to implement, its sequential nature doesn’t adapt to immediate hardware needs. In general, the update and draw logic is short enough that there is no worries about finishing all tasks within one vertical retrace, but there may sometimes be a slight delay from when the audio buffers empty before they are refilled, since they are not synchronized with the vertical refresh. Unfortunately, this leads to the audio popping issues described earlier. Due to time constraints, the choice was made to simply disable audio in the N64 game rather than overhaul the design to better handle task scheduling.

Figure 28 - Pong64 in action

(43)

SD May 12-14 Final Report 42

For the game itself, the team decided to implement an N64 recreation of the classic game Pong. There are several reasons for this. First, Pong is a relatively simple game, which means the gameplay

implementation is not too difficult while the majority of the actual programming effort is spent on the backend work. Second, Pong is an immediately recognizable classic with proven game mechanics.

Third, Pong is easy on the art assets requiring minimal 3D modeling and graphic design experience.

Finally, Pong remains one of the few arcade games not emulated by MAME. Since the original Pong was implemented entirely in hardware, there is no software “ROM” to speak of to emulate, and even with modern processor technology, we are still a ways away from faithfully emulating it at the gate level in real time. Thus, Pong does not appear elsewhere on our machine.

Since we do not have access to a Partner64 or other network attached N64 cartridge unit to deploy our game to actual N64 hardware, all development and testing had to be done within an N64 emulator.

Debugging tools were very limited. Most debugging had to be done by trial and error or by displaying debug text on top of the screen. Additionally, it was sometimes the case that some problems would be encountered only when using specific video plugins for the emulator. Since the emulator itself is not perfect, it becomes difficult to tell whether the issues encountered are problems with the code or the emulator. There were also some occasional bugs in creating the N64 ROM header, which would prevent the game from being able to start on an emulator. While the root cause of these bugs were never

determined, modifying the code image in any way was generally enough to make them go away.

Overall, the N64 development was a great learning experience for the team. It provided a good insight into how our favorite console games were developed along with some of the technical challenges faced as well as some of the various hardware interactions that must be emulated correctly in order for a game to function properly on an emulator.

(44)

SD May 12-14 Final Report 43

8.11 Results

Figure 29 - ISU Football players playing Super Smash Bros on MASE during VEISHEA

The system proved to be a hit during the demonstrations for Fridays At Noon and VEISHEA. Many members of the general public stopped by to play games like Super Smash Bros Brawl, New Super Mario Bros Wii, Pac Man, Gauntlet and Dig Dug. No serious bugs were discovered during the demonstrations, and the system performed as expected.

(45)

SD May 12-14 Final Report 44

9. Testing and Evaluation 9.1 Testing

Testing of the project was broken down into several steps. First, when the joysticks, LED controllers and other equipment arrived, they were tested in isolation using provided sample software to ensure the hardware was not faulty. All of these components simply connect over USB and use native Windows HID drivers, so these could be tested on our personal machines to allow for testing at home. After it was verified that the hardware was functional, it was necessary to try and interface with it from within our own simple test applications to test that we can communicate with the devices from within our code. This allowed us to move on to integrating the interface with the hardware into our software front end.

On the software side, development could proceed almost entirely on personal development machines with a reasonable expectation that the software will behave the same on the actual board. Every so often, the latest SVN build would be tested on the board to ensure there were no unforeseen problems. The board was configured with remote access to allow ease of testing from home.

At some points during the course of the software development, it was necessary to create stubs for unimplemented modules that would behave similarly to the module in order to allow other modules that relied on it to be tested. For example, the LED management code was stubbed out to allow its integration into the rest of the project before it had been finished. The calling code could still be tested for correct functionality, even though the LED code had not yet been implemented. Additionally, the software front end was designed to also take in input from the keyboard, mouse and a connected Xbox 360 controller to simulate control using a joystick without actually needing the joysticks to be present. All this helped to test different parts in isolation as they were developed.

(46)

SD May 12-14 Final Report 45

Figure 30 - LEDs running all white

Figure 31 - LEDs running SDEC diagnostics

(47)

SD May 12-14 Final Report 46

When it came time to integrate everything together, there was much testing that needed to be done to verify all the wiring was correct and was making a strong connection. In order to help facilitate this testing, a diagnostic screen was added to SDEC that displays the status of all of the buttons and joysticks in the system in an easy to follow pictorial form as well as run test patterns on all the LEDs. This screen proved immensely useful, as it allowed us to quickly check the connection of all the buttons and LEDs at runtime without quitting out of the software.

Figure 32 - SDEC Diagnostic screen

Each emulator added to the system had to be individually tested and configured for use with SDEC. In particular, the emulator must be able to start from the command line taking a ROM as an argument and launch full screen. Some emulators would refuse to start with a shared DirectX context and as such could not be run alongside our front end. Others would by default try to force odd color depths on the display that would cause incorrect colors when running full screen. Some would also cause SDEC’s graphical context to be destroyed by applying odd changes to the display. While SDEC is designed to handle this, losing the graphics context means that ALL graphical assets must be discarded and reloaded and as such can cause long load times, so it is best to avoid this scenario if possible. Emulators that tested

incompatible were simply replaced with other emulators for the same console that were compatible. If an emulator was admitted, the control and LED configurations had to be created and validated through

(48)

SD May 12-14 Final Report 47

playtesting a variety of games using the maximum allowed players for the system.

All games admitted to the system had to be individually tested to ensure the game was playable at an acceptable speed with no game breaking glitches, as to satisfy NR1 and NR3. The control of the game had to be assessed via playtesting to make sure that all required buttons are available. In particular, the GameCube, PlayStation 2 and Dreamcast all have additional analog sticks and directional pads that could not be added due to space and usability requirements. Any games found requiring these inputs for essential functionality had to be discarded.

Stress testing of the front end software was also performed by quickly cycling through the menus, rapidly starting and quitting different games and attempting to run with missing games, emulators, screenshots and other assets. It was discovered that some emulators may crash with an error message if they are closed during initialization. While SDEC will recover from this by closing the error message in the background and retaking the screen without any additional input needed from the user, it still looks bad for an error window of any kind to be displayed to the user, and the popup will momentarily minimize SDEC. This has since been avoided by preventing the user from killing an emulator immediately after it has been launched.

Testing of the N64 game was done with small incremental builds. Due to the lack of proper debugging tools, it can be difficult to determine where bugs are coming from if there are too many untested changes at once.

9.2 Evaluation

FR1 The system must be able to emulate at least four different consoles The system currently supports eleven different consoles.

FR2 The system must include MAME

MAME is included with over 50 compatible arcade games.

FR3 The system will allow for input for up to four players simultaneously

Four players is an easily definable number and we have enough joysticks and buttons to allow for four players as well as easy testability across any four player game.

FR4 The input control scheme will provide enough buttons to map to all of the required buttons in all emulated games

No game added required the use of more buttons than we have implemented.

FR5/6 Ensuring all relevant OSHA standards are met

Each rule is individually looked over and verified for complete compliance.

FR7 The core system must be removable and be able to run connected to a separate display and speakers

The core system is consistently removed from the cabinet for ease of transportation. In addition to the S- Video adapter used to display on the TV, the system also supports output over VGA or DVI at any

(49)

SD May 12-14 Final Report 48

standard desktop resolution, and the software can be configured to match.

FR8 The team must have a product completed enough to demonstrate at VEISHEA

The product was indeed completed in time and was demonstrated during both the VEISHEA Friday and the Saturday.

(50)

SD May 12-14 Final Report 49

10. Closing Materials

10.1 Contacts

Faculty Advisor:

Joseph Zambreno 327 Durham

Ames, IA 50011-2252 515-294-3312 Team Members:

Brandon Otto Software Engineering 316 Lynn Ave.

Ames, IA 50014-7122 507-430-0877

[email protected] Jonathan Henze Computer Engineering 1131 Frederiksen Ct.

Ames, IA 50010 612-616-7570 [email protected] Kevin Moore

Computer Engineering 1131 Frederiksen Ct.

Ames, IA 50010 563-650-8219

[email protected] Marvin Toeung Computer Engineering 1113 Frederiksen Ct.

Ames, IA 50010 712-301-7093 [email protected] Richard Rojas Electrical Engineering 1321 Frederiksen Ct.

Ames, IA, 50010 563-249-1308 [email protected]

(51)

SD May 12-14 Final Report 50

11. Appendix

Operational Manual 1. System Setup

 Ensure the powerstrip in the control box is connected to an electrical outlet. The cabinet has a flap in the back to allow easy access to the inside, which can be used to take the power cable out the back.

 Ensure the power cord from the TV is connected to the powerstrip in the control box.

 Ensure RCA audio and S-Video cables are connected from the board to the TV as shown below.

These are located near the back of the control box.

Figure 33 - RCA & S-Video connection

 Press the black and white power switch, shown below, to power on the system. The system will boot and automatically begin running the custom front end software, which will take control of the display.

Figure 34 - Motherboard

 When play has finished, simply press the power button again and the system will shut down.

(52)

SD May 12-14 Final Report 51

2. System Use

 Use any of the joysticks to navigate the front end software. Pressing the joystick up or down changes which game is selected, while pressing the joystick left or right switches to a different subcategory such as games for a different console. Press the yellow button to change category sorting options.

 Press the green button to choose a game to play. A screen will be shown indicating how the controls of the original system are mapped. Press the green button again to continue to the game.

 At any time during gameplay, press both the start and select buttons on player 1 to return to the front end program.

 At any time while on the menu screen, press both the start and select buttons on players 1 and 2 at the same time to switch to a diagnostic screen, which can be used to test the button and LED connections. Press player 1 and 2’s start and select buttons at the same time again to return to the menu screen.

3. Transportation

 ●Disconnect the RCA and S-Video cables from the control box to the TV. Unplug the TV from the powerstrip.

 Unplug the power strip if needed and pull the cord into the control box.

 Remove the control box by lifting straight up. The control box must be transported separately from the cabinet. It is recommended to use two people to carry the control box due to its size.

 Fold the arms of the cabinet around to its sides. This will allow the cabinet to be small enough to fit through doorways.

 Ensure the cabinet wheels are unlocked, then proceed to push it to its destination. The cabinet travels sideways to fit through doors.

 Fold the arms of the cabinet back out to the front and carefully place the control box on top.

Ensure that the arms are locked into place, as shown below.

Figure 35 - Locked Cabinet Arms

(53)

SD May 12-14 Final Report 52

4. Adding New Games

 Open the file “games.csv” in C:\SDEC using a spreadsheet editor like Excel or a simple text editor like Notepad++. This file contains the list of games displayed in the front end, as well as additional information about each game.

 Each row represents one game. The headings on the first row of the spreadsheet describe what is needed in each column. A row may be commented out by starting the line with a #. In general, the ROM for the game should be placed in the same folder as other ROMs for that system, and a box art screenshot should be placed in the screenshots folder for that system.

 Screenshots can be in .jpg, .png or .bmp format and can be any size.

 If the game ROM or screenshot can not be located at runtime, a message will be output to log.txt.

The screen for the game will show “No Image Available”, and the game will not start if selected (the system will simply do nothing, allowing the user to choose another game instead).

 Game names must be made of printable characters and symbols from the English alphabet only.

Commas are not allowed.

 Filenames may contain any system allowed character with the exception of a comma. Some emulators may expect specific extensions for ROMs.

 All file paths are assumed relative to the paths given by the console for ROMs and screenshots 5. Adding New Consoles

 Open the file “consoles.csv” in C:\SDEC, which contains the list of consoles and their corresponding emulators.

 Like with “games.csv”, each line represents one console and may be commented out be starting the line with a #.

 When defining the console, the path to the emulator, folder containing ROMs and folder

containing screenshots for the console must be given. Paths can either be full paths or relative to the SDEC directory.

 A logo should also be given for display in the front end. The logo can be in .jpg, .png or .bmp format at any size, though wide aspect logos tend to fill out the display area better in the front end. The logo should have a fully transparent background to look nice in the front end.

 Some emulators require additional command line arguments upon startup. These can be defined in “CallingConventions.ini”, and are referenced by a zero based index in “consoles.csv” based on the order they are defined. See the comments in “CallingConventions.ini” for more information.

 The executable given for the emulator must be the actual emulator program itself, not a startup script. The front end must be able to end the emulator by terminating the launched process, and the death of the launched process must signify the emulator being fully closed.

 Any bad paths will be noted in log.txt.

6. Adding Additional Music

 Simply add the music to the SDEC\Music folder and it will automatically be added to the music rotation the next time the front end is ran.

 Songs must be in MP3, FLAC, OGG or WAV format. FFMPEG may be used to transcode music from other formats into an accepted format.

7. Adding Additional Videos

 Simply add the video files to the SDEC\Videos folder and it will be automatically added to the video rotation the next time the front end is ran.

 Video files must be in the WMV format with an accompanying stereo audio track in the WMA format.

 Video files must be encoded in the VC-1 codec using a fixed bit rate of no more than 10Mbps.

 The height of the video cannot exceed 720 pixels, and the width cannot exceed 1280 pixels. Any combination lower than this is valid. Any aspect ratio is allowed.

 Videos must run at 30 frames per second.

(54)

SD May 12-14 Final Report 53

 Use either Microsoft Expression (preferred) or Windows Live Movie Maker to convert videos to a compatible format. In Microsoft Expression, use the Xbox360 720p preset with the above considerations for best results.

Multi-Arcade Emulation System