Help to copy PAL16 / GAL16 / GAL20 ICs

I'm currently working on a project to "clone" some old computer boards I
have. The companies are long since out of business. These boards are from
around 1983 to 1985.

Please be a little patient with me as I'm not that familiar PAL/GAL ICs and
can use all the advice I can get.

I'm researching in to copying a few of the PAL16 / GAL16 / GAL20 ICs on
these boards. I've been reading that it is possible to "read protect"
(aka - registered) these chips and fear I may run in to this issue.

I'm going to be purchasing an EPROM/PAL/GAL programmer in the near future
and could use some advice on what models and software may be appropriate for
my work. My needs are pretty basic and most of the technology I'll be
working with is from the 1980s. I've been look at an Advin Pilot-MVP, but
fear it may be more programmer then I might need. Any recommendations?

If the PAL16 / GAL16 / GAL20 ICs are "read protected" (aka - registered)
what options do I have to try and reverse engineer these chips? What
options do I have to try and
figure out how these chips are programmed? I have some basic electronics
knowledge, enough to be dangerous, but nothing advanced enough to guide me
with PAL/GAL ICs. Any and all advice will be appreciated.

I'm also looking for someone to help or "tutor" me with these PAL/GAL ICs
and I'd be willing to pay for this service.

You can email me directly at "apl2research -at- comcast.net" or post a
replay
here. Thanks in advance for your help.


Henry

 

Best place to start is to download a datasheet for one of these devices
and see what is actually in it:
http://www.latticesemi.com/products/spld/GAL/index.cfm

As you'll see they are just a bunch of general purpose configurable
gate inputs and register outputs (with a common clock), so you can't do
all that much with them (compared to modern PLD and FPGA's for
instance). They are usually used for address decoding and latching etc.
Although if your devices are doing some tricky stuff it will be harder
to reverse engineer.

It's easy to figure out which inputs and outputs are used, and then you
could try capturing the outputs with a logic analyser while modifiying
the inputs and see if you get lucky.
The circuit around the device can tell you a lot about what is its
intended function, but you've got to have a fair bit of design
experience to know this.

You can extract the data from *some* of these "read protected" GALs,
but some techniques are destructive, so that may not be too good if you
don't have many of them. There are companies which claim to be able to
do this for a fee, or will reverse engineer the design for you, again,
for a fee.

If yours aren't read protected then your job is pretty easy. You can
get GAL programming software that will read in the device and show you
the internal gate and register mapping, or draw you a schematic.

Regards
Dave

 

copying a few of the PAL16 / GAL16 / GAL20 ICs

http://groups-beta.google.com/group..._frm/thread/fbb15c91b434c725/bac51fdc1c8e0b0a

http://groups-beta.google.com/groups?filter=0&q=Help-to-copy-PAL16-GAL16-GAL20-ICs

 

Yes, I know. I wanted as many independent opinions as possible.

Henry

 

http://groups-beta.google.com/group..._frm/thread/fbb15c91b434c725/bac51fdc1c8e0b0a

The problem with that
is that the ones that are off-base don't get corrected.

 

The is one thing I've had to take into consideration. What's funny is now
matter how many different people reply there's so few real knowledgeable
people posting or willing to help. Everyone wants to tell me about how I'm
"stealing" the code to these chips, how I'm so stupid for not using a logic
analyzer (which should only take 15 minutes to do) or how they don't even
make PALs anymore so give up. I've never read so many people willing to
bitch and complain about a simple question and so few with real answers. I
guess it's just a reflection of the state of where our country is these
days.

Well enough bitching. Update: I spoke to a Korean buddy of mine who's
eyeballs deep in to electronics and he had this idea:

I build a device which I'll hook up to my parallel port to "brute force"
analyze the PALs. I found the data sheet for the PALs on
www.alldatasheet.com so I now at least know what I'm dealing with. PAL16L8
and PAL16R4. I believe that GAL16V8 will work to replace both of those.
Once I build the Brute Force Analyzer I'll write a program to analyze the
specific type of PALs I have. Now I wonder
if I can do the same for GALs?

Now my next question is why can't I find ANY information on other people
trying Brute Force analysis on PALs? You would think someone else much
smarter then me has thought of this and tried it.

Any links to prebuilt kits that may help, or will I have to build my own?
I'm not even sure what you would call such a device.

Comments? (yes I know I'm stupid, yes I know I'm stealing, yes I know this
will never work)


Henry

 

People will always have opinions!
Simply take what information you are given and ignore the crap.

Yes, but potentially harder.

They most likely have, but it's not really the generic solution you
might be thinking it is. If the device is using non-registered logic
(i.e. it's just gates decoding an address) then it's pretty easy, just
put every possible binary combination on the inputs and record the
output - bingo you have the full logic table for the device and you can
easily recreate it using discrete gates or another PAL/GAL. That can be
done easily with the parallel port and a few decoder chips and few
dozen lines of code.
But if it's using registerd logic (using the internal flip-flops), it
could be doing anything - this would be much harder to "brute force"
analyse.

I did a parrallel port based digital IC analyser many moons ago that
could automatically detect and decode any digital logic chip, and I can
tell you that the software is a fair amount of work. I suspect it would
be similar for a PAL/GAL analyser.

Yes it will work, you just gotta be smart about it. The circuit around
the PAL will tell you heaps and will greatly narrow down what you have
to check for.
This is why no one has probably bothered to do a kit or project to do
this as a universal solution.

Have you actually checked to see if the devices are security protected
yet?

Dave

 

Oh, I forgot to mention...
Even if you do manage to copy the device, that may not be the end of
the story - it simply may not work with a newer device.
Some (bad) designs actually rely on the propagation delay in the
PAL/GAL device, or there could be fanout issues or some other factor.
It would not be the first time I have seen this, especially on older
designs.
In fact I have once seen it done *deliberately* in order to fool people
trying to copy the design. I have also seen GALs that actually do
nothing at all, but they had complex internal circuitry connected to
all sorts of points in the circuit. From the schematic point of view it
looked as if they were integral to the entire design, but functionally
they did nothing. Once again, done to fool people trying to clone it.
Another "clone fooler" method is to make the signals simply pass
straight though the GAL. Anyone trying to reverse engineer it would
think it couldn't possibly be that simple, so they think something is
wrong with their method.

If you use a newer device (which are very fast compared to older
devices) you could be changing the propagation delay and this could
cause a whole host of problems. Something to keep in the back of your
mind...

Dave

 

Hello Dave. Thanks for the advice. I will keep it in mind when
prototyping. I knew the GALs were much faster, but with out testing I'm not
sure if this will affect timing. I pretty sure everything is controlled via
a LS245.

I've order a PLD Programmer and should have it later this coming week. Once
I have it I'll check all the PALs, but I'm pretty sure they are protected.
Knowing the company who designed the PALs, they didn't give many secrets up
willingly.

May I ask if you still have some schematics or software that I can review?
Maybe a Website with kits? It help the thought process and give me a few
good ideas.

Thanks again.


Henry

 

On commercial designs you usually set the security fuse as a matter of
course, so yeah, most likely protected :-(

A photo and scren shot of an early prototype is here, that's all I have
I'm afraid:
http://alternatezone.com/electronics/old.htm

Sadly the schematics and source code have been lost somewhere along the
line. The hardware was really simple though, just some latched serial
to parrallel devices to feed data into the device (via protection
resistors), and some parallel to serial chips to read data back out.
You can buy commercial equivalents these days that search based on a
pre-programmed library of parts, although my softare went beyond that
and allowed you to debug unknown devices like PLDs and GALs if needed
by feeding signals and clocks in manually. The screen shot shown is
only one of debug pages.

I believe you can get special "pin driver" chips designed specifically
for this purpose these days, they are used in some of those "DAC per
pin" "universal programmers".

Have fun.

Regards
Dave

 

[Attributions and top-posting corrected]

Nowadays it would probably be easier to use a dedicated microcontroller
to cycle through the permutations, especially if it's a one-off project,
or, perhaps, a microcontroller driving a small CPLD.

There are also gadgets that combine logic analyzers with pin drivers,
like these guys http://www.linkinstruments.com/logana5.htm, where you
can dedicate some channels as outputs and use the balance for inputs.

However, as David notes, the general solution to the problem is
reasonably complex. The PLD probably includes a state machine, where the
condition of the outputs depends on the prior history of the inputs. You
can't expect just to wiggle the inputs and then record the outputs. In
the most general case, you'd need to stimulate it with all possible
sequences of inputs.

You're helped (greatly!) on the smaller PLDs since all of the registers
are connected to dedicated I/O pins, their state is available whenever
*OE is asserted, and *OE itself is fixed to one pin. Buried registers or
tricks played with *OE would make the job much harder.

Truly, your best bet is to hook up a logic analyzer to an operating
circuit and run it through its paces. Once you've seen what it does,
write your own functional equivalent.

 

One shortcut is that if the PALs are the right version, there's a
testing algorithm to preset the registers, so that you have
full visibility.

There was an outfit that spammed the newsgroup here, over dozen
years ago, for their PLD reverse engineering board/software. It was
not worth the $400 to me to find out if it worked. (Some garage in
Atlanta, as I remember). Try an advanced search on Google newsgroups
in sci.electronics circa 1990.

But the first thing would be to get an old programmer that has the
algorithm to read out the fuse map that particular version of PAL.
If the application was trivial, some outfits didn't bother to blow
the security fuse. (You couldn't return the chips to the manufacturer
if you had a problem with them if you did).

Mark Zenier
Googleproofaddress(account:mzenier provider:eskimo domain:com)

 

Just a brief update if anyone cares. There is hope, if anyone in the future
has found these threads and was in the same boat as I. Seems there are a
few options available to people with PAL's (not sure if this will work with
GAL's, but I'm also going to try) that may be "protected" and need to copy
them.



I first found a service that used a Brute Force Analyzer to try to recover
and create a JEDEC file from my PAL's. After they had some issues with the
analyzer, due to the age of the machine, I then found a buddy who had a few
good ideas on working with HAL's from the early Mac's. His idea was to
expose the silicon "chip" so it could be examined by a microscope. Once
exposed pictures could then be taken of the "fuse field" that is inside a
HAL/PAL (see data sheet of PAL if you never seen the "fuse field") and it
could then be possible to recreate a JEDEC file, manually of course. I'm a
basic idiot (due to frequent parental droppings and lack of experience) and
probably would have never occurred to me to try such a thing.



He tried a few different ideas to expose the chip, but most were
unsuccessful. His Website chronicles different ideas and stages of things
he has tried. The address is
http://www.stockly.com/forums/showthread.php?p=6 to see some failed
attempts. The real good stuff is here:
http://www.stockly.com/forums/showthread.php?t=17&goto=nextnewest. Take a
look around the whole site. He's really quite smart.



Anyway. he found a service that will "decap" the IC, called MEFAS.com. They
do failure analysis, so really we just use "part" of the services they
offer. If you visit their Website you'll see that they offer a LIB service.
Basically they can "jumper" the security fuse and then you will be able to
"read" the JEDEC file from the PAL. Right now I have a HAL I sent to be
decapped ($175 with return shipping, pics are more if you need them, about
$350 total). There are issues with HAL's that I go in to in a moment that
the LIB process won't work. The idea with the HAL is simple - I found a
version of a HAL (from an Apple IIe) that was in PAL form. Luckily I was
able to read the PAL with my programmer, convert the PAL code to GAL form
and burn a working GAL. Sounds like quite an accomplishment? Naaa. If any
unschooled idiot like me can do it, trust me - you could too. Anyway,
converting the PAL to a GAL is just kids play - the real luck with this is
that I found a PAL which I could read. Since I know the HAL is identically
the same, programmed and logic (fuse field), then I can use the JEDEC as
sort of a "Rosetta Stone" to read HAL. I could have purchased some old PAL's
(and YES they are still for sale in some places!) and burned a few and had
then decapped, but knowing the JEDEC file AND having a piece of equipment to
test the PAL with is really quite a find!



Now for some HAL info. These things are VERY rare. I'm not too sure if
anyone outside of Apple even used them. Basically they are the same as a
PAL, but they lack the "programming" circuitry that a PAL has. A PAL can be
programmed "in the field" where as a HAL could only be programmed in the
factory. HAL's were made by request only. They were a way to "mass
produce" a PAL, which is just a custom piece of logic. The HAL was
programmed, or burned, while in the manufacturing process. Since the
manufacture had access to the bare chip they didn't need any of the
programming circuitry and that helped keep the cost of the finished IC down
since it was a "simpler" IC to produce. Since a HAL lacks any programming
circuitry it also can't be read, so it acts as a copy protection like the
security fuse does in a PAL. Oh sure, you can read a HAL if you want to
try, but all you'll get is a "block" of un-blown fuses somewhere in a JEDEC
file. Nothing useable that will let you recreate the IC. So since HAL's
don't have a security fuse the LIB process offered by MEFAS.com won't help
much.



Hopefully I won't need to manually decode my PAL's. I'm hoping to just have
MEFAS.com "jumper" the security fuse back and be able to read it. Feel free
to contact me if I can be of any help in the future. I can be reached via
email on any of these two sites: www.reactivecomputerservices.com and
www.gse-reactive.com. My email is listed on both sites.



Thanks again for everyone's input. My next project involves recreating some
of the PAL logic in CPLD's. If anyone is familiar with CPLD's and their
programming, please get in touch with me. I could use some help!





Henry

GSE-Reactive.com

My email is listed on the site if you wish to contact me directly.

 

There was a problem with early PALs...seems some of the metal would
migrate and reconnect a blown fuse. The solution was to build the fuse
onto a vertical wall. This stopped the problem but would make reading
the array a bit harder.

I decaped IC by first milling a depression over the chip, possibly
shaving off some of the gold or aluminum wire inside. The part was then
heated along with a strong solution of nitric acid inside an acid hood. The
temperature would be about 300 degrees F.

The hot acid was carefully dripped into the cavity which would then foam up.
Tongs were used to then tap the debris into a buffer solution. Repeat as
necessary
to reveal the chip on the lead frame. If done carefully, the acid would not
spill
over and destroy the IC leads. When the chip was exposed, the IC was
plunged
into the buffer solution until cool. Acetone was used to wash away the
remaining
epoxy particles then the IC was rinsed with DI water which was then chased
with methyl alcohol and blown dry with nitrogen.