Results:

 

Our final product is functional, playable, and even quite enjoyable. It is reminiscent of the individual handheld games such as Donkey Kong and Gauntlet that were popular 15 years ago, before Game Boy or any other video game system was placed on the market. For each new game the course to be played is randomly generated, so there is no repetition and quick onset of boredom. The restrictions on shots, while at first frustrating, also ensure that the game isn't too easy and that interest is maintained. Towards the end of the project, it became quite frustrating for us when our program prematurely halted, not because our code was wrong, but because we lost our current game.

Our Atmel MCU runs at 4 MHz, while our "nintendo controller clock" runs at ~4000Hz. Due to the nature of golf and the relative sloth of human reflexes, however, speed was not really an issue. 4000Hz is much faster than any human pushbutton I/O requires, so our program polls for input at a rate of only 16Hz. In places, we even chose to purposely elongate the running-time of our code. Shot animation is one example of this. We felt more suspense is generated when watching the animation of a shot, as opposed to immediately repositioning the ball.

Out LCD is large enough and provides enough functionality for a complete visual interface. The LCD is divided into halves, one displaying the course and one showing the menu. Every course has a tee in the bottom half of the display, a hole in the top half of the display, and three sand traps. The four sides of the course represent out of bounds markers, which if passed will warrant a one-stroke penalty and a rehit. The menu contains a circular compass to display direction, a variable height bar to display power, and lines of text to display user options and/or directions. This text varies with a player's progress in the sequence of club selection, aiming, and swinging.