Here is a link to an excel file with the microcode executed for each opcode:
http://sites.google.com/site/olivier2smet2/CL.xls
The first page is the PLA decoded with some comments.
The second is about the outputs of the control logic.
The third is the microcode for each opcode (the Byte and Multibyte opcode are grouped). This was done with a python script interpreting the PLA for each opcode.
The fourth is the opcodes in octal, the fifth in hexadecimal.
The comments are mainly in french, sorry.
It was used to make a simulation with tkGate software. Actually it's operational (based on the patent and some other documentations) but this bug is a serious one ...
To see the bug, look at 'Ajustement PC' : adjust the PC (R4-5), code done after the most opcodes (and particularly NOT done after ARP and DRP opcodes see 'ARP R#' witch jump back to state 16d (read a new opcode)).
It can be seen that after 'LDM D,=a' opcode the jump is made to state 7d (Adjust PC)
Adjust PC (state 7d for PCL:R4 and 17d for PCH:R5) is adding N register + 1 to PC.
N is an internal register counting the bytes read from the last 'real' opcode, and in this case the =a loop (state 1, near excel line 148, is done 2 times and stopped due to RPTE input) increments N by 1 at each loop (NCDM column, INN output).
If a DRP R4 opcode was just before the LDM, N was already incremented by one (state 25d excel line 41).
So the total adjustment is 3 or 4.
It is consistent with the tkGate simulation where the PLA is computed with a Verilog script to drive the rest of the CPU (done with the schemes from the patent).
Edited: 5 Mar 2010, 5:38 a.m.