The first way to do this is for me to read their fuse maps directly using my old Dataman device programmer. 

The PAL14L4 has no security fuse, so this would be straightforward.

However, most people are very reluctant to post essential and irreplaceable components to strangers on the web.

A way round this is to wire the 14L4 chips to an EPROM socket like so:

The 10L8 appears as a 1k x 8 bit ROM.
The 12L6 appears as a 4k x 6 bit ROM.
The 14L4 appears as a 16k x 4 bit ROM.
The 16L2 appears as a 64k x 2 bit ROM.
The 16L8 is trickier, because 6 pins can be either input or output. But that's a problem for another project.

Reading the device like a ROM, the addresses will go through every possible combination of inputs, and the outputs read. 

From this information, one can deduce the logic.

2025-09-17 15:30

The physical Speculator arrived in the post!

I made a spreadsheet of the connections of the PALs, RAM and host connector.

With this information, I read the PAL chip fuse maps, which I then converted to equations, and then edited the equations to have their proper pin names.

It looks like the RAM is permanently enabled, which I would expect to clash with other I/O devices.

Also, RA1 and RA0 seems to be fixed, and RA2 priority-encodes only 4 out of 8 possible keyboard columns.
That is all it can do, because it can only encode four OR-terms.

However, so long as the board actually works, I shan't bother working out why.

The GAL16V8 can have up to eight OR terms per pin, in non-tristate mode, so a full 8-bit priority encoder can be implemented.

There are six TTL chips, where the Memotech version only had two.

2025-12-02

Creating the GAL chips and comparing their behaviour with the PAL chips showed that my device reader had not read the fuses for pins 14 and 15 (see other log). Today I tested five known-blank PAL16L4CN chips, and they all read bank as non-blank. Again, the fuses for pins 14 and 15 were read as blown. So I have to conclude there is a fault with my reader, not the chips.