Pong on a VT100 Emulator over a serial port
Gabriel Weisz and Garrin Felber
Introduction
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.
Design
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.
- Initscreen sets the initial paddle and ball positions and directions, and draws the paddles (they do need to be fully drawn once), and the scores.
- Updatescreen computes the new ball and paddle positions (from previous positions and keypresses indicating paddle motion), decides if one of the players has scored a point, and then redraws the paddle and ball. It does change the score and call initscreen if a point was scored, and prints a message and enters a spin loop if one of the players has won the game.
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).
Results
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.
Appendix
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.
