\begin{section}{Conclusion}
\label{sec:conclusion}

After an extensive period of continuous refinement, redesign, and
debugging, sometimes encouraging, sometimes discouraging, the final
result of this project well exceeded expectations.  The device is
impressive both in technical scope and entertainment value.

The greatest difficulties in designing and building this project were
in the analog components and the DRAM timing.  Since this was
expected, we begin with the analog I/O module, passing the digital
output of the ADC directly to the input of the DAC to form a
pass-through analog video device.  Making this work correctly took
quite a long time, most of which was spent on the DAC.  Much of this
difficulty arose from the op amp connected to the output: this chip
could not be modeled as an ideal op amp.  If it could, then the
resistor across the inputs would be irrelevant, but in reality it
keeps the output from ringing uncontrollably. A cheap, fast, voltage
based DAC would have been better, but was not available to us.

The differencer module's control FSM went through several design
revisions before the final version.  We spent a good deal of time
experimenting with timing delays and control signals before the module
actually performed time differencing: most configurations we tested
differenced horizontally or vertically adjacent pixels, giving an edge
detector rather than a motion detector.  Originally, we had planned to
process one pixel for every four clock cycles; however, the timing
constraints for the DRAM and the various PALs were only barely met by
this design, and the amount of digital noise in the signal was
unacceptable.  Thus, we moved on to a six-clock-per-pixel revision,
which was an improvement, but not sufficient.  The final
eight-clock-per-pixel design satisfies all chips' timing requirements,
and the resulting difference signal has only minimal (on the order of
the least significant bit) noise.

Originally, we had intended build a targeting system.  The change to a
pong game was actually faily minor, and did not affect the I/O,
Differencer, or Bitmap Overlay modules.  Only the section that
controlled the position of the ``ball'' (originally a target) needed
modification.  The targeting system would have tracked moving objects
by monitoring the stream of differences and placing the target on the
region of greatest motion.  However, pong is a far more amusing and
captivating project, and it more effectively demonstrates the
capabilities of the differencer.

The implementation of bouncing in the CPLD was a particularly clever
part of the project: the naive way to do this would be to implement a
signed velocity and an eight-bit accumulator, and implement both
addition and subtraction in the accumulator.  However, this naive
approach would have taken far too many resources, and would have
resulted in the splitting of the pong module over multiple CPLDs,
which would have been very inelegant.  The separation of logical
positions and screen positions was an elegant solution to this
problem, allowing the logic to treat the ball as if it moved in one
direction only.

The other prideworthy aspect of the design was the tightness and
efficiency of the differencer.  In order to operate at the speeds we
desired, we ordered a 28.8 MHz clock and a high-speed DAC from an
electronics supplier.  This speed pushed most of our components to
their limits, and all the timing constraints were met only after a we
did a great deal of work on the timing diagrams.  The high speed of
our data transfer required us to keep all of the circuitry on one lab
kit to limit noise and delays, which was quite a handicap to
overcome: by the end, we had used every row of every protoboard, and
the ICs were packed bumper to bumper.  Finally, our decision to
perform all operations synchronously --- instead of delaying
operations until the blanking periods of the video signal --- allowed
us to have such an efficient and flexible design.

Unlike many of the other video games built for 6.111 projects, this
project could not be written simply as software for an entertainment
system.  Disregarding the fact that most such systems have no camera,
most entertainment system CPUs are not fast enough to implement a full
frame rate differencer in software.  A hardware solution such as ours
will always be more efficient than software.

In conclusion, a purely visual interface, involving no buttons,
switches, keyboards, or keypads, is far more intuitive and engaging
than the traditional interfaces to digital devices.  A similar design
to ours could well be very successful in a ``real-world'' design
situation geared towards non-technical users.

\end{section}
