Project to create an ATX 80286 mainboard based on the IBM 5170

[rodney]

Hi Johann,

Very impressive to see your progress!

Certainly, I have ran your equations through Logic Friday to reduce them.
You can find the results in my attachment. Some of your results are already the same as PA.EXE.

I am seeing a difference with END_CYC and GATE_245 where PA.EXE has longer equations.

The difference for END_CYC for example is with FSYS_16 being included with PA.EXE as an input for the equation and not with your python script.

I compared your equations with PA.EXE in the text file, included in the attachment.
I also included the equation file for WinCupl I used, and two comparing readouts where your equations are compared with U87 for DATA_CONV and GATE_245.

I compiled a GAL and programmed one, I have tested it in the 5170 however it's not starting and no beeps/sounds.

I compared your resulting GAL with U87, and for GATE_245 it's already quite similar to U87.
I also compared DATA_CONV which is 100% identical with yours compared to U87.

In my next post I will share my new files due to the new read adapter. You can test them also if you like.

 

[rodney]

I have built the new EPROM adapter according to the schematic I posted.

The BIN file was converted to equations by PA.EXE with the following command:

PA.EXE ADAPTED_EPROM_27C020.BIN -signal RAS,MEMW,IOR,AIOW,Q1,IO_CS_16,AEN_1,AEN_2,Q4,FSYS_16,RES_0WS,XA0,XBHE,END_CYC,DMA_AEN,GATE_245,DIR_245,DATA_CONV -polarity 0x00 >ADAPTED_EPROM_OUTPUT_001.TXT

After minimizing/factoring the equations resulting from above PA.EXE command, I noticed a few extra logic terms for /GATE_245.
So apparently this EPROM adapter is reading more information out of U87.

I tried a compare using a pull up on GATE_245 and using a pull down on GATE_245 and got different results.
WIth the pull down on GATE_245 the programmed GAL does compare 100% with U87.
With the pull up I get a few 02 readings at 1A00 so this time the GAL is outputting 0 while U87 is outputting a 1 on /GATE_245 for those reads at 1A00.

So apparently there is something different happening in U87 on output GATE_245 since this time using a pull-up or a pull-down is showing different output results for certain input combinations on GATE_245 starting at 1A00. Possibly there is some OE function happening which needs more testing.

I still had to use the DMA_AEN pin to be able to compile and program all the equation terms for /GATE_245 which are now even more than before.
I tried my best to reduce the equations by substituting parts from the other inputs as much as I could however I was not able to reduce the whole set of equations enough to fit the GAL chip.

I could try to test the resulting GAL with the 5170, but I will need to wire in an AND gate for DMA_AEN to create that pin for the 5170.

Somehow I doubt that this resulting GAL is going to work since I still have no explanation for what is happening with /GATE_245, and I still believe the equation is too complex since it won't fit in the GAL, but I will wire something up and do the test anyway just to see if there is anything happening with the 5170.

Here are the resulting equations that I currently have for the test GAL:

ALL EQUATIONS COMPARED:

MINIMIZED VERSIONS:

Minimized:
!DATA_CONV =       AEN_1 AEN_2 XA0' XBHE' Q1 IO_CS_16 IOR'   
        + AEN_1 AEN_2 XA0' XBHE' Q1 IO_CS_16 AIOW   
        + AEN_1 AEN_2 XA0' XBHE' Q1 FSYS_16' RAS;

Minimized:
!DIR_245 =       AEN_1' RAS MEMW
        + AEN_1 AEN_2 XBHE' MEMW' 
        + AEN_1 AEN_2 XBHE' AIOW;

Minimized:
!GATE_245 =       AEN_1' AEN_2'     FSYS_16 RAS   
        + AEN_1' AEN_2'     FSYS_16 IOR'
        + AEN_1'         FSYS_16 XA0 RAS 
        + AEN_1'         FSYS_16 XA0 IOR' 
        + AEN_1'         FSYS_16 XBHE' RAS
        + AEN_1'         FSYS_16 XBHE' IOR'
        + AEN_1 AEN_2 XA0 XBHE' IO_CS_16 IOR'   
        + AEN_1 AEN_2 XA0 XBHE' IO_CS_16 AIOW   
        + AEN_1 AEN_2 XA0 XBHE' FSYS_16' RAS   
        + AEN_1 AEN_2 XA0 XBHE' FSYS_16' MEMW';


Minimized:
!END_CYC =       Q4 
        + RAS RES_0WS'
        + AIOW RES_0WS'
        + IOR' Q1 IO_CS_16' 
        + AIOW Q1 IO_CS_16' 
        + RAS  Q1 FSYS_16 ;

I tried to reduce the equation for /GATE_245 by taking out various terms and trying to create those terms in other output pins:

Name     IBM-5170-U87 ;
PartNo   00 ;
Date     13-01-2023 ;
Revision 03 ;
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=NUMBER14;
PIN 17=GATE_245;
PIN 18=DIR_245;
PIN 19=DATA_CONV;

XA0 = XA0;
XBHE = XBHE;

DMA_AEN = AEN_1 & AEN_2;

DATA001 = DMA_AEN & !XA0 & !XBHE & Q1;
DATA002 = IO_CS_16 & !IOR;
DATA003 = !FSYS_16 & RAS;

!DATA_CONV = DATA001 & DATA002  # DATA001 & IO_CS_16 & AIOW   # DATA001 & DATA003;

DIR001 = DMA_AEN & !XBHE & !MEMW;
DIR002 = DMA_AEN & !XBHE & AIOW;
DIR003 = DMA_AEN & !XBHE & XA0;
DIR004 = RAS & FSYS_16;

!DIR_245 =       !AEN_1 & RAS & MEMW # DIR001  # DIR002;

GATE001 = FSYS_16 & !IOR;
GATE002 = !AEN_1 & !AEN_2;
GATE003 = !AEN_1 & XA0;
GATE004 = !AEN_1 & !XBHE;

NUMBER14 =  GATE002 & DIR004  # GATE002 & GATE001 # DIR004 & GATE003  # GATE001 & GATE003  # DIR004 & GATE004;

!GATE_245 = NUMBER14 # GATE001 & GATE004  # DIR003 & DATA002  # DIR003 & DATA003  # DIR002 & XA0 & IO_CS_16  # XA0 & DIR001 & !FSYS_16;

END001 = !IOR & Q1 & !IO_CS_16;
END002 = AIOW & Q1 & !IO_CS_16;

!END_CYC = !RES_0WS & (AIOW # RAS) # Q1 & DIR004 # END002 # END001 # Q4;

However this source file didn't compile without using the DMA_AEN pin to create another set of terms for /GATE_245, which does compile now.
The compare read only shows identical results when using a pull down on /GATE_245 at U87.
So clearly something is going on with U87 causing a difference to happen in the reads only for a select few input combinations starting at 1A00 only when using a pull-up on pin 17 of U87.

Both compare reads are included in the attachment.

Johann, my thanks for your efforts on the new python scripts, it's great to see how much progress you have made!

 

[rodney]

So, being not able to help with the electronic details, I'm still following the path "what, if PA.EXE has a bug?".

Hi Johann,

Your work really has the potential to help this problem considerably and could possibly become a key influence to achieve the solution to finally be able to reproduce a 5170 "from scratch" which is what we are trying to accomplish.

So if you can finally work out the last problems to be able to process the complete input terms, that is really valuable work for the 5170 recreation.
Since IBM has done some irregular things in U87 which I am certain were done out of pure necessity to be able to achieve a 5170 design that will even fit on a mainboard PCB, I hope we can ultimately recover the original equations by analyzing the information.

While looking at the compare results of U87 and the test GAL each time, I am encountering a problem in this work which is similar to the problem of processing the 27C020 BIN files into AND/OR lists of equations.
So in this matter it could be really helpful and possibly provide breakthrough information if I could employ some software assistance by a certain python analysis "toolbox".

If you have time and would be interested in looking into this, could you perhaps write a python script to process some information?
What would really help the process is as follows:

When I read the EPROM mode results, I will get the information in hexadecimal address positions which then refer to the output data.
I am already able to visually spot certain points of interest because I am doing a bit-wise compare which only leads to a few possible hex data values.
For example, only "0" and "2" in case of GATE_245.

So what I am going to do is to assemble lists of the hex addresses which are producing differences in the PAL output.
I will assemble lists with hex address values of:
- the first compare read analysis where U87 was producing 0 outputs while the test GAL was producing 1 outputs.
- my second analysis where a pull up resistor on /GATE_245 is revealing a floating or at least transitioning condition of /GATE_245 due to the fact of a resistor to VCC being present

So the input information will be
- a list of the input names with comma separation, ordered from LSB to MSB. (ordered from A0 to A12 for example), where the number of inputs is defined by how many names are provided.
- a text list of hexadecimal addresses which correspond with the binary values of those inputs.
This text based input file would list the hexadecimal positions where a certain occurrence presents itself in the analysis.
I attached a table of the inputs I am using now.
So the command syntax for providing the input names in this case would be something like:

-signal RAS,MEMW,IOR,AIOW,Q1,IO_CS_16,AEN_1,AEN_2,Q4,FSYS_16,RES_0WS,XA0,XBHE

So I need a conversion into the same
output = "A & B & !C" + !A & !B & C etc. equations in a similar fashion as you already did in your PAL analysis python script.

It would really help to be able to provide the input names and the address list of important positions so that the data can be converted into a list of equations which reflect the positions of interest.

If a script could output the resulting list of equations according to the binary value of each provided address in the same syntax as your python script you already made, that would be really useful and could save
me hours of work assembling all these positions by hand and converting them into "the input is true" or "the input is false" for each input bit.

If you have time, I would appreciate it if this were possible. It could possibly lead to big steps forward in the whole process.

Today I will wire up something to be able to test the complete GAL on the 5170 mainboard while supplying DMA_AEN using a separate AND gate.
I will post the results as soon as I know more.

This process is turning out to be really complex, I hope we can figure it out and get to the breakthrough moment where the 5170 will power up and actually provide a POST.

We will have uncovered the final key to the historic IBM design which resulted in the whole AT line of PC development since.
What IBM did was really so important and amazing, to provide true backwards compatibility with all 8 bit devices.
From the PAL we can see that detecting all these conditions was quite complex and must have taken some considerable development and testing time.

It's really a pity that we can't know some insider stories and information from this historic work floor back then!

 

[rodney]

Another really useful feature would be to use a "+" sign instead of the "#" sign in the list of equations.

This would enable the equations to be directly copied into Logic Friday without needing to manually replace all the # signs in notepad each time.
Logic Friday doesn't accept any "#" characters for OR functions.

But that's just a casual side note in case this would be easy to supply "+" characters instead of "#".

 

[rodney]

For reference, I have done more testing with WinCupl.
Factoring and substituting doesn't appear to affect WinCupl output.

When working with WinCupl, what it is doing with your supplied source file can best be observed in the .DOC output file.
Here, you can see that it doesn't matter much if you enter the equations in factored form or otherwise.
WinCupl just follows its routines to generate the source as used to create the fuse map.
Which you can see happening in the .DOC output file.

When trying equations, the compile options may sometimes help in order to be able to get to a successful compilation and jedec file.

So for clarity I am posting the equations here that I will test today, in the same sequence as is re-arranged by WinCupl.
This also reflects the actual AND/OR notation which results in the fuse map the closest.

Name     IBM-5170-U87 ;
PartNo   00 ;
Date     13-01-2023 ;
Revision 03 ;
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=NUMBER14;
PIN 17=GATE_245;
PIN 18=DIR_245;
PIN 19=DATA_CONV;

XA0 = XA0;
XBHE = XBHE;
RES_0WS = RES_0WS;

DMA_AEN = AEN_1 & AEN_2;

!END_CYC =
    FSYS_16 & Q1 & RAS
  # !IOR & !IO_CS_16 & Q1
  # AIOW & !IO_CS_16 & Q1
  # RAS & !RES_0WS
  # AIOW & !RES_0WS
  # Q4;

NUMBER14 =
    AEN_1 & AEN_2 & !FSYS_16 & RAS & XA0 & !XBHE
  # AEN_1 & AEN_2 & !FSYS_16 & !MEMW & XA0 & !XBHE
  # AEN_1 & AEN_2 & !IOR & IO_CS_16 & XA0 & !XBHE
  # AEN_1 & AEN_2 & AIOW & IO_CS_16 & XA0 & !XBHE;

!GATE_245 =
    !AEN_1 & FSYS_16 & RAS & !XBHE
  # !AEN_1 & FSYS_16 & !IOR & !XBHE
  # !AEN_1 & FSYS_16 & RAS & XA0
  # !AEN_1 & FSYS_16 & !IOR & XA0
  # !AEN_1 & !AEN_2 & FSYS_16 & RAS
  # !AEN_1 & !AEN_2 & FSYS_16 & !IOR
  # NUMBER14;

!DIR_245 =
    !AEN_1 & MEMW & RAS
  # AEN_1 & AEN_2 & !MEMW & !XBHE
  # AEN_1 & AEN_2 & AIOW & !XBHE;

!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;

 

[jonny64]

I cannot promise anything as I'm quite busy in my day job, but I will certainly try - being able to build my own 286 would be so awesome!

Please provide me some input data and maybe an example output. Reading the textual description of the desired algorithm is often really hard to understand.

 

[jonny64]

So, I figured out why my equations differ from PA.EXE: It was a bug in my Python script (computation of mask_left was missing the bit shift). I'm attaching the new script (so that nobody works with a known broken software) and the new equations (with '+' instead of '#', as requested). From first sight the equations now look identical to the ones from PA.EXE.

Now waiting for new input to create a new script, Rodney.

 

[rodney]

I have decided that I am going to expand on the idea of an in-circuit test method on my 5170 mainboard.

What I am going to do is to build a test PCB which contains two sockets for a GAL chip.
The first GAL chip will supply all the known outputs which appeared to verify correctly in the compare adapter reads:
!DMA_AEN
!END_CYC
DIR_245
DATA_CONV

The second GAL chip will only supply the output GATE_245.

This test adapter PCB can do two things in one go, to test the equations which we already obtained and provide a GAL test socket for only testing GATE_245.

The test PCB can be verified with U87 in the socket of the GATE_245 test GAL.

This test, if it proves to be successful with U87, could provide us with several certainties which allow us to be able to concentrate on GATE_245 exclusively by knowing for sure that this is the only remaining unknown logic.

 

[rodney]

I cannot promise anything as I'm quite busy in my day job, but I will certainly try

Hi Johann, I totally understand, what we do here is in our spare time, which is limited to begin with.
Frankly, I am rather disappointed by all the complications with this PAL, but the reward of a working 286 concept is too alluring to let me quit this troublesome project, same here.

To describe it in more detail, say I provide the following command: (just hypothetically it can be different if more practical to program)

commandname -signal RAS,MEMW,IOR,AIOW,Q1,IO_CS_16,AEN_1,AEN_2,Q4,FSYS_16,RES_0WS,XA0,XBHE textfile.txt output.txt

The contents of textfile.txt is as follows, whichever length applies in the case:

1A00
1A01
1A02
1A03
1A05
1A07
1A08
1A09
1A0A
1A0B
1A0D
1A0F

The program takes the number of inputs and applies it to each entry in the file textfile.txt and rewrites it into output.txt as follows
1A00 ->(13 bits)-> 1 1010 0000 0000 -> write as follows: RAS & MEMW & !IOR & AIOW & !Q1 & !IO_CS_16 & !AEN_1 & !AEN_2 & !Q4 & !FSYS16 & !RES_0WS & !XA0 & !XBHE
1A01 ->(13 bits)-> 1 1010 0000 0001 -> write as follows: + RAS & MEMW & !IOR & AIOW & !Q1 & !IO_CS_16 & !AEN_1 & !AEN_2 & !Q4 & !FSYS16 & !RES_0WS & !XA0 & XBHE
where the ! in front of the input name indicates it's a 0 in the corresponding address bit, and if the bit equals 0 there will be just the name of the input pin.
I suppose it's more clear to separate the entries with a few spaces and terminate each line with a return character, and start from the second line to add "+" and spaces before the first term.

Something like that, it already looks a bit like a script.

I also would not mind to edit the actual script and insert the data values there somehow for example in a input area which lists the variables etc, if that makes it easier to make.

If you don't have time, it's totally fine and I will try to find a different way to accomplish it.
You know, at least it is already supportive and encouraging for me when I see some other people interested in my project and even willing to spend some time to join me to look at the problems with this PAL.
And that all my work may benefit other people by enjoying to use the end result, which will be published on GitHub.

If we tackle this PAL obstacle, that will greatly push the project further, and on the other hand, without the PAL, I can forget about the whole project ever succeeding in the first place.

There is only one way, which is by computer program, that makes sense for doing this work of creating actual equations which represent the address entries I need to convert.
Maybe I can do it in BASIC or something.

 

[rodney]

So, I figured out why my equations differ from PA.EXE

My compliments for your work, Johann, and thanks for spending the time on it!

I am currently soldering lots of wires to my test PCB so I can insert it into the test position on the 5170.

I hope we can be lucky but I think it is going to take more work before we can obtain a working PAL!

After I have had the chance to test out some things and report the result here, I will have a closer look at your python script.
If I ever decide to study python, your script will be a great motivation to learn what can be done, and how to do it in a useful way.
Of course, a substantial portion of linux is made from python, so the usefulness is beyond question!

 

[jonny64]

Here we go...

jonny@Mac-mini-von-Johann ibm-5170-u87 % python3 rodney.py -signal RAS,MEMW,IOR,AIOW,Q1,IO_CS_16,AEN_1,AEN_2,Q4,FSYS_16,RES_0WS,XA0,XBHE textfile.txt output.txt
jonny@Mac-mini-von-Johann ibm-5170-u87 % cat output.txt
RAS & MEMW & !IOR & AIOW & !Q1 & !IO_CS_16 & !AEN_1 & !AEN_2 & !Q4 & !FSYS_16 & !RES_0WS & !XA0 & !XBHE
+ RAS & MEMW & !IOR & AIOW & !Q1 & !IO_CS_16 & !AEN_1 & !AEN_2 & !Q4 & !FSYS_16 & !RES_0WS & !XA0 & XBHE
+ RAS & MEMW & !IOR & AIOW & !Q1 & !IO_CS_16 & !AEN_1 & !AEN_2 & !Q4 & !FSYS_16 & !RES_0WS & XA0 & !XBHE
+ RAS & MEMW & !IOR & AIOW & !Q1 & !IO_CS_16 & !AEN_1 & !AEN_2 & !Q4 & !FSYS_16 & !RES_0WS & XA0 & XBHE
+ RAS & MEMW & !IOR & AIOW & !Q1 & !IO_CS_16 & !AEN_1 & !AEN_2 & !Q4 & !FSYS_16 & RES_0WS & !XA0 & XBHE
+ RAS & MEMW & !IOR & AIOW & !Q1 & !IO_CS_16 & !AEN_1 & !AEN_2 & !Q4 & !FSYS_16 & RES_0WS & XA0 & XBHE
+ RAS & MEMW & !IOR & AIOW & !Q1 & !IO_CS_16 & !AEN_1 & !AEN_2 & !Q4 & FSYS_16 & !RES_0WS & !XA0 & !XBHE
+ RAS & MEMW & !IOR & AIOW & !Q1 & !IO_CS_16 & !AEN_1 & !AEN_2 & !Q4 & FSYS_16 & !RES_0WS & !XA0 & XBHE
+ RAS & MEMW & !IOR & AIOW & !Q1 & !IO_CS_16 & !AEN_1 & !AEN_2 & !Q4 & FSYS_16 & !RES_0WS & XA0 & !XBHE
+ RAS & MEMW & !IOR & AIOW & !Q1 & !IO_CS_16 & !AEN_1 & !AEN_2 & !Q4 & FSYS_16 & !RES_0WS & XA0 & XBHE
+ RAS & MEMW & !IOR & AIOW & !Q1 & !IO_CS_16 & !AEN_1 & !AEN_2 & !Q4 & FSYS_16 & RES_0WS & !XA0 & XBHE
+ RAS & MEMW & !IOR & AIOW & !Q1 & !IO_CS_16 & !AEN_1 & !AEN_2 & !Q4 & FSYS_16 & RES_0WS & XA0 & XBHE
jonny@Mac-mini-von-Johann ibm-5170-u87 %

 

[jonny64]

I'm looking around in the PA.EXE generated equations, and as you already mentioned, these two pins seem odd:
pin 15 = XA0; /* Fixed low output w/ output enable */
pin 16 = XBHE; /* Combinatorial output w/ output enable */

I mean, PA.EXE says "output", but at the same time, these two pins are used as inputs for some equations?!

Until now, we always assumed both these pins as "known to be inputs" - but where does this information come from? Can you say this for sure from the schematics?

Additionally, did you make this "XA0 = 0" part of your PALASM/WinCupl input? And if yes, wouldn't it make sense to remove it, if we know it is an input?

 

[rodney]

Here we go...

Wow that is great, you already did it. The output looks great, I can insert it into Logic Friday easily.
For example, your sample output translates to this:
INSTANCE =
RAS MEMW IOR' AIOW Q1' IO_CS_16' AEN_1' AEN_2' Q4' RES_0WS'
+ RAS MEMW IOR' AIOW Q1' IO_CS_16' AEN_1' AEN_2' Q4' XBHE;
only two terms already!
And it's remarkable that we see terms which include the cycle timer outputs Q1 and Q4 which I wrote about earlier.
It's quite possible that something similar to the above controls an OE function on !GATE_245.

I am thinking, possibly to use an OE function can decrease the complexity of the input equations needed to complete the whole output response.
Especially if the OE eliminates many of the input signals which could simplify the equations and make them possible to fit inside the GAL capacity.
Additionally, if Q1 and Q4 are indeed involved, this could be applied to all the equations for GATE_245 in one go.
Possibly a pull up resistor will not be necessary if the output pulls another input low.
And possibly not having that resistor there may speed up the signal.

After I finish my soldering and testing work, I will get busy using your script to assemble some equations, hopefully the results can help us to provide the clues to finally decode the entire U87!
I will post the results here later so others can also look at it if they want.

Thanks for your help Johann.

 

[rodney]

Hi Johann,

I have found that WinCupl is a somewhat weird and quirky program.

One of the things it does is sometimes it goes into an "erronic assumption mode" where it will remain stuck in, and it's hard to get it to exit from it.

For example, in my WinCupl files you will sometimes find stuff which makes no sense.
Such as "XA0 = XA0;" and "XBHE = XBHE;"
These entries I have entered into WinCupl to prevent it from assuming that these are to be programmed as outputs.

I know the 5170 schematic almost by heart, both XA0 and XBHE are coming from the 5170 into the PAL, and are deemed to be inputs in our process regarding the PAL. What is the purpose of XA0 and XBHE you may like to know?
Both of these signals originate from the 80286 CPU and serve to control the mode of databus access.
IBM named BHE and XBHE in positive active manner, however it is actually negative active as stated by Intel.
I have found various examples in the XT and AT where IBM used incorrect naming which is annoying, but I just keep their naming for the most part to avoid confusion further on because their names will tend to be the standard as everyone knows and recognizes them. So I just think "so be it" in those cases.

Anyway, here is the table for the databus mode of the CPU:

BHE        A0
0          0        WORD TRANSFER (16 BIT MODE)
0          1        BYTE TRANSFER ON UPPER HALF (D15-D8)
1          0        BYTE TRANSFER ON LOWER HALF (D7-D0)
1          1        WILL NOT OCCUR

So you can see why U87 takes these as an input because it's important for detecting the byte transfer modes and switch the conversion transceiver accordingly. U87 is elemental in the backward compatibility conversions from 8 to 16 bit and vice-versa which allows 8 bit hardware to be used. You can see from various design areas that backward compatibility was really taken seriously by IBM which I really respect and I believe it's a good business decision especially at those times when it was so essential to gain support for their PC standards from the industry.

When I am using PA.EXE, additionally, there are some erroneous "detections" happening regarding the attempts by PA.EXE to determine whether there are any OE functions used. I know what you mean about those entries, however they don't make sense one way or any other as far as I'm concerned. If I am wrong, if someone who knows it for certain could explain it to me, I would appreciate that. If there were an .OE entry regarding one of the real outputs, I would take that much more seriously, however as you mentioned before, we don't know the source code of PA.EXE so we can't know anything. And even if the source code is available, I don't have much programming experience yet so I probably would not be able to see much clear information about how PA.EXE functions from the source. Another detection which also clearly fails to be correct by PA.EXE is when it tries to detect whether a pin is input or output. Luckily it at least lists the respective pins correctly as input pins in the equations. I have not seen any OE information in PA.EXE output files which I have found informative or useful in our case here.

I can tell you more about the OE functions. When using WinCupl, it creates several intermediate files during the compile process, such as the .DOC file.

The DOC file attempts to explain various assumptions by WinCupl, shows the derived final equations, and also shows you what settings WinCupl will program into the fuse map regarding each "OE" capable pin.

An example:

DATA_CONV.oe  =>    1

DIR_245.oe  =>    1

END_CYC.oe  =>    1

GATE_245.oe  =>    1

NUMBER14.oe  =>    1

RES_0WS.oe  =>    1

XA0.oe  =>    1

XBHE.oe  =>    1

As you can see in my example, every output capable pin must be listed here so the correct setting may be applied to it.
When the pin is determined as logic "1", that simply means what you would expect, "always enabled".

However when we are faced with a pin which is to be used as an input I'm still not entirely certain on what the value should be.
Though from my source files which I am programming, I saw that my inputs were compiled as above.
I only saw a 0 with RES_0WS so I added a line "RES_0WS = RES_0WS" and since then WinCupl added a "1" at the OE setting as well.

I assume this is correct unless I hear otherwise. So far, the GALs function correctly so there is apparently not a problem in assuming this.

I hope it's clear since you are also working on the translations of equations it is somewhat relevant to understand it.
Both PA.EXE and WinCupl are not perfect I believe, but they do get the job done once you know how to work around the typical issues. Anyway, we now have an alternative to PA.EXE.

I always have not liked applications that assume things. I believe it's much better when the user is asked what they want to happen, like providing some input rather than assuming stuff wrongly which is a risk in automatic systems.

I would have much rather liked to see PA.EXE asking me which pins are in and which are out.

 

[rodney]

I just finished my initial testing of the in-circuit adapter PCB.
Unfortunately there is some problem with the before assumed to be correct equations.
I have confirmed the in-circuit adapter PCB to be correct by wiring GATE_245 temporarily to socket 1 and inserting U87 there, and I get a normal POST happening on the 5170. The adapter PCB is very solid and reliable so I can be sure of the tests.

Right now I am suspecting a problem with at least also DIR_245 since I lately believe that the control of the conversion transceiver involves an OE component. So it's quite possible that there is also an OE component on DIR_245.

So I will wire up an additional test by moving DIR_245 to U87 in socket 2, to see if DMA_AEN, END_CYC and DATA_CONV are at least correct running on the test GAL, or if there are also problems in these equations.

I always knew that there could be possibly some residual differences in the logic, but still disappointing to find this happening because it means that determining the equations of U87 will be even more work still. I will update with further findings.

 

[rodney]

I have some more test results now.
I changed my dual GAL PCB so I can plug every output to be used from either socket.
That way it's more flexible for testing.

I have discovered more details about WinCupl. As I mentioned it was a little unclear about how to proceed when an input/output capable pin should be used as an input. In that case, said input needs to have its OE function disabled.
As Eudimorphodon indicated, there could be methods employed where the OE function can facilitate a bidirectional function of an I/O capable pin, however in our application specifically, RES_0WS, XA0 and XBHE are all inputs only.

So I added the following lines in my PLD file for WinCupl:

XA0.oe = 'b'0;
XBHE.oe = 'b'0;
RES_0WS.oe = 'b'0;

These are essential or the 5170 cannot do anything with the PAL inserted, it interferes with XA0, XBHE and /END_CYC.

So after this problem was solved I proceeded to test further to see which outputs are working.

The result of testing at this moment is:

- DMA_AEN is working
- DIR_245 is working

- END_CYC is a marginal case, sometimes the 5170 powers on, sometimes not. It's not stable and sometimes after resets it could work for a while

- DATA_CONV in this case the 5170 is throwing some BIOS error beeps so something is not working right there.
- GATE_245 is not working at all. We already knew that something is up with this output probably requiring OE functionality.

So I have tested more extensively with DMA_AEN and DIR_245 from the GAL and the rest from U87.
This test went well and the 5170 ran stable on them. I included one of the best tests, to format a floppy disk.
So DIR_245 is correct for at least selecting the direction of conversions, which is quite important.

So what's next? I will look into trying to determine which equations should be used to "overlay" an OE equation on top of the output equations. There this also should be able to eliminate a lot of input terms ideally, which I hope could be accomplished.

When I have more theories about the OE functions I will try to compile them and test them out.

Since the usual analysis of DATA_CONV, GATE_245 and END_CYC do not provide working functionality, I am going on the assumption first that all three of these pins contain an OE function. This function will show up in the resulting equations so in those instances OE should be true. For GATE_245 there is additional information possibly from the EPROM compare reads.

I am also thinking about doing specific OE testing on the three remaining pins. I could try doing reads with pull-up resistors and pull-down resistors and compare them with eachother. Any differences will point to OE function being responsible for them as a most likely explanation.

I still cannot exclude any latching to be present, but first I will attempt to explain what is happening with some form of OE functions on those outputs. Adding OE function is not only enabling more conditions to be programmed which are superimposed on top of all equations for the respective output, at the same time this allows more precise timing of the output by syncing it with inputs which provide the accurate timing necessary. Since the outputs are not requiring floating conditions, I believe it's mainly done for being able to create more complex input conditions.

Now at least I will be able to do tests directly on the 5170 according to what's needed which is at least going to quickly show whether an output is correct or not.

I think the best method to proceed is doing one output at a time, trying to use OE function to get that one output to work properly and stable on the 5170.

It's looking like a difficult path forward. I don't have much experience about reverse engineering PALs but I can clearly see from this experience that not all cases are straight forward. The databus conversions are not a simple thing for sure.

 

[jonny64]

One question came to my mind which needs an answer by somebody with more electronics knowledge than me:

The EPROM adapter uses 4.7k pull-up/down resistors to detect OE conditions. From my understanding, the EPROM reader works in a push/pull fashion, i.e. it applies either high or low voltage level to the address line, which is then applied to the output pin via said resistors. In other words, the EPROM reader drives the output pin high/low with a certain "force" (sorry, this is probably an adequate term...). At the same time, the PAL itself will drive its own output pin high or low (or switches to high-z).

Question: Is it guaranteed that the internal PAL circuitry drives the output pin high/low with a stronger "force" than the EPROM reader? I mean, can it happen that the EPROM reader "overwrites" the PAL output, so we do not get the actual PAL output in our results?

 

[jonny64]

I am also thinking about doing specific OE testing on the three remaining pins. I could try doing reads with pull-up resistors and pull-down resistors and compare them with eachother. Any differences will point to OE function being responsible for them as a most likely explanation.

This sounds like a good approach to me... remove all the original resistors from the EPROM adapter; then for the first dump pull-up the known outputs and for the second dump pull-down. Feel free to send me the results of this experiment so I can compare.

 

[rodney]

Hi Johann,

It's a good question you are asking. When a PAL output is going into tri-state floating, that means that at this moment it's not driving the output at all, which is exactly what the respective read position in the EPROM is trying to determine using the resistors. So the output will become high impedance when it is not driven by the PAL. This high-impedance technique has been invented for example to support a "bus" design where multiple chips are connected to a bus line and only one at a time is supposed to drive the bus line, though there is also an exception to this in case all bus members use "open collector" outputs to pull the bus line down and the function is to be functionally ORed together from all bus members. IBM also uses this technique on some ISA lines. I read this somewhere in a manual that this is what they expect and suggest to card manufacturers. If more chips pull a pin down in such a configuration, it won't conflict with eachother when using open collectors.

When the PAL is not driving an output, it should be easy to pull the output low or high, whichever is desired in the case. It will be similar to an open line.
Especially when looking at the PAL when not connected with anything, it will be ideal to probe the PAL. When it is in circuit, it may be connected to a LS logic input, where the story will be different and you will probably need a 1k resistor to force a pin when nothing is driving it. Anyway, with LS logic it's better to leave no inputs open so I prefer not to use that in any actual circuits.

In our case, a 4k7 will do, or even a 10k should be okay for a floating output pin on a PAL I believe. Though it's really always best to use a scope to check the signal. I have done this before for example on my XT design.

I am still working on the matter regarding the PAL, it's quite difficult. I have reduced the "20" conditions to two short terms of four inputs with your very useful python script, great! This information by itself means likely not much but I will consider all the equations and information together to see if something pops out at me. The superimposing of an OE function needs to be considered according to the configuration in the whole circuit and active high or active low level of the output etc. So I need to look at the whole situation to see if I can find their method. Also I will need to do some test compiles to see if they will fit within the PAL limits of total gates used or not.

It may become necessary to do more test reads, which I will then do. It's a pity that I don't have more than 1 U87, I could read two next to eachother, one pulling a pin low with a resistor and the other pulling the same pin high. Then I can compare the nibble characters with eachother in a hex editor. My hex editor can open multi-document so it is somewhat possible to compare, though not easy.

 

[jonny64]

Hi Rodney,

I'm NOT referring to the high-z (i.e. not-OE) case, but a regular high/low output of the PAL. The EPROM adapter will always either apply Vcc or GND to all PAL output pins via a 4.7k resistor (pins 23/25/4/28/29/3/2/30 from the EPROM adapter go to PAL pins 12-19 via 4.7k resistors). Is it electrically assured that the PAL drives its outputs in a way which "overrides" what is applied from the EPROM adapter??

Cheers,
Johann