Final Design by Jacob Reece & Kyle Wyan
The Redhawk Duels digital hardware game is the creation of Dr. Peter Jamieson. Our objective was to alter the given code in ways that would make duels easier to win. We interfaced the Altera DE2 board with VGA and a PS/2 Keyboard. The VGA allows us to see where our ship is in relation to the game boundaries, see a 60-second timer in progress and have text displayed on the screen. We also added flashing patterns of color to the screen. This does not help us in the game, but it is a unique visual effect among our peers. The PS/2 Keyboard allows us to control our ship via keys rather than switches and push buttons on the DE2 board. Our ship performed well in battle, but we would have done better had we spent more time on a clever battle strategy after completing our project code.
Redhawk Duels is a game designed in hardware that allows two users to battle against each other. Each user controls a ship, and the objective of the game is to lower the opponent’s power by shooting their ship until it cannot move or return fire. Power is gotten from a “crystal array” whose connections are determined by the connections of wires on a breadboard connected to the DE2 board. There are eight crystals, and a circuit must be made that starts at any crystal, goes to every other crystal once and only once, and then returns back to the starting crystal. The path from every crystal to every other is given a pseudo-random number between 0 and 10. Following is an example from the Project Description by Dr. Jamieson that shows the crystal array on a smaller scale (only four crystals) (Figure 1).
Figure 1: Crystal display (before hit) Figure 2: Crystal display (after hit)
After a ship is hit, some or all of its power paths will lower (Figure 2). The power paths are updated by the game master every minute, and the idea is to rewire the breadboard to optimize the crystal array for maximum power each minute. If a user’s breadboard wiring contains a path with a power of 0 at the end of a minute, that player will lose.
The game controller comes standard with game controls that are operated using a FPGA (Field Programmable Gate Array), or more specifically, the Altera DE2 board. However, the standard is not very useful because everything is controlled by switches and push buttons.
Information is cycled through the DE2 board’s hexadecimal display while other information, such as whether the opponent’s ship is detected or whether the Ethernet connection is healthy, is displayed with LEDs. But, there is not a display screen that tells the user where their ship is located relative to the game’s boundaries or the opponent’s ship. This makes game play very difficult. So, we thought of ideas to make game play easier.
We brainstormed ways to make user interface with the ship easier. We came up with the following:
Implementing video via VGA:
Implementing control via PS/2 Keyboard:
Getting to Work
We used Dr. Jamieson’s Basic Ship project as a base for our design. Because neither of us in our group had any idea how to start interfacing the VGA or Keyboard with the DE2, we immediately turned to Internet research for help. We found www.johnloomis.org and used Loomis’ VGA and PS/2 Keyboard lab projects as an outline. We changed bits of code here and there throughout his projects to find how to make useful changes, such as displaying different colors on the VGA, instantiating a box of characters, moving that image of characters around on the screen, and displaying keyboard scan and break codes.
After many, many hours spent changing Loomis’ code, we still could not figure out how to call individual characters to the screen or draw an individual pixel. Harrison Bourne showed us how to do both. That was all the push we needed to get started making our preliminary ideas a reality.
Interfacing the PS/2 Keyboard
Before jumping straight into the VGA, we wanted to get the Keyboard working. We thought this would be a good place to start because it didn’t seem as complicated as interfacing the VGA.
We looked through Loomis’ Keyboard code very carefully, and came to the logical conclusion that the reg scan_code must be what we need to use in order to assign ship functions to the Keyboard. We were right. This made interface with the Keyboard very easy. We altered code in the ship_proto module from using switches to maneuver the ship and control firing to using keypad keys to control the ship and space bar to fire. We also used keys to turn the sensor on our ship.
Interfacing the VGA
1. Crystal Display
After testing the keyboard and finding it to work just as we wanted, we started making the outline for our crystal display by calling a myriad of characters to the screen. Figure 2 shows the bottom right corner of our monitor.
Figure 3: Outline of Crystal Display
The way we did this may be referenced in the textbox.v file. The ‘0’s shown in Figure 3 are there for three reasons:
1) Our ship was not programmed to the game master at the time, therefore having no way to receive power.
2) We were never able to correctly bring the power paths to be displayed on the screen, even when connected to the game master, though we spent many long hours attempting to.
3) ‘0’ was our default state for those areas of pixels.
Our timer was built using a state machine to control the Ten’s Place, which counts from 0 to 6, and another state machine to control the One’s Place, which counts from 0 to 9. Therefore, two separate “timers” work together to create the illusion of a 60-second timer (Figure 4).
Figure 4: The Timer
The code that defines the timer is also found in textbox.v.
3. Game Boundaries and Ship
The game boundaries were drawn pixel by pixel and were drawn to scale of the game master’s boundaries, which were 640 x 480 pixels. Our boundaries were 320 x 240 pixels and placed in the upper left part of our screen. We drew the ship as a small square and related it to the regs px and py from ship_proto.v in such a way that makes the ship we drew move on our monitor in sync with the ship we are controlling from the game master. For example, Player 1 starts the game in the upper left corner. Figure 5 is a snapshot of our monitor at the start of a game when we are Player 1.
Figure 5: Game Boundaries and Ship
The code for this can be found in textbox.v, but we did need to bring px and py from ship_proto.v to textbox.v by calling textbox.v in the ship_proto module.
4. Flashing Patterns
Making our monitor flash colors to a defined rhythm was the most difficult and time-consuming part of our project that we got working. Figure 6 displays the rhythm and corresponding colors that one of our Flashing Patterns produces and loops through.
Figure 6: A Flashing Pattern
where GRN_BLK represents green text with a black background, BLK_BLU represents black text with a blue background, and represents 120 BPM (beats per minute). This code is found in our ship_proto module, which has module vgalab2 from John Loomis annexed.
We also made a flashing pattern that flashes at a constant rate through a dazzling rainbow of colors. This code is also found in ship_proto.v.
Comparison of Final Design with Project Proposal and Preliminary Ideas
The first thing we worked on was interfacing the Keyboard. We had quick success with this and were highly motivated to keep pushing on. We moved on to our next objective: detecting the enemy ship.
We found at the very start of the project that there indeed was a sensor that detects when the enemy ship is directly in front of ours. We wrote code that should have fired our ship’s cannon when it detected the enemy ship, but when we tested it, it constantly fired until it an out of power. We could not find what was going wrong, so we assigned fire to the Keyboard, had a red LED light up whenever our sensor detected the enemy ship, and moved on.
We only had one goal in our proposal for the VGA: to display the power crystals. Between writing our proposal and starting the project, we thought of several other uses for the VGA. We included those in our list of Preliminary Ideas. Unfortunately, we were never able to display our power crystal array on our screen, though we believe we were very close. We did, however, have many other ideas for the VGA work.
Something that entered our minds around halfway through the project was making the screen flash different colors. We knew it wouldn’t help us win a battle, but it was a challenge we wanted to take anyway. We wrote two successful sets of code for two flashing patterns, and we also are able to disable the flashing and display the screen constantly in whatever colors we wish.
We met many of our goals for this project. We didn’t think we would have time to integrate the VGA, but we did. We thought we would have to spend a long time trying to figure out how to use the Keyboard, but we figured that part out more quickly than any other. We wanted to write an algorithm that would detect the enemy ship, but that was already done for us. While we didn’t get the crystal array to display on our screen, we were able to get several other useful things up. We learned more than we ever thought we would during this project and had a lot of fun dealing with the challenges that came along.