I got myself an interesting bit of museum-grade hardware last week from a friend of mine. Little (not in size, though) Z80-based industrial computer,  four A4 sized cards on a back plane, 8KByte of battery-backed up SRAM. Device seemingly worked – one could read data (programs) from memory, but saving didn’t work correctly or at all. My first suspicion was of course software Eprom(s) as the computer originates from somewhere 1980’s. As I hadn’t instant access to a prommer, I first decided to check possible hardware-faults in address decoding logic of memory card as the fault was hinting to that sort of problem as well. I didn’t find any faults in there, couple of potentially hazardous design-flaws, but as the device had already worked 20+ years, those had perhaps been proved to work after all.
So I loaned a simple prommer from a friend and started verifying the eprom contents. One out of the three eproms was outputting random-ish bytes here and there. I could read out 4-5 different commonly repeating binary images out of the one Eprom, but none of these worked at the actual hardware. With any of the tried images the computer stays dead silent, with original supposedly-corrupted rom, it atleast starts up. As the prommer-software lacked any control parameters over the reading, I decided to do what I had planned to do for some time now, my own prommer (well, memory-reader at this point atleast). I was hoping that with settable read-speed, I could perhaps still salvage the lost contents somehow. On to the matter… few hours and roughly 100 lines of C later, I had Atmel mcu interfaced to eprom and could read it’s contents over serial port to PC.
Good news, after slowing down the read operations and precise control over the vcc, I could now get more consistent data out of the eprom. Bad news, none of these images was even close to the ones read with the commercial prommer.  At this point I verified that my prommer was actually reading the data correctly and not outputting any garbage –  it worked, so the fault was really the ROM itself. I read the contents for about 30 times, out of the results there can be found three commonly appearing binary patterns. Looking at these three patterns more closely, reveals there is difference between them only in three address locations, so I can now atleast get quite consistent garbage out of the chip.
Too bad for more testing, the commercial prommer decided to stop working at this point (what seems like timing problems with the PC, it’s one of those using programmed I/O through parallel port), so I couldn’t test all of the read images on the actual hardware. So I’ll propably have to continue with adding the write operations and some kind of terminal functions to my own prommer.
What troubles me at this point, is that despite the more consistent data, I can’t be sure if the the idea of slowing the read was correct at all or if I did end up with more garbage than with the commercial prommer anyway. Disassembling the rom contents doesn’t immediately reveal anything as there are no illegal opcodes or non-sane parameters at the differing address locations and digging through thousands of lines of disassembled code to understand it, is too much trouble to do for just plain curiosity. Anyway, should this test succeed, it would propably be a nice bit of information as the much used eproms are getting older every day in all kinds of equipment.
Long story short – if you have a car, refridgerator, tv or anything useful (and old) equipment you have containing eproms, back the data up before it’s too late. They’ll fail eventually to point of no repair.