Virtual Game System - A game console with a mechanically scanned display.

If you move a bright light fast by the eyes, it will leave a line behind because the human brain and eyes are slow to interpret fast changes in light intensity, leaving an afterglow. If a row of LEDís is moved sideways while the LEDís intensity is changed, an image will shortly visualize in the air where the LEDís are moved. If this is done several times, for example if the LEDís are mounted on the end of a bar mounted on a motor as in the figure on the right, the same area in the air could be scanned several times showing the same image each time. Done at high speed it would generate a quite good virtual display hanging in air thanks to the persistance of vision effect of the brain. People has started to refer to this kind of display as POV-displays (Persistance of vision displays) as if it was the only type of displays depending on the peristance of vision effect but that is kind of ignorant as many display types use the same effect, like for example CRTs and multiplexed LED displays, thus "mechanically scanned display" is a more accurate name.

The idea of making a mechanically scanned display came from Bob Blickís mechanically scanned clock. He made a clock using the same technique, so I wanted to take his idea a step further and make games with it, resulting in this project. The biggest problem to do this was the communication between the game system and the graphics card. This was not a problem for the original mechanically scanned lock because in that system the clock-functionality was built in to the graphics card. So no communication was needed for the clock.

The mechanics

The mechanics is an essential part of this project since it is a mechanically scanned display. The system has basically two parts, one solid platform, and one rotating rotor. The rotor is a bar, with the graphics card in one end, and a balance weight in the other. On the graphics card, a Plexiglas bar is attached, with 16 LEDís (10mm) attached on it. To get a wider viewing angle of the LEDís they have been made rugged with sandpaper.

To get a more stable rotor, the motor is attached and rotating with the rotor, and the axle is mounted at the platform. The motor has an extra long axle, so the three ball bearings, for power supply and communications can fit between the rotor and the platform.

Picture of the rotor and platform (Click to enlarge) Drawing showing the motor attachment


One of the hardest problems in this project has been the communication between the rotor and the platform. The mechanically scanned clocks that have been done before didnít communicate with anything, the clock functionality is in the microprocessor that is rotating with the rotor. The power supply have been transmitted to the rotor in many different ways, for example by taking it from the rotor of the motor that is getting it through coal contacts, or some people have used bearings, but my choice was to use ball bearings with wires soldered to them. First when only the power supply was to be transmitted through them, it seemed ok, but as I first tried to communicate between the two PICs the result was catastrophically bad. As the bearing was not conducting all the time due to micro gaps, it was impossible to do any communication at all, when looking at the signal it was full of noise, but the power supply didnít have this problem. So I tried to increase the current to 100mA when communicating, and it really decreased the noise by breaking through some of the micro gaps. Now it was possible to see the information clearly, but the amplitude was lower and it had a quite big offset from the ground level of the game system. This was due to there is some resistance in the bearings, and when running a big current through them, there was a quite noticeable voltage drop. The voltage difference problems was solved by removing the DC component of the signal with a capacitor and add a bias voltage (VDD/2=2.5V). Now it was possible to get a clear signal by using an operation amplifier to compare the signal with an adjustable reference level. The communication problems were solved! The same circuit for communication is used for both the graphics card and the game controller.

Detail picture of the communication bearings and the IR synchrnization LED and switch (Click to enlarge) Detail drawing of the communication bearings

The graphics card

Picture of the graphics cart and LED's
(Click to enlarge)

The graphics card controls the LEDís, these are driven by two 74573 latches. These are connected to Port B, and the latches are selected with the two lower bits of Port A. To limit the current through the LEDís there is one 270 current limiting resistor on each LED. The synchronizing IR.-switch is inputted at pin 2 of the Port A, giving a positive pulse as the IR.-switch passes the IR.-led. The IR led is placed inside of a tube, to make the IR beam more narrow, giving a more stable picture.

The communication interface is connected to pin 2 and pin 3 of Port A. Using a standard voltage regulator (7805) the 5v-supply voltage is achieved. Because of the noisy environment, both sides of the regulator got big capacitors to reduce noise.

Schematic over the graphics card. (Click to enlarge)

The game control unit

Picture of the game system control unit
(Click to enlarge)

The game control unit is based on a PIC16F84. It has two 74245 to read the joysticks, and one DA converter (TLC7524) for sound. To select one of these three devises are selected by a 74139 demultiplexer, controlled by the two lowest bits in Port A The data bits of the DA and the 74245ís are connected to the Port B of the PIC, but only using the 7 lowest bits. This is because the seventh bit is used as SDA, and together with the fourth bit of the Port A as SCL, forming an I2C interface. On the I2C interface, a real time clock and an eeprom (2kB) is connected. The clock is for keeping track of the time (For the implementation of the clock), and the eeprom is for storing game data, not used in my test software though.

To get correct voltage out from the DA, a reference voltage is needed, this is generated by one transistor (BC547), one resistor and one potentiometer to be able to adjust voltage. The communication interface is connected to pin 2 and pin 3 of Port A.

The joysticks are digital joysticks, the same kind used with the old game computers Amiga and C64, connected with 9p-dsub connector.

A standard 7805 regulator is used to get the 5v-supply voltage needed for the circuit.

Unfortunately I originally misplaced the layouts, but I found the layout for the gamesystem (but not the graphics card) recently on paper and have scanned it. Here is a reverseengineered component placement, I'm not 100% sure if it is correct but it is something.

Schematic over the game system control unit. (Click to enlarge)

The graphics card software

Startup test image, showing
that the display is up and running

The graphics card is a high performance application, so the code was written in pure assembler. It has two main tasks, showing the image, and interpreting and performing graphic commands.

At startup the image shown is a test image to see that the graphics card is working correctly, as seen at the right picture.

The main loop is reading the communication port continuously and performs the command sent. If the game system doesnít send any command the game system reads 0xFF and that is interpreted as a "no operation" command. When a command is received, the lower 3 bits (bit 0-2) are the command, and bit 3 tells what color the command should be in, where a zero means "off" and a one means "on". The commands that can be sent are:

0 - Clear screen ()
1 - Put Pixel (x, y)
2 - Horizontal Line (x, y, length)
3 - Vertical Line (x, y, length)
4 - Put a character on the screen (x, y, char)
5 - Load entire graphics memory (mem0Ömem47)
6 - Draw line using Bresenham's algorithm (x1, y1, x2, y2)
7 - No Operation ()

Some of the commands have parameters, these are the ones shown in parenthesis after the commands. They are sent directly after the command byte, all parameters are one byte each. Most of the memory used for the graphics controller software is the bitmaps for command 4 Ė putchar. It can output letters A..Z, numbers 0..9, and a few special chars for example parentheses, apostrophes etc.

The communication protocol is quite simple. For each byte, one start bit (zero) is sent to the game controller, then a synchronization bit follows, telling the game controller if the screen is being drawn (like the vertical sync indication bit in a standard graphics system). If the sync bit is not zero, then the game system can start a transfer to the graphics controller. First a start bit (zero) is sent from the game system to tell the graphics controller that a byte is coming. Then the byte follows with the LSB first and the MSB last. Each bit transferred takes 20us.

Each time the read byte operation is performed, a check of the IR-switch is done. If the IR-switch output is high, then the screen is to be draw before the command can be performed. The screen memory is organized in columns instead of rows (that standard graphics controllers are using), this because a whole column is shown at the same time. Showing one column is quite easy. But to make the layout of the PCB easy, the bits are not in order, and therefor reordered before outputted to the LEDís. The piece of code showing the display gets one column of graphics data from memory, reorders the data output the data to the LEDís waits for a while, then do it again. This is done for all 24 columns, each 16pixels high.

To get be able to see the pixels in x-axis better, there is a little gap between the pixels where they are turned off. The time the LEDís should be on and off is dependent of how long time a lap takes. So to get a constant image size, an interrupt routine is counting how long time a lap takes, and from the lap-time the delays are calculated.

The game control system software.

The software in the game system has quite low performance requirements, but the code is quite complex, so it was ideal to make it with a c-compiler. (PIC-C by Hi-tech Software from Australia, their compiler is the best C-compiler available for the PIC) The communication routines require very precise timing, and therefor they are written in assembler. The images below shows what programs I've implemented on the system.

The game Pong implemented on the virtual game system. The game Tetris implemented on the virtual game system.
A clock implemented on the virtual game system. A text scroller that shows text sent from a RS232 port.


Schematics, source-code and hex-files are available in

More mechanically scanned stuff

If you want to know more about mechanically scanned stuff, check out some of these links:

  • Bob blick's propeller clock

  • Daryl Bender's propeller clock

  • Questions ?

    If you have questions about the games, make sure to check out the FAQ (Frequently Asked Questions) before you ask me.

    Copyright note

    Virtual Game System (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.