IBM 5162 Weird CPU reset

[Alois54]

Hello Everyone,
I'm currently in the process of troubleshooting my IBM PC XT/286 5162 which doesn't boot or beep with the stock ROMs.
When trying with SuperSoft diag BIOS, sometimes I get no beep at all, sometimes it will start beeping completely erratically (like there are random resets every 0.1sec to 1sec) and finally hangs (with a continuous beep if it was beeping while hanging)
After hours of probing with a scope, I found something really interesting using this procedure : https://www.minuszerodegrees.net/5162/diag/IBM 5162 - Ground IO CH RDY.htm

If I ground I/O CH RDY pin on an ISA slot, I still get CPU activity after the startup reset, sometimes for a few seconds, sometimes it never stops.
If I probe the READY signal when I have the CPU in this weird activity state, I can see a square signal coming from the 82284 just because the CPU tries to access and write to RAM (and so will enable SRDY signal through the 82288)

I'm really at a loss here because if I understand the 80286 reset sequence correctly, with I/O CH RDY grounded, it should simply tries to access the ROM, so it would push 0xFFFF0 on its address lines and S0,S1,M/IO,COD/INTA signals should be 1,0,0,1 respectively to signal at the 82288 an I/O read... and so the READY signal should always stay high with the CPU indefinitely waiting with no activity.

I tried with another 80286 (a CG 80286-8 C from a working IBM 5170) with same results.
Does anyone know exactly how should look like a reset sequence of a 80286 ? Because I'm getting activity on the S1 line only 3.3µs after the falling edge of the reset signal and this seems really strange to me...
Thank you! 🙂

 

[modem7]

I'm really at a loss here because if I understand the 80286 reset sequence correctly, with I/O CH RDY grounded, it should simply tries to access the ROM, so it would push 0xFFFF0 on its address lines and S0,S1,M/IO,COD/INTA signals should be 1,0,0,1 respectively to signal at the 82288 an I/O read... and so the READY signal should always stay high with the CPU indefinitely waiting with no activity.

A read of ROM is a memory read, not an I/O read.

And one thing to be aware of, on a good motherboard, is that the state pins will not stay at the 'memory read' state. They later (exactly when?) change to the idle state. That is reflected in the "Not LOW ..." text in the top-left of the diagram at [here], which I created in support of the IBM 5170s 'ground I/O CH RDY' procedure. Measurements made using a logic probe.

You see something similar happening in the 8088. For example, if you were to halt an 8088, you might expect that the 8088's status pins would go to the 'halt' state and stay that way. But they don't. If I halt an 8088, the 8088's status pins show the 'halt' state for only a very short while, then the state changes to 'idle'. Logic analyser capture at [here].

... and so the READY signal should always stay high with the CPU indefinitely waiting with no activity.

Yes.

The procedure that you pointed to was written by me. I do not have an IBM 5162. The procedure is based on the same one for the IBM 5170, and was validated by someone here who does have a 5162.

If I ground I/O CH RDY pin on an ISA slot, I still get CPU activity after the startup reset, sometimes for a few seconds, sometimes it never stops.
If I probe the READY signal when I have the CPU in this weird activity state, I can see a square signal coming from the 82284 just because the CPU tries to access and write to RAM (and so will enable SRDY signal through the 82288)

Something is not right. Reference diagram at [here].

You have already swapped out the 80286, and so you know that the cause was not an 80286 sometimes ignoring /READY.

As an experiment, you could temporarily connect the 82284's /READY pin to +5V, expecting to see what the 'ground I/O CH RDY' procedure indicates that you should see.

It certainly sounds like you need to work backwards, trying to establish why the 82284's /READY pin is fluctuating during the 'ground I/O CH RDY' procedure.

 

[Alois54]

Hi, Thanks modem7 for your answer (and for the great minuszerodegrees.net site )

A read of ROM is a memory read, not an I/O read.

Yup, I found out that after posting my message.

The procedure that you pointed to was written by me. I do not have an IBM 5162. The procedure is based on the same one for the IBM 5170, and was validated by someone here who does have a 5162.

I'm pretty sure your procedure is correct 🙂 because when the CPU finally stops I get the expected state, now I have to find why it doesn't do that immediately on boot.

It certainly sounds like you need to work backwards, trying to establish why the 82284's /READY pin is fluctuating during the 'ground I/O CH RDY' procedure.

I agree. When the CPU is still in this abnormal activity state, I'm getting a square signal on /READY pin coming from a similar signal on /SRDY pin of the 82284.
/SRDY is equal to 0WS AND -RESET AND SYS0 signals.
0WS and -RESET are always high (and this is normal), the square signal comes from SYS0
SYS0 is equal to DWAIT0 NAND +RAS
DWAIT0 is a buffered version of WAIT0 which is always high but I don't really know if this is normal because this signal is generated by U90, a PROM used as a sort of address decoder I think and since I have no dump of this ROM, I can't validate this signal.
+RAS signal is -MEMR NAND -MEMW
-MEMR and -MEMW both have activity coming from the 82288 simply because S0,S1 and M/IO signals have activity from the CPU.
My only theory for now is that U90 should decode a ROM access and should pull low WAIT0 so that /SRDY signal stays high but I don't really see how to test that... 😕

 

[Alois54]

As an experiment, you could temporarily connect the 82284's /READY pin to +5V, expecting to see what the 'ground I/O CH RDY' procedure indicates that you should see.

Do you think forcing +5v won't overload and fry the open collector of the /READY pin of the 82284 ? I'm afraid of lifting the /READY pin of the 82284 to test this...

 

[modem7]

Do you think forcing +5v won't overload and fry the open collector of the /READY pin of the 82284 ?

Good pickup. I had forgotten that it is open-collector. It's something that I would be reluctant to do.

 

[modem7]

My only theory for now is that U90 should decode a ROM access and should pull low WAIT0 so that /SRDY signal stays high but I don't really see how to test that...

The only PDF that I have of the 5162's technical reference is VERY painful to view. It will will be a while before I track back through its circuit diagram to see the circuitry that you see.

As long as that WAIT0 is not open-collector, how about tying it LOW as a test. I do that often for TTL outputs, and so far, I have been lucky. You would then get confirmation that the problem is U90 or earlier.

 

[modem7]

My only theory for now is that U90 should decode a ROM access and should pull low WAIT0 so that /SRDY signal stays high ...

I agree, based on the diagram that I created then put at [here].

For the 'ground I/O CH RDY' procedure, 'WAIT0' and 'DWAIT0' would be LOW (because the reset address is an address of ROM).
That would force 'SYS0' to HIGH, and because the 'ISA 0WS' and '-RESET' signals would be both HIGH, /SRDY would be taken HIGH.

 

[Alois54]

Thanks for your help.
I tested tying DWAIT0 to ground with a 25ohms resistor (pin 18 on U14) and now the CPU behave has expected on reset with the ground I/O CH RDY procedure.
Even better I can see the correct data on the CPU data lines at this state. ("0x65EA" in my case because I'm using Supersoft BIOS on this test)

I think this also would explain the strange beeping/crash behavior with Supersoft, since the WAIT0 signal is not working this would result in very aggressive timings and read errors. 🤔

While accessing 0xFFFF0, resulting in 0x65EA on the data bus, U90 was still outputting a high WAIT0 signal, so I'm pretty confident this PROM is bad. Now finding a working one is going to be real hard since this is not a simple 74LS logic chip 😞

 

[Alois54]

OK, so sourcing a new old stock Bipolar PROM seems to be easy, finding someone to program it is a bit harder BUT finding a dump of a good U90 seems impossible. 😨
Does anyone have a dump or could make a dump of this PROM ? Maybe the dump of U72 in a 5170 might be compatible but I can't find one either... 😥

 

[jafir]

Forgive my ignorance, but is this type of PROM something that can just be "read" with a compatible programmer? Or do they have security features to prevent that?

 

[Alois54]

No protection of any kind, this type of ROM can be read easily, however they do need a special programmer to be programmed because of the very specific voltage&curent required...

 

[modem7]

OK, so sourcing a new old stock Bipolar PROM seems to be easy, finding someone to program it is a bit harder BUT finding a dump of a good U90 seems impossible. 😨
Does anyone have a dump or could make a dump of this PROM ? Maybe the dump of U72 in a 5170 might be compatible but I can't find one either... 😥

The subject of recording ROM's like that has been discussed here previously, many years ago. I seem to remember that it was someone from the MAME project that was particularly interested. If content of some ROM's was posted on these forums, I would have grabbed a copy, but I cannot find any such ROM content on my PC.

 

[Alois54]

Well, I've disoldered U90 on my motherboard and I have some news 😅
I tested it in my TL866II+ using a hand made .LGC file and O2 bit (WAIT0) is working fine. (and I'm starting to think nothing was wrong with this bipolar PROM...)
I'm going to analyse the truth table for this bit to try to understand why it was always high on boot (but at first glance, I think a was missing +REFRESH signal on U90...)
I'm also going to try to dump the content of this ROM and upload it to the forum. (This might take a while, xgpro is really not user friendly when it comes to using a custom ROM )

 

[Alois54]

OK, I have analysed the status of the WAIT0 bit of U90 for every input address and it goes like this :
If +REFRESH is high, WAIT0 will always be high.
If +REFRESH is low, the status of WAIT0 depends on the value present on the address bus and the jumper J10 :
If J10 is low then :
0x0-0x7FFFF WAIT0=H (512K system board memory)
0x80000-0xDFFFF WAIT0=L
0xE0000-0xFFFFF WAIT0=H (System ROM)
0x100000-0xFDFFFF WAIT0=L (I/O channel memory)
0xFE0000-0xFFFFFF WAIT0=H (System ROM)
If J10 is high then :
0x0-0x9FFFF WAIT0=H (640K system board memory)
0xA0000-0xDFFFF WAIT0=L
0xE0000-0xFFFFF WAIT0=H (System ROM)
0x100000-0xFDFFFF WAIT0=L (I/O channel memory)
0xFE0000-0xFFFFFF WAIT0=H (System ROM)

So... I think the ground I/O CH RDY might need a little rework for the 5162. 😅
I'm back at my original problem now

 

[modem7]

I say to myself, why does the ROM receive +REFRESH, a pulse that occurs during each RAM refresh cycle (about once per 15 μs) ?
The only reason that I can think of is to disable CAS generation during RAM refresh cycles (RAM refresh in the 5162 will be of the RAS-only type).

Note that no +REFRESH pulses are expected during the 'ground I/O CH RDY' procedure, because the POST has not executed; the POST being what sets up the triggers for RAM refresh (one pulse, about every 15 μs, out of the timer chip).

If +REFRESH is high, WAIT0 will always be high.

Odd. Surely CPU wait states are irrelevant for RAM refresh.

So... I think the ground I/O CH RDY might need a little rework for the 5162.

It worked for someone else, but that is only one 5162 motherboard. Is it the case that for the 5162, the norm is that certain chips (relevant to the 'ground I/O CH RDY' procedure) on different 5162 motherboards default to different states !!

In the 'ground I/O CH RDY' procedure, is your +REFRESH at a HIGH or LOW? Being an active-high signal, and not looking at the circuit diagram in detail, one would expect a LOW.

 

[modem7]

In the 'ground I/O CH RDY' procedure, is your +REFRESH at a HIGH or LOW? Being an active-high signal, and not looking at the circuit diagram in detail, one would expect a LOW.

If your +REFRESH line is HIGH during the 'ground I/O CH RDY' procedure:
Comparing the 5162 and 5170 circuit diagrams, the circuitry that generates +REFRESH is practically identical.
Shown at [here], including some logic levels that I measured on my 5170 motherboard.

 

[Alois54]

First, thanks modem7 for your input, I really hope we'll be able to fix this 5162

In the 'ground I/O CH RDY' procedure, is your +REFRESH at a HIGH or LOW?

I've checked and my +REFRESH is low on boot, it was just a bad assumption I had before analyzing the complete status of WAIT0 for all addresses in U90.

It worked for someone else, but that is only one 5162 motherboard.

Maybe your procedure is correct and we're still after the root cause of the problem. Though, now that I know the boot process a little better, I don't understand why just grounding I/O CH RDY would stop the CPU starting to execute the ROM code on a 5162 since it would still get a ready signal via /SRDY when accessing the ROM (for 0xFE0000-0xFFFFFF, WAIT0 is high) (on a 5170, the /SRDY signal is just tied high).

I was able to dump U90 using minipro on linux (they added bipolar PROM support a few months ago, what a chance !) but I get something strange, the first 6 bytes are corrupted and different for each dump. I think the dump process starts too quickly after powering the chip or enabling the /OE signal. I have to debug this to have a good dump before uploading it here.

By the way, I'm in the process of buying a second hand high-end rework station to be sure not to damage the board when unsoldering chips

Once I have this rework station and a good dump of U90, I will re-solder U90 on my mainboard and start probing again, hoping to find a new clue.

 

[modem7]

What confuses me periodically is the naming of some signals/pins. For me, a better name for /READY is WAIT (i.e. HIGH tells the CPU to wait).

And I don't like WAIT0. The 'WAIT' at the start instantly convinces my brain that a HIGH will result in a waiting action, whereas the actual action is opposite. Perhaps MEMNOWAIT would have been better.

The fact that a plus or minus is not on some signals sometimes causes confusion. For example, -RES/0WS suggests that the 0WS bit is active high.

 

[modem7]

I agree, based on the diagram that I created then put at [here].

I have updated the diagram.
The bits in red are in relation to the 'ground I/O CH RDY' procedure.

 

[modem7]

(on a 5170, the /SRDY signal is just tied high).

Yes, the 5170 is a simpler affair.