Once all of the dumps of all the PALs are obtained, thats when things get interesting. We have to turn those dumps into logic diagrams. 

At this point, I began searching around on the internet to see if there were any projects that could decode the "dumps" back into the logic that I needed to help demystify the architecture of the system. Mainly, the memory map. 

I decided to go with this project here: 

https://github.com/psurply/ReGAL

In order to get the logic out of the dump, I have to convert it into a format that this program/script can understand. That's where I had a friend of mine make a utility to do this in C# as I was busy with other things and he wanted to help contribute. 

There were a few bugs that needed worked out, But.... the tool work pretty well. you could specify the file, number of inputs, and then number of outputs.  However, the tool still has a few bugs where it doesn't put a comma where its needed, and it orders the signal names wrong. But that's not a big deal, I just have to remember that I have to swap those around when it generates the CSV file. 

Eventually, you end up with something like this: 

This represents the CSV file that the ReGAL python scripts require to be able to generate the verilog output. 

But, as you can see, we still have a layer of obfuscation that we need to work through. And that is the signal names. only thing it knows is i0-ix, and Q0, through Qx. 

What we have to do at this point is basically rename the signals in the csv file to ones that actually make sense. And the only way to do this is by looking at the schematic, and attempt to make educated guesses based on the circuit design, and how the PAL is used. Takes pretty good critical thinking skills here. 

Otherwise if you don't perform this step, you end up with this after you run the script:

Not very helpful, unless you wanna do this the hard way, of course. :-)

So, back to the schematic to see what we can decipher. There are plenty of things here we can take out of the equation that are known constants. For example, the CPU itself: 

We know what all those signals are on the 68K CPU. so we can define all those net values. 

For the sake of this discussion, Lets pick U48 which is an AMPAL16L8. Lets see if any of these signals match up into what is connected into U48:

Here we go. the majority of the inputs are connected into the CPU Bus. So we can go ahead and name those nets in the CSV file going into ReGAL. we can also see the R/W line connected, as well as the Address Strobe and some address lines. So this chip does address decoding. We can safely make this assumption. 

Next thing is to look at what other chips are hooked into that PAL, especially on the outputs:

Ah! we see that the ROMs are connected into this IC. So we know for certain that this is an address decoding PAL, which will be critical to figure out for deciphering the architecture. 

Wash... Rinse... Repeat. Given known facts that its VMEBus, and where else traces are connected, you can figure it out. Eventually, I end up with this: 

Perfect! One chip down. So, we can go ahead and rename our signals in the CSV file for processing. 

That's better! At least this will make the logic much easier to understand. Now, it is time to run it through the ReGAL script. 

Bingo! Now, isn't that easier to read and figure out? I think so. Now, it is just a matter of going through each and every PAL and do these steps. 

Note: There will be signal names that you just don't know what they are doing. And I still have that. But it is what it is. We can make educated best guesses here and still get what we need. 

Eventually it starts to look more complete: (prepare to spend many more hours, as I did)