D. Results of the Design
D1. Speed of Execution
There is no flickering or artifacts on the screen at all. Everything works pretty well eventually, although we spend a lot of time in solving many flickering problems. Most of the time, we need to introduce extra frames, so that all calculations or drawings could be performed, and hence eliminate flickering. We try to optimize our codes for speed and simplicity, so that we do not face this problem of flickering, as playing a game with even a little flickering would be very distractive. We are able to interface the controller at ease, and hence there is no delay in the signal transmission. The moment we press the buttons, we can see on the screen that the space shuttle moves correspondingly as well as the shoots the bullets smoothly.
D2. Accuracy
The video signal timing aspect is explained in details in section B5. All the numerical calculations are performed well, as our program does not require very complicated computations. We put in extra caution on casting, so that there wouldn't be any casting problem affecting our program.
Our sound implementation is very simple. First we create an array of musical notes in flash memory from middle C to the C above it. The entries of the musical note array correspond to the frequencies of the musical notes. Then every time we want to produce a sound, we turn on the Clear Timer on Compare Match (CTC) mode and set clear OC0 on compare match. The OCR0 value is set to be equal to the entry in the musical note array. So port B.3 will produce a sound at different frequencies according to different notes. After a desired period of time, we turn off the CTC mode and stop producing the sound. The most interesting sound is when the space shuttle shoots a bullet. When we detect a push on the shoot button, we sweep through eight notes from high C to middle C quickly and this creates the shooting sound that we can hear in most of the bullet shooting arcade games. The other sounds of our video game, like when the player loses or wins, are produced by playing two notes consecutively.
D3. Safety In Design
As our project is using standard black & white television as the output, it is a standard means of output, and hence our project is very safe in nature. The only possible problem is due to any short circuit or other seizures, which is of very low risk and is typical to any usage of Television. We ensure that there is no live wires hanging around, and hence there is no chance of short circuit. Our STK 500 is powered by 5V, and hence, even if there is any short circuit, there wouldn't be any danger of life happened. The Sega Genesis Controller is a switch input and hence, is not required to be connected to any electricity, so there is no safety issue at hand.
And since this would be a video game, there is no any further danger beyond that of any typical video game using Sega controller. As the game may be challenging in nature, as for higher difficulty levels, the players could get a little over excited, but other than that, there is no safety issue at all.
D4. Interference with Other People's Design
Our project does not utilize any Radio Frequency (RF), and hence would not project any RF interference. There is no CPU noise or any other noise generated. Our game does provide sound effects, but if there is a need of quiet environment, the player can just turn off the TV volume.
D5. Usability
This Shooting Star game is usable and desirable for anyone who can play video game. So, basically anyone from an age of 2 onwards will be able to play this game, and even an infant could use his/her finger to press button B to fire a bullet! It is easy to learn, as a user only has to know that he/she needs to press button B to shoot, and use the left/right button to move around.