No luck in identifying if anything is explicitly issuing a RESET (by monitoring any POR related signal on the H2/BASEIO or Executive or Display itself - none of them invert, unless I press the RESET switch myself). But, I did find something interesting....
Monitoring A1G2 P02, the Display is being TOLD to turn off.... (more on this in a moment)
As a result of being TOLD to turn off, via A1G2 P05 the Display commands the SPEAKER to turn on....
What's telling the Display to turn off? Monitoring A1L2 D07, the Executive ROS is telling the Display to turn off.
And the interesting part is: this doesn't happen with the GOOD WORKING Display card (i.e. A1L2 D07 never triggers from the Executive to the Display to turn off).
So.... WHY is the BAD DISPLAY inducing the Executive to turn off the Display? (within 4 instructions)
Well... I monitored A1L2 (Executive) P05, P06, D06... None of them ever invert. I zoomed out on the scope, I zoomed in -- thinking maybe I missed the signal. I don't think I missed it (but I haven't learned enough to setup triggers and such on the scope).
So, what does "CR" mean? My working theory is there is logic omitted in the Executive ROS SLM diagram - another signal could be triggering the B07/D07 (display off and process LED), and internally the Executive ROS could be resetting itself back to 0x000A, as an implicit internal reset). Something besides either an Addr or Bus Error is inducing the Display to go off.
So
@stepleton I'll have to read up more on what you mentioned about Cycle Steal - that's what I'll need to study next. I assume it's something like: the processor COULD be writing to Display memory (0x0200), but the Display needs to read RWS in order to know what to display. In software, this is a deadlock potential - you have a resource being read/write at the same time. So the Display has to "steal" some time to read from the RWS, in order to know what to render? And if that sequence is getting out of sync, maybe the Executive somehow detects this and induces and internal reset? That's all speculation.... Since I don't think the Executive cares much about Cycle Steal, that's up to the Processor. The Processor A1J2 does have a "Cycle Control" box, with "Display Request Pwrd" as an input. But I'm not seeing how the Processor can induce the Executive to turn the display off (I mean, within 4 instructions; seems it would need a direct path).
In the Processor I checked S08, U09, and I removed the S07/S09 Machine Check Jumper -- no signal change, and no runtime change.
So, the next plan then is to monitor B02 and D06 (Stolen Cycle Next and Stolen Cycle) coming out of the Process A1J2, along with the A1G2 D07 (Display Req) coming out of the Display -- to see if their sequence matches how they go with the GOOD card. Maybe the BAD Card is interpreting those outputs differently.
IF that sequence does end up being different between the cards, then -- well, that D02 Printer Clock is one of the inputs into the Cycle Steal Logic box. Maybe just the Character Counter DIP is messed up, causing the Printer Clock signal to go bonkers, which in turn messes up the Cycle Steal Logic, and causes the system to reset itself ?? I wonder if I could test that by somehow fixing the Printer Clock signal to be ~0.1V like it is with the working Display card (in which case, maybe all the output just goes to the first column -- but at least the Alarm would be quiet :D )