In September 2006, I purchased a Samsung 204B SyncMaster monitor for $320+tax. It was a 4:3 monitor, and for certain tasks like my Logic Analyzer Cart, it’s perfect.
It failed in July 2024, and would no longer power on. There was a VERY faint blue flashing happening on the blue power led on the right-hand side of the unit. I figured it was a power-related problem.
There was a HDD backup utility for the Commodore Amiga called Quarterback, part of a suite of tools called Quarterback Tools. This utility allowed you to backup existing files on your HDD, compress and/or encrypt them, and split them across multiple floppy disks.
This backup tool stores a catalog, which contains a number of directory entries at the beginning of the backup file, and then contains file markers for either compressed (CFM + 0x90) or uncompressed (FMRK) files.
I just recently added another HP/Agilent logic analyzer to my collection. This time it is the 16902A. I needed to remove the CPU tray to replace the IDE HDD with a SATA SSD. As a result, I figured I’d take couple images with my copy stand and share them. Hope you enjoy!
So for today ladies and gentlemen, I present a teardown of an HP/Agilent logic analyzer cable. I think this is part number 16715-61601. This cable is used to connect one of a series of 40-pin compatible modules (many of the 167xx series, but not all) from the 60-pin connector on the LA side, to the 40-pin connectors that supports a variety pod adapters. The most popular, at least in my world, of the 40-pin pod adapters is the flying lead one, the venerable Agilent 01650-61608 pod adapters.
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.
