Working with RTE IV B
I would be so much more confident of the state of the systems I have generated if I could get two 'terminals' talking simultaneously, using Multi-Terminal Mode (MTM) which is the alternative to the more complicated session manager.The interrupt table ties the terminal controller card to the PRMPT program which is the way that MTM issues prompts and interprets commands from terminals. Regardless of the terminal client I use, only the system console terminal is talking. The other does nothing when I connect or characters.
Finally this evening I realized what was wrong. I am embarrassed because it should have been obvious, but since I began by modifying the answer file for the disk image I downloaded from the HP Museum, I was just enhancing what I had. Not much of an excuse.
I defined a number of partitions for the machine - one RT and several BG - which means there was only one partition available to run the prompts and converse with users, regardless of the number of terminals that may have been online. RTE couldn't dispatch the PRMPT program when I fired up the second terminal because it had no partition available. Doh.
I spent an hour generating and completing a new system with two RT partitions, in the hope that I can get it talking to two sessions simultaneously. Once that works, I can back off from the use of MUX as a second device and generate this for twin BACI cards, just as I will have once I fix the defective card.
However, my first attempt at running on the system with twin terminals and two RT partitions still failed to start a second session. Whatever the problem is, it is not just the lack of a second RT partition. Sigh.
Diagnosing bad 12966A BACI card
With my serial card stomping on other I/O activity, it has something wrong with one or more components. One or more of the output drivers is driving a pin on when it should not. It could be a failed output drive, but equally it could be a bad input or internal chip which leads to that output state.
HP did not use tristate components for these shared buses, instead they have a transmission line for each signal pin which runs from the motherboard up to the end of the IO card cage. Every card plugged in has a driver that can drive current into the line when switched to a 1 value, while ignoring the current injected by any other board as long as the driver is at 0.
However, just like a tristate bus, if more than one card drives a 1 signal at the same time, they step on each other. Only one board at a time should be active, capable of driving current on pins, but there is no way for the system to differentiate between a 1 bit sent by the permitted card and a spurious 1 bit injected by a failing card. Thus, I/O is disrupted when the defective serial card steps on signals coming from an active good card.
First step is to build up a map of the 86 pins on the connector from the card to the I/O cage backplane. I could figure out the power supply pins and energize my board on the workbench. That will allow me to look for a hot output driver. If I assume the failure is a pin that is stuck on, I will find the problem.
More likely, the output pin is driven by some combination of the usual signaling sequences on the input pins, where it is incorrectly responding when the board is not selected. It would be a good application of a logic analyzer to watch all the input and output pins on the board, capturing any case where an output is driven spuriously.
One electrical challenge with that is the shared transmission line scheme used on the I/O backplane. When any card in the cage drives a pin with current, I will see it on my card because they are electrically connected. Unless I can put a one-way valve, a diode, in series with each pin, I won't be able to spot when my board is the one driving the current. The shared line will show a signal as any board drive it.
That would require me to do something more complex for debugging. I would put the analyzer probes on the inputs to the driver board, after having statically checked on the workbench to find any stuck on chips. The issue with this is that each driver chip has multiple input signals, which could swell the number of probed signals well beyond the 128 lines available with my logic analyzer.
I could improve the odds that a static test on the workbench will find a bad component, beyond just monitoring output bits for a driven 1 bit. I could also put the scope on the output of the first logic gate that is activated by an incoming signal.
First, I could watch to see if any of those gates are falsely detecting the input signal as on, with no current applied. I can then drive a current on the input pin, on the bench, and see if the logic responds properly, since a failure could potentially be caused by a board failing to respond to a 1 signal when it should.
None of these steps are certain to locate a failed part, nor to give sufficient information to help narrow down the search. Use of the logic analyzer on all the input and output pins to the board would be the most certain, if I could find a way to deal with the challenge of detecting only current when it is driven out of my board and not when it is coming in from the transmission line from another board.
After powering the board on the bench (although only with +5V, not -2V or the +/- 12V rails), I saw mixed and puzzling results on various output pins. All I could measure was voltage, not current I had no sink circuit set up. Some of the output pins were at 3+V others were near zero. I would have expected all of the outputs to sit near zero unless they were driving a 1 bit.
It is possible that I need to add a source of -2V, since that is used to bias down the input signals and without it, they might be interpreting a 1 coming in. That will be my next experiment.
However, concurrently I need to trace out the input and output circuits for a couple of pins, to interpret what voltages I should see with the pin floating free except for a VOM lead. It may be that I won't be able to tell anything from the pins until they are driving a sink.
After reading the spec sheets on the driver chips and the schematic of the board, I see that I need to pull the line down through a 1.5K resistor to -2V such that it will not have a logic 1 level voltage unless sufficient current is flowing through that resistor to make the other end
No comments:
Post a Comment