Reading a 27C512 EPROM with a Raspberry Pi – ROM-dumping!

Recently I retrieved my Elektor SCMS “copybit killer” from storage and a quick Google search brought up this forum post from just under a year ago – someone was looking to build the project and needed a (binary) image of the ROM contents…

27C512 – 512kbits (64k x 8 bits) of 5V CMOS ROM

Initially I offered to physically send my ROM to someone with a dedicated reader (probably something from the TL866 family that seems to be popular amongst hobbyists) but then decided that seeing as I had breadboard, wires and plenty of small/embedded microcontrollers & Raspberry Pis lying around I really should have a go at reading the ROM myself!

Old Pi Model 2B I’d been using as an LCD Clock – LCD removed ready to read ROM!

How hard could it be? Wire up the address & data buses to GPIO, step through all the addresses 0-65535 and record the data to a file. Easy. (If you ignore level-shifting issues that is πŸ™‚ more about that later… )

Old Pi 2B GPIO to Elektor ROM on breadboard

I discovered this post (which talks about dumping C64 ROMs & also references a previous article) which uses a Raspberry Pi… The Python on the site didn’t work quite right for me, I had to add some debug print statements to work out what was going on and then add some unhexlify from the binascii module to get an actually binary ROM image. There are other ways to do this (properly) but this was the first hack that worked for me, so it stuck. My python to read the chip is available to download below:

Eventually it worked; I had a binary image of the ROM contents. The original Elektor article that refers to the Pascal used to generate the binary ROM contents mentions an output file size of 32768 bytes. My image is all zeros after 0x7FFF so I think it’s all good!

Sanity check – peeking inside the binary image of the ROM

I wasn’t sure of the data integrity as the 27C512 is a 5V part and the Raspberry Pi’s GPIO is all 3V3 (and not 5V tolerant) and I had powered the ROM from 3V3 too. In the python script I’d inserted pauses of 1ms after setting the address/OE/CE before reading the data bus. Looking at the contents of my binary image it looks mostly sensible: it’s easier to judge by eye with this particular ROM due to its function as a finite state machine (FSM), it’s not just “random” binary data (like executable code might appear). There are some anomalies to the repeating patterns though: e.g. 0x7FE8 in the image above and a few other locations I’ve spotted too. I can’t say for definite at the moment if they are corrupt locations or good data.
(UPDATE [2021-02-22]: turns out they’re good data. Very good data. They’re the cool locations that do the magic! Thanks to the very clever people at the SonyInsider forums (well, Kevin Allen especially) – they reverse engineered the state machine function from the ROM contents and the S/PDIF spec… and even wrote some simple C code to generate the binary ROM contents. Truly epic work. I converted the C into python, (not pretty!) so we can at least re-generate the ROM image! Tested & working on Fedora 33, RaspiOS (buster) & MacOS Catalina.)

hexdump – data looks reasonable & uniform…

Datasheet says “No” – minimum Vcc is 4.5V – hmmm. To satisfy my curiosity I gave in and purchased a USB EPROM programmer from (the TL866IIplus) and imaged the chip again. Looks like reading the 27C family slowly at 3V3 is viable as the image from the Pi and the USB reader are identical:

$ md5sum elektor_scms_rom.bin
64bd11d7cd3a2ffcde307e94fd8fd679 elektor_scms_rom.bin
$ md5sum TMS27C512@DIP28.BIN
64bd11d7cd3a2ffcde307e94fd8fd679 TMS27C512@DIP28.BIN

TL866II plus GUI on windows – XGpro

There are other ways around reading a 5V part in a 3V3 system – there are numerous level-shifting devices built into modules that can be placed between the ROM’s data outputs and the Pi’s GPIO, or a simple 2k2/3k3 resistor divider on each data line (address lines etc. can be driven directly from 3V3).

Reading this particular device (Texas TMS27C512) with Raspberry Pi GPIO at 3V3, with Vcc=3V3 worked for me. It might not work with other manufacturers’ devices and/or other sizes of device. The original Elektor article sparked my hunt for the source which, via the fascinating work done on reverse-engineering the FSM operation from the S/PDIF spec, ultimately led to the C/Python code that can re-generate the binary ROM image.

code extract – python to re-generate the binary ROM image

Working with these old EPROM components took me right back to when I first started work in the Telecom industry and that was a long time ago πŸ˜€

Published by zedstarr

Chilled out human being, doing techy stuff.

One thought on “Reading a 27C512 EPROM with a Raspberry Pi – ROM-dumping!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: