I reviewed the microcode while implementing the MDR workaround I discussed yesterday. I realized that the problem affects currently only 5 instructions, namely:
ADD AH, (SP)
SUB AH, (SP)
CMP AH, (SP)
SHL AH
SHR AL
I took advantage of MDR clearing whenever I manipulated the low or high byte of A register, using the full 16-bit A and the entire 16-bit MDR in the internal microcode, but storing the result in either low or high byte (examples in yesterday’s post). In those cases I needed a pre-zeroed MDR to avoid carry to or borrow from the byte that was not relevant. But it affects only 5 instructions. In other cases there is no borrow or carry from/to the byte that should remain intact (mostly when performing bitwise instructions other than shifts), or I am manipulating and storing the low byte of A (the high byte may receive a carry or borrow but I am not storing it anyway), or I am performing the operation in cycle other than the first one (with MDR already messed with something, so it has to be zeroed anyway). Besides, only the A register has a feature on independent low and high byte manipulation. Other registers are purely 16-bit. Hence, the overall impact of the MDR bug is lower than I initially thought.
So, the question remains open – should I use four 74’163s as described yesterday and keep the MDR clearing feature, or dump it. In the latter case, I can use only four 8-bit three-state output registers (two for the MDR instance connected to the left ALU bus, and two for the right ALU bus). I could use four 74’374s, and there would be no need for additional 74’244s. That’s four chips instead of eight in current design. The trade-off is between one extra cycle in 5 instructions, and four additional chips (increased power consumption, propagation delay, circuit complexity and board density).
I cannot yet make up my mind completely, but today I am leaning towards simplifying the MDR circuitry.