The ROM has 13 address bits: 8 from the opcode, an extra one that is clear for normal opcodes and set for internal subroutines, and 4 bits for the microcode instruction counter.

However some of the address bits are ignored, for example anything that matches the bit pattern 00xxx0xx is some kind of ALU operation, either between two registers, or a register and memory. The 3 bits in the middle select the operation, the low bit the operand size (byte or word), and the second one the direction (which operand is in memory, if any - with two register operands both encodings can be used).

All of this extra information is decoded by random logic. The microcode for this class of opcodes looks like this (in one representation anyway, not necessarily the most easy to understand but based on the patent):

    M     -> tmpa      1   XI    tmpa
    R     -> tmpb      4   none  WB,NX                     
    SIGMA -> M         4   none  RNI      F                
                       6   W     DD,P0                     

On the left are the register moves: M is the first/destination operand, and R the second one. SIGMA (Σ in the patent) is the output from the ALU.

The first line of code on the right sets up the ALU ("type 1 instruction" XI: select ALU operation from opcode bits; first operand in tmpa, second one is always tmpb). The next one prepares to write back the result and decode the next instruction. If the result goes to a register, the third line will be the last one executed ("type 4", RNI: run next instruction; F: update flag register). If it goes to memory, the store happens on the fourth line ("type 6", write, default data segment, no auto-increment).

You can find more information in the linked patent (US4449184) and blog post (https://www.reenigne.org/blog/8086-microcode-disassembled)

Yes. The logic is (slightly simplified): if the first cycle of an instruction then load opcode directly into the microcode address else if short jump then update 4 low bits of the microcode address else if long jump or subroutine call then load microcode address from translation ROM else if subroutine return then load microcode address from pushed address else increment the microcode address to the next instruction.

(This is implemented in hardware with a multiplexer, not as sequential if-then-else instructions.)

There's no decoding logic between the opcode in the instruction register and the microcode address. So yes, the opcode bits are the index into the microcode ROM.

rep_lodsb covered a lot of the instruction handling in the sibling comment.

I hope to write a part 2 before too long.