Reading a PAL fusemap with a microscope

I'm very excited to be traveling home Saturday! To see the chip! :)

The inputs to the chip are:

01 - CLK - 16MHz 02 - I - D0 03 - I - D1 04 - I - D2 05 - I - D3 06 - I - D4 07 - I - D5 08 - I - /DMA 09 - I - TC 11 - /OE - TSEN

12 - R - /DMALD

13 - R - PWM 14 - R - NC 15 - R - NC 16 - R - NC 17 - R - NC 18 - R - NC 19 - R - NC

So its a pretty simple device. I'm going to try to ignore those output pins when I am reading the device. I want to make sure I try doing this blind. :)

When I got home I tried to take my own higher resolution pictures, but it seems the chip has corroded...? Or maybe my imaging technique is bad. Take a look:

I am going to the university on Monday to use ther metallurgy microscope. It has a video camera mounted to it, and will go higher than 40x.

Here is an image I took with a 40x microscope with my 3x camera zoomed held to the eye piece ;) I'm pretty sure I'm zoomed in on the block for pin 7.

And this is what the block should look like empty. I'm having a hard time locating the input and output feedback connections. They don't seem to be where I'd expect them.

Here is an image showing how I identified the pins:

Is the gold blob I identified a fuse that has not been removed? Or in this case since its a HAL a fuse that was deposited? HALs probably just wouldn't have a fuse where as a pal should have one burnt?

Any suggestions at all? And is there a chance with this HAL that its fusemap visually would be different from the datasheet organization or a regular PAL? Since its not programmed but manufactured at a factory?

Any industry contacts anyone could recomend? I'd love to figure this out. :) I'll try to get some better pictures on Monday.

I've had success reading the fuse map! :) It took 200x and a decent microscope. Still holding the cheap digital camera to the eye piece, but hey...it works. :)

You can see in the images below that a HAL has all the fuses, but some have been cut. So my guess would be rather than them being manufactured with a pattern, they are manufactured 100% connected and then mechanically cut later?

Here is a huge picture of the entire silicon. The fuse map is the big rectangle array to the left. 50x

Here is a 20pin DIP with an arrow pointing to the map. Its amazing the scale inside these chips...and they're 30 years old! :)

Here is one 8x32 256 fuse array with the inputs and flip flop results annotated. 200x

A shot of the bond wires, 200x.

MMI logo 200x

Those pictures were of the ASG, Apple Sound Generator, in the 128k to Plus macintosh. I'm going to write a program to visually read the fusemap so that I don't have to. Pretty cheap, $45 for a chemical decap and then a few hours writing down 1s and 0s. ;)

I was under the impression that HALs were chaper than PALs. Therefore it would be unlikely that such a process would be used. While the gap at the "blown fuse" is small, it does not look significantly different than other gaps in the metalization pattern. I think a mechanical process would have left some sort of recognizable "scar" at the cut. The other method used commonly to remove metalization, "laser trimming", would also leave some visible mark.

More likely the HAL started from the same mask set as the PAL, but the cuts were added to the mask. Also it is likely that to save more on processing, the "fuse" metallization is actually the standard aluminum used in the rest of the chip rather than the alloys used for a fusible link. All of the cuts would be in a single mask layer, allowing the factory to pre-build most of the chip and do quick turns for new patterns.

Just my 2 cents, Gabor

Gabor is correct.

PAL's are programmed by blowing fuses or storing injecting charge like a flash device. You can get factory programmed PAL's but they are still PAL's and are no different than the ones you buy. Programming is a relatively expensive process.

HAL's are 'Hard Array Logic'. They are programmed with a mask (the final, metal mask) during manufacturing. They are generally ordered only in large volume because the cost of the mask, testing and marking must be spread over the end volume. Also, sometimes they can be made on smaller die, though for the case of a 16X8 I doubt anyone bothers today.

Marc Re>> I've had success reading the fuse map! :) It took 200x and a decent

You could have reversed engineered this with a Vector testing programmer, original circuit, and a text editor, but probably not as much fun...

You can verify your logic, when done fusemap extracting, with vector testing and even create a new device - this sounds like a std 20 in 16x8 device ?

(Also watch that some devices have pin polarity fuses)

-jg

I posted this in another thread, but didn't hear from anyone. Maybe here it will get more exposure?

I'm beginning to question the organization of the fuse map in a HAL. It doesn't seem to be related to the datasheets. I've collected a lot of data so far and have outlined it below.

Here is an x-ray of the actual package to show where the bond wires go:

Here is the whole chip:

Here is the map which is connected to "Pin 2", but the connections to the fusemap seem to indicate pin 3:

Here is the fuse map schematic for pin 2. Note the locations of the input and feedback fuses.

Can anyone give me any insight? Will I have to translate the location of the vertical fuse columns to what they "should be" in a GAL?

Thanks, Grant

Probably not. We all read the same news group and articles.

You do seem to be having too much fun. Considering the performance of todays PCs, it would seem you could get to a solution by doing an exhaustive search with a PC controlling the device via some simple circuitry hanging of a printer port.

It seems you have hung much of your analysis on the assumption that the chip layout should follow the diagrams in the data book. There is no such requirement, and it would surprise me if you did find a perfect match. The diagram in the data book is laid out for easy of viewing and presenting a logical view of the functionality of the device. The chip layout is laid out to minimize area, to leverage repeated structures, to meet power/noise/other requirements.

For example, in the data sheet you see the FF feedback coming across the fuse array as two adjacent lines. But if the Q and Q-bar outputs were not adjacent as they come out of the FF structure, then on the chip the lines may not be adjacent. It is also very common to see structures that share something are laid out as alternating normal lay out and then mirrored layout, so that the shared resource (a signal line, a power/ground, a control line) is only needed once per pair of things.

Hope the above helps expand what you are looking for. I still think that a PC based sw/hw exploration would get you to a complete picture with a few days of programming (changes as you learn stuff), and probably less than an hour of CPU time.

FYI: The HAL products were promoted as Hard Array Logic, with the intent of mask programming the devices for high volume cost reduction. In fact many HAL devices were just normal PALs that were programmed at the factory. Have you plugged the device into a PAL programmer and seen if it can be read back? I hope so.

Philip Freidin MMI FAE 1980-1983

Yes, Its read as nothing.

I've read a bunch on reverse engineering and PALs, but have not found any information on brute force methods. In fact all I found were testimonials about Apple using PALs to slow down people copying their computers. Also heard a few people talking about IBM slowing down the first clone with a state machine PAL in the FPU?

I try not to do TOO much book learning without actually getting dirty, but from what I heard its pretty hard to guess a PALs function by logic tests. Would the program you suggest I write already have a hint of what the PAL does and test for input sequences that make sense for THAT PAL?

I know what this "ASG" PAL does, and I'm trying to ignore it. You're right, I am having too much fun. :) A lot of things I do once, and afterwards pledge to never do again. This may be one of them, but at least its looking possible. ;)

I've printed out photos of the fuse maps and by Saturday night Alaska time should have a working replacement. :)

This can only slow down someone who copies blindly not knowing what the hardware does. You can copy an Apple ][ this way, but not //e due to LSI chips. However since it is well known what exactly the hardware is supposed to do, an engineer wouldn't have any trouble making a circuit to do it. Either using programmable logic or a bunch of off-the-shelf TTL chips. I guess I can say I know what I'm talking about: I did a clone of Apple

2 in a single FPGA chip for fun. Only took a couple of days. Of course I have access to design tools that are a far cry from what was hot in 1980.

There are PAL/HAL chips with no registers. Those are trivial to figure out. Now a chip like 16R8 has 8 registers. Let's assume all 8 outputs are used. The output after a clock pulse depends on 8 input signals and

8 current outputs that represent the internal state. The most brute force approach I can think of: Suppose you feed random numbers to the inputs till you get all possible 256 output states. Remember the input sequence to get to each state. From each of 256 states apply 256 different inputs and a clock. You have ALL the possible combinations. Now it is a simple matter of math to figure out which inputs cause a change to which outputs etc.

-Alex.

I'm becomming a little unhappy with the quality of some of the images, there are about 3 fuses I can't quite make out. Having a microscope HERE would help, I'd just 400x zoom instead of 200 and figure out whats going on.

I've transcribed all 2048 bits, and I'm almost ready to make some GALs.

Regarding the order of the columns, I find it strange that IF they didn't use the same column order from the data sheet that they would keep the pattern going per pin. For example, what should be the fuse map block for Pin #2 is actually #3. The inverting/noninverting inputs and flip flop returns match what should be for pin 3, but are in the spot next to pin 2.

I've found a pattern: (this needs to be viewed with a fixed font to look good)

Fuse Block #: Fuse Indicated Pin #: Assumed Pin #: 1 3 2 2 2 3 3 5 4 4 4 5 5 7 6 6 6 7 7 9 8 8 8 9

That's a pattern IMO, and I think its worth reassembling the jedc file assuming that the fuse blocks are not in order, but that the columns are in the proper order.

What do you think?

Grant

If interested, here is the complete fuse map in one image:

High Res: 20.3MP, 2.2MB

Low Res: 5MP, 800k

Don't forget you can run Test Vectors, to compare your new GAL, with these devices [you do still have one that works ?] so you do not need 100.00% reverse engineer coverage. For simple SW that will create GAL JEDEC Test Vectors, look at Atmel's WinCUPL, or ICT's WinPLACE

Most programmers that can pgm GALs can also run these test vectors. Better ones can edit and save test vectors in the programmer.

-jg

This is quite amazing!

Can you give some details on what you did for the CompactFlash interface? Did you develop your own IDE controller?

Also, you mention USB 2.0. How did you handle the hardware/software issues with getting that to work?

Very impressive design!

You could consider putting some more screen shots or something up.

Thanks, Ram.

Not much. I bought a CF to IDE adapter - just 2 connectors and some wires as CF can work in true IDE mode. Interfacing a 3.3 v IDE interface to an FPGA is rather trivial. I made the CF respond to i/o addreses belonging to a "card" is slot 3. On the software side did a simple ProDOS driver. Not my idea and I was not the first - I found a CF interface for an Apple 2 on the 'net. The implementation was mine.

IDE doesn't need a controller. An "IDE controller card" for a PC is just a bunch of bufferes.

I have a USB board form Digilent with a parallel interface that is connected to the FPGA. They provide USB drivers. A state machine inside FPGA to talk to it was not all that hard to do.

Thanks.

Maybe later when I have time.

"logjam" wrote in news:1126586558.061877.123600 @g47g2000cwa.googlegroups.com:

I figured, based on the pinout you gave.

Isn't it easier to apply vectors to the input pins and reverse engineer the equations that way?

I'd like to get the equations for the Mac PLUS PALs.

Retro