I'm sorry, I made a mistake. The critical edge for E is the *falling* edge.
However, even triggering on the wrong edge, there's some strange looking results in your screen shots, so I thought I'd better set this up and try it myself before you invest too much time with this approach.
The idea was to try to find anything that's not satisfying setup/hold times, or two outputs fighting each other which would result in an undefined TTL level.
The two data buses are Dx and BDx, respectively for the processor and external bus (B probably meaning buffered). U2350 drives BDx-->Dx for bus reads, and U2450 drives Dx-->BDx for bus writes.
In order to verify signal levels, it would be more proper to trigger when actual reads and writes are occuring. Such a trigger would use the enable signal low on the driver (U2350 or U2450), the processor VMA high (Valid Memory Access), and that pattern clocked by the falling edge of E. In short, the trigger definition would be:
nEN = 0 (probe U2350 or U2450)
VMA = 1
E = falling edge
By using the nEN signal on U2350 you can look at bus reads, and nEN on U2450 for writes. If you go through again and look at both Dx and BDx (x=[0..7]), you should get results similar the screen shots below. (These are from a 2445A, which is the same as far as the processor section is concerned).
The signal should always be stable on the falling edge of E, except when looking at BDx on bus reads. This is because Tek is reading from peripherals that are either not installed in the system, or the chip being addressed is not driving all the pins of BDx, leaving those signals to float to any level.
These types of problems are sometimes really hard to track down. The above may not show you anything of interest. It's only a guess as to where to start.
If you can find something that fails consistently, it could help. The scope has a number of automated tests that can be put in a loop. You already know that TEST 04 fails, but you could try the other tests, and perhaps let some of them loop for a while.
Some other ideas:
If you push A/B to put the scope back into operation after the TEST 04 FAIL, can you find anything that doesn't work or has a weird behavior?
If you put the CAL/NO CAL jumper in the NO CAL position, does it still show you the CAL routines in DIAG mode?
If you look at the cal data with EXER 02, do you see a lot of parity errors (indicated by an "X") in locations 01 to 6E? Is there any noticeable pattern to the data being displayed? Like runs of 55 or AA?