Connect with us

Help to copy PAL16 / GAL16 / GAL20 ICs

Discussion in 'Electronic Basics' started by Henry, Aug 1, 2005.

Scroll to continue with content
  1. Henry

    Henry Guest

    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-" or post a
    here. Thanks in advance for your help.

  2. John Fields

    John Fields Guest

  3. Best place to start is to download a datasheet for one of these devices
    and see what is actually in it:

    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.

    Dave :)
  4. Henry

    Henry Guest

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

  5. JeffM

    JeffM Guest

  6. Henry

    Henry Guest

    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

    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 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)

  7. 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"

    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

    Dave :)
  8. 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
    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

    Dave :)
  9. Henry

    Henry Guest

    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

    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.

  10. 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:

    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.

    Dave :)
  11. Rich Webb

    Rich Webb Guest

    [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, 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.
  12. Mark Zenier

    Mark Zenier Guest

    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)
  13. Henry

    Henry Guest

    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

    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 to see some failed
    attempts. The real good stuff is here: Take a
    look around the whole site. He's really quite smart.

    Anyway. he found a service that will "decap" the IC, called 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 won't help

    Hopefully I won't need to manually decode my PAL's. I'm hoping to just have "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: and 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!


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

    Lord Garth Guest

    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
    to reveal the chip on the lead frame. If done carefully, the acid would not
    over and destroy the IC leads. When the chip was exposed, the IC was
    into the buffer solution until cool. Acetone was used to wash away the
    epoxy particles then the IC was rinsed with DI water which was then chased
    with methyl alcohol and blown dry with nitrogen.
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day