I delivered my initial results to [Nigel].  We are in agreement that the PIO added to the 'main' (MCU2) board is the thing that does the interboard communications.

On the MCU board I had observed that PIO Port A was the datasheet calls 'control' mode, which means 'general purpose I/O'.  But PIO Port B is in 'handshake mode', which means it handles strobe and ready in hardware and you just have to service interrupts.  After spending time on the PCU board, I see the same pattern:  Port A is gpio, and port B is handshaking.  So I believe the port B is cross connected between the boards, and this is what does interboard communications.

One curiosity is that in the board shot, I can see a serial jack next to the PIO.  But there are no Z80-SIO or other UART chips on board.  This unit was meant to have an online feature that apparently was never developed.  So, no UART?  Could this be bit-banged serial?  That was a thing back in the day; even the TRS-80 Model I could manage 300 bps.

I also found an NMI handler.  It's so weird that it might be junk code:

0066     ; XXX NMI
0066     nmi_66:
0066 F5        push    af
0067 C5        push    bc
0068 D5        push    de
0069 E5        push    hl
006A 21 82 60  ld      hl,  loc_6081+1  ; XXX wut? middle of an instruction; we're probably in the weeds
006D 22 00 C0  ld      (word_C000), hl  ; XXX wut? we write here, but we immediately over write with the ldir
0070 11 00 C0  ld      de, word_C000    ; XXX initted from 0238; has IM2 vectors and other stuff
0073 01 18 00  ld      bc, 18h
0076 ED B0     ldir
0078 3E 80     ld      a, 80h
007A 32 6D C0  ld      (byte_C06D), a
007D E1        pop     hl
007E D1        pop     de
007F C1        pop     bc
0080 F1        pop     af              ; XXX what, no RETN?
0081 C9        ret

So it's blasting the IM2 vector table with bytes from an instruction stream.  It doesn't even blast the whole table, just most of it.  Definitely serious devastations.  But it does this under disabled interrupts, and moreover the routine ends with a RET, which leaves the interrupts disabled.  (Normally you end this routine with a RETN, which restores the interrupts to whatever state they were in before.)  So the blasted table doesn't cause immediate destruction.  And moreover it's not the whole table that's blasted, just most of it. 

cross referencing it to other locations, notably I find:

02C3     sub_2C3:
02C3 3A 6D C0  ld      a, (byte_C06D)
02C6 B7        or      a
02C7 20 0D     jr      nz, loc_2D6
...
02D6     loc_2D6:
02D6 CD AC 02  call    sub_2AC
02D9 C3 00 01  jp      boot_100

so when set, it does cause a warm boot that reinitializes the system.

There is another reference:

55D6 3A 6D C0  ld      a, (byte_C06D)
55D9 A7        and     a
55DA C0        ret     nz

which just exits a subroutine early if it's set.  Maybe because that routine knows that it's all going downhill from here, so don't bother with whatever you were going to do.

So, it could be that a pushbutton is attached to /NMI and serves as a reset on this board.  I don't know why they would do it this way other than that maybe it permits a more orderly shutdown.  At the same time, the weird code blasting the interrupt vector table is puzzling.

[Nigel] inquired about port 30h, 38h, and 39h.  I have no idea what those are for yet.  All I can say is that they are written very early in the boot process, and the data does not involve the instruction stream at all.

I expressed my belief that I should go back to MCU2 and spend some time with ROM 4, which I hadn't looked at much before other than to verify that it does set the system into IM2.  The rest is unexplored.

[Nigel] has a bit of urgency since his emulator is not running, so he sent me some instruction traces of where it is located.