Interestingly, all of the STO and RCL instructions in program memory goto the same microcode address. Also of interest is these instructions show the clash between “merged” keystrokes and unmerged ones: STO and RCL are merged keycodes (one step for two key presses); but not all of them are merged. (I think they ran out of available codes before they ran out of key sequences and decided to keep what they could.) As a result, you can see the behaviour of both approaches in the same instruction.
STO 1 – STO 8 are merged. “STO {+|-|*|/} n” clearly is too much to be so, and a STO program code (just itself; not STO 1, STO 2, …) exists to be a prefix for the operator and then the memory number.
A similar situation exists for RCL. RCL 1 … RCL 8 are merged. RCL also exists as a program code in its own right. However, whilst storage recall arithmetic did exist on some calculators, it doesn’t with the ’65. Thus the choice of having RCL by itself to get followed by “9” (for RCL, 9) is perhaps a poor decision. RCL 9 is the only unmerged RCL instruction so it might have been better to have a single “RCL 9” program code rather than a single “RCL” program code. Still, most things involve design trade-offs and it is likely that this approach fitted better into the limited microcode address space.
All of the merged STO and RCL instructions (STO 1-8, RCL 1-8) goto 01360. The STO and RCL, by themselves (not merged), goto 01347. That is the same place that [f], [f-1] and [g] goto. And interestingly, also the same place that DSP, GTO, LBL and RTN goto.
No analysis yet but here’s the microcode traces:
65-rcl-8.txt
65-rcl-9.txt
65-sto-8.txt
65-sto-9.txt
65-sto-plus-1.txt
65-prgm-sto-rcl.txt
