CMPE12, Fall 2011, Section 01: Lab 7: Final Lab: HC11 Game Machine

200 point lab!!!

100 for check off!

100 for write up!

Due date

Due Friday, December 2 for in class check offs. Write ups due Sunday December 4 by 11:59:59.

Lab Objective

This lab will give you a chance to show off your HC11 programming skills in a fun and creative way. You will be programming a game of your choice. The basic requirements are that it needs to use some LEDs, the LCD, take some input from the switches on the board, uses the interrupt button, and of course be a fun game!!! A basic version of this game will earn you a "C", more advanced ones a "B" or "A", and really cool & challenging ones will get an "A+" and some extra credit. Think of this lab as your final chance to get a better lab grade overall. If you like you can also implement a few additional simple games to get full credit.

Lab tutors: Go over these topics

Your lab tutor will cover the following topics in the first 40 minutes of lab.

  • Interrupts
  • Using SWITCHES in the HC11
  • Pulse Accumulator for random numbers

Interrupts with HC11

Configuring interrupts for the HC11 is pretty easy. All you need to do is:

Make an ISR, it is just like a procedure/sub routine but returns with RTI.

Put the address of the ISR into the Jump Table.

Here is an example of how you would set things up. All we have is the one button on the board that can act as an interrupt source. Below is how you would setup this

button to work with your own service routine. A VERY important thing about interrupt service routines is to make them short and simple. Do not call a bunch of routines or have a lot of instructions in an ISR!

// Initializes the ISR jump vectors to our interrupt service routines, it is this simple.

// Jump vectors are defined in v2_18g3.asm

ldx #BUTTON_isr

stx ISR_JUMP15

 // Here is the code for interrupt service routine you will create

BUTTON_isr:

// Put your code in here.

// Use this to return from an interrupt

rti

 

Game Ideas:

Here are a few basic ideas, and a ranking of how they might be graded. Please keep in mind that this is a long lab and so we are expecting a challenging and fun game to be the result.

C) Simon Says

--Frogger

--Whack-A-Mole

A) Adventure Game

Of course these all depend on the way that they are implemented, and you are of course free to come up with your own new and exciting ideas. Feel free to run your ideas by your TA, as they can give you an idea of how well they might be graded.

Other ideas that might be interesting and will depend on implementation:

A Zelda like adventure game that uses the LEDS as lifes (half-lives = blinking light) and a combination of telnet console and LCD to play.

"Suped-Up" Simon Says, with randomly sped up lights.

"Guitar Hero" style game with switches.

"Duck Hunt" game where you have to shoot the LEDS with the SWITCHES, containing multiple difficulty levels.

Battleship

The Basic Game Idea for Simon Says:

Simon Says is pretty simple. You just follow what the computer does. The computer will light up a random LED. You raise and lower the switch that matches it. The computer then does the same LED plus a new random one. You repeat it. This continues until you mess up.

 

a) Read through the sample code links below for help on generating random numbers, you will need this to determine the next LED to light up.

b) You need to use the switches for your input.

c) To "enter" your switch you will use the interrupt button.

d) Be creative with the LCD. You should display the length of the game at the least. Additionally you can use the terminal to display graphics if you like.

e) Again, this lab is supposed to be fun so be creative.

f) You will most likely want to use a big array, maybe of 100 elements, to store the LED pattern that the computer will light up. You will create this array with the random number generator at the start before the person plays.

g) Set some realistic delay between the lighting up of the LEDs, maybe make it a game setting, easy, hard, expert or something.

h) Document ALL your work. This means meaningful comments in the code and a clear, concise README that describes the game you implemented and how to play it.

i) To make it more challenging you could make it be patterns of more than just 1 LED.

 

Here are some files that can be of use for you to make random numbers.

pacc.txt: Pulse accumulator usage.

pacc_ex.asm: Sample code showing how to use pulse accumulator to generate clock ticks and a "random" number.

pa_testing.asm:   Some more sample code on how to use the pulse accumulator.

interrupt_ex.asm: Interrupt sample code

 

Grading template

This is a suggested grading rubric. Your tutor may or may not use this rubric to grade by, but it is a good general guideline before submitting your code to check off these points.

Check off requirements

You MUST get your game checked off by your TA/Tutor. You MUST also submit your lab like normal. There will be NO late submissions accepted! Failure to submit by Sunday Dec 4th will result in an AUTOMATIC ZERO.

General Specifications

___ (10 pts)  load and run without syntax and run time errors

___ (10 pts)  have clean procedural style implementation

___ (10 pts)  Generates random numbers using pulse accumulator

___ (10 pts)  Prompts for user on how to play the game

___ (10 pts) LEDs light up one at a time, player tries to remember order, or appropriate to game design

___ (15 pts)  Uses interrupts in some manner

___ (10 pts)  Uses switches to get some input

___ (10 pts)  Display total number of guesses on LCD, or life counters or dynamic score updates, etc 

___ (10 pts) Robustness of incorrect inputs, looping, exit of game, does it function as expected

___ (5 pts)  have good comments (more complete program comments, more detailed procedure headers) [See comments for any missing part above.]

Extra credit specification

In addition to the above if the game is just really cool then give 10 or more points for extra credit.

___ (10 pts)  Extra games or exceptional implementation

Overall

Grade:_____  point(s) out of 100 is your Lab7 grade

Lab write-up requirements

 Since this lab is more in depth than most previous labs, you will be required to create a Lab7_Report of suitable depth. For this lab, your README should be in the form of a game instruction manual or "quick start" guide. To that end, it should include the following information:

  • Introduction
    • Detail what your game is; is it a new twist on an old game? Or a completely new game? Be creative!
  • How to Play?
    • What are the controls? How do I play? What do I need to press? 
  •  How do I win?
    • What are the conditions? Do I have to get a certain number of things right? Do I need to beat a timer? Let me know!
  • Secrets
    • Are there any hidden things in your game? Different game modes, backdoors, etc?

Your lab report MUST be submitted as a pdf this time, and should be formatted to be visually appealing and easy to read. Make sure to use spell check, grammar check, and read it over before submitting!

 

Get creative and have fun!