After making the tetris game, it was very easy to make a Pong game. The game Pong was the world's first video game in the early 70ís; this is a modern version of it, made with a little bit less hardware than the original version. In my version, the video signal is generated in software. The video generating hardware is a 5-bit DA converter built with a few resistors. Usually the video signal is generated in video games is created with a dedicated video chips, reading the image data from a graphics memory. In this project the video signal is calculated in real-time by the microprocessor as the electron beam sweeps over the screen. This page only describes the software, you can find schematics and description of the hardware here and for your service I also sell the parts for building the system here if you want to make sure you get the correct stuff, don't have an oscillator, don't have a programmer or can't make PCBs yourself.
How to play the game.
The first screen is where you select how you want to play by moving the joystick: UP and DOWN to select Human vs. Human, Human vs. Computer or Computer vs. Computer. Start with FIRE. The computer vs. computer game to plays forever or until someone reset the game using the reset switch. You start serving by pressing fire, it is also possible to change direction and speed of the ball using fire. The player who has the serve will get points. If the player with the serve miss the ball, then the serve goes over to the other player. The paddles are moved up and down with the joysticks. It is possible to smash (increase speed) by pressing FIRE, and when doing so it is also possible to steer the ball by moving joystick up or down. When someone wins a game over picture will show and tell who won.
The game logic is taken care of in the invisible lines at the top of the screen. The ball and the paddles are first generated with the setgrapics routine that loads the bitmap data and converts it using a palette and then writes it to the output buffer. The data in the buffer is outputted to the screen with the memtovideo routine. there is a delay before and after the ball is shown that varies depending on the ball position, the variation is divided into 12cycle steps to keep the phase of the signal correct. The code for the game control is mostly things to keep the ball and players within the screen, however it is not as easy as one could think as the program must always take exactly the same number of clock cycles or the TV looses its lock to the color carrier. Keeping track of all flow paths and keeping the timing is the largest problem when generating color signals in software.
The sound generation is very simple; there are two sound channels for outputting sound. The sound is called at the beginning of each scan line and outputs a sinus waveform from ROM for each channel to the audio DA, the position is updated according to the speed variable. The speed is changed according the speed change variable and thereby can be pitched up or down. A kind of bounce sound is created by pitching a ton down quickly when the ball bounces. There is also a timer variable to keep track of how many frames the sound should be active.
Most of the game data of the game is stored as one big chunk to be able to use the program ROM more efficient. This is done by using all the 12 bits and the iread instruction, which makes it possible to store 50% more data than by using retlw, but at the cost of speed. It is hard to use 12bit data efficiently, but to make it easier I chose to separate the game data into one fastmem- and one slowmem- part, where the 8 lower bits of each 12-bit word is the fastmem and the upper 4 bits are the slowmem. Getting one byte from the slowmem requires two iread but the fastmem only requires one. Graphics objects are stored as 4-bit palette values, so is the music, but the font and text strings are all 8-bit values, so it is quite natural to store the 4-bit data in the upper part and the 8-bit data in the lower part.
The software is written to run for both PAL and NTSC with almost the same code, done by making all timing with constants. The constant system selects what TV system to use. In the code I have also prepared timing for PAL-M and PAL-N but they are not tested. It is not possible to generate SECAM color video signals in software with this design, so there is nothing in the code to support it. Note that the frequency which the chip should be clocked depends on your TV-system. (This is described more in the system information page)
Schematics, layouts, source-code are available in sxpong.zip (172kB) it contains both PAL and NTSC versions, make sure you put the appropriate version into your chip.
When making this kind of software ios is good to have emulators. There are unfortunately no emulators yet, but there are some open source emulators for my previous pic-games. (For example the PIC16F84 emulator by Jesus Arias), there are also open source sx-emulators available (For example Loren Blaney's SxSim). These open source projects are a good start for making your own sx color video game emulator.
More info about video signals.
There is not much written on generating color video signals in software, but there some stuff written about generating B&W signals. If you want to know more about generating video signals check out some of these links:
SX-Pong (C) Rickard Gunee. This is open source, use this at your own risk ! You may use the information on this page for your own projects as long as you refer to the original author (by name and link to authors homepage), don't do it for profit and don't hurt or harm anyone or anything with it. The author can not be held responsible for any damage caused by the information on this and related pages.