Pong on a VT100 Emulator over a serial port

Gabriel Weisz and Garrin Felber


We wanted to show that it is possible to implement a (faitly simple) game on the ATS4414 board. Pong was an obvious choice, because it was the first video game in history. We chose to use a VT100 emulator because we couldn't get our LCD to work (we decided that the data input was fried), and this was an available alternative. It also supported the other main design decision that we made: rather than redraw the entire screen between frames, just draw the parts of the screen that change.


Besides the game itself, the major design goal was to only update as little of the screen as possible between frames. The use of VT100 text mode facilitated this - characters couldn't overlap, and things moving could be erased by drawing a space where they were before moving. We don't have the microcontroller wait between frames, but rather draw them as fast as possible, because this makes the game more interesting. Besides the serial communication routines (taken from the rs232 sample code) we had two main functions: initscreen and updatescreen, as well as some utility functions.

Program Design

The program has two main functions: InitScreen and UpdateScreen.
We also have several utility functions. We have one function to start printing a string in memory to the serial port.
There's a function to convert numbers to ascii.
Finally (and most importantly> there's a function that will send the escape sequence to move the VT100 cursor to a specified point on the screen (this function is heavily used in updates).


The game works! The speed of the game is reasonable. It does slow down when the paddles move far (we have both slow and fast paddle motion) but by raising the communication speed we have determined that this is due to the slowness of HyperTerminal's VT100 emulator rather than due to communication overhead (we determined this because when the paddles don't move, the ball moves very fast, but when they do move, the ball moves at the same speed that it moved at with a slower communication speed). This shows that our decision not to pause the processor between frames was justified, since this would only make the fast updates slower and not help the slow updates. We also think that this makes the game more interesting (it provides the oppertunity for some strategy since you can change the speed of updates when the ball is near the opponent's side).

What we would do differently

The main thing that we would do differently is make sure that our LCD works before trying to use it. We had originally planned to use a graphics mode LCD (along with modifications to the code to allow the ball to not be exactly on an bit boundary) and wrote a lot of code to use the LCD before we realized that it just didn't work and that we didn't have time to get another one. Everything else works well, and we're happy with it.


The code is here
No schematics are required - just the board with a 4414 chip and that wire connected so the serial interface can be used.