SR-56 f(n) Curiosity

[Matt Agajanian]

Hi all.

I’m sure on the SR-56, there were sufficient keycodes available that the Stat and Polar/Rectangular functions could have been accessed with just the 2nd prefix key. So, why were the stat and Polar/Rectangular accessed with an extra 2nd f(n) prefix?

Since there are just 100 program steps available, I’d think that the extra f(n) would just compromise the programming capacity.

[Nigel (UK)]

(04-30-2022 09:36 PM)Matt Agajanian Wrote:  Hi all.

I’m sure on the SR-56, there were sufficient keycodes available that the Stat and Polar/Rectangular functions could have been accessed with just the 2nd prefix key. So, why were the stat and Polar/Rectangular accessed with an extra 2nd f(n) prefix?

Since there are just 100 program steps available, I’d think that the extra f(n) would just compromise the programming capacity.

Looking at the key codes in the manual, the 2nd function of a key is coded by adding 5 to the unshifted key code. So LN x is 13; LOG x (2nd LN x) is 18. This won't work with the numbers, which have keycodes from 0 to 9. So 2nd 8 would be keycode 13, which is LN x; 2nd 1 would be 6, which is 6! To allow shifted functions on the numeric keys, the f(n) key was introduced as a separate "shift" keycode that stands apart from the numeric key.

If this is the reason, it clearly isn't the only way of solving the problem. As you say, there are plenty of keycodes available. Fewer than 70 of the 100 possible 2-digit keycodes are actually used, so "2nd 1" could be keycode 50, for example. As things stand, the action of 2nd in program mode is simple - add 5. Perhaps there wasn't enough free ROM space for the code needed to deal with the special cases of shifted numeric keys; perhaps rewriting the code wasn't considered to be worth the effort at the time.

The TI-57 doesn't have this problem - there are no 2nd functions on the numeric keys. The TI-58/59 handle it properly, by breaking the "2nd key = keycode + 5" rule for the numeric keys.

Nigel (UK)

[Gene]

I discuss this during the SR-56 presentation at a previous HHC - video is on youtube.

I wondered if the SR-56 had been a six bit machine? That would have meant 64 instructions.

The key issue Nigel brings up is another possible issue.

F(n) was simply a prefix key. I don't think the "why" was ever discussed in print anywhere.

[Dave Britten]

I think in most cases, we can answer questions starting with "Why did TI..." with "it was easier/cheaper to build that way". Which isn't to say that TI calculators are wildly inferior, just that they often used extra RAM to allow for simpler instruction decoding or ROM routines. For example, the TI-59 is a byte-oriented, BCD machine, and while each program step is stored as a full byte, only instructions with decimal digits are used. That's 100 out of 256 possible instructions that were actually used! There was plenty of room in the instruction table to merge INV with other instructions (beyond the couple where they did, like INV SBR/RTN), but they opted for a simpler-yet-RAM-wasteful design.