Due to the nature of this project, it is rather difficult to precisely synchronize
the hardware and the software. Consequently, there is always a wiggle on color pieces
on the screen. This is simply because the interrupt calls are not properly synchronized
with the rest of the software. There is also moderate delay within the interrupt that
can cause unwanted portions of color on the screen. One solution to this is to write the
interrupt code in assembly and to attempt to reduce unwanted cycle time in entering and
leaving interrupts. However, that was not a significant problem for our project.

The biggest obstacle that we encountered was a strange flicker and unneccessary lines on
the screen. It appeared as if the lines were being pushed towards the right at constant
intervals on the screen. Our first intuition was to deem this a delay problem. We tried
multiple methods of reducing delay, but all attempts failed. However, we were able to
realize that the problem was a conflict among two interrupts. While the main screen
writing interrupt was constantly being called, another interrupt, which served for maintaining
timers, was also being called. Apparently the latter interrupt was being given preference,
which caused a disruption in the uniform execution of the former interrupt. The solution was
to eliminate the latter interrupt and move its code into the main interrupt. This removed
all unwanted lines.

As far as the safety and compatibility are concerned, the project is compatible with any color
TV. Also, the code is simply enough for anyone to be able to understand. The code isn't very
safe, in terms of semantics. There are no big memory leaks, however, the CodeVision C compiler
is not very good at check for array index bounds. Some of our array accesses could have easily
been overflowing; however, we made sure that no such cases affected the performance of the game.