Have you checked pin 1 of the LS157 chips for proper activity? That is what selects which input signal goes to the output of the chip.
I masked off all the other pins around PIN 1 of each of the 74157 chip. The results were consistent on both the "BAD" and GOOD Display card. Which is:
IC1 and IC2 were mostly 5V, but had sporadic brief pull down to 0V. I didn't have an extra hand to image while holding the probe, but essentially like this:
IC1 = 1582601 / 767396 ==> 74157 (DATA SEL/MUX)
IC2 = 1582601 / 767396 ==> 74157 (DATA SEL/MUX)
IC10 and IC11, as far as I could tell, stayed at 0V always.
IC10= 1582601 / 767396 ==> 74157 (DATA SEL/MUX) flat 0V in STEP and RUN
IC11= 1582601 / 767396 ==> 74157 (DATA SEL/MUX) flat 0V in STEP and RUN
Assuming that's all OK, it's a bit of a puzzle. Just for fun, could you measure the resistance to ground on the 7492B's pin 6 and compare it with some of the other signal input pins to that chip, pins 1-5, 7, and 9?
(assume meant 74298?)
74298 pin resistance comparison on IBM 5110 Display Card (pin 8 is ground in this chip, but I kept the probe on the A1 connector pins D08 GND just as a more stable point to latch onto).
Code:
"BAD" // "GOOD"
1-8 ==> 20.5 Mohm // OL
2-8 ==> 22 Mohm // OL
3-8 ==> 1.290 Kohm // 1.230 Kohm
4-8 ==> 1.290 Kohm // 1.240 Kohm
5-8 ==> OL // OL
6-8 ==> 0.735 Mohm // OL
7-8 ==> 1.290 Kohm // 1.240 Kohm
8-8 gnd
9-8 ==> 1.290 Kohm // 1.240 Kohm
10-8 ==> 30 Mohm // 23 Mohm
11-8 ==> OL // OL
12-8 ==> OL // OL
13-8 ==> OL // OL
14-8 ==> OL // OL
15-8 ==> OL // OL
16-8 ==> 0.566 Kohm // 0.459 Kohm
20+ Mohm is essentially the same as OL?
pin 6 is an obvious outlier here. But it's not obvious how this difference translates to the issue we're seeing.
Recap - that issue is, the BAD display is repeating its content every 8th column (across each row). I'm still trying to rationalize how that's happening. Assuming the RWS content is correct, the Display is showing content that contradicts the 0x200 - 0x600 RWS region it should be latched to.
So... if I assume the COL/ROW counters are working ok... Say at the top left, COL 0, ROW 0. That corresponds to some address:
0x200, 0x201, 0x202, 0x203, 0x204, 0x205, 0x206, 0x207 ... (first 8 chars)
0x208, 0x209, 0x20A, 0x20B, 0x20C, 0x20D, 0x20E, 0x20F ... (next 8 chars)
As
@stepleton mentioned earlier, from this appears the "4th bit" is stuck "on". So where the Display think it is drawing address 0x200, it is querying RWS 0x208 and drawing that content instead. When the Display gets to drawing 0x208, it ends up querying the correct RWS 0x208 address (again).
100000
0000
100000
0001
100000
0010
100000
0011
100000
0100
100000
0101
100000
0110
100000
0111
1000001000 (next 8 chars)
....
BusOut has a PARITY bit line also. I assume because of this "stuck bit" the Display is saying the BusOut content doesn't jive with the Parity value, and induces the RED InProgress light (which I thought would cause a RESET or freeze/system halt, but instead just seems to be corrupting part of the Display - maybe just the Display is resetting and the CRT content appears partial {in RUN mode}, but the system at a whole seems to be completing the ROS checks and Language ROS startup).
So..... Bus Out could be used by H2 (BaseIO) to tell the Display which address to query? (but this is 0-255, so it's some offset from some base address - I don't quite understand the Device Address X vs Y pins. to speculate:
0x200 00 (first 4 rows of 256)
0x300 01 (second 4 rows of 256)
0x400 10 (third 4 rows of 256)
0x500 11 (fourth 4 rows of 256) (0x5FF end of display buffer)
BO DA.X ?
As this P11, pin 6 of 74298 is a "4th index" (BO-3), maybe it is the cause of this issue we're seeing?
(and did blast most of a full can of compressed air - same result though)