After 5 experimental test runs with some educated guesswork I believe I have found it!
These are the 020 EPROM read back results, minimized with Logic Friday:
Code:
Name EPROM_READ_T5;
PartNo ;
Date ;
Revision ;
Designer ;
Company ;
Assembly ;
Location ;
Device virtual;
/* Dedicated input pins */
pin 1 = RAS; /* Input */
pin 2 = MEMW; /* Input */
pin 3 = IOR; /* Input */
pin 4 = AIOW; /* Input */
pin 5 = Q1; /* Input */
pin 6 = IO_CS_16; /* Input */
pin 7 = AEN_1; /* Input */
pin 8 = AEN_2; /* Input */
pin 9 = Q4; /* Input */
pin 11 = FSYS_16; /* Input */
/* Programmable output pins */
pin 12 = END_CYC; /* Combinatorial output */
pin 13 = RES_0WS; /* Input */
pin 14 = DMA_AEN; /* Combinatorial output */
pin 15 = XA0; /* Fixed low output w/ output enable */
pin 16 = XBHE; /* Combinatorial output w/ output enable */
pin 17 = GATE_245; /* Combinatorial output */
pin 18 = DIR_245; /* Combinatorial output */
pin 19 = DATA_CONV; /* Combinatorial output */
/* Output equations */
!DATA_CONV =
!IOR & Q1 & IO_CS_16 & AEN_1 & AEN_2 & !XA0 & !XBHE
# AIOW & Q1 & IO_CS_16 & AEN_1 & AEN_2 & !XA0 & !XBHE
# RAS & Q1 & AEN_1 & AEN_2 & !FSYS_16 & !XA0 & !XBHE;
!DIR_245 =
RAS & MEMW & !AEN_1
# !MEMW & AEN_1 & AEN_2 & !XBHE
# AIOW & AEN_1 & AEN_2 & !XBHE;
!GATE_245 =
!IOR & !AEN_1 & !AEN_2 & FSYS_16
# !IOR & !AEN_1 & FSYS_16 & XA0
# RAS & !AEN_1 & !AEN_2 & FSYS_16
# RAS & !AEN_1 & FSYS_16 & XA0
# !IOR & IO_CS_16 & AEN_1 & AEN_2 & XA0 & !XBHE
# AIOW & IO_CS_16 & AEN_1 & AEN_2 & XA0 & !XBHE
# RAS & AEN_1 & AEN_2 & !FSYS_16 & XA0 & !XBHE
# !MEMW & AEN_1 & AEN_2 & !FSYS_16 & XA0 & !XBHE;
XBHE = AEN_2 & !XA0;
XA0 = 'b'0;
DMA_AEN = AEN_1 & AEN_2;
END_CYC =
Q4
# RAS & !RES_0WS
# AIOW & !RES_0WS
# !IOR & Q1 & !IO_CS_16
# AIOW & Q1 & !IO_CS_16
# RAS & Q1 & FSYS_16;
/* Output enable equations */
!XBHE.oe = AEN_1 & AEN_2;
XA0.oe = !AEN_2;
/* End */
And here are the actual source equations which are used to program the GAL chip which read back as above:
Code:
Name IBM-5170-U87 ;
PartNo 00 ;
Date 26-01-2023 ;
Revision 06 ;
Designer Rodney ;
Company - ;
Assembly None ;
Location None ;
Device G16V8A;
/* *************** INPUT PINS *********************/
PIN 15=XA0;
PIN 16=XBHE;
PIN 1=RAS;
PIN 2=MEMW;
PIN 3=IOR;
PIN 4=AIOW;
PIN 5=Q1;
PIN 6=IO_CS_16;
PIN 7=AEN_1;
PIN 8=AEN_2;
PIN 9=Q4;
PIN 11=FSYS_16;
PIN 13=RES_0WS;
/* *************** OUTPUT PINS *********************/
PIN 12=END_CYC;
PIN 14=DMA_AEN;
PIN 17=GATE_245;
PIN 18=DIR_245;
PIN 19=DATA_CONV;
!XBHE.oe = DMA_AEN;
XA0.oe = !AEN_2;
RES_0WS.oe = 'b'0;
XBHE = AEN_2 & !XA0;
XA0 = 'b'0;
DMA_AEN = AEN_1 & AEN_2;
!DATA_CONV =
AEN_1 & AEN_2 & !FSYS_16 & Q1 & RAS & !XA0 & !XBHE
# AEN_1 & AEN_2 & !IOR & IO_CS_16 & Q1 & !XA0 & !XBHE
# AEN_1 & AEN_2 & AIOW & IO_CS_16 & Q1 & !XA0 & !XBHE;
!DIR_245 =
!AEN_1 & MEMW & RAS
# AEN_1 & AEN_2 & !MEMW & !XBHE
# AEN_1 & AEN_2 & AIOW & !XBHE;
!END_CYC =
FSYS_16 & Q1 & RAS
# !IOR & !IO_CS_16 & Q1
# AIOW & !IO_CS_16 & Q1
# RAS & !RES_0WS
# AIOW & !RES_0WS
# Q4;
!GATE_245 =
RAS & !AEN_1 & FSYS_16 & !XBHE
# !IOR & !AEN_1 & FSYS_16 & !XBHE
# !IOR & IO_CS_16 & AEN_1 & AEN_2 & XA0 & !XBHE
# AIOW & IO_CS_16 & AEN_1 & AEN_2 & XA0 & !XBHE
# RAS & AEN_1 & AEN_2 & !FSYS_16 & XA0 & !XBHE
# !MEMW & AEN_1 & AEN_2 & !FSYS_16 & XA0 & !XBHE;
When looking at the source equation for !GATE_245, we can reason back how the first two terms get distorted by the EPROM read back.
Code:
!GATE_245 =
RAS & !AEN_1 & FSYS_16 & !XBHE
# !IOR & !AEN_1 & FSYS_16 & !XBHE
# !IOR & IO_CS_16 & AEN_1 & AEN_2 & XA0 & !XBHE
# AIOW & IO_CS_16 & AEN_1 & AEN_2 & XA0 & !XBHE
# RAS & AEN_1 & AEN_2 & !FSYS_16 & XA0 & !XBHE
# !MEMW & AEN_1 & AEN_2 & !FSYS_16 & XA0 & !XBHE;
When DMA occurs, DMA_AEN goes low.
This in turn enables the oe function of XBHE.
XBHE is then generated from:
XBHE = AEN_2 & !XA0;
This leads to the creation of two extra product terms in the EPROM read back result:
Code:
!GATE_245 =
!IOR & !AEN_1 & !AEN_2 & FSYS_16
# !IOR & !AEN_1 & FSYS_16 & XA0
# RAS & !AEN_1 & !AEN_2 & FSYS_16
# RAS & !AEN_1 & FSYS_16 & XA0
# !IOR & IO_CS_16 & AEN_1 & AEN_2 & XA0 & !XBHE
# AIOW & IO_CS_16 & AEN_1 & AEN_2 & XA0 & !XBHE
# RAS & AEN_1 & AEN_2 & !FSYS_16 & XA0 & !XBHE
# !MEMW & AEN_1 & AEN_2 & !FSYS_16 & XA0 & !XBHE;
When !AEN_2 is true, this enables output XA0 which negates XA0 from being seen as part of the product term, so XA0 disappears in those EPROM results which forms a separate product term in the equation results. This occurs twice, once in the "!IOR" term and once in the "RAS" term.
When AEN_2 is true, this takes XA0 again from the read input, thus showing up in the equation, because it was analysed as being a part of that product term.
Why do we see XA0 "showing up" and not !XBHE as per the original equation?
Because !XBHE is generated from !(AEN_2 & !XA0).
AEN_2 is true, so it equals 1, and we are left with !XBHE = !(!XA0) = XA0 being substituted in the minimized EPROM read result.
Somehow, I believe that !XBHE gets minimized away from those product terms, I am still somewhat unclear on the automated process of how this happens since many minimized lines would be involved, however I can at least observe the resulting equation and attempt to form a theoretical explanation for this.
This is my theory which is also indicated by the identical EPROM read result as U87.
So the equations at least produce the exact matching result to create the additional result terms.
I don't exclude that there are other hidden things, though I am not seeing those at first glance.
The additional effects occur when DMA happens which is only happening in the first two product terms of the "original equation" for !GATE_245.
The last 4 of the 6 terms are non-DMA situations involving the CPU.
There is some DMA happening in DIR_245 but the equation do not involve the inputs XA0 and/or XBHE since they only detect the direction of the conversion transceiver.
Since we have analysed what happens to the related DMA lines in GATE_245, this would suggest that possibly no more "surprises" would be hiding inside U87.
I attached revision 6 of the GAL equations for U87, as well as the 27C020 read back bin file so you can test with this Johann.
I should note that both revision 5 and revision 6 function perfectly, but as you mentioned, it is also nice to actually observe the identical logic in the read back result itself.
In fact, during my tests I also believed that !XBHE is actually not needed at all in the first two terms of !GATE_245, which was proven in a perfectly functioning 5170, however for correctness let's keep to the "matching" version 6, which is also my preference and why I spent the time on it today after all.
I was entertaining a final thought while doing this work. Now we may have the fully original equations as far as known to us, then how could one arrive at that conclusion in software?
That seems to be incredibly complicated because combinations of output logic apply differently to the measurements by EPROM reads. So how to detect for this in software?
Quite possibly only a human person could attempt to see patterns and use logical reasoning to predict the original equations which were distorted.
How would it be possible to construct and predict the whole "system" as it were, from the EPROM readings alone?
To me this looks like an extremely difficult problem.