SR-52->HP-67 Keycodes efficiency

[Matt Agajanian]

Hi there.

Even as TI’s technology was robust, could they have developed and fully-merged keycodes even as early as the SR-52/56 generation?

Also, by the time the TI-58/58C/59 was introduced, I’m certain TI could’ve implemented a multi-keystroke fully-merged system. Besides, since SR-52 mag cards were incompatable, why didn’t TI use fully-merged keystrokes for the 58/59? I could see, if SR-52 mag cards were compatable, the keycode structure would need to remain identical. But, since there was no backward-compatability, why did TI hold to such a memory-hungry keycode system?

[Dieter]

(12-21-2017 02:59 AM)Matt Agajanian Wrote:  But, since there was no backward-compatability, why did TI hold to such a memory-hungry keycode system?

Memory hungry? If you want to store an instruction like "STO 01" there are two ways to do so:

1. Assign separate opcodes to each and every possible combination of command and parameter. For STO, RCL, SUM and PRD and registers 00-99 this alone means 400 (!) separate opcodes. While a single byte can hold 256. Now think of INV SUM, INV PRD and other commands like OP 00...40. Or GTO to dozens of different labels. Where does that end? Four bytes per opcode? Six?

This is the way the HP67/97 does it. But here there's just 10 registers for storage arithmetics, and not more than 15 labels.

2. Allow multiple byte instructions. This is how it is done in the HP41. Sure TI could have implemented a similar system. The TI59 standard memory configuration of 60 data registers and 480 program steps then would have meant, say, 200 or 250 merged steps – but of course with the same number of bytes as occupied by unmerged steps. It makes no difference whether "STO 01" takes one line or two.

BTW, take a look at the TI57. Here you can see merged steps in a TI calculator of the same era. But with merely 10 labels and just 8 data registers.

Dieter

[Matt Agajanian]

Thank Dieter.

Yes, before I sent the original post, that’s what I thought—since the simpler TI-57 incorporated the merged keystrokes, why couldn’t the same be implemented in the 58/59.

Alluding to an earlier post from (I think PANAMATIK) where several OP Code charts for Woodstock and HP-67/97 OP Codes were shown, I did not realize that even TI’s models were under a 256-bit constraint. Thus, I can now more clearly understand the limitations. Now that you I am aware of these, TI-58/59 programming structures seem more powerful than I originally thought.

Thanks

[Gene]

Marketing might be another reason.

As it was, the TI58/59 had 480 or 960 steps.

Merged, the number would have been **lower** and less of a way to appear > HP.

[Matt Agajanian]

(12-23-2017 08:26 PM)Gene Wrote:  Marketing might be another reason.

As it was, the TI58/59 had 480 or 960 steps.

Merged, the number would have been **lower** and less of a way to appear > HP.

Ah! I see your point. If I understand you correctly, for TI to implement merged codes, more memory would be consumed, thus again limiting the program step/memory register count. Good point!

[Dieter]

(12-23-2017 08:32 PM)Matt Agajanian Wrote:  Ah! I see your point. If I understand you correctly, for TI to implement merged codes, more memory would be consumed, thus again limiting the program step/memory register count. Good point!

If one program step would consume one, two or three bytes the standard TI59 memory allocation (60 registers, 480 lines) would mean 480 bytes and thus only 160 lines in the worst case. Or typically maybe 250, as I wrote in my first post.

I'm not sure if advertizing a program memory of "up to 960 bytes" (and zero registers in the small print ;-)) would have been a good idea in 1977. The typical user might have asked how this translates to a familiar number of program lines, and this number might have been as low as 480 or 320. As far as I know the HP41 was the first calculator where a number of bytes instead of lines was published (max. 2237 bytes, up to ~2000 lines).

All this implies that lines with different byte counts would have been possible, technically. If, on the other hand, each and every step required the same two or three bytes the available program memory indeed would have been down to a fixed maximum of 480 or 320 lines. With not a single data register, that is. ;-)

And so finally we get to a familiar topic again: how many TI steps are equivalent to one HP step. #-) The usual result is a ratio near 1:1,8. So if you set a TI58/59 to 30 data registers (comparable to the HP67/97) and you get 240 or 720 program lines, this is roughly comparable to 130 or 400 HP-steps. Which confirms that HPs two calculators in most cases had more ressources than a TI58 but less than a TI59.

Dieter

[badaze]

(12-23-2017 05:30 PM)Dieter Wrote:  ...
BTW, take a look at the TI57. Here you can see merged steps in a TI calculator of the same era. But with merely 10 labels and just 8 data registers.

Dieter

But with 50 steps, 10 labels may take at most 20% of the whole memory. So I would say 10 labels represent a huge number.
50 merged steps for a TI 57 represent more or less 80 steps for a TI 58/59.

[Gene]

(12-23-2017 09:29 PM)Dieter Wrote:  I'm not sure if advertizing a program memory of "up to 960 bytes" (and zero registers in the small print ;-)) would have been a good idea in 1977. The typical user might have asked how this translates to a familiar number of program lines, and this number might have been as low as 480 or 320.
Dieter

Gene: Hi Dieter. Time to start on the HP 67 games 2 rom? :-)

Perhaps, but then again, HP seemed to be the one who focused on merged codes, effectively **defining** the functionality by the unique byte counts that were possible (well, they extended that on the HP 67 with the P<>S function).

TI on the other hand seemed to relish in the marketing literature by showing 224 steps vs. 100 for the SR-52 compared to the HP 65 and then later 960/480 steps vs. 224 for the TI59/58 compared to the HP 67/97.

At the time, I suspect most users may not have been as aware of the differences as HP users were, in part because we were arguing that 224 is actually closer to XYZ steps on the TI model when in "arguments"

Never underestimate the power and stealth of marketers to confuse the user/buyer.

I believe my previous thought is probably truer than you suspect.

Gene

P.S. If I had a way to assign a usefulness per post statistic to a user, I think you would be near the top. In nearly EVERY single post of yours that I read, I either learn something outright or read something that causes me to stop and think. That's a reason I click on them. :-)

[Matt Agajanian]

Agreed! On numerous occasions, Dieter, your insights have been most educational!

[Dieter]

(12-23-2017 10:14 PM)Gene Wrote:  Gene: Hi Dieter. Time to start on the HP 67 games 2 rom? :-)

Should be possible in January. But maybe you already have one or two programs to start with. ;-)

(12-23-2017 10:14 PM)Gene Wrote:  TI on the other hand seemed to relish in the marketing literature by showing 224 steps vs. 100 for the SR-52 compared to the HP 65 and then later 960/480 steps vs. 224 for the TI59/58 compared to the HP 67/97.
...
Never underestimate the power and stealth of marketers to confuse the user/buyer.

I see this power at work in your sentence with the "960/480 steps". ;-) This value can be found in numerous other sources. Even the overview on Wikipedia mentions "100 memories" and "960 program steps" (at least they get it right in the "Memory" section). But as we all know this 960 or 480 is just the highest possible number of program steps with not a single data register left. With 30 registers (similar to the HP67), the TI58 had 240 steps left. Or about 140 "HP-steps". ;-) The same is true for the TI59's 960 steps. What do you do with a 960-step-program that cannot use a single data register? OK, except "t". ;-)

(12-23-2017 10:14 PM)Gene Wrote:  I believe my previous thought is probably truer than you suspect.

I think we are closer than it seems.

(12-23-2017 10:14 PM)Gene Wrote:  P.S. If I had a way to assign a usefulness per post statistic to a user, I think you would be near the top. (...)

(12-23-2017 10:36 PM)Matt Agajanian Wrote:  Agreed! On numerous occasions, Dieter, your insights have been most educational!

Gene and Matt, thank you very much for your kind words.

Dieter