In order to properly reverse engineer a PAL, you need to correctly identify which pins are inputs, and which pins are outputs. This in some cases is trivial because some of the PAL’s pin functions are fixed. Let’s look at the example of a PAL16L8.
Of all of the different techniques this one may be the simplest but also the most important.
When you’re trying to reverse engineer something, understanding the system is key to unraveling the black box which is the PAL. You need to understand what connects to the PAL on the inputs, what it connects to on the output side. Usually going one level back isn’t enough. Why? Because maybe the PAL connects to an OR gate, that then takes a couple other connections. So what you need to do is follow from the primary driver to the consumer of that signal.
Dumping ROMs is a pretty common practice in the space of reverse engineering, and many eeprom readers are cheap, easily available, and there’s really not much to them. Plunk your ROM chip in the reader, press, go, and you have a binary file with the contents. Provided that your reader supports the ROM chip, or you need an adapter like I built in this post to read Commodore Amiga ROMs in a TL866A:
I’ve recently put a new page online on the site. It hosts a basic outline on different techniques to enable one to reverse engineering a PAL, and produce a modern equivalent.
Right now, there are about a dozen topics/techniques, with no content beyond basic background information.
As time goes on, I’m going to add more and more posts, with the page serving as the outline, index, with centralized links.
If you’ve been following my blog, you’ll see that I’ve been reversing a Commodore Amiga SCSI HDD Expansion card called the Dataflyer. On that Dataflyer, there’s a PAL that handles address configuration (the latch), chip selects, and converting the 68000 signals to those the peripherals understand.
Since I’ve been reverse engineering a DataFlyer Plus HDD SCSI expansion card for the Commodore Amiga, I’ve needed to get a much better understanding of how the AutoConfig process works. I’m by far no expert on it, but I have learned a lot and wanted to share a couple logic analyzer traces of this occurring in the wild. The Commodore documentation refers to these expansion cards as PICs or Plug-in Cards.
While trying to reverse the function of the Commodore Amiga Expansion Systems DataFlyer 500 BUSS PAL, I really needed to know what was connected to what. There are no, as far as I know(!!), schematics available for this board, so I thought I’d bring that to end.
I will be publishing schematics relatively soon once I’ve had some more time to double-check them.
So I’m in the process of trying to reverse engineer some custom PALs from a Commodore Amiga Dataflyer 500. It would be ideal to read those PALs directly, however I don’t have a compatible PAL reading solutions. I’ve found some online but they are easily $800-$1200. So someone on a previous blog post commented about a potential solution that works with the TL866A eeprom reader.
I had a few needs to for a simple voltage display that can handle the range of +5v to +12v. There’s a few different applications like displaying the state of a battery, a state of a power supply and so on. I was fairly interested to know how accurate these displays are considering they are only a few dollars each. I ordered these from Amazon.
