Reverse engineering the EPROM

A project log for Twitter feed on an old LED marquee

An adventure in '80s electronics and embedded Linux

Enrico GueliEnrico Gueli 04/02/2022 at 14:194 Comments

My initial plan was to desolder the microcontroller (a Winbond W78C32C-40 MCU, with an 8051 core) plus a few other logic chips in the board, then add some wires to control the LED circuitry. But desoldering was tougher than I thought, and while in the process I though "wait, why don't I keep the MCU and reprogram its firmware to get pixel data from outside?"

Here's the idea: I dump the contents of the EPROM (a 27256 DIP which, by the way, is accessible and replaceable from outside the chassis) to my PC, reverse-engineer it, figure out how exactly are the LEDs controlled, then write an 8051 firmware of my own that somehow gets the data from the external Linux machine and displays it.

What to use to get the data? The marquee already has a serial connection (you'd use that on a PC to program the text, animations etc.) but the MCU datasheet puts a limit at 9600bps, too slow to get raw pixel data. I want the bi-color 85*7 display to be refreshed 60 times per second, so I need 2[bit per pixel]*85[columns]*7[rows]*60[fps] = 71400bps minimum.

So instead of using a serial connection, I might somehow add a "virtual memory" so that when the MCU reads it, it actually reads data coming from outside. Something like memory-mapped I/O.

The advantage of this approach is that you don't need to change anything in the existing hardware. No desoldering, no messing up with wires. Where the EPROM socket is, I would put a DIP IDC connector like this one that breaks out all its pins through a flat cable to another board, containing logic level shifters and anything else to interface the display to the Linux board.

The disadvantage is that it's another level of "hacking" this device; in addition to the hardware I need to have a deep understanding of how the firmware works. Sounds complicated, but also a really interesting challenge! What do you guys think?


Ken Yap wrote 04/02/2022 at 23:14 point

One thing you have to take into account is that the 8051 is Harvard architecture. So built-in fonts would be stored in the EPROM, but working memory for display buffer would be in the SRAM, underneath the EPROM. The firmware almost certainly multiplex drives the LEDs from the buffer. What you might be able to do is to replace the comms routines in the EPROM with a faster comms method, maybe even a parallel port circuit that you add on. You might be able to find some unused I/O space on the 8051.

  Are you sure? yes | no

Enrico Gueli wrote 04/03/2022 at 08:04 point

Good point. But if I go with breaking out the EPROM pins, I can only have control over the code memory.

The current firmware seems to use less than half of its available space (32k), so there might be indeed room for some additional I/O. Which is fine I guess, as the I/O is mostly feeding data into the MCU. I understand the MOVC instruction can be used to read data from code memory; I can tell the MCU to read at specific locations just to signal the intention to read data from outside, then copy then actual data into the RAM framebuffer (if there's one, gotta look into the firmware).

At this point this is all speculation. I'll finish reverse-engineering the schematic, to see how memory/data is actually mapped, then start with the firmware.

  Are you sure? yes | no

Enrico Gueli wrote 04/02/2022 at 22:20 point

It does, but it goes via 2400bps serial line. I have more complex animations in mind, that the current firmware can't do, so instead i wanted to render the animations on the Linux machine and send the frames to the display.

  Are you sure? yes | no

Ken Yap wrote 04/02/2022 at 20:56 point

Doesn't give you the serial interface command set?

  Are you sure? yes | no