As you key in a merged keycode the calculator has to remember which keys led up to this point. After all, pressing the [0] key produces very different results if it was preceded by [f], [g], [h], [STO], [RCL], [STO] [+], and so on. Here’s how it keeps track:
The “state” information (where it is up to) is stored in a combination of the S register bits and the M1[x] nibbles like this:
| keys | s | m1 | notes |
| GTO | 7,10,13 | 0d0 | |
| GTO f | 4,6,10,13 | 0d0 | |
| GTO . | 7,8,10,13 | ff0 | |
| GTO . n | 7,8,10,13 | fn0 | |
| GTO . n n | 7,8,10,13 | nn0 | |
| GTO [0-9,A-E,(i)] | final | ||
| GTO f [A-E] | final | ||
| GTO . n n n | final | ||
| DSP | 13 | 060 | |
| DSP [0-9,(i)] | final | ||
| f | 4,6,13 | 000 | |
| f GSB | 7,13 | 0b0 | |
| f LBL | 7,13 | 0f0 | |
| f others | final | ||
| f GSB [0-9,A-E,(i)] | final | ||
| f LBL [0-9,A-E] | final | ||
| g | 4,6,7,13 | 000 | |
| g GSB f | 6,7,13 | 0a0 | |
| g LBL f | 6,7,13 | 0e0 | |
| g GSB f [A-E] | final | ||
| g LBL f [A-E] | final | ||
| g others | final | ||
| STO | 4,7,13 | 090 | |
| STO – | 4,7,8,13 | 0a0 | |
| STO + | 4,7,8,13 | 0c0 | |
| STO * | 4,7,8,13 | 0e0 | |
| STO / | 4,7,8,13 | 080 | |
| STO [0-9,A-E,(i)] | final | ||
| STO – [0-9,(i)] | final | ||
| STO + [0-9,(i)] | final | ||
| STO * [0-9,(i)] | final | ||
| STO / [0-9,(i)] | final | ||
| RCL | 4,10,13 | 070 | |
| RCL [0-9,A-E,Sum,(i)] | final | ||
| h | 4,6,8,13 | 000 | |
| h SF | 6,8,13 | 080 | |
| h CF | 6,8,13 | 060 | |
| h F? | 6,8,10,13 | 050 | |
| h STI | final | ||
| h RCI | final | ||
| h SF [0-3] | final | ||
| h CF [0-3] | final | ||
| h F? [0-3] | final | ||
| h others | final | ||
| others | final |
When you press the [0] key it needs to check the S register and M1[x] to see what you mean.
There’s more to untangle yet but here’s a trace/listing for prefixes then [0].
It's only fair to share...
