Merged Steps?



#2

Ok, I feel really dumb for asking this, but I am definitely one of the younger generation and never really used RPN programmables. The 49 was where I really cut my teeth. With the talk of the wp34 i keep seeing "merged program steps" and wasn't 100% certain I understood that.

Does "merged steps" just mean encoding the f or g into the byte with the keycode as well? Would things like GTO then just take an extra byte for the number part? What other commands would require more space? Would there ever be a 3 byte command?

For a simple example, if you have a calc with 100 merged steps this means you could do 100 simple steps, or 50 more complicated ones (yeah, not useful, but I am just checking my understanding).

Thanks for clarifying my ignorance! :-)

TW


#3

Yes, "merged steps" means multiple keystrokes only take one program step.

Under the hood, this means designing an instruction set that can handle all possible valid keystroke combinations, and then encoding/decoding keystrokes so that something like "STO IND 04" can be represented in one instruction.

The concept's only valid on keystroke-programmable calculators; for calcs like your 49 that have an actual programming language, it's not an issue.

#4

The HP-12C is a fair example of "merged program steps". Anything that can be a program line in a 12C occupies exactly one byte of program memory, and there are no multi-byte instructions.

I'm not sure whether that's true of the 12c Platinum.


#5

Hmm. I could see that working fine on the 12c due to the limited nature of things. I am guessing the 15 has some multibyte commands then since it had quite a bit more memory.

Dunno what the 12cp does. Since it was done by china and I've looked at the 35s code, I doubt it is pretty!

TW


#6

Quote:
I am guessing the 15 has some multibyte commands then since it had quite a bit more memory.

Yes, the 15C has two byte instructions. See the op-codes decoded: http://www.brouhaha.com/~eric/hpcalc/hp15c/tennant83.html.


- Pauli


#7

Are you aware of the increase the registers in the 15C effort of a few years ago.

It would be wonderful if the non-existent limited edition took advantage of this :-)


- Pauli


#8

Quote:
It would be wonderful if the non-existent limited edition took advantage of this :-)

Yes, it would, but apparently it did not:
Specifications
Memory
Memory registers
65

#9

but if it is using a simulator to run the original 15c rom image, then all one needs to do is get a copy of the firmware, patch it as documented elsewhere, and the extra memory will be there.



of course, this would require HP to make available the firmware, which they are only likely to do if a bug is found, necessitating making a replacement available...


#10

Now that speed is not a problem anymore, double memory should be the next goal. It this can be achieved with a simple firmware patch, so much the better. I'd like the 15C to be able to solve at least a 3x3 complex linear system. It does, but then programs are limited to about 150 steps and 11 memory registers (R0 through R9 plus I) when complex mode is set. Not so bad, but it could be better.

Who said "65 registers is all you'll ever need"? :-)

#11

Tim,

Please see the top paragraph here. BTW, we are very pleased with the WP 34S taken as reference by you :-)

Walter

#12

A calculator with non-merged steps pays one step of programming memory for each key stroke. The very earliest programmables are in this category as is the 30B.

Fully merged means that every possible instruction takes a single step. e.g. the 34C, 11C, 16C.

Then there are partially merged where some commands are merged even though they are multiple keystrokes and some aren't. The 65 and 15c fall into the category.


The 41 series kind of mixed things up by having properly variable length instructions -- many commands are one byte, those with an argument are two and ones with text arguments or text itself are longer. Talking about merged steps here starts becoming meaningless. The 42S must have extended this scheme to fit all its functions in.


The 34S is strictly partially merged. Although, for most intents and purposes, fully merged is more appropriate. The only instructions which aren't a single step are those that take an alpha argument. i.e. alpha labels and commands that use alpha labels. All other commands including those that reference numeric and hot key labels are a single step. This is regardless of the number or type of key strokes required to access them and regardless of the argument or if indirection is being used. I managed this by increasing the op-code size to sixteen bits: we've 26489 legal op-codes currently and 504 distinct commands.

- Pauli


#13

Yeah, 16 bits would definitely give the needed space. :-)

I was wondering how so much was getting put in a "merged" step thinking that meant 8.

TW


#14

We're close to having used half of the sixteen bits and it wouldn't be hard to envisage needing a lot more on a device with extra RAM.

Right from the start I decided that the op-codes would have to be larger than eight bits and sixteen is the next natural size. We've got more distinct functions than will fit in a byte and I thought this would be the case well before implementing many of them. So either I'd need a system of command prefixes and more code in the instruction decode state machine or a longer word size.

I'm surprised you didn't look at the sources to answer your step related questions ;-)


- Pauli


#15

Why bother when I can just ask? ;-)

Also, I tend to try avoiding looking at sources if possible to anything remotely close to a calculator. Saves the potential of ever being influenced by something I see and potential legal issues if someone ever claims something was copied.

TW


#16

Quote:
Also, I tend to try avoiding looking at sources if possible to anything remotely close to a calculator. Saves the potential of ever being influenced by something I see and potential legal issues if someone ever claims something was copied.

Fair enough. The lawyers rule as usual :-(


I can't think of anything in the 34S you would want or need to copy -- you've got the hardware support and power management, you've got a trustworthy maths library. The keyboard decode and instruction execution aren't anything special. Our floating point format is more compact but part of the IEEE standard. We do some clever things with function pointers to save space (128Kb even aligned instruction addresses fit into 16 bits :-) but again nothing a competent embedded software guy wouldn't be able to do. And everything is open source and meant to be read.

Still I do understand where you're coming from.


- Pauli

#17

The 32s/ii is a great example of a fully merged programmable calculator. It puts all functions into one step taking 1.5 bytes and includes small integers (0 thru 254) in that as well. Furthermore it stores all other numbers in packed format so that they take a fixed amount of space and appear as one program step too. This means that the number 100 takes 1.5 bytes and that the number 1000 takes 9.5 bytes, and the number 1.23456789012E123 also takes 9.5 bytes. While this might seem like a waste for numbers like 1000, in practice this calculator is extremely efficient with program storage and extremely easy to program.


#18

This would put the 32s/ii into the partially merged category wouldn't it? Likewise, the equations/prompts in programs are a single step but multiple "base units".

Still, one of my favourite calculators BTW.


- Pauli


#19

Compacting numbers and strings is on our todo list for the successor of the 34S.


#20

"our todo list for the successor of the 34S"

it gets better?


#21

If we don't run out of ideas, it will! :-)

#22

Quote:
This would put the 32s/ii into the partially merged category wouldn't it? Likewise, the equations/prompts in programs are a single step but multiple "base units".

It could be that I'm not understanding your comment correctly but.....

I don't think that "fully merged" was ever meant to include arbitrary length string data like equations and alpha prompts, how could it unless string data were simple stored outside of the code stream and be pointed to by the code. Non-base 10 numbers work the same as base 10 numbers on the 32s/ii taking up 9.5 bytes each. You could argue that it's not fully merged becasue numbers are 9.5 vs 1.5 for everything else, but I'd extend the meaning to "fully merged" to allow for this.

I can't think of any calculator that makes better use of memory.

#23

Tim:

Having cut my 'programmable calculator' teeth on an HP65, merged keystrokes were a welcome feature.

On the HP65, GTO 00 required two (of the precious 100) program steps.

STO and RCL were merged.

Also of course, 'in those days' of numeric LED displays, the keystrokes were displayed in numeric format. Even though it's been over 35 years, those keycodes are still burned in my memory (3301 is STO 1, 41 is ENTER, 84 is R/S,... etc...).

TomC


#24

Quote:
Also of course, 'in those days' of numeric LED displays, the keystrokes were displayed in numeric format. Even though it's been over 35 years, those keycodes are still burned in my memory (3301 is STO 1, 41 is ENTER, 84 is R/S,... etc...).

Yeah, and the key codes made sense, representing the row and column number of the key. To my horror, on the 9810, the key codes are essentially random. And no, nothing's merged.


#25

Quote:
To my horror, on the 9810, the key codes are essentially random. And no, nothing's merged.

Yeah it's seemingly random and it's in octal so only the digits 0 thru 7 seem to make any sense at all. OTOH if you have the Printer Alpha ROM you can read the mnemonics which makes programming much easier. The blindingly fast speed of this beast helps compensate for the lack of merging of keystrokes.


#26

The HP9810 keycodes make a certain amount of sense -- to the machine, but not to the user.

They are 6 bit numbers, hence 2 octal digits. They are the keycodes sent by the keyboard, and the codes stored in the logically 6-bit wide program memory (this memory is physcially 3 bits wide, consisting of 3 1103 DRAM chips, each keyciode occupies 2 consecutive loctions in the physical DRAM, odd-numbered bits in one location, even numbered bits in another. No I've not just been reading the current Datafile...)

You can work out the keycodes from the keyboard schematic diagram of course, but I will agree a Printer Alpha ROM is very handy...

#27

I think that the concept of merged program steps really "comes into its own" in fixed-number-of-steps key-stroke programmable calculators. I also wish to differentiate from RPN programmable and key-stroke programmable (i will explain later).

Being a slightly younger member of the forum, my first programmable calculator was the 28C, i.e. RPL like your 49. However, later I obtained the 20S on which I learnt key stroke programming. It is an algebraic, but I think the same concept of key-stroke programming holds for RPN calculators with key-stroke programming too.

A key-stroke programmable just records the actual key strokes and plays the back as if the keys were being pressed by the user. So unmerged step programming would result in e.g. shift-asin to be 2 program steps for one function. Some of the first models had some merging e.g. "STO 1" & "RCL 1". Now the 20S has 99 programming steps, irrespective of number of keystrokes per step. So being fully merged, you basically have one program step for a function such that things like "Lshift-hyp-sin" are three steps merged into 1 line, allowing the user much more efficient use of space (numbers take 1 step per digit, therefore it's more efficient to load constants for a program into memory registers - e.g. the 20s does not share prog & register memory).

Now, the 32s was mentioned, this has RPN programming. The concept of "merged steps" becomes mory fuzzy. Again a single function per line, but now the function name or symbol is diplayed e.g. 10x or SINH. However, the 32s counts bytes, all functions are defined and use 1.5 bytes, as do numbers from 0 to 99. Now, to have a number say 100 in the program costs 9.5 bytes, so it is "cheaper" to do e.g.:
...
A02 10
A03 x2
...
this "unmerges" steps but only uses 3 bytes compared to 9.5!

As mentioned, the 32s diplayes the function name or symbol, key-stroke programmables display all the key-codes of the keys used to access the function, in the one merged line. e.g. this pic on wikipedia: HP20s.jpg displays the keycodes for Rshift-LBL-A. Do these point to a reserved function thus using a fixed number of bytes? Or is there enough memory for the max. number of keycodes per line * max number of available lines? I don't know.

The 35s of course adds even more complexity to it's programming, allowing whole formulas to be put on one line - but this is not merged program steps, it just eats memory. Of course, where lines refer to a function accessed using multiple keystrokes, it is a merged step.

Anyway, a long post revealing my personal observations made by playing around on various programmables.

-Bart


#28

Some of the early TI programmables were really really bad at using memory locations for program steps.

INV SIN took two bytes or program steps.

The 30b does something similar.

Essentially (to me) it is as if a non-merged step calculator program is recording and playing back a macro instead of encoding the actual instruction to be executed.

Pressing g GTO 09 on the 12c requires pressing 4 keystrokes but is encoded as one byte and takes one step.

On the very early SR 52, GTO 174 would take 4 steps of the available 224, which made it very tough to program.

#29

Merged steps were introduced in the HP-25, IIRC. Around November 1975, HP published a 2-page ad in Popular Electronics magazine (that's the one I had, perhaps there were other similar in other magazines) in which the HP-25 was introduced. The HP-25 was shown as a new programmable, with the HP-65 and HP-55 behind it in the main photo.

The HP 25 has only 49 program steps, but introduced what was then called "key phrases", meaning something similar to the "merged steps" of our time. As the possible commands were less than 256, each operation used just one byte, but this was not the main concern. Nobody was counting bytes, but we were surely counting the very scarce steps (or program lines).

I never had a 65 or 55, so this is not from direct experience, but I understand that a command like "GTO 33", "FIX 9" or "STO + 5" needed more than one program line (or step) on those models. In the HP 25, such operations take just one program step each.

The display showed the program line number on the left side and up to three keycodes (row and column, except for digits). For instance, if program step # 18 contains "GTO 10", the diaplay will show "18 13 10".

It's interesting to see how the available 256 opcodes were assigned to the possible operations on the HP-25.

We had:

10 digits
10 FIX
10 SCI
10 ENG
08 conditionals
50 GO TO (GTO 00 was a special case)
06 trigs
02 >Rect & >Polar
01 Pi
04 logs
02 square and square root
01 power
02 1/x and %
02 INT and FRAC
01 ABS
03 Sigma +,- and clear sums
02 Mean and Sdev
04 Basic Math
08 RCL
08 STO
32 STO arithmetic
03 Programming (STOP, PAUSE and NOP)
07 Stack & registers (Enter, x<>y, Roll Down, CLx, CHS, EEX, LASTx)
02 Clear Stack and Clear Regs
01 Decimal point
02 HMS and HR
03 Angular modes (DEG, RAD, GRAD)

194 in total.

Such an arrangement leaves some opcode space free, which was put to use on the HP-29, but with many differences. For instance, having more registers and 98 program steps would not permit keeping the same scheme. Label addressing (instead of step number addressing) and secondary registers were some of the measures taken to keep opcode space. On the HP 67, the usage of register bank switching via the "P<>S" operation, and the separation of display mode and number-of-digits choice also were measures to keep opcode space (DSP 0-9 and FIX-SCI-END consumed only 13 opcodes, instead of the 30 needed before).

Disclaimer: These data are just from my memory as I'm writing this answer, and are believed to be true; but I'm not doing research to fully support them, so there may be some inaccuracies. Detailed and precise information about opcodes in those old models are to be found in Eric Smith's works and also in articles in his web site.

[/pre]


#30

In that same month, the November 1975 HP Journal had a nice Woodstock article, including a discussion of HP25 programming with merged keystrokes and "key phrases":


#31

Thank you!

#32

Thanks for the article Jake, it's very interesting.

#33

Funny how one's perspective changes. When discussing merged program steps I now instantly gravitate to the memory efficiencies discussed above. But when I started out with the HP-25 it only meant a nice improvement in the LED-based user interface, particularly to someone just learning programming.

Also, I'd like to take this opportunity to note that "Merged Steps" would have made an awesome name for a 80's dance band.

Bob


Possibly Related Threads...
Thread Author Replies Views Last Post
  Maximum number of program steps in HP-42S, 33S, and 35S? Walter B 3 235 12-18-2012, 03:44 PM
Last Post: Eric Smith
  Merged prefixes on the 65 Matt Agajanian 3 103 03-12-2012, 12:49 AM
Last Post: Matt Agajanian
  HP-12C erase program steps x34 7 305 02-13-2011, 03:52 PM
Last Post: Bart (UK)
  Re: HP-25 fails to store programming steps Alberto Fenini 0 83 02-02-2009, 04:35 AM
Last Post: Alberto Fenini
  Re: HP-25 fails to store programming steps Mike Morrow 1 123 01-28-2009, 04:24 PM
Last Post: Michael de Estrada
  HP-25 fails to store programming steps Alberto Fenini 10 361 01-27-2009, 07:48 PM
Last Post: Randy
  HP-25C Forgets steps in memory John Garza 0 60 01-24-2007, 06:08 AM
Last Post: John Garza
  Ok. Have NoVRAM - what are first steps? Gene 7 237 09-21-2004, 11:47 PM
Last Post: Gene
  Re: Whoops! 10 Steps hugh 0 62 11-26-2003, 04:26 AM
Last Post: hugh

Forum Jump: