keithSo 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.
https://dreamjam.co.uk/emuviews/readpal.php
So I decided to build this. Using an old school Radio shack 276-168B protoboard, wirewrap sockets, lots and lots of 30awg Kynar(?) wire, some resistors, and a cheap Amazon ZIF socket — I’ve created this monster.
I’m not convinced that, for whatever reason, this thing actually functions. I took great care in checking and double-checking my wiring. And I color-coded my connections to separate them.
The whole concept seems sensible. The PALs have a number of fixed input pins, a number of fixed output pins, and then some I/O pins which can vary based on setup. This adapter allows the TL866A to drive all of the pins via the number address lines, and then records that data values present on the potential output pins.
The pa.exe downloadable from the link above is what converts this EEPROM reading output file into a CUPL file that lists the equations for each output pin.
The results I’m getting seem at least partially correct, and I’m working with Bob to try to burn some new GALs and test them.
More to come on this…
Hi Engineer,
I’m glad you’re working on this. I have tried, following this project, to read the PAL data of my Dataflyer-500 but I assume that it is dead and I have not been successful in reprogramming everything. I would be very happy if you could read your PAL data and make it available in order to resurrect damaged Dataflyers like mine.
I look forward to your results.
I’ve read both the BUSS PAL and the DTACK02 (IDE PAL), and while testing of that results is happening soon, I have low confidence.
What I *am* optimistic of though, since I can deduce the logic inside the PAL, albeit with time-consuming reverse engineering, is that I’m able to reproduce that function easily with a microcontroller. I’m not saying this would be the final state, but it seems an approachable step. The uC board would plug into a small adapter board to accommodate the pin differences.
I’ve used this design successfully on combinatorial PAL/GALs, which works fine. But, this design will unfortunately not work on registered GALs/PALs (those that have flip flops in them and the HDL uses those flip flops).
Hey Jim,
I think we’ve bumped into each other at least once at a CoCoFest…. I was there in November and May, which I think you couldn’t make.
These are TIBPAL16L8 devices, which are not registered. My weak understanding is that you can still make a RS latch or similar and have a couple bits of state in a pure combinatorial device. I do wonder, though, if that would be detectable via the pinout — ie would it require an output to be connected back as an input?
I initially created a microcontroller stimulator. I iterated through inputs, and saved the results of the output. With the plan to use a kmap solver to create equations later.
My understanding of what’s really an input and an output has changed as I mature my overall understanding. It yielded very sparse results.
I’ve almost reverse engineered the function of the BUSS PAL, but the DTACK02 PAL will definitely require more work….
Maybe I’ll double-check my adapter in case my miswire is throwing off results….
Thanks
[…] You can see my attempts here to build and use the adapter during my reverse engineering attempts wit… Spoiler: It didn’t work. […]