Connect with us

Help to copy PAL16 / GAL16 / GAL20 ICs

Discussion in 'Electronic Components' started by Henry, Jul 28, 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" 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. Any recommendations?

    If the PAL16 / GAL16 / GAL20 ICs are "read protected" 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 replay
    here. Thanks in advance for your help.

  2. Tim Shoppa

    Tim Shoppa Guest

    [read protect] What options do I have to try [...]?

    For non-registered devices, it's straightforward to figure out which
    pins are in and which are out (trace out PC traces or remove PAL and
    figure out what's open circuit vs what's driven), walk the ins through
    all possible combinations while recording the outs, and come up with
    the logic inside.

    For registered devices, it can be substantially more difficult. If you
    can figure out the purpose of the registered PAL then it gets easier.
    Having a multichannel scope and observing the device in operation may
    reveal typical usage, especially if you can put the micro that talks
    through the PAL into a debug loop.

  3. There used to be a company (late 90's) on the 'net that advertised that
    they could read PALs...been gone a while as far as I can figure out.
    Perhaps they are 'underground' now.

    John :-#)#
    (Please post followups or tech enquires to the newsgroup) John's
    Jukes Ltd. 2343 Main St., Vancouver, BC, Canada V5T 3C9 Call
    (604)872-5757 or Fax 872-2010 (Pinballs, Jukes, Video Games) "Old pinballers never die, they
    just flip out."
  4. newtype

    newtype Guest

    Once you get a Universal Programmer, and you can read the PALs.
    Where ar you going to buy obsolete PALs ? Maybe buy modern GALs, SOIC
    and solder them on a DIP socket. Chances are you might find some PALs,
    and when you get them, the IC pins will be rusty brown or black?
    Use tarnx to remove the corrosion?

    You mightalso come across old bipolar PROMS w/ the PALs,

    Any programmer bought now will be able to read the older parts.
    General Devices has alot of Universal Programmers,

    google pld tutorial , you'll find plenty.
  5. Henry

    Henry Guest

    Hello John. I would read then convert from PAL to GAL. Now if I can only
    read the PALs. They may have had the security fuse blown. I'm probably
    going to have to 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 analyze on PALs? You would think someone else much
    smarter then me has thought of this and tried it.



    message <John
  6. It's a subject I thought about some years ago, when someone had a device
    that wished to reverse engineer. I never actually tried, however.
    Here are some of my ideas:

    1) An 'L' device such as the 16L8 has no internal registers. So what it
    drives out depends only on what it sees on its pins. For devices with
    no feedback (internal use of pins which are also used driven out)
    such as decoders for example, reverse engineering is pretty easy.
    Where feedbacks are present, it's somewhat harder. It may be helpful
    to 'backdrive' the output pins (drive into them with a strong source
    which will overpower whatever the PAL is trying to drive out) so you
    control what the chip sees on them. [Backdriving needs to be limited
    to short timescales to avoid damage, some chips spec 1 sec max but
    it's better to go much shorter, also the 1 sec max often is only
    permitted for short to GND not short to VDD!]
    I think with care one can backdrive pins and simultaneously
    measure what the PAL is trying to drive out, by backdriving
    to voltage levels not quite fully up and down, and meaasuring the
    current needed to maintain that level. e.g. drive to 0.4V, if
    device is trying to drive down you will have to source current to
    keep it up to 0.4V.
    My feeling is that these techniques will permit complete reverse
    engineering of an 'L' device automatically.

    2) An 'R' device feeds back from the internal register, not from the pin.
    However simple devices like the 16R4/16R6/16R8 provided fixed
    output-enable pins, so one can just enable the outputs to see the
    internal state.
    So one can determine the current state, and try different input
    combinations to see what state one ends up in when clocked. I think
    it is again possible to automatically fully map all reachable states
    and the transition conditions between them.
    The 16R4 and 16R6 have some unregistered pins, which can be processed
    like those on an 'L' device. It's probably easiest to backdrive
    these while mapping the registered pins fully, then work out the
    equations for the unregistered pins afterwards (using your knowledge
    of the state transitions to get the device into each possible state
    as required) using the above techniques for 'L' devices.

    3) The 'V' series combined the 'L' and 'R' structure in the same device,
    one can program the mode of each output pin separately.
    So one needs to work out which output bits are programmed to 'L' mode
    and which to 'R' mode. A big complication is that the output enable
    of registered pins comes from another product term. There may be no
    way to turn it on! This buried state may have to be inferred from
    device behaviour, which makes the problem much harder.
    I vaguely remember some devices provided a way to load such registers
    for chip test, but that feature got locked out when the protect bit
    was set...

    4) Later devices (e.g. Lattice GALs) added more features such as more
    than one clock pin, async register clear from internal terms etc.
    These all make the problem harder!

    Hope this helps (or is at least interesting reading!)

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