(2 Weeks)
You may work in PAIRS for this lab.
In this lab you have the opportunity to make many of your own design decisions. We recommend that you follow good design practices and document such decisions both in your code and in the lab report. You may want to add a special section to your report in order to document your design decisions.
Are you ready to start a revolution with your 1337 typing skills? Although the final product of this lab may never attain the incredible popularity of the arcade and playstation game "Dance, Dance, Revolution" , it follows the same idea, and involves solving design issues that have not been addressed in the previous labs. The original DDR game is quite simple: the player stands in a central area, and "dances to the music" by pressing touch pads to the front, back, left and right with his or her feet, according to directions given on the screen (arrows that float up the screen). The goal of the game is simply to push the correct pads at the right time. If you get enough right, you get to pick another song and continue, otherwise it will cost you another dollar. This simple (and in some people's opinion, silly) idea has become surprisingly popular (Try a google search on DDR: in may, 2002, this generated 50,000 hits!) Like all modern arcade games, DDR was implemented by a team of digital systems and software designers. Maybe shortly you will be designing and implementing the next arcade hit!
In this lab you will create a simple game similar to DDR. This design will build on the concepts introduced in lab4. We will use the keyboard arrow keys instead of foot pads, and the LED digits instead of an arcade screen. A sequence of arrow key "steps" will be loaded into the RAM. These steps will be displayed on the XStends LED digits for a period of time. The player will attempt to press the arrow key indicated before time runs out and the next key is displayed. The last key pressed within the allotted time interval needs to be the key indicated on the display. If the key is incorrect, then the player "loses a life". If the player has no lives remaining, the game is over. At the end of each time period, the game progresses to the next "step" regardless of whether the previous key was entered correctly or not. For our game, the goal for the player will simply be to continue playing as long as possible before losing all her/his "lives".
More specifically, the player starts with 3 lives, which is the maximum attainable. Each incorrect key results in the loss of one life. At the end of a sequence of moves, the player receives an additional life for "completing the level", up to a maximum of 3 lives. The number of lives remaining will be displayed on the single LED digit on the XS40 board. Each "level" is defined as the completion of the given sequence. Once the sequence is complete, it repeats. Optionally (for bonus marks in the lab), the sequence speeds up each time it is repeated. The recommended initial speed for the game is about 1/2 second per key.
RAM content specifications:
The RAM should contain a sequence of ascii characters, from the set {U,
D, L, R, E}. The meaning of the letters are as follows (recommended display
characters (as in lab4) are in brackets):
Display specifications:
The displays must show the following information:
Bonus Functionality:
(Discretionary bonus marks may be given for other significant
improvements of the design.)
ASCII display unit VHDL code (or txt ).
Keyboard Scan codes (use the "make" codes)
Display characters (some imagination required...). Note that the ASCII line shows the what character the LED is trying to resemble, but all the codes (input to the display unit) on the HEX line are for the UPPERCASE letters, which is what the display unit expects. Unknown codes will result in nothing being displayed.
Test Sequences (Intel HEX files, to load into RAM):
[Return to CMPUT 329 Lab Home Page]