Recovering code from ancient EPROMs and PLAs
booth
I have to duplicate a board that was designed by our company 18 years
ago. It has 2732A EPROMs, 8086 and 8753 CPUs and an PLS101 PLA on it.
Unfortunately the old codes are lost.
Is it possible to recover code from the EPROMs and the PAL or do they
have code protection.
All kind of help will be appreciated.
Thanks
Dr. Anton T. Squeegee
boothmu...@hotmail.com says...
> Dear All,
> I have to duplicate a board that was designed by our company 18 years
> ago. It has 2732A EPROMs, 8086 and 8753 CPUs and an PLS101 PLA on it.
> Unfortunately the old codes are lost.
> Is it possible to recover code from the EPROMs and the PAL or do they
> have code protection.
The 2732's -- Should be no problem. You should be able to read
them with any device programmer capable of handling such.
The microcontrollers -- Those are old enough that I don't think
they have code protection. I could, however, be wrong. Again, should be
readable by any device programmer that can handle the specific device
type.
The PAL -- Could be dicey. All PALs, from the earliest 16L4 on up
to the current devices, have an option called a 'security fuse' which
can, at the programmer's discretion, be popped during the actual
programming operation.
If this has been done, you don't have any real way to recover the
fuse map from the PAL itself. Your only options would be to reverse-
engineer the PAL's functionality based on what it's doing in the
circuit, or to (destructively) open it up and look at it through an
electron microscope.
If the security fuse was NOT blown at programming time, you will
be able to read the PAL, and recover the fuse map.
Here's the kicker. Given the variety of devices you've specified,
attempting to read them will require a high-end 'Universal' device
programmer, something that can handle memory, microcontroller, and
programmable-logic devices all in one package. This means that you will
need something that uses a technology called pin-driver.
Such systems do not come cheap on the 'new' arena. You're looking
at a bare minimum of about $500, and they go sharply up from there.
Manufacturers of such include EETools, Advin, BP Microsystems, Xeltek,
and Data I/O.
If you do not want to invest in such a system at this time
(SHAMELESS PLUG ALERT), I offer reading and programming services at a
nominal fee. Details are available at:
http://www.bluefeathertech.com/devices.html
Happy hunting.
--
Dr. Anton T. Squeegee, Director, Dutch Surrealist Plumbing Institute.
(Known to some as Bruce Lane, ARS KC7GR,
kyrrin (a/t) bluefeathertech[d=o=t]calm -- www.bluefeathertech.com
"If Salvador Dali had owned a computer, would it have been equipped
with surreal ports?"
Richard Henry
"booth" <boothmu...@hotmail.com> wrote in message
news:1119196269.2...@g43g2000cwa.googlegroups.com...
> Dear All,
> I have to duplicate a board that was designed by our company 18 years
> ago. It has 2732A EPROMs, 8086 and 8753 CPUs and an PLS101 PLA on it.
> Unfortunately the old codes are lost.
> Is it possible to recover code from the EPROMs and the PAL or do they
> have code protection.
The 28732A is wide open. You should be able to read it directly with any
EPROM programmer that has the appropriate socket. One precaution: is this a
UV-erasble part? Has it been stored in the dark?
Philips has discontinued the PLS101, but they still have a datasheet for it
online.
http://www.semiconductors.philips.com/acrobat_download/datasheets/PLS100X.pdf
There are 16 inputs, 48 internal product columns, any of which can be
assigned to any of the outputs, 8 outputs, and a chip enable output control.
BP Microsystems list several programmers that can handle it.
James Meyer
<Spammers...@dev.null> wroth:
>
> The PAL -- Could be dicey. All PALs, from the earliest 16L4 on up
>to the current devices, have an option called a 'security fuse' which
>can, at the programmer's discretion, be popped during the actual
>programming operation.
>
> If this has been done, you don't have any real way to recover the
>fuse map from the PAL itself. Your only options would be to reverse-
>engineer the PAL's functionality based on what it's doing in the
>circuit, or to (destructively) open it up and look at it through an
>electron microscope.
>
I've often wondered if, for PAL's that have been protected, one couldn't
present the pins with PNR sequences and record the applied states and the
resultant outputs. For PAL's with registers and flip-flops, you might have to
apply pretty long sequences to ensure that data migrates through all the
registered stages.
With that data, it should be possible to extract the logic function
equations for the PAL. The extraction process could be "smart" or as simple as
an exhaustive search. Who cares if it takes a million trials? A computer is
going to do it eventually. Once you have the equations, passing them through a
compiler for that chip (or any other chip) should yield a functional
replacement.
The replacement chip may or may not have an identical fuse map, but if
it functions the same, who cares? The original function must have been
"computable" or it couldn't have been in the chip to begin with.
Jim
Anno Siegel
[reverse-engineering PALs]
> I've often wondered if, for PAL's that have been protected, one couldn't
> present the pins with PNR sequences and record the applied states and the
> resultant outputs. For PAL's with registers and flip-flops, you might have to
> apply pretty long sequences to ensure that data migrates through all the
> registered stages.
Pretty long, yes. It may or may not be theoretically possible to recover
the fuse map, but practically the combinatorics would explode. You'd
have to consider not only every input combination, but every sequence of
input transitions, up to a length of 2^n for n flip-flops, I guess.
With m inputs, thats all sequences length 2^n of m-bit words, so
(2^m)^(2^n) = 2^(m*2^n) input combinations. That gets large pretty soon.
[...]
> The replacement chip may or may not have an identical fuse map, but if
> it functions the same, who cares?
You would care if the fuse map comes out much larger than the original.
The thing worth protecting is probably not so much the logical function
of the device but the particular optimized implementation (the Karnaugh
map work).
Anno
cs_po...@hotmail.com
so you can scan its truth table easily.
The eprom is similarly easy to read. A little trick - if you have an
older ethernet board with a socket for a boot rom, you have an eprom
reader. It's probably intended for a 2764 so you may have to do some
pinout translation, but it's a quick way to get the contents of a rom
without specialized hardware.
The 8086 has no internal memory. It's 16 bits wide so one eprom
probably contains even addresses and the other odd.
It's the 8753 that may be interesting.
Sure this thing isn't just a PC-XT clone? If so, the 8753 is probably
just providing the standard keyboard controller function.
Rich Grise
An 8753 is the EPROM version of an 8053, which is a souped-up 8051.
So, yeah, keyboard controller sounds close. Also should be easy to
read out, unless it has its security bit set. Of course, knowing
what the original circuit was supposed to _do_ would help a lot. :-)
Have Fun!
Rich