| Electronics > FPGA |
| Reading a 16L8 PAL / question on early SRAM card |
| << < (3/3) |
| AK6DN:
--- Quote from: Kleinstein on December 31, 2024, 09:32:22 am ---AFAIK there is no way to read a PAL. In most cases they are used for combinatorial logic (no flip flop). In this case one could measure the truth table and than synthesize the logic from there. So not reading the chip but mesure the function and regnerate the required logic. --- End quote --- Of course there is. Just about any professional programmer that can program a PAL via a .jed file can read the PAL contents back into a .jed file. I have an EEtools TopmaxII and I know it can read a PALs programming into a .jed file that I can then save, and use to verify other PALs against or program blank devices. I know the original DataIO 2900B could do the same, as well as some of the recent Xeltek programmers that support PALs. |
| PCB.Wiz:
--- Quote ---Of course there is. Just about any professional programmer that can program a PAL via a .jed file can read the PAL contents back into a .jed file. I have an EEtools TopmaxII and I know it can read a PALs programming into a .jed file that I can then save, and use to verify other PALs against or program blank devices. --- End quote --- Only Provided the security is not blown. |
| metertech58761:
I have a GQ-4X and a TL-866II programmer at home, and neither have definitions for the 16L8. I have access to an MPLab PM3 programmer, as well as a BPMicro unit (which is what it was likely programmed on), and the latter DOES have definitions for the 16L8. |
| AK6DN:
--- Quote from: PCB.Wiz on January 02, 2025, 08:27:55 am --- --- Quote ---Of course there is. Just about any professional programmer that can program a PAL via a .jed file can read the PAL contents back into a .jed file. I have an EEtools TopmaxII and I know it can read a PALs programming into a .jed file that I can then save, and use to verify other PALs against or program blank devices. --- End quote --- Only Provided the security is not blown. --- End quote --- Well yeah of course. If the security fuse is blown on a device, the internal programming will be unreadable. The only way to determine the functionality of a device with its security fuse blown is a brute force approach, stimulate all inputs, observe all outputs, write equations, and optimize. Of course this assumes no internal feedback or internal state, which can increase the reverse engineering complexity dramatically. But my point was that legacy PAL programmers provided the capability to both read and write/program the fuse arrays. So reading the device on a legacy programmer may produce the fuse programming if it is unsecured, or at worst an all blown and/or all unblown fusemap if it is secured. In my experience the TL866/T48/T56 (I have the latter two devices) are useful for programming modern EEPROMs and uControllers, or simple RAM or 74xx chip testing. But they do not support legacy devices like PALs and BIPOLAR PROMs. For those I have my trusty EEtools TopMaxII series device which supports all the old stuff, and most new stuff too. |
| Navigation |
| Message Index |
| Previous page |