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

[rodney]

A minimization of the original equation I verified with U87 can be written as follows:

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

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

From this AND/OR equation you can see that FSYS_16 taken with RAS=1 and Q1(timing of CPU bus cycle) results in !END_CYC being active low when this term is true.
So this occurs more frequently when only using Q1 and RAS in our state evaluations of this last test, resulting in more 0 reads of the output.

The CPU cycle timer which generates Q1 and Q4 was designed by IBM as a function of the inverse double CPU clock and /ARDY, the signal which controls the READY state for the CPU to exit the command cycle.

The logic level of /ARDY going through the cycle timer is controlled by /END_CYC which resets /ARDY to 0 logic level at certain moments. When /END_CYC goes active low, the cycle timer starts running, otherwise it will remain in RESET.
Eventually the timer will advance at double CPU clock speed to let Q4 give off a positive logic pulse. That's my theory, since this occurrance might be very brief to let a single "1" state of Q1 be able to clock through to Q4. I believe they created this circuit by running tests to see if a pulse could be generated using this release-from-reset method. Q4 will become active after two CPU clock cycles, or 4 double CPU speed cycles. So Q1 and Q4 are logic 0 most of the time, and only provide positive pulses sequentially after being initiated by /END_CYC going active low.

!END_CYC seems to be activated when memory reads or writes or IO writes are occurring, using the terms
# RAS & !RES_0WS
# AIOW & !RES_0WS

And then "synchronised" using terms with Q1 and Q4 which are only then generated after RAS(memory read or write) and AIOW(IO write) activate it while !RES_0WS is inactive high.
That's what I am seeing when looking at these circuits and equations together as a whole.

 

[Eudimorphodon]

Too much has been added to this thread since I last looked at it for me to rally digest everything, but I’m going to chuck this out there:

A latching action was programmed by IBM into U130 which I am certain of.
I deduced this from the operation of the coprocessor in documentation of Intel, IBM and a clone build.

If you look at the datasheet a PAL16L8 is combinatory only, full stop. PALs with ”latches” have a dedicated clock pin and an ”R” in their name.

Are you *absolutely* certain you’ve ruled out that there might not be some tristate action going on here? It might behoove you to go over the schematics tracing the lines the outputs of these GALs are on to make absolutely sure there are no pull-up resistors hanging on them; the presence of such would be *extremely* suspicious. Using the tristate control is a common trick to make a PAL/GAL act like an open collector, and it is at least possible some of these lines like DMA_AEN could be designed to use open collector wire-ors.

 

[Eudimorphodon]

It might behoove you to go over the schematics tracing the lines the outputs of these GALs are on to make absolutely sure there are no pull-up resistors hanging on them; the presence of such would be *extremely* suspicious

FWIW, I spent some time eyeballing the schematics and I no longer like this theory; I’m pretty skeptical tristate/wire ors are used on any of the outputs, I don’t see any pull-ups or additional drivers on these lines.

I stand by thinking that it’s really unlikely that there’s any secret latching action happening inside these chips. PALs like this were very fast, I don’t think you could rely on internal delays or whatever to synthesize some kind of “latch-like” activity in an unregistered PAL.

 

[rodney]

Hi Eudimorphodon,

You are absolutely right, there are no programmable output latches on a PAL16L8. As stated here before, the PAL16L8 is combinatorial only.

As you just also wrote in your updated post it is also possible to compose a latch from logic gates. Latches are nothing more than a circuit made from logic gates which is then represented with a simplified symbol. I want to include this fact in this thread so it is understood for any reader unfamiliar with this why I am considering it to be a possibility. In fact, I must consider it because I am seeing irregularities in the output reads. And the irregularities are originating somewhere inside U87. The difference must be in the sequence of presenting input values on U87 while probing the outputs. There is a difference in the pin order on my compare read setup compared to the Charles MacDonald published 27C020 type adapter schematic. Apparently we must consider this fact to be very relevant and indicative of a difference, because it is producing a difference compared to the logic equations which come from the PA.EXE analysis. Both the EPROM mode and compare read are done with the same programmer, my Conitec Datensysteme Galep-III.

So if there were a problem with PA.EXE, I think this would have been discussed to be aware of this fact if that were the case. It has been used to read many PAL chips from various computer systems, as I understand also a lot of arcade classic boards from arcade machines, and some different digital equipment as well. I am not ruling out a problem with PA.EXE however, I can't rule anything out until I have found the reason.

Every suggestion or thought is welcome and I will consider all of them with care.

Likely or not, possible or not, I must consider to form a theory why the output differences are happening. Why is the PAL presenting different values at different sequences of reading the inputs? These are questions I need to answer. This would only be possible if there is some latching going on, or in case PA.EXE contains an error. Unless anyone can present me with a different explanation, which I also would prefer to follow up on. It remains and can't be ignored that the usual logic analysis is proving not to provide and accurately predict the equation that can describe the complete function of U87.

I checked the IBM circuit again and definately there are no pull-ups present on any of the U87 PAL outputs. I also didn't remember any from my work before, but just to make sure I checked it. And, there is also the fact that the PAL16L8 only has OE capability on pins 19 and 12. No other pins can do this. The "I/O" pins are not really I/O, but are programmable to be I or O type pins.

There is another thing to consider which I want to elaborate on. The equation for !GATE_245 I am getting from analysis is too complex. There are 8 AND/OR terms which is too much with so many variables. It simply is. I have so far done various methods from positive and negative active equations to rewrite the minimized equation in many different forms, and extracting parts of it to replace them with logic from the other equations, trying to reduce the gates needed in this way, however all combinations of using parts of the other equations to substitute parts in the equation for GATE_245 with those are still failing to compile due to a shortage of gates in the GAL. Etc etc etc I even used quartus to enter all the equations and see what quartus made of them. Those outputs are also not providing a solution to recreate the equivalent of the used analysis of GATE_245. So there is the fact of complexity of the minimized equation. How can such a complex equation be formed from analysis of such a simple PAL component, that is something to consider as well. I may be in error and there could be a way to produce everything in a PAL, but it so far eludes me. So this fact made me decide to take the outputs one by one and see what compares correctly with U87, and what doesn't. The only problematic output I have been able to detect is GATE_245.

One of my theories is that GATE_245 gets activated and deactivated by some combination of timing signals Q1 and Q4 which are synced to the CPU clock and bus state cycles. This creates the timing for high to low byte conversion to be able to occur.

I will be looking at new methods of analyzing the PAL. However I am not putting my faith in analysis errors, I believe it's coincidental that my different input sequence in the compare reader has discovered the problem in the logic.

About logic speed inside the PAL, I don't know if faster gates would make it inpossible to produce a latch. If the gates are all faster, the detection of conditions also should be proportionally faster. So if propagation time is essential to exist, in this case I don't see the difference with a slower logic version of a latch since all gates are equally fast as far as I know. If it's possible with normal gates, it should be possible in a PAL if the PAL can provide the gates necessary.

I will be studying various latch circuits to theorize if and how it would be possible. I think there must exist some kind of feedback to do this, but that doesn't necessarily need a feedback from an output, theoretically shouldn't it be possible to provide a feedback in an equation which represents a latch? Anyway I need to study this more. If I could know how it could be done, maybe I can find a way to test it.

Those deviating output conditions where I suspect latching present a 0 when the input combination should have presented a 1. I have verified several of these input combinations with my switch PCBs and they do not provide a 0 on the output. Which is important to remark here. So why is the tested input condition providing a 1 with the switch setup, and a 0 with the compare reads? I have tested and it is completely consistent.

 

[rodney]

Here is a schematic of my PAL compare reader.
So I am connecting the EPROM side to my Galep-III and reading it out as an AMD 27C64 EPROM.
I have posted the read-out results in this thread earlier.
So the left part(bits 7-4) is the GAL, and the right part(bits 3-0) is U87.
U87 is presenting output conditions where the output is 0 while the GAL outputs a 1.

I am open to investigate any theory, the goal is to be able reproduce the PAL and proceed with my project.
If any programmer wants to help, it's much appreciated.
And I appreciate jonny64's help too since he is doing some programming in python which is a useful skill.
I hope to learn this one day as well since I am a huge linux fan and user since many years.

 

[rodney]

Here is a table of the inputs compared between my EPROM side-by-side read adapter and the Charles MacDonald diagram adapter used with PA.EXE.
The inputs are only different for /RES_0WS, XA0 and XBHE. However the sequence is somewhat similar.
So there is the possibility that there is something wrong in the analysis, I should try other methods to verify it more.
I wish there were a method where I can indicate which is an input and which are outputs so the analysis is more clear.
Somehow I got a feeling that this is not going to be straightforward either, it already isn't now.

 

[lowen]

So, going a completely different direction, another member on VCF has actually de-capped a PAL and read the fuses directly from the die. If you had another U87, perhaps you could de-capped it and read the fuses, then reverse engineer from there. The post mentioning this is Thread 'PAL fusemap to JED?' https://forum.vcfed.org/index.php?threads/pal-fusemap-to-jed.1246209/

 

[Eudimorphodon]

About logic speed inside the PAL, I don't know if faster gates would make it inpossible to produce a latch. If the gates are all faster, the detection of conditions also should be proportionally faster. So if propagation time is essential to exist, in this case I don't see the difference with a slower logic version of a latch since all gates are equally fast as far as I know. If it's possible with normal gates, it should be possible in a PAL if the PAL can provide the gates necessary.

Your post made it sound like your theory might be premised on some transitory phenomena. If the claim here is you’re actually seeing an actual stable latched state… I mean, sure, you could construct a simple SR latch using the feedback lines that would give you paired Q-/Q outputs, but making a gated latch would require the use of a second set of the output modules (who’s feedback would be the gate to the “real” outputs) and thus make them unusable for inputs, which the schematics don’t seem to allow.

A PAL doesn’t have any other “buried” logic in it, the 8 output modules are it, so it seems to me that *if* for some bizarre reason IBM implemented SR latching behavior between a couple outputs you should be able to see it with external analysis.

 

[Eudimorphodon]

checked the IBM circuit again and definately there are no pull-ups present on any of the U87 PAL outputs. I also didn't remember any from my work before, but just to make sure I checked it. And, there is also the fact that the PAL16L8 only has OE capability on pins 19 and 12. No other pins can do this. The "I/O" pins are not really I/O, but are programmable to be I or O type pins.

Here's a diagram of the PAL16L8’s internal arrangement:



Why do you believe that the chip only has OE capability on pins 19 and 12? Every output section has a dedicated product term running to the tristate line on the output buffer:

The thing that's missing on 19 and 12 is the feedback line, which is why these pins can't operate as inputs. (All you're doing when you use one of the I/O lines as an "input" is keeping it permanently tristated and not using any other product terms on it.) See page 13 of the ATF16V8 GAL datasheet where it describes "complex mode"; that's the mode that emulates the PAL16L8.

I don't have the schematic in front of me, is it possible that one of the "outputs" is actually bidirectional, and based on one of the input pins acting as a tri-state gate one of the other outputs is switching between using the feedback state of the I/O line as externally asserted by a device downstream of it verses a value that the PAL itself is asserting?

(edit: fwiw, digging into this has been pretty educational. I wasn’t totally clear on why/what the distinction between Simple and Complex mode was, because I haven’t used tristate much while playing with GALs.)

 

[rodney]

Hi Eudimorphodon,

Yes, my theory is that it could be possible that something "sequential" is happening. Later I will illustrate in more detail in this thread why I am already relatively certain that U130 also contains some kind of signal retention logic. This takes some explanation and bundling information from different sources, which I will do just to illustrate it for all people interested in the 5170. At the moment it's more important to get U87 reverse engineered completely. For preservation sake, I would prefer to finally have a reasonable estimation of what IBM has originally programmed. Their work was really important.

You make a good point, when the complexity of a latch is increased, the chance of such a complex latch being present becomes much smaller to zero inside a PAL. I should remember and consider this point that it must be something "simple" in this process of finding out what is going on, thanks.

I just took out some old theory books yesterday to revisit how latches were developed, each additional "feature" making a flipflop or latch more advanced will require an additional "stage" of gates compared to the most basic SR function. Like for example turning a SR flipflop into a D flipflop, using triggering instead of direct control, etc. Just to keep the kind of gates and their intereconnection in mind, how this can relate to a logic equation.

So if any latching were done by IBM, it would more likely only be the most basic type of latching. This is a small advantage in trying to find out what is going on. Perhaps for more clear discription I should use the term "flipflop" from now on because it can't be much more than that since there are not enough gates available to make complex logic elements besides already doing all the decoding which is happening in U87.

About the OE capability, I was also looking at that diagram in the datasheet a few times and it also appeared to me that other outputs seemed to have an enable capability as well. Which contradicted what was described elsewhere in the datasheet stating that only two pins were output enable capable, the meaning of the table I saw was not so clear looking at it now. After looking at the diagram again I also believe you are right that all outputs could be OE enabled. So that will be a different matter to consider this now. I should do some experiments to confirm it and try to create an output enable and see if it works on one of the other outputs besides pin 12 and 19. So this also makes it a bigger possibility that perhaps GATE_245 was floating during the moments of reading out in certain areas.

Another experiment I have been meaning to do is to remove a pull-down from pin 17 GATE_245 on U87 in my compare adapter.
I applied pull-downs later on in order to get the other unconnected pins to zero for certain tests while reading the comparing results of a single output, only connecting those outputs on U87 and my test GAL. Maybe those pull-downs actually revealed a possible floating condition. I did have some suspicion of this output pin floating and tried to set some combinations on my switch assembly PCB and attempted to pull down GATE_245 manually with a resistor, however I was not able to do this. Maybe the combinations were not correct, it's possible. I will do more testing to compare with a pull up resistor on pin 17 to see if those input "addresses" will now produce a logic 1.

About acting as an input, I see your point, maybe this is possible as well, even if a compiler may refuse to do this, a fuse map could be altered to create this kind of function. From memory I didn't notice any such output situation on U87 where I would need to consider that a signal is fed into them. I don't believe that is the case because I would have already become curious after noticing something irregular like that. I will look again but I don't think so on this theory. But technically I agree, it does seem to be right what you claim about still using it as an input. So some of the wording I have read about PALs is incorrect. Which can illustrate that there are many things possible with PALs. To use them myself I am more attracted to now, however I seriously dislike the fact that they make it really hard to figure out the logic inside when encountering one on a PCB.

I really need to look at the PAL diagram more often to consider alternate ways it could be used besides what you read as described in the datasheet. I have only been looking at PALs since I am now dealing with one in the 5170, so I need to clarify the complete function of a PAL more, thanks for thinking along with me Eudimorphodon!

I have read the thread by Chuck (G), and thank him for writing it. I love his practical application of the theory and very relevant for people in this forum. The Trantor SCSI adapter is actually a card which I have looked at several times in the past when I was looking for a good candidate for a SCSI adapter to integrate on my XT mainboard which I abandoned and decided to go with the intended application by NCR of the 53C400, their design is absolutely great and a low part count solution for having SCSI. Anyway, I may create a more comprehensive schematic of what Chuck (G) designed so it becomes more clear how to build his device on a PCB which I aim to do. What I'm looking for is more methods to double check the PAL. I think later I will also create a dedicated web page about the whole process just to help others in preserving retro technology. I have some old Super Nintendo copy box ful of GAL chips which I want to reverse engineer. Not because of needing it since it's rather obsolete, but for purely nostalgic reasons and for an interesting project to do because in those years I had wanted to do this. Those copy box makers turned a Super Nintendo into a whole system with expansions. Anyway, I would really like to recreate the PAL device and method for reverse engineering by Chuck (G).

Hi lowen, the decapping method is definately a very good idea, thanks for pointing this out. I bought the 5170 mainboard specifically for my project so I don't mind to sacrifice U87 at some point for the good cause. My problem however at the same time is a bit of a "chicken or egg" thing. I will be needing the 5170 mainboard functional in order to test various stages of the 286 mainboard design for this project. The changes I want to make are extensive so I really should be doing more verifications first before committing to a whole mainboard PCB. I may resort to look into decapping if I absolutely can't find a single method to reverse engineer the PAL and produce an identical set of equations. That's my only option since destroying U87 also makes it impossible to test any other design stages. Also I can't be 100% sure if this will work. If I can find a method or person who is willing to do it which is 100% sure, I would consider it more seriously to go this path first before moving on with the next design stages. I hope something can happen to provide some breakthrough discovery so I can save some time soon in the whole process of this project.

 

[rodney]

Hi Eudimorphodon,

I really need to use other additional methods to do analysis of U87, especially regarding the determination of any OE function. From our talk I really have concluded this. I think the method by Chuck (G) may provide some more concise information.

It's great to have you all join in to look at this matter in more detail. When analyzing an unknown chip it's really important to look at things from all perspectives in order to have any chance to know the exact contents.

I will try the pull up test soon on my compare adapter and report here what I have found when comparing with some of the last positions where I got the unexpected 0 outputs. I can't check them all because there are many but I can pick out a few examples and cross check them.

Thinking about this OE matter more, I still don't know what they would have aimed to accomplish by floating GATE_245, but I can't exclude anything before I verify and test it first. It would be rather weird and remarkable if this is happening. I will try to get the results as soon as I can.

 

[rodney]

I have modified the compare reader, this time pulling pin 17 GATE_245 high on U87, however I am still getting the 0 output in those same instances which also occurred before. So it is definately under control of U87 that I was reading a 0 in those deviating result positions compared to the test GAL.

 

[Eudimorphodon]

Which contradicted what was described elsewhere in the datasheet stating that only two pins were output enable capable, the meaning of the table I saw was not so clear looking at it now

The table’s labeling in kind of a dumpster fire, but yeah, it’s not saying that those two pins are the only ones capable of controlled OE, it’s formatted the way it is to distinguish those two pins that don’t have feedback lines (and thus can’t also act as inputs, because feedback and input are the ”same thing”) from the other six “complete” pins. Again, the docs about “complex” mode in the GAL/ATF16V8 datasheet confirm this.

 

[Eudimorphodon]

I just took out some old theory books yesterday to revisit how latches were developed, each additional "feature" making a flipflop or latch more advanced will require an additional "stage" of gates compared to the most basic SR function. Like for example turning a SR flipflop into a D flipflop, using triggering instead of direct control, etc. Just to keep the kind of gates and their intereconnection in mind, how this can relate to a logic equation.

Here's a thread where someone demonstrates how to do a latch that has a "D" pin with enable with only combinatorial logic with a GAL/PAL. (This example is on a 22v10, but it should work on GAL16V8 in simple or complex mode or, indeed, a PAL16L8.) It is certainly within the realm of possibility that IBM could have implemented something like this on one of their PALs, but let's consider the limitations here:

• Maybe someone smarter than me can think of some way around this, but so far as I can noodle out there's no way to implement a latch like this without having at least two output pins that will *always* be a "pair" once the latch is set (in this example you have Q and QN, and for the latch to be "latched" they always have to be the opposite of each other); Is this condition satisfied by what's actually hanging off the output pins in the schematic? (IE, is there a situation downstream where one of the outputs should *always* be off while another is on?) From what I recall every pin of these chips was connected, there were no "spares" to be the complement of this latched output you're imagining.
• Okay, maybe I lied above about the "two pins must *always* be paired with each other rule above, I guess I can *maybe* think of edge cases:
  • Because a PAL16L8 is just combinatory it doesn't have any concept of preset, so if there's a flip-flop/latch implemented it's possibly/probably going to come up in an inconsistent state. (IE, the latch example I pointed to above is reliant on Q/QN being in opposition when E goes high to get their initial D/!D; if you powered it on with E low then they could have the same initial value *until* E goes high. E is the clock pulse.
  • I suppose you could add additional product terms that disable the latching action? This opens a huge can of worms.
  • (EDITED) I initially wrote this saying that you'd have two pins that would be complements, but because the feedback allows negation instead of having Q/QN always be in opposition you could have them always be the same, which maybe makes it a little trixier to sniff out a potential latch. I mean, like I suggested above with that huge can of worms maybe you have a "hold" input as another product term so they'll only be locked together when that "hold" pin is set. (And again, they could potentially be *either* a complement or the same, only rule is their state is going to be locked together because this latch action literally relies on the feedback of each forcing/holding the state of the other, IE, like the two NAND gates in an SR latch.)

Anyway, I guess maybe the broader point I'm getting to is *if* there is a latch implemented in either one of these PALs the behavior should be visible, if indeed potentially tricky to suss out. Again, there are no buried gates nor *real* registers on an "L" PAL. When you're looking at the diagram of the PAL's fuse map you can think of all the grid intersections leading to each AND product term as being part of a wired and. There's no secret magic; each AND has to be "true", IE, a 1 (which is why every intersection offers both the "plain" and "negated" term) for the whole line to be true, a single "false" drags it down. There's not another layer of logic in here you can exploit to "hide" a latching behavior. (Unlike a "registered" PAL, which literally *does* have a "memory cell" inside of it in addition to the product terms.)

 

[rodney]

I have double checked all my adapters, swapped the test GAL and U87, it's clear that the logic 0 outputs are consistent, but just to verify that. Definitely the compare adapter is working properly and no cause can be found in the adapter itself, other than the different pin configuration because the EPROM adapter for PA.EXE checks all the 8 pins if they are outputs so the connection of pins is shifted.

Additionally I have written down all the AND terms of /GATE_245 being active low indicated by the previous analysis, and tried to find a latching pin from those conditions, then changing to the conditions where the latched output became active, however so far I have not been able to let the PAL activate /GATE_245 in a combination which was contrary to the initial equations at those conditions. Indeed if there is any latching happening it should be visible, I agree, and I am using a RED LED with an inverter to even more clearly signal an active GATE_245 during my switch probing. Manually I have so far not been able to reproduce what I get on the compare adapter reads. This is the difficulty of being a human and not being able to simulate/recreate the same things accurately by switches, which is obvious because I am not seeing the active states which are happening in those cases. For example, simultaneous toggling off of multiple switches is just plain impossible to do by hand.

Maybe a solution lies in recording the operation of U87 in the 5170 and triggering the logic recording on the switching to active mode of /GATE_245. I do have a logic analyzer but I don't expect that it's fast enough for an 8Mhz system.

I don't see any part in the schematic where there could be some kind of feedback to inputs where negative terms are fed back similar to the flipflop stage gates.

For example, /GATE_245 and /DIR_245 are only connected to the low to high byte translation transceiver. DATA_CONV is only connected to a D latch on the 5170, nothing else, same goes for /END_CYC. Those two D latches control the CPU ready transitions, nothing going back to any inputs. And I am getting those unexpected states on the EPROM reader, so this is a condition of not in circuit so there is nothing externally connected to U87 except the reader. So the reader must produce the difference, the question is how is it doing that.

Another thing I want to attempt is to change the Charles MacDonald adapter. I want to check if the readings will be different when I rebuild the adapter in a different configuration. I will reproduce the schematic in KiCad and then try to change it up to simulate the same sequences as the compare read adapter. I will look at this in more detail soon to try to make the read adapter more closely fit the results I am expecting from U87. There must be some difference that produces the 0 results in those occurrences, so I want to attempt to let the 2Mbit EPROM adapter catch the results with the 0 outputs, and it can then possibly allow PA.EXE to at least produce the equations that match those 0 results. Maybe these results if detected properly by a new read out could produce a more simplified equation. As long as the outputs produce states which allow the 5170 to do the conversions, it's fine with me also. The limitation of PA.EXE is that it requires the file size of the BIN file to be 256KB, otherwise it will throw an error and not do any analysis unfortunately. Another thing I am noticing is that the GATE_245 and DIR_245 equations don't contain either of the timing inputs Q1 and Q4, so the switching occurs on the CPU read/write activity alone. I suppose that during 8 bit conversion the CPU inserts read pulses to get the converted byte separately, since the 286 was designed to be aware of 8 bit to 16 bit conversions which is signaled by A0 and /BHE. When /BHE is active low, the conversion transceiver reverses to allow the byte on the upper half of the databus to be read. This is also reflected in the equation for the /DIR_245 output. Apparently during conversion the CPU is doing the read/write timing so the logic to activate the conversion transceiver is possibly not timing critical and should reflect the conversion conditions and the actual second byte read/write instance happening. However there may have been some problems to let the conversion transceiver turn on in time so the read signal may have been extended somehow, which is where a latch function might be required. So the latch should be reset by a transition to a "non conversion" condition of the inputs.

/GATE_245 is active in more instances because it also switches for low to high byte conversions. So this is another clue to explain that there should be more equations on this output pin. Or at least different equations which result in additional activations of /GATE_245. The conversion conditions are always happening at !A0 & XBHE or A0 & !XBHE according to the 286 datasheet. So this points out that the equations for /GATE_245 are indeed incomplete, we are missing the !A0 & XBHE components where /GATE_245 also should be active low to convert from low to high byte, from 8 to 16 bit for example IO operations on 8 bit devices or during writes by the 8 bit DMA controller to 16 bit memory for example when writing floppy data to memory. Probably those are the 0 reads on the compare adapter which are somehow not reflected in the equations. Without equations reflecting this, the system won't work with the PAL in it.

 

[rodney]

Another thing I am suddenly realizing is that there may have been some kind of delay built into the PAL. This is another sequential thing that could be introduced in logic. If they used a number of gates in sequence this could possibly delay the activation of /GATE_245 under certain conditions. I don't know if this would be possible in a PAL since they are really fast. Perhaps the EPROM read sampling was too late to catch the delayed state, but the compare adapter did catch it. This is another possible cause to observe different results in two differently wired adapters that probe the same inputs differently. IBM has previously used some circuits to delay or extend signals in order to achieve the timing necessary, especially in DMA control. Logically the gate connections may make less sense, but when looking at the timing that's of course the reason for doing these. Perhaps this kind of delaying or extending circuit does exist in the PAL somehow. The PAL may have been tested in circuit and changed by IBM to achieve the right timing.

For 8 to 16 bit or 16 to 8 bit conversion, the timing is really essential and is probably being derived from the read/write pulses of the CPU. Delays may have needed to be included. There are for example also delays built into the XT-IDE which is doing similar conversions to what the 5170 is doing. From the XT-IDE I have had a lot of experience with needing to adjust the timing delays. The XT I worked on also used 8Mhz clock. If the timing is slightly off, the conversions will not properly reflect the databus and produce data errors.

Theoretically the 0 output results we discussed could be reflecting the delayed results of previous states which were still present at the time of reading the next condition. So maybe the previous state is more relevant. This also depends on the sampling timing of the Galep-III I am using compared to the address state transitioning. Since on the EPROM read certain input conditions take more time to be read out due to probing the inputs to check if they are outputs in between, possibly the PA.EXE EPROM adapter read is slower to switch certain input changes than the compare adapter. Using this adapter could possibly have missed the extended output values when they occurred.

 

[rodney]

I will now build the adapter as per my attachment. This adapter will only function with U87 and is not suitable for any other PAL.

What I want to achieve is to change the order of read-out when controlling these 27C020 address-to-input connections by the programmer used to read the output states.

So basically I am presenting a different pin order of the PAL as seen from the pins of the EPROM. This way I am hoping to be able to simulate the read out which happened on the 27C64 EPROM compare read more accurately, and hopefully at least to find the other "hidden" values. Arguably they may belong to the previous input value, which I will hope to adjust. But the first step is at least to detect the extra 0 values to be recorded by the 27C020 read out bin file, which hopefully will be equal to the read values on the compare adapter. Theoretically, if this now occurs, it could also be a delay related issue where I will need to find the correct "previous" equations for each instance. So a lot of extra work to do. But I believe that once I write down a few values, this could give an indication to the conditions containing !XA0 & XBHE which were previously not described in any equations for !GATE_245.
!GATE_245 should contain equations for both direction conversions, not only for one way. Perhaps adding certain extra equations of the delayed conditions may lead to a reduction of terms. Anyway, I will proceed one step at a time doing this work. At some point any delays, if this is proven, will need to be integrated back into the equations. Also, I am thinking that perhaps I could see some delays happening on a scope once I am more clear on where to find them related to certain input transitions.

The whole process remains a reverse engineering effort, which is arguably more difficult because the original design is still unknown and it appears that some irregular things are going on here which make it more difficult and as of yet inconclusive. Perhaps indeed some delays could be an explanation for the inconsistent reads. Though I am still considering the speed of the PAL which is really high compared to the EPROM reader. Arguably to have the sequence of controlling the actual inputs interrupted by other checks as with the MacDonald adapter will certainly introduce really long interruptions of sampling the EPROM read signals in the same sequence as with the compare read adapter.

So I will be supplying to PA.EXE the following pin order:

-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

Which order I will realise by wiring the PAL to the EPROM socket in a different order, listing first all the inputs and then wiring the output signals to the remaining D positions of the EPROM where those pin names would be expected to be found by PA.EXE as supplied.

I will be omitting the resistors because this method of reading will not combine input/output on the same address lines and data lines. The signals are already separated by knowing which is what and wiring them to the read inputs and address bit outputs of the programmer which is reading the PAL. And I am keeping the address to input signals wired the same as the compare adapter this time.

 

[Eudimorphodon]

Another thing I am suddenly realizing is that there may have been some kind of delay built into the PAL. This is another sequential thing that could be introduced in logic. If they used a number of gates in sequence this could possibly delay the activation of /GATE_245 under certain conditions. I don't know if this would be possible in a PAL since they are really fast.

Again, there are no buried gates, and the AND product terms are essentially wire-speed. The only way you could meaningfully trigger delay would be to chain up the OR gates via feedback, and that would be obvious because the pins associated them wouldn't be available for any other purpose; IE, you'd have to use the whole PAL to build up a remotely significant delay chain for a single signal. And given the speed of these devices I'm skeptical if even you did use the whole PAL to delay a single signal it would lag by more than a couple dozen nanoseconds, almost certainly not enough to do meaningful work on a 6mhz machine.

 

[rodney]

Indeed, I have the same impression. So then the only thing remaining would be a type of flipflop which gets set somehow.

I will wire up an adapter as described and let's see if this can produce any equations, and if the information can be made sense of.

Hopefully this uncertainty can end soon and leave us with clarity finally.

I am already thinking a plan B which will be looking at other methods to produce equations from the PAL.
Possibly the current method is not suitable for all situations, I shouldn't put 100% faith in it yet unless other methods produce the same results.

 

[jonny64]

So, being not able to help with the electronic details, I'm still following the path "what, if PA.EXE has a bug?". So I extended my Python version with output of the equations (source code attached).

Rodney, is it feasible you try these out without wasting too much of your time? Or would I need to compile them first?

END_CYC = !RAS & !IOR & !AIOW & !Q1 & !IO_CS_16 & !Q4 & !RES_0WS
# !RAS & IOR & !AIOW & !Q1 & !IO_CS_16 & !Q4 & !RES_0WS
# !RAS & IOR & !AIOW & Q1 & !IO_CS_16 & !Q4 & !RES_0WS
# !RAS & !IOR & !AIOW & !Q1 & IO_CS_16 & !Q4 & !RES_0WS
# !RAS & IOR & !AIOW & !Q1 & IO_CS_16 & !Q4 & !RES_0WS
# !RAS & !IOR & !AIOW & Q1 & IO_CS_16 & !Q4 & !RES_0WS
# !RAS & IOR & !AIOW & Q1 & IO_CS_16 & !Q4 & !RES_0WS
# !RAS & !IOR & !AIOW & !Q1 & !IO_CS_16 & !Q4 & RES_0WS
# RAS & !IOR & !AIOW & !Q1 & !IO_CS_16 & !Q4 & RES_0WS
# !RAS & IOR & !AIOW & !Q1 & !IO_CS_16 & !Q4 & RES_0WS
# RAS & IOR & !AIOW & !Q1 & !IO_CS_16 & !Q4 & RES_0WS
# !RAS & !IOR & AIOW & !Q1 & !IO_CS_16 & !Q4 & RES_0WS
# RAS & !IOR & AIOW & !Q1 & !IO_CS_16 & !Q4 & RES_0WS
# !RAS & IOR & AIOW & !Q1 & !IO_CS_16 & !Q4 & RES_0WS
# RAS & IOR & AIOW & !Q1 & !IO_CS_16 & !Q4 & RES_0WS
# !RAS & IOR & !AIOW & Q1 & !IO_CS_16 & !Q4 & RES_0WS
# RAS & IOR & !AIOW & Q1 & !IO_CS_16 & !Q4 & RES_0WS
# !RAS & !IOR & !AIOW & !Q1 & IO_CS_16 & !Q4 & RES_0WS
# RAS & !IOR & !AIOW & !Q1 & IO_CS_16 & !Q4 & RES_0WS
# !RAS & IOR & !AIOW & !Q1 & IO_CS_16 & !Q4 & RES_0WS
# RAS & IOR & !AIOW & !Q1 & IO_CS_16 & !Q4 & RES_0WS
# !RAS & !IOR & AIOW & !Q1 & IO_CS_16 & !Q4 & RES_0WS
# RAS & !IOR & AIOW & !Q1 & IO_CS_16 & !Q4 & RES_0WS
# !RAS & IOR & AIOW & !Q1 & IO_CS_16 & !Q4 & RES_0WS
# RAS & IOR & AIOW & !Q1 & IO_CS_16 & !Q4 & RES_0WS
# !RAS & !IOR & !AIOW & Q1 & IO_CS_16 & !Q4 & RES_0WS
# RAS & !IOR & !AIOW & Q1 & IO_CS_16 & !Q4 & RES_0WS
# !RAS & IOR & !AIOW & Q1 & IO_CS_16 & !Q4 & RES_0WS
# RAS & IOR & !AIOW & Q1 & IO_CS_16 & !Q4 & RES_0WS
# !RAS & !IOR & AIOW & Q1 & IO_CS_16 & !Q4 & RES_0WS
# RAS & !IOR & AIOW & Q1 & IO_CS_16 & !Q4 & RES_0WS
# !RAS & IOR & AIOW & Q1 & IO_CS_16 & !Q4 & RES_0WS
# RAS & IOR & AIOW & Q1 & IO_CS_16 & !Q4 & RES_0WS;
DMA_AEN = AEN_2 & AEN_1;
(See attachment, system will not allow me to post all equations as text...)