• Please review our updated Terms and Rules here

GAL compilers?

I'm hoping to use Palwiz to work on some PALs on the Lomas S100 boards I've borrowed (mentioned in other threads in the S100 forum). Some of the boards have 20L10 devices and Lomas secured the PALs, so a friend of mine brute-forced them.

So, I decided to build a brute-force reader for myself and I'd like to run the output through Palwiz. Can I use the 22V10 in simple mode or is there an easy way to expand the device list to include the original 20L10? For replacements for any 16L8's on these boards, I've substituted the 16V8 which works just fine.

Thanks!
Rich
 
Its output is specifically targeted to one of the few GAL chips that are available. Any other chip could have the matrix be completely different.

If you happen to have actual blank 22L10 chips and a programmer that works with them, that's impressive because they've been obsolete for so long. You could find the data sheet for that chip and maybe create a new table for it, but that's all on you. I recall that I cleaned up the code enough in the most recent version that at least it's not too messy to add a new one.

But if you're going to use an actual GAL 22V10 chip, then you need to select one of the 22V10 configurations. Read the 22V10 data sheet for what the modes are. Basically (if I recall correctly) the output stages can be set up in one of two or three different ways depending on whether you want to use the registers or not, and it's a whole-chip setting. They had to do this because there were so absurdly many original PAL chips.

I'm going to guess that you started with a 20L10 and that it has no registers, and you want to use a 22V10. So that would probably be 22V10 simple mode.
 
If you can suss out the logic equations for the 22L10's I'd be 95+% sure that they'll compile fine for 22V10 simple mode. Sort of the point of GALs' multiple modes was to make them compatible with as many flavors of the old PALs as possible.
 
One of the Gotcha's with the 22v10 is that there are different numbers of terms available on different output pins. The pins closer to the center have twice as many terms possible as the pins closest to the ends of the chip. As long as you don't exceed the number of terms, you're fine.

Also, you may be able to put any port into "registered" mode and use the storage in the 22v10 but you can't move the clock pin around - once you set for this mode, Pin 1 becomes the clock, and it's only rising edge. However the Output Enable can rely on other terms and I think IIRC that pin 13 can be reassigned as a general input, though convention is to use it as an output enable.

Also, you can't switch between input and registered output on output pins on the 22v10. The feedback pins come from the register bit, regardless of whether the output is enabled or not.

As was noted, just check the datasheet.

As a curious element - do you see the brute-force output file as a series of terms (eg, .PAL or .PLD file) or as a JEDEC file?
 
@Bruce Tomlin : Thanks for the additional detail. The original chip (from an S100 SCSI board) is a 20L10 and the replacement would be a 22V10 in simple mode. I have several programmers but they're too new to program an original 20L10 if I could even find them. The programmer I use is for programming PALs is the Wellon VP-290. Generally works fine. Otherwise I use the TL866 programmer.

@cj7hawk : Also, thanks. The "brute force read" basically tickles the inputs in order and then records the bit pattern to a file, based on a program from Chuck Guzis. For my first tests, I assumed that all of the I/O pins were truly outputs (which is indeed the case -- the test chip is an address/function decoder for a 68030 board). So, no "nudge resistor" testing is needed. This file is read and decoded to a series of terms. That file is then compiled into a JED file.

I don't know if anything works just yet, but I have a 22V10 programmed with a known set of equations. I read it with my "cracker" and now I need to decode the terms.

Rich
 
RichCini said:
I don't know if anything works just yet, but I have a 22V10 programmed with a known set of equations. I read it with my "cracker" and now I need to decode the terms.

Rich
Click to expand...

As in manually decode the terms? Back to a PLD file?

It's not that hard if you can read the JED and you use the offsets in the datasheet.

It's just an AND/OR combination. it gets easier if you label the input pins according to their actual function and display a full row of terms per line when decoding the JED. Just pay attention to which terms are complimented :)

If you do this regularly, you could write a simple decompiler for the JED file.

David
 
cj7hawk said:
if you can read the JED
Click to expand...
Not likely if all you have a is an old chip. The methods of reading those chips are arcane and were presumably NDA, and I doubt any programmers supported read-only access, even if the protect fuse wasn't blown. You have to do it the hard way, by tickling the inputs and watching the outputs, then apply some Karnaugh map magic. Good luck with registered chips if they use feedback terms.
 
Bruce Tomlin said:
Not likely if all you have a is an old chip. The methods of reading those chips are arcane and were presumably NDA, and I doubt any programmers supported read-only access, even if the protect fuse wasn't blown. You have to do it the hard way, by tickling the inputs and watching the outputs, then apply some Karnaugh map magic. Good luck with registered chips if they use feedback terms.
Click to expand...

He's already extracted the JED from the chip by combinatorial probing, and his software generated the JED file to his satisfaction.

I'm just referring to being familiar enough with the JED to "Read" the file as a human, and understand which fuses it's blowing, so he can manually convert this to an AND/OR format PAL document. Then he can make changes to it and recompile it.

Like disassembly, but manually... By hand. But it's a bit difficult if you're not familiar with how the JED file relates to the fuses.
 
Bruce Tomlin said:
I doubt any programmers supported read-only access, even if the protect fuse wasn't blown.
Click to expand...
If they could write them you would need to read them to verify (obv before the protection fuse is blown).
You have to be careful that you be sure to select the correct manufacturer and part number.
My Data I/O, EEtools, and BP Micro programmers can all generate JED files.
Support for 3.3v parts is a general problem for some old programmers but not an issue here.
 
cj7hawk said:
He's already extracted the JED from the chip by combinatorial probing, and his software generated the JED file to his satisfaction.

I'm just referring to being familiar enough with the JED to "Read" the file as a human, and understand which fuses it's blowing, so he can manually convert this to an AND/OR format PAL document. Then he can make changes to it and recompile it.

Like disassembly, but manually... By hand. But it's a bit difficult if you're not familiar with how the JED file relates to the fuses.
Click to expand...

A fuse map wouldn't really be extracted from a PAL by combinatorial probing. A truth table would be generated, or maybe a FSM for a PAL with registered outputs. Then from that information, logic equations could be synthesized, and mapped into an equivalent, but non-unique fuse map.

If a fuse map was actually extracted from a non-protected PAL using the manufacturer verification algorithm, that can be translated back into equivalent logic equations. The OPALjr 2.01 package from National Semiconductor contains the JED2EQN.EXE utility which supports the following list of devices, which does include the 20L10:

Code: 
EC16C4   
EC16P4   
EC16P8
EC16PE8
EC16RD8
EC16RM4
P10H8   
P10L8   
P10P8   
P12H10   
P12H6   
P12L10   
P12L6   
P12P10   
P12P6
P14H4   
P14H8   
P14L4   
P14L8   
P14P4   
P14P8   
P16C1   
P16H2
P16H6   
P16H8   
P16L2   
P16L6   
P16L8   
P16P2   
P16P6   
P16P8
P16R4
P16R6
P16R8
P16RA8
P16RP4
P16RP6
P16RP8
P18L4
P18H4
P18P4
P20C1
P20H10
P20H2
P20H8
P20L10
P20L2   
P20L8   
P20P10   
P20P2   
P20P8   
P20R4   
P20R6
P20R8   
P20RA10 
P20RP4   
P20RP6   
P20RP8   
P20X10
P20X4
P20X8
P22V10
G16V8QS
G16V8A
G16V8
G20RA10
G20V8QSV
G20V8QS
G20V8AV
G20V8A
G20V8V
G20V8
G22CV10V
G22CV10
G22V10V
G22V10
G6001V
G6001
MAPL128
MAPL144
MAPL244
MAPL268
 
I used to use Opal back in the day, but found it less supported on modern systems, and ended up using GALASM now under WSL on Windows.

I haven't found any good PAL compiler software that works under Windows11. :(

Combinatorial probing doesn't generate an original source, but as noted, it can sometimes put one together depending on the complexity of the original program as often the PALs didn't have particularly complex outputs, and as noted the OP was satisfied with the outcome.

In the Video Game industry though it was a different case - they used GALs and PALs to prevent copying and they tried to make it as difficult as possible to recreate them. Unfortunately, they were also what was often broken or failed when the video game boards died. Usually we had to go back to the manufacturer to get the chips.
 
Lomas protected the chips on all of its boards, so they aren't readable directly. I have encountered some unprotected chips in my work and those I can usually read with a programmer. I've even used an earlier version of the DuPAL v2 board to read 16L8 devices. The DuPAL v3 board is almost all SMDs and I haven't built it yet.

So by tickling the pins directly I'm getting what I’ll call “raw” data. From that, I need to get to the equations which I then can recompile using WinCUPL or any of the equivalents (grossly oversimplifying the manual effort in making sure the equations make sense). I guess I can run my file through JED2EQN and see what comes out.

Rich
 
Last edited:
RichCini said:
Lomas protected the chips on all of its boards, so they aren't readable directly. I have encountered some unprotected chips in my work and those I can usually read with a programmer. I've even used an earlier version of the DuPAL v2 board to read 16L8 devices. The DuPAL v3 board is almost all SMDs and I haven't built it yet.

So by tickling the pins directly I'm getting what I’ll call “raw” data. From that, I need to get to the equations which I then can recompile using WinCUPL or any of the equivalents (grossly oversimplifying the manual effort in making sure the equations make sense). I guess I can run my file through JED2EQN and see what comes out.

Rich
Click to expand...

Depending on the number of active pins, you could possibly even use karnaugh maps to solve the minimal and/or logic equation to produce the output. I think there are even online solvers to save you some effort.
 
You must log in or register to reply here.
Back
Top