"Dumping" Protected GALs - Any Tricks?

[SuperSVGA]

If you feel like sharing the schematic once it's complete I wouldn't mind staring at it for a few minutes and making a wild guess what the registered one might do.

Yep, I'll upload it once I stop being stupid and getting turned around halfway though.

Here's what the current progress on the board itself looks like:

Along with the original scan:

There's a lot more going on in the inner layers than I anticipated, so it's going to take a bit to get it fully complete, but I should be able to at least get all the GAL connections mapped out.

you might want to consider using one of those "bitbang it with an arduino" methods to at least get it

Do you have a link to one of these? All I've been able to find so far is one that uses a custom PCB/shield, though I guess I could breadboard it if I was confident in the wiring.

 

[luRaichu]

Matthias Heinrichs / Galdurino · GitLab

GitLab.com

gitlab.com

 

[croissantking]

You can get around the security fuse on a lot of GAL16V8 and 20V8s by messing with the programming voltage.

You have to apply a voltage to the programming pin just at the right time before VCC to the chip gets applied and then read it like you normally would.
The problem here is that the timing seems to be important so you’ll spend a lot of time with trial and error. Another unknown factor is the voltage that you have to apply. This is not necessarily the actual programming voltage of the chip but rather a seemingly random value between 7V and 20V depending on the chip.
Make sure to not directly connect the external voltage source or you’ll instantly fry the GAL but instead use a 4.7k resistor in series.

I’ve been messing around with the GALs on a Micron Xceed SE/306-48 according to your notes but haven’t got any to reveal their contents yet. I’m using a T48. Unfortunately, my bench PSU only goes up to 15.5V so this could be a bit of a show stopper.
I just wanted to check:

- that the programming pin is indeed pin#1?
- how long before hitting read (on average) were you applying voltage to the programming pin? Are we talking a few seconds, or a fraction of a second?

 

[stepan]

Galdurino and co are nice when they work. But they're not always an option.

I have used https://github.com/cdhooper/brutus28 in the past. It's straight forward for combinatorial logic, but anything more complex is work to figure out.

I wrote a set of expect scripts to help with the reverse engineering of GALs through Brutus28 which are available here for anybody curious: https://github.com/reinauer/laoshi/tree/main/logic ... Basically once you have a theory of operation, you can write test scripts to prove out the theory on the original parts and then modify your PLD source code until it passes those tests

# Simulate a read from 0x1001. A14 should go to 1
puts "Setting A0 !A1 A12"
outputs [pins_to_hex A0 A12]
if { [inputs] == [pins_to_hex VCC A0 CLKOUT CLK A12 A14] } {
  puts "OK: CLKOUT+CLK is HIGH, A14 is HIGH"
} else {
  set debug 1
  inputs
  puts "Error: expected VCC A0 CLKOUT CLK A12 A14\n"
  exit 1
}

 

[Bolle]

- that the programming pin is indeed pin#1?

No. Pin 2 is the EDIT pin on 16V8 and 20V8. Also note that it will only work for actual GALs. Not for PALs and not for PALCEs.
Your GALs are likely dead now if any other pin than #2 has seen programming voltage.

- how long before hitting read (on average) were you applying voltage to the programming pin? Are we talking a few seconds, or a fraction of a second?

Something from as instantly as it gets when done by hand and a few seconds.
Sometimes it also helps to spam reads after removing the programming voltage because it seems some capacitance in the chip itself can hold enough power to successfully read that way.

I just checked and it seems I only got dumps of the GALs from the Xceed 3010-78 and not the 306-48. The dumps do match the documented code that’s flying around the net somewhere, so I‘d guess the same is true for the 306-48.

 

[croissantking]

Something from as instantly as it gets when done by hand and a few seconds.
Sometimes it also helps to spam reads after removing the programming voltage because it seems some capacitance in the chip itself can hold enough power to successfully read that way.

Are you contacting the pin momentarily, or keeping it held there during the read?

 

[Bolle]

For most chips it seems that you want to hold the programming voltage through the whole read operation.
Some chips however seem to only produce useful results when programming voltage is taken away again before the actual read operation is started.
The fun thing is, that there's no way to know how your exact chip will react, so it's possible you'll be sitting there trying for a very long time until eventually it's giving you a successful read.

A lot of chips will read just fine using the GALdurino but the software has some annoying quirks that won't let you save jedec files and it's limited to 16V8 and 20V8 while the actual method works on all other GAL types as well - I have successfully read 22V10, 20RA10, 18V10 and 26CV12.