PAL Brute Forcing
Page on analyzing PAL devices by supplying a large number of test vectors. This may be extendable to other devices like GALs, but this type of analysis typically works best on very simple devices.
- Industry standard fuse format
BP Microsystems .bin
- Presumably this is the JED fuses converted directly into a binary w/o metadata
- Maybe like the MAME .bin w/o the small header?
- Custom format with a very small amount of metadata
- Can be converted to .jed etc using tools included in MAME
- TODO: add link
- Output from techno-junk 27C020 adapter
- Output from pal866
- An EPROM like adapter to enable brute forcing using COTS programmers
- Fast since it uses standard algorithms
- Doesn't handle registers
- Reference post processing workflow
This approach does not work for the following devices: All registered PAL devices. (PAL16R4, PAL16R6, PAL16R8, etc.) All GAL devices configured to be registered. (GAL16V8, etc.) PEEL devices (18CV8, etc.) which have a different architecture than PALs/GALs. Non-PAL or GAL devices (82S153, PLS153, etc.) which have a different architecture and pinout than PALs/GALs.
- Eagle design files provided for EPROM adapter
- Windows binary provided to analyze EPROM into equations
- Hardware + software toolchain for copying PAL devices
- As a stand alone solution, board is much more complex than readpal
- More powerful than others?
- FOSS tl866 software to read out PAL16 family devices
- Registered PAL WIP
- Doesn't require any adapters
"Obviously, this method is limited to devices implementing combinational logic (PAL working in registered mode are out-of-scope for this proof-of-concept)."
"The current implementation uses an arduino mega to drive the device under test. The setup required to perform the IO probing on the example defined above can be described as follow:"
"For combinatorial stuff, I use my Unisite to apply all possible combinations of inputs via JEDEC test vectors and then record the output. I then do a bit of processing and use espresso to create equations for the table. For registered stuff, I usually capture traces from the device in-circuit with a logic analyzer and then use that as a basis to write test vectors"