国外网站转载-led旋转显示

工作很忙，没有时间翻译，拜谢原作者。感兴趣的可以研究下，不喜勿喷。
原网址    http://www.rickard.gunee.com/projects/mechscan/dualpic/gamesys.php
有源程序（可惜是汇编），电路图，PCB板图


Virtual Game System - A game console with a mechanically scanned display.
Introduction
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

Communications
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.

Download.Schematics, source-code and hex-files are available in vgsys.zip(34k).

More mechanically scanned stuffIf 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 noteVirtual 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.