Help to copy PAL16 / GAL16 / GAL20 ICs

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.

Tim.

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)            
        www.flippers.com              "Old pinballers never die, they 
just flip out."

John Robertson wrote in news:2005080422361456600% spam@flipperscom:

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.

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.

Comments?

Henry

"newtype" wrote in message ...> John Robertson wrote in

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

Mike.

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.