When we set out on this project we decided to start with a fairly simple concept, based on the classic Arkanoid game, which we could expand on as time allowed. Due to the complexity of the code that we developed, we have scaled back some of our original objectives in some areas. However, we have added additional features in other portions of the system, exceeding our original design parameters.

 Originally we set about designing a system that contained the following features and controls: 

• VGA resolution graphics
• Mouse controlled interface
• Complex collision detection
• Player lives
• Multiple levels. 

After code development and hardware configuration, we realized that some of our original features would be unrealizable with the current system. Making the necessary changes, we developed a system with the following features : 

• VGA resolution Graphics
• Button controlled interface
• Complex collision detection
• Player lives
• Audible collisions. 

This project was designed into four modules. The game module (ark.vhd), the display module (draw.vhd), the sound module (beep.vhd), and the chip module (arkanoid.vhd). All entities compile, simulate and have been verified in hardware.

Our chip implements a hardware version of Arkanoid. The object of the game is to remove all of the blocks of the screen by bouncing a ball off of each block. The ball is bounced off a paddle controlled by the user. Two push-buttons on the Altera board control the horizontal movement of the paddle. Originally, the ball is connected to the paddle and is released when both push-buttons are pressed. The ball can bounce off of the roof, walls, blocks, or paddle. When the ball hits the roof or walls, the ball reverses direction. If the ball hits the paddle, it bounces back at a speed and direction determined by where the ball hits the paddle. If the ball hits a block, the ball rebounds and the block is removed. When all the blocks are removed, the next level begins. If the ball touches the bottom of the screen, a life is lost. When a player has lost all his lives, the game is over.

FEATURE DESCRIPTION  

• VGA resolution Graphics: We use VGA (640x480) resolution at 60Hz for the display of the game. This allows us to provide smoother animation and crisp graphics for the system. 
• Button Controlled Interface: Using the buttons provided on the Altera board we set pin 28 and pin 29 to be the right and left controls respectively. Also, activating both buttons at once causes the ball release. 
• Complex Collision Detection: To make the game more variable and interesting, we have set the rebound angle of the ball variable depending on the location of it’s impact on the paddle. There are 7 different rebound styles the ball could actually take depending on the placement of the impact. 
• Player Lives: As in all games the added element of lives makes the game far more challenging. By limiting the number of lives to 3 we hope to increase the difficulty of the game while still making it possible to complete a level. 
• Audible Collisions: Much of the allure of video games is the bombardment of as many senses as possible. For this reason we have added sound to the game indicating when the ball has made a collision.

• Monitor: We are using a standard 640X480 VGA monitor. We have two counters that are used to create horizontal and vertical synchronization pulses, based on the clock input, which are sent to the monitor. This tells the monitor when a new row or column of pixels must be written. The color of each pixel depends on the value of the red, green, and blue output signals. 
• Push-buttons: The flex push-button #1 is used as the mouse_L input and push-button #2 is used for the mouse_R input. These inputs tell the game code where to move the paddle. 
• Reset: We have included an asynchronous reset using DIP switch #1. An asynchronous reset was used because we found the circuit performed better with an asynchronous, rather than synchronous reset. 
• Sound: When a collision is detected, the sound signal begins to oscillate. This sound signal feeds an audio amplifier and speaker. The frequency of the sound signal determines the pitch. The volume can also be changed externally. 
• Memory: We have used the FLEX 10K20 board’s Embedded Array Block’s to store the position of the blocks. This allows the drawing program and the collision detection to locate blocks easily. 

ARKANOID: 

Arkanoid is the top-level component. It instantiates the Ark, Draw, and Beep components. This component takes in the clock, reset, move_left, and move_right signals. The signals Red, Green, Blue, Horiz_sync, and Vert_sync control the video display. The sound signal creates a sound when a collision is detected. 

ARK: 

Ark is the game component. It initializes the blocks in memory, and rewrites the blocks based upon the game logic. Once the memory has been loaded, the game enters game mode. Any collision with blocks is detected, and the ball rebounds. The block is removed from memory and a collision signal is sent if a collision is detected. A "blocks_gone" signal starts the next level. If the ball hits the walls it rebounds. If the hits the paddle, its speed changes based on where it hit the paddle. If the ball hits the bottom of the screen a life is lost. Once all a players lives is lost, the game is over. The position of the paddle and ball is sent to the draw component. 

DRAW: 

The draw signal is responsible for the video display. At the start of the drawing process, the coordinates of the ball and paddle are calculated. Then the drawing process begins. The timing of the monitor is controlled by the clock signal. A counter is used to count the row and column of the electron beam. If the electron beam passes an object, the color of the pixel is changed. If no blocks are drawn during the drawing process, a "blocks_gone" signal is sent to the Ark component. 

BEEP: 

If a collision is detected in the game code, the sound signal oscillates at 30Hz for 0.1s. The schematic for the external audio circuit can be found in Appendix A. The VHDL code for all of the components can be found in Appendix B.

CIRCUIT TIMING 

The vertical sync for the VGA monitor runs at a 60Hz cycle (active low). To accommodate the write time of the video display and the memory requirements all game functions occur during the vertical reset. When the vertical sync pulse goes low, the calculations for collisions, redrawing, and sound are made. When the vertical sync pulse goes high, the drawing routine takes over and draws the results of the recently updated game on the monitor.

DESIGN DETAILS 

We implemented our design using a FLEX 10K20C240-4 board. We chose this board because it had an adequate number of logic cells and was readily available. The embedded memory was also useful for our design. By ignoring the five least significant bits of the horizontal counter, the address remains constant for exactly 32 pixels. Similarly, the four least significant bits of the vertical counter are ignored, giving the block a defined height. If an address contains a ‘1’, then a block that is 32X16 pixels will be drawn on the screen. Otherwise, nothing will be drawn on the screen. A block can be erase by assigning its address the value ‘0’.

There were several problems we encountered with our code. In most cases, we found ways to work around or solve these problems, however, with others, the size of the code or the complexity of the problem forced us to abandon the feature. 

Problem #1: Synchronous Reset not properly being set.

Solution: Made an asynchronous reset

Problem #2: Code not responding to mouse inputs.

Solution: Replaced mouse feature with push button input

Problem #3: Level not resetting upon completion.

Problem #4: Instead of counting blocks to see when we finished the level, we set a flag to go high when the draw component indicated no blocks drawn. We then reset the level on that flag.

Problem #5: Insufficient room for multiple levels.

Solution: Only one level was set.

TESTING 

Our design was simulated using the Maxplus2 simulator. We have included four simulation waveforms in Appendix C.  

• Arkanoid: This simulation shows the overall function of our chip. Note that although this simulation indicates that our design is operating correctly, the complexity of our design makes hardware testing more meaningful. 
• Ark Part 1: This simulation demonstrates some of the internal game logic. 
• Ark Part 2: This simulation shows the design correctly setting up blocks in memory. 
• Beep: This simulation shows how the sound component behaves when a collision is detected. 
• Draw: This simulation shows how the draw program sends display signals to the monitor.

The design was implemented in hardware and operated correctly. There are a few bugs that we hope to repair promptly: occasionally a block will not disappear on the first collision, the blocks occasionally initialize incorrectly, and the game occasionally doesn’t reload when all of the blocks have been removed.

IC DATA SHEET 

As stated above, our code came very close to utilizing the full capacity of the Altera chip. Due to careful optimization, we have managed to include these features: 

• VGA resolution Graphics
• Button controlled interface
• Complex collision detection
• Player lives
• Audible collisions 

Our design, including this feature set, required 923/1152 logic cells (80% capacity). The logic cell usage for each component is shown in Fig. 1.

File # of Logic Cells

ARKANOID.VHD 923

ARK.VHD 588

DRAW.VHD 232

BEEP.VHD 102

The maximum and minimum clock speed is 25.175 MHz. VGA standards, built into monitors, dictate a clock speed of 25.175MHz to operate in 640x480 resolution at a 60Hz refresh cycle. The generated 60Hz refresh cycle and the main clock (25.175MHz) are used to clock various processes within the game. As the program interfaces with humans, it is required to maintain a certain "playability", and thus it would not be beneficial to increase or decrease the clocking.

Setting the pin assignments was relatively easy, as the system is largely self-contained within the Altera board. The pin assignments are shown in Fig. 2.

Return to Arkanoid Index