The current state of PAL dumping kind of sucks.
I aim to do something about that..
The current state of PAL dumping kind of sucks.
I aim to do something about that..
@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.
@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
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 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.
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?