While 4-bit identifiers are straight forward to use, 5-bit identifiers greatly expand the potential of the computer. Using 10-bits to identify source and destination only leaves us with 6-bits for the rest of the instruction, 5-bits when we take the instruction mode bit into consideration. With three 5-bit pieces, we do not have a stable opcode for the "MOV" portion of the instruction... each hex character is made up of 4-bits.

Device      Binary     Hex
   0         00000       0
   1         00001       1
   2         00010       2
   3         00011       3
   4         00100       4
   5         00101       5
   6         00110       6
   7         00111       7
   8         01000       8
   9         01001       9
  10         01010       A
  11         01011       B
  12         01100       C
  13         01101       D
             . . .
  30         11110      FE
  31         11111      FF

If the highest order bit is the instruction mode (1 for firmware address, 0 for microcode), that means that the first hex digit must be a 7 or less. Any value of 8 or higher will indicate that the remaining 15-bits are an address in the EEPROM bank.

The control logic needs to decode this in parts, and in this case it would be in unwieldy 5-bit chunks.

010000 - MOV
00001 - Source Device
01111 - Destination Device

An alternative to this would be to combine the source with the MOV instruction and make the destination 8-bits (padded  with zeros from 5-bits)

M04, 1E - Move the value from device #4 into device #1E.
MFF, 09 - Move the value from device #FF into device #9

I do not like this, it is not an elegant solution, it wastes instruction bits, and it means numerous duplicate instructions. I think I need to stick to 4-bit identifiers. Fifteen devices (plus the zero register) will limit the number of devices I can use effectively with the MOV instruction, but other instructions may be more flexible..