I sent a PAL to MEFAS to be decapped. They e-mailed me this picture of the die before they sent it back. I just received fedex confirmation that the package arrived, but I'm out of state for the next few days.
Here is the photo:
Its a 16R8 HAL, not actually a PAL but it should be the same.
I counted 8 groups, and 8 rows which makes 64 rows, and that sounds right. I only counted 16 olumns an not 32, but maybe when I get a higher power shot it will make more sense.
Which areas would you like me to take a closer picture of? I will post some when I get back in.
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.
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
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.
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.
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)
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.
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.