RATIONALE OF PROJECT:
We began selecting this project by identifying the need for a fun and entertaining final project whose construction required a nice balance between computer programming and hardware design skills (our group, 3 members combined, would result in 2 EE majors, 1EE minor, 1CS major, and 1 CS minor). The general idea resulting from this would be a computer game, with additional input and output devices that we used in the game for real-time user interaction.
After tossing standard video game ideas away, which would interface with only a joystick, we remembered how fun it was to play miniature golf as a kid! Actually, one of us played it over Spring Break. Each of us being a fan of the game, making a miniature golf game provided the nice design balance, as well as entertainment.
The project can easily be divided into two parts: the Atmel programming code, and the hardware design. The fundamentals behind the miniature golf game should be obvious, but our game is interesting in that we believed we could use an actual putter and ball to use as the user input for a stroke in the game. Though for sure miniature golf games have been created on electronic hand held games, it is likely that none use a real putter to determine shot velocity.
GENERAL LAYOUT STRUCTURE:
Our project consists of the game code, the putter and golf ball combination, and their interaction. In general, the user boots us the program to see a title screen, hitting any button to proceed to the 1st hole of this 9 hole course, and a scoring grid that keeps track of the total strokes. He uses only the putter to control the game, including shot direction and power. This force is gauged by an accelerometer chip that is attached to the ball. The golfer repeats these steps until the hole, and then eventually the course, is finished.
We followed the RS-170 video standard. This is the standard used in North American and Japanese black and white television. This requires 30 frames per second, and 525 lines per frame. We modified the number of lines per frame to make the calculations faster, and thus easier to finish all the calculations during the short period of time before we had to be ready to send out the next frame. We first chose to only use the odd lines, reducing the number of lines per frame to 262. Then, we only used lines 30-230, and of these, we doubled up the lines so we only had 100 lines (this reduced flicker, and also reduced the number of calculations necessary per frame.
When we want to create a line (to be displayed on the television), we have to start with a horizontal sync pulse of 5 us at 0V. Then, we have to create a "Back Porch" portion of the signal, which is a 5.9us signal at 0.3 V. Then, we have 51.5 us to send out our desired picture. This is done by black being 0.3 V and white being 1.0 V, and the voltages in between 0.3 and 1.0 correspond with varying grays. The position in time of the voltage corresponds to the position of that pixel on the screen. Once we finish sending out the signal for the picture, we have to have a 1.4 us "Front Porch" section of the signal, before starting on the next line.
Once we finish sending out the signals for all the lines in the frame, we have to send a "New Frame" signal. This consists of a series of three 63.55 us vertical sync signals. This directs the TV to return to the top of the screen, and start drawing from there.
USE OF OTHERS' MATERIAL:
We utilized code from a previous 476 lab, where we had a TV display. We asked permission of our instructor, Professor Bruce Land, before using his code. It is available from http://instruct1.cit.cornell.edu/courses/ee476/ .