HP Forums

Full Version: Capricorn CPU microcode
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

I started to look more precisely to the Capricorn CPU with the HP patent # 4424563.
With this patent I started to look at the microcode of the CPU, but it appears that the given microcode is not the final one. It can be seen with the LDM R4,=xxyy instruction.
In a real HP85/86 this code jump to xxyy+1 address and with the microcode from the patent this jump to xxyy+3 or +4 (if DRP R4 code before).

Does anyone have more informations about that ?

Thanks in advance.


Edited: 4 Mar 2010, 11:16 a.m.

Interesting. The patent application was submitted at a late enough date that the PLA contents (microcode) should have been long since finalized. I haven't yet studied it in enough detail to confirm your finding, so perhaps you could explain in a bit more detail how the patent microcode gets to +3/+4 rather than +1.

Aside from finding someone who worked on it, the only way I know to determine the exact microcode in a production Capricorn chip would be to decap and photomicrograph the chip, and thereby extract the PLA pattern.

I was having trouble visualizing the flow of the microcode, so I used graphviz to plot a graph of the state machine: http://www.brouhaha.com/~eric/hpcalc/series80/capricorn-ucode-state.pdf

It only has the state numbers (in octal), without any annotations to explain the meanings of the states or transitions.

Here is a link to an excel file with the microcode executed for each opcode:


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.

Thanks for the graph, I found a mistake in the excel file given previously.
After state 37O (31d) it's state 4O (4d), not 8O as I used ...
I'll look at it more precisely.

It's only in the excel file not on the microcode I used, so not a real mistake.

Anyway, I just wired a small hack to the simulation (CLN when WRAM and CDRP==5 for those who might understand ;) ) and it's enough to continue

Edited: 5 Mar 2010, 11:19 a.m.

Anyway, I just wired a small hack to the simulation (CLN when WRAM and CDRP==5 for those who might understand ;) ) and it's enough to continue

Could this 'hack' exist already in the real HP-85, either as a few gates inside the Capricorn processor chip or as external logic?



Yes it could be. It's a simple one only 10 gates or so and all the signals are already in the function block 'COUNTERS' (on patent fig 1)