Now that we have all the PAL logic dumped in a state where we can read it to figure out what's going on, we can proceed on figuring out the architecture.
However, there are a couple registered PALs that I don't have the logic for, and there are a few PALs I didn't bother getting the logic to, as it wasn't relevant to the mission at hand. However it might not be a bad idea getting it anyways in case the PROM inside a PAL ever bit-rots. Any cases of this happening? Please comment below. (I don't know).
July-August of 2019, I focused solely on the graphics card and its logic so I could further probe the card to figure it out. I will get to this soon, but instead of going in chronological order, lets go in order of architecture.
So after studying the logic and design of the CPU card circuit, we can make these conclusions:
the CPU card is also the bus master. (of course). However, any card on the bus can request access to the bus, and the CPU card will grant it, allowing other peripheral cards to gain access to the bus. Usually this is done for DMA reasons. The cool thing? if the CPU card grants bus access, the CPU can still access its own 2MB of RAM at $0, as well as the ROM, etc... and continue to execute code as long as it doesn't need the rest of the bus! kinda neat.
However, only the graphics card can be a bus-master in the system currently. All the other cards such as the I/O, and Data/Audio are slave-only devices that require communication through vectored interrupts.
We learned that this is a VMEBus-based system, Well... a variant of it. But the primary Address/Data bus is pinned the same as VME. However IRQ lines have been routed a different way as the decode logic is in the cards themselves instead of across the bus. so the IPL lines are not exposed across the bus. Just the IRQs themselves. They instead put a voltage on the 3 IPL pins, no longer making the system 100% VME Compliant. So as I mentioned earlier, don't go plugging in VME cards!
Now that was fun! (Actually, no. it took many hours)