Don't know if I'm going to have time to do a video for this, so will try it the old fashioned way...

Progress:

• Added U95 XOR gate to allow inverted branch conditions.  MIR11 (bit 11 of the Micro Instruction Register/Microcode instruction)  determines whether the condition is inverted or not.  This necessitated another minor change.  The /DRR (Data Ready Reset) line to the UART is asserted when the character is read from the UART.  This requires us to know whether an apparent reference to the UART (register 3 on the B Bus) is an ALU operation and not a branch.  Since an ALU operation may assert MIR11, there are two possible cases for an ALU operation: branch condition = 0000/MIR11=0 & branch condition = 0111/MIR11=1.  Fortunately, I chose to use a comparator (74LS85/U88) to generate the signal, so all that was necessary was to change the B1, B2, B3 inputs to MIR11 instead of ground.  This mod, of course, is just an optimization but it cleaned up the microcode nicely I think.

• Updated the microcode to use the new inverted branch conditions.  This eliminated over 20 microinstructions.  The most common case was branch-if-non-zero <target> replacing branch-if-zero .+1/branch <target>. 
• Added some wire wrap pins to the board for the Micro Instruction Address to make hooking up the logic analyzer easier. 

These signals are not carried out to the bus, so required the use of grabbers to access.  With the pins, the leads can connect directly.  The pins are mounted upside down so they stick up from the top of the board.

• Added the Moving Inversion Memory Test to the main microcode.  If you hold the EXAMINE switch when pressing RESET, it will run the test continuously.  Press RESET to get out of test mode.

The Moving Inversions Memory test does occasionally fail, but it's not a memory problem.  It always fails on the reverse test when it is decrementing the memory address.   Example failure: MemAddr = 8FF, expecting a pattern of E00 but seeing a pattern of C00.  Memory locations 0-7FF contain E00 while locations 800-FFF contain C00.  This appears to be a carry propagation time issue with the ALU.  Assume MemAddr was at 800 and was decremented, but we latched the output before the high 4 bits settled.  Then, instead of 7FF we have 8FF.  Have not been able to confirm this with the Logic Analyzer because it is so infrequent, but changing the decrement instruction (MAR <- --MAR) to 3 instructions (MAR <- ~MAR/MAR <- ++MAR/MAR <- ~MAR) eliminates the problem.  Looking at the '181 data sheet, a difference operation does take slightly longer than a sum operation (on the order of 1-2nsec), so it appears that it is running right on the edge.  Which is odd, because I calculated the worst-case delay for a microinstruction as something like 88 nsec, which is well within the 100nsec cycle time.  Either I calculated wrong somewhere or the chips I'm using didn't read the data sheet...

Anyway, a couple of solutions come to mind:

1. slow down the clock.  Substituting an 8 MHz oscillator for the current 10 MHz one would add 25 nsec to the cycle time, which should be more than adequate.
2. add a 74F182 carry lookahead generator and leave the clock alone.  This should gain, I dunno, maybe 10 nsec for ALU operations which would bring it back in line.

Since I have some '182 chips, I'm going to try solution #2.  The only problem is that the ALU board is full.  But there are some individual pads down by the bus lines (you can see in the lower left in the picture above) where it can be put - they're the pads that the power input connector is soldered to on the microcontroller board -  just won't have the niceness of 3 holes-per-pad...  I think once this chip is added, the hardware will be done.