Introduction
My favorite hacking at the moment is to get surplus displays working. The displays from the HP Digital Entertainment Center PCs are available from numerous vendors for quite low prices and so caught my attention. A word of caution here, I tried multiple sources and it appears all "new" offerings were obvious pulls, carefully disguised pulls or new but of seconds quality. Anyway, even used they are a nice display: large 16x2 5x7 characters plus additional icons; a removable color filter; just low enough current draw to run the display+Arduino from USB; and, a compact physical size. There are also handy project components on the front also: a couple of LEDs, an LDR and an IR phototransistor. On the down side, the connector has an awkward pitch (2 of my displays came with the original cable attached fortunately), communication is quite slow and I haven't been able to find any user-defined character functionality.
Determining Pinout
My first step was to figure out the pinout of the connector. This wasn't too difficult - there aren't many components and most of the important traces are on the side not obscured by the display glass. A key step is figuring out power requirements. I do this as follows: locate a known IC on the board (in this case, a serial EEPROM), figure out where that IC gets its VCC and VDD from (2 pins on the connector in this case), then account for all other pins to ensure there is no secondary power line such as 12v. In this case there were no other power pins so since the EEPROM is limited to 5v and it would be a bit crazy for the on board VFD power supply to operate of 3.3v, I assumed power and all logic was 5v. At this point I hooked up power and the display powered up and displayed a scrolling marque, "WELCOME TO THE HP DIGITAL ENTERTAINMENT CENTER". Supply current was also measured, ~450ma.
The connector has 12 pins: 2 for power, 4 signal lines running to the large IC with custom markings and the other 6 connect to the LED, LDR and IR circuitry.
First Attempts at Communication
There are only two ICs on this display board: a 256 byte serial EEPROM and 44 pin controller labeled with custom part numbers. It is this simple because the usual high voltage driver chips with shift registers are actually embedded in the glass display. I have driven shift registers like this in the PrimeVfd library so I considered just breaking out these pins and driving the display glass directly from the Arduino. It seemed a little too dirty though so I continued on.
I hooked up the 4 signal lines mentioned above to the Arduino and started experimenting with code and a meter. I quickly discovered that 3 of the lines had pull-up resistors and the fourth was normally low. When the 4th was pulled high the display blanked, indicating that this was a reset pin. However I was not sure if instead it was an "inhibit marque and accept data" pin so I tried my next experiments with the pin both high and low.
With 3 possible communication pins, I made a sketch to test different possible communication protocols: serial at all standard data rates (even if you are close, garbage will usually display), scanning for i2c on 6 different possible wiring combinations, sequential and random SPI clocked serial data and brute forcing all possible ways of clocking data in with those three pins. None of these tests had any visible effect on the display, as it turns out because I was sending data too fast.
Identifying the Unknown IC
I decided it was time to figure out what chip was on the board. I was fairly certain it was some kind of microcontroller since using a CPLD or custom ASIC would be massive overkill. I picked up my loupe and started documenting which pins did what, such a where the crystal attached, power, i2c, etc. While doing this I noticed that there was still very faint evidence of the original markings on the chip. I was quite lucky here, my other examples of this display have no trace of the original markings. This was too enticing not to follow so I spent about half an hour experimenting with different lighting and viewing angles until I came up with 89S52. You can sort of make it out in the above image. Google matched that with the Atmel AT89S52 microcontroller. A quick check of the datasheet and the important pins matched up.
This is a flash memory based microcontroller. I don't know why all the effort was put into custom marking the microcontroller, it is not especially difficult to create this kind of functionality and this implementation as it turns out is not all that good. I'm tempted to have the chip decapsulated and unlocked just to see what was worth trying to hide. The 4 control lines actually connect to the 4 pins needed for in circuit programming: RST, SCK, MOSI and MISO. The 89S52 can be erased even after the lock bits have been set so at this point I now had the option of creating new firmware. The new firmware could even be embedded into an Arduino library and uploaded the first time the sketch was run. This still seemed a little clunky and I wanted to see if I could figure out how to use the original firmware.
I wrote a sketch to communicate with the in circuit programming interface of the 89S52 and read back what I could. Unfortunately the lock bits had been set so extracting the program that way was not a p option. At this point I clipped directly onto the communication pins of the EEPROM chip, pulled the 89S52 reset pin high and used a simple sketch to extract the EEPROM contents to see if there were any clues:
WELCOME TO THE 32 87 69 76 67 79 77 69 32 84 79 32 84 72 69 32
32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32
32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32
32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32
32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32
HP DIGITAL ENTER 72 80 32 68 73 71 73 84 65 76 32 69 78 84 69 82
TAINMENT CENTER 84 65 73 78 77 69 78 84 32 67 69 78 84 69 82 32
32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32
@/?A???????? 12 0 0 0 64 47 255 65 255 255 255 255 255 255 255 255
???????????????? 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255
???????????????? 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255
???????????????? 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255
???????????????? 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255
???????????????? 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255
???????????????? 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255
???????????????• 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 165
The EEPROM size is the same as the 89S52 RAM size and my guess is that the 89S52 copies the EEPROM contents into RAM at startup. This is all quite silly since the 89S52 has 8k of flash memory with probably more than enough space to fit in the marque text. However in our case it works out: if we don't like the HP marque text we can clip the EEPROM and create a sketch to overwrite the first 128 bytes of the EEPROM with our preferred text, or just spaces if we want a blank display. Good stuff, but I didn't see any other clues I could leverage.
