The last log 20. Automated upload of overlays into program memory brings a new instruction: OVL (for "OVerLay") that puts the core in "upload" mode and waits for new instructions to be written in the instruction SRAM. OVL is a special case of the CALL instruction, the degenerate CALL PC which acts like a Jump.

As a side effect, OVL FFh can also become the general version of INV with the added bonus of halting the core and wait for user intervention. For this to be viable, CALL must exchange the opcode value with MOV. Easy.

In the case of INV=FFFFh as a side-effect of OVL, the effect is :PC will be loaded with FFh, core will wait for one instruction followed by one CRC. Unless CRC is good, the core will get stuck or simply reboot hard.

But there is another issue, explained in 18. Constant tables in program space : we need a special instruction to read a byte from the instruction space. The instruction coding space is saturated so another trick is necessary.

I have decided to shrink the IO addressing space to recover one bit. That bit will then select between IN or OUT. There will be "only" 256 registers but it's already "a lot".

This makes room for the desired LDC opcodes: LDCH and LDCL each access 256 bytes. The difference is again with the R/Imm8 flag, which is not used because Imm8 is useless in this case (contrary to IN and OUT).

LDCH/LDCL can now have the required two register operands, for the address and the destination. It looks like a MOV with 2 cycles instead of one. The SRC operand is routed to the Instruction Memory's address bus. The PC and the destination register's address need to be latched to preserve the program's state. Sequencing gets a bit trickier but it's a necessary kludge...

I've updated the instruction format diagram :

I must update the whole software now...