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:

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

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

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

Henry

>

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

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:

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

[snip...snip...] [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.

--
Rich Webb   Norfolk, VA

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 snipped-for-privacy@eskimo.com 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

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

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!

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.