Wednesday, May 02, 2012

Reverse Engineering a Dot Matrix Plasma Display

Awhile back, I bought a lot of arcade parts from somebody on Craigslist with the intention of getting some parts and marquees for my house. I wanted to try my hand at reselling as well to see if I liked it. Most of the garage has been sorted, sold or thrown away at this point and in the back corner I found a box labeled "Betson Replacement Screen." I pulled it open and found a brand new dot matrix display. Remembering a post by a friend on his progress reverse engineering a LED display from the 80s, I decided that I had to get a picture on it.

The first thing I did when I got it upstairs was flip it over and google the model number, "APD-128G064A-1". My initial excitement was dashed when I realized that the copious links all pointed to the same 2-page PDF document that was almost entirely devoid of information (datasheet here). It did go over the theory of use at a very high level. Also, thankfully, it discussed voltage requirements. With that bit of information I decided that my best course of action would be to get power to it and see if it did anything, followed by attempting to trace the circuit and figure out what pins did what. Since the datasheet called out the method by which the screen could be updated, I just needed to get a good idea of which pin was for each of the six signals listed. Then I could experiment with a microcontroller and confirm my guesses.

There was a nice test fixture (possibly for probing converted voltages?) that mentioned Vcc, so I stupidly hooked 12V to that and ground to the gnd pin. Nothing happened, and I shut off the power supply and re-read the data sheet. I realized that it called out two different voltages, one for DC-DC conversion to run the plasma display, and one for the logic. With that bit, I re-examined the ignored 4-lead cable attachment and realized that it was probably the power connector. Vcc as labeled was traced to a pin, ground to two more, and I guessed that the last would be the 12-36V DC-DC input. I re-soldered to these instead of the test points and turned the power on. I was immediately greeted with a zapping noise and several of the dots lit up temporarily. Before I could congratulate myself, the power supply tripped. No matter, I knew I had the power lines connected right.

With a renewed excitement, I soldered wires to the used pins of what appeared to be the logic connector and began tracing the circuit out. Every chip on the circuit was a 7400 series chip with the exception of the shift registers. All of them had data sheets online. I managed to probe out several of the connections, concentrating on the circuits that fed the clock and data in pins on the shift registers. After a good hour or so of probing, I had the following crudely sketched schematic and was 99% sure as to the use of four of the six inputs. The other two were either row clock or row data, but I could figure that out by trying both combinations.

Backside of the display.

Schematic bits.

I hurried to Fry's to pick up an Arduino board and they had what they called "Arduino Compatible" OSEPP Uno boards. I got it home and after a bit of googling learned that you had to manually select a different board type. I burned the blinking light test binary on and it worked, so I was off throwing together a quick test application. Armed with a new, beefier power supply, I tried my code. The first thing I attempted was to display a test pattern to the screen. It failed outright. I figured that since the display claimed that the row needed manual resetting that I wasn't clocking the row line in properly. After a bit of time experimenting, I had a program that took the random garbage that showed up on the screen when it booted and stepped it down one line per second. I now knew which line was row clock and which was row data. After a few ore hours of throwing code together, I came up with this program. I powered on the display and below is what I was greeted with:

I had officially achieved liftoff! There was a pesky problem with wobbly pixels in some areas, and the screen refreshed so slowly that it flickered like hell. Also, there was garbage at the bottom of the screen that I couldn't account for. Now that I'd prototyped it, it was time to get rid of the Arduino libraries (they are very slow) and go to raw register accesses. Also, I wanted to create some sort of protocol by which I could update the display using the USB to serial connection provided on the Arduino. I briefly tried creating 3 color and 4 color grayscale images by displaying images 1/2 of the time, and then 2/3 and 1/3 of the time. The screen stopped lighting all the pixels when refreshed too quickly and when I slowed it down well enough to get a clean picture, it flickered, so that was out. Also, since there was only 2 KB of SRAM, I had to place half the image in EEPROM which meant that access times for the two frames were not in sync. I finally settled on a simple serial protocol by which the EEPROM could be rewritten, a 1KB buffer in SRAM could be rewritten, or text could be rendered onto the screen using the EEPROM image as a 128 character 8x8 font.

The program took me a few nights to complete, thanks to some setbacks with the Arduino programming environment. However, I got the column data clocking out via SPI instead of bit banging which drastically improved the refresh speed. I also converted to raw port accesses which helped. The images now displayed crisply and I could dump data to the screen using a test program in Visual Studio. I put my friends to work helping me format an 8x8 font bitmap and drawing black and white images to display, and the results are below:

Text rendering using font burned to EEPROM

A cat!

Milhouse is not a picture.

The current source code to the Arduino application is available here. The visual Studio application that I developed into a console application is available here. They're probably not much use to anyone who doesn't happen to have one of these screens available but I figured they would be educational to the curious. The serial protocol can currently accept a 128x64 image for display or burning into the EEPROM. It can accept text to be rendered. It can clear or invert the screen. It can force text to be drawn normal or inverted. It can also move the cursor. I plan to add several more functions to the serial API such as scrolling and scaling, blitting and other high level graphics operations one might expect from a nice display driver. I would take the easy route and just upload full processed images but unfortunately I can't push the serial past 57600 baud or the interrupt can't keep up with the image refresh.

That isn't all, however. I plan to pick up an old laptop from a friend and put Linux on it. From there, I'll need to port the console application and add a web server. I want to put up a simple PHP script that allows poeple to upload images or text to the screen from the internet. Possibly, I also want it to take twitter updates or texts on a google voice number. Basically, I want this to be an interactive toy that guests who come to my parties can interact with using their phones. Stay tuned for more development!

6 comments:

Schwuuuuup said...

dragonminded.blogspot.de is stealing bandwith from dragonminded.com?? WTF?

Overexcited Script? ;-)

DragonMinded said...

Apparently google redirects the blog to country-specific domains. I have *.blogger.com and *.blogspot.com whitelisted of course. I've removed the whitelist for now since I didn't expect Google to do this (grrrr).

Anonymous said...

Maybe add blogspot.*

I still can't see anything!

DragonMinded said...

Have you forced a full reload (Ctrl+F5 on most browsers)? I took the entire .htaccess file off of the server so there should be no reason why it doesn't load.

michu said...

hey, nice work! If you have trouble with the serial port latency (as I had) check out my blog posts at http://neophob.com/2011/04/serial-latency-teensy-vs-arduino/ and http://neophob.com/2011/02/low-latency-serial-arduino/

cheers

miceuz said...

i had some fun reverse engineering chinese LED module. All datasheets I could find were in chinese :)

http://blog.hardcore.lt/mic/archives/011068.html

...and this one is not forgiving - if you let the line of leds on for some time, mosfets for that line start smoking :)