The current state of PAL dumping kind of sucks.

I aim to do something about that..

Even if you don't care about PALs, this should be a neat utility to just stick any DIP chip in a T48 and toggle its inputs and observe its outputs.
@gloriouscow Could it support TL866-II+ as well, or only the newer T48?
@root42 im guessing it probably could, but I'd have to look into the differences.
@root42 maybe can support the dupico as well at some point. I was just inspired by https://github.com/donohoe00/cabbic and having some success talking to a t48 with that example with https://github.com/kevinmehall/nusb
@root42 I think abstracting hardware access over a PinDriver trait is a good idea anyway, then we can more easily expand to other devices.
@gloriouscow This would be largely appreciated ... I've decided on not getting particular pieces of hardware due to having more than 5 smaller PLDs.
Reverse engineering those always seemed extremely labour intensive.
@gloriouscow wonderful! I did something similar with the dpeeper (https://github.com/DuPAL-PAL-DUmper/dppeeper) but this is much more flexible and does not require custom hardware!
@hkz oh wow, that is nearly identical.

@gloriouscow it's an evolution of a previous tool of mine that was a bit more automated but also more limited in potential.
I have not ported everything over the new board and tooling, but this has served me well up to now to dump PROMs and other weird devices. And also to reverse a PAL for the Mac Plus. Ended up defining a TOML format so every user can build their own IC definition to help them analyze the device.

Should you see any interesting idea in there for your project, be my guest.

@hkz I'm even using TOML for pin definitions, but we went about it completely differently. I have an array of pins with attributes, you have attributes with arrays of pins. Funny.

@gloriouscow heh :) Well anyway, I'm happy someone else is tackling the problem, and using the T48 is a great approach: one instrument less on my desk and pretty easy to obtain and useful hardware too.

Beside, I now have less guilt in letting that thing rot :D

@hkz I am unsure if I can detect tri-state pins without an additional adapter, but at least if one is needed it will simply be a mostly passive backplane with a few resistor packs.
@gloriouscow yeah that can be an useful feature, especially for GALs or more complicated PLDs
@hkz I was using PALDump https://github.com/rpocc/PALDump but the code (and breadboard/pin layout) makes a lot of assumptions, like exactly six outputs. The Chameleon has tons of PAL variants with everything from 2 to 10 outputs so I was facing a complete rewrite of that in any case.
GitHub - rpocc/PALDump: Combinatorial Programmable Array Logic dumper for Arduino

Combinatorial Programmable Array Logic dumper for Arduino - rpocc/PALDump

GitHub
@gloriouscow yeah my first version of the dual made assumptions too (a bit more flexible than that, but still). And it bit me in the back rather soon. So planned for something a bit more flexible in the end. No power supply beside 5v though. Unless a specific interposer is used.

@hkz

I went ahead and made a GpioProvider abstraction to support different boards.

Do you have any assembled dupico boards you could send my way perhaps? I'll happily pay you whatever.

I'd like to add support for it.

@gloriouscow nope, ended up assembling just one rev.1. It wasn't a commercial endeavour.

I should still have the PCBs around.
You can choose: if you wish I can send a PCB to you directly, as soon as I find where I hid them, or... If you're not in a hurry, you can wait once I place my next mouser and I will assemble and ship one for you. It's a rather cheap card.

And don't worry about paying.

I might end up regretting calling this thing PALchemy if I end up making it a generic pin-poker.

I'm not going to risk any of my (currently) irreplaceable Chameleon PALs testing this thing, so I made a definition for a 74LS04.

@gloriouscow array of struct vs struct of arrays... age old discussion. :-D

@gloriouscow Last time I read a PAL, I uhhh... desoldered it from the circuit, attached it to an FPGA w/ level shifters, and read it over UART: https://github.com/cr1901/ATD_M117/blob/main/PALdump/bitstream.py#L153-L208

The code has bitrotted sadly^1, and I long tore down the circuit.

1. Although taking a peek, only the simulations look completely out-of-date.

@cr1901 I kind of meant "sucks" in the sense of it's kind of confusing and a bit obtuse, there's a zillion formats for the logic and it's not obvious how to go from dumping a PAL to making a replacement.

Not to disparage any other programmer, the tools that do exist do a good job at what they were made to do.

@gloriouscow Oh, no argument there that it sucks. I've talked with @david_rysk and @Lord_Nightmare a while ago about how to dump registered PALs. Which my code doesn't handle. IIRC, it can be done reasonably automated but I'd have to dig into my IRC log.

I won't touch PAL programming, which is... just a mess. Even finding the documentation sucks, and certainly hasn't gotten better now that search engines are shit. I found them on Google Groups mirror of Usenet and random Tripod/Angelfire sites.

@cr1901 @david_rysk @Lord_Nightmare

So I have some ideas on the registered PAL front, although I have no real idea about practicality, but the idea might be to attempt to visualize the registers based on an educated guess of their logic, and then get some confirmation on whether your guess is invalidated or passes input-fuzzing.

One thing I really wanted is something where you can give names or purposes to the pins.

Since I've traced out the Chameleon motherboard, I should be able to mark these pins with sensible names.

So I will have definitions for both the base PAL types, such as PAL16R4, bus also a PAL instance, such as "DCON" here - the instance definition will map readable names to pins and provide pin type overrides, so if you know an I/O pin is for sure an input or an output there's no need to spend minutes verifying that every time, and if you know a pin is disconnected, there's no reason to update it or read it.

@gloriouscow not in a million years would I have ever come up with the name PALchemy that’s genius

@mcjonestech

i like this magic cauldron as an icon although the dark cauldron doesn't read very well on dark mode background... I tried a white outline but it kind of looked naff. Maybe a purple potion bottle would look better?

@gloriouscow maybe? I think it depends on how stark the contrast is between dark mode and the white/gray of the bottle.