I’ve been ignoring the HP-25 for some time now, years really. Not because it didn’t deserve some attention but because it had plenty.

There are lots of emulators around for the HP-25. It was, rightly, a very popular calculator; and so it had lots and lots of emulators. Another one really wasn’t needed.

To misquote someone very badly, “Ask not what you can do for your country, ask instead what your calculator can do for you.” To my complete surprise, there are a lot of things in the HP-25 that don’t work the same as other calculators. Hidden within is a glimpse into the early development work for the entire series.

How did this happen?

I’d started with one of my HP-29C emulators and plugged in a HP-25 ROM and faceplate. It was a good starting point as many consider the HP-29C to be an upgraded HP-25 and, from a practical perspective, it uses the same scancodes as the HP-25.

Unlike many of my earlier experiences, this combination just came up immediately. “0.00” in the display and all keys working. Fantastic. You’d think, “it works just like the ’29.”

However, it doesn’t.

There are certain things you do when creating a new emulator. Aside from the work to get this far, you need to map out what’s where in memory:

• Where does this one store LastX? (If it has one – it does, in ram[8].)
• Which part of the RAM is the program stored in?
• Where are the STO/RCL registers in RAM?
• Where is the user program counter stored? (Used to display which program step you are on.)

Those sorts of things.

That’s when it started getting interesting. Things didn’t behave the same.

Sure, STO/RCL memories 0-7 were stored sensibly in ram[0..7].

User program memory is 49 steps. That is, normally, seven steps stored per register so 7 registers for that. There were 7 registers for program memory. These are ram[9..15]. Looks pretty normal so far.

But then I entered a program step.

Register Order

With the other programmable calculators in the series (really just the HP-29C and HP-67/97), program steps go into the highest register and work downwards. The first program step goes into the highest register.

I expected (never considered anything other than) program step 01 would go into ram[15] but it didn’t. It went into ram[9]. That was a surprise.

It also shows that HP had tried doing it in the more obvious order before switching to the “top first” approach. That was something I didn’t know. The HP-25 came out in 1975 (with the HP-21) before the HP-67 in 1976 and the HP-29 in 1977. The ’25 was their first go at a programmable on a woodstock CPU.

Byte Order

Next shock: program step 01 didn’t go into nibbles 0 and 1.

With the later calculators, the first program step is stored as a “fully-merged key code” as one of 256 possible values in an 8-bit byte. That is two x 4-bit nibbles. You see a program step as two “digits” in a data register. I said “digits” because for program steps, that includes “numbers” “a”-“f”. The two digits store a hex code (00-ff) not just normal decimal digits (ie 00-99).

On an cleared HP-67 (f CLPRGM), pressing “f LBL A” would result in “000000000000fa”.

On a cleared HP-29C (f PRGM), “g LBL 0” gives “000000000000f0”.

You can see the hex code for the program step in the last two nibbles of the register. It makes some sense: the lowest program step goes into the least significant digits. But it wasn’t always done that way.

On a cleared (power up) HP-25, pressing ENTER as program step 01 gives “f6000000000000”.

The first program step goes into the first two nibbles of the register (nibbles 13 and 12). That’s different. It looks like HP started with doing the more obvious approach of writing the bytes into the registers from left to right. I always thought it would have been easier to read (for those human hybrids that just read hex codes like a native language) if they’d picked left to right. Well here’s proof – they did. It’s likely that a deliberate decision was made, after the HP-25, to switch to least significant nibbles first. There’s likely to be a “lesson learnt” hidden in the HP-25 microcode.

Synthetic Programming

Ok, I might have the title for this section wrong. Synthetics were after my time and, I think, mainly around the HP-41. However, I’m referring to instruction codes in user programs that a user was never intended to key in.

Users discovered special program steps with the HP-67 when they loaded HP-65 magcards into a HP-67. The formats used were different and the HP-65 never wrote checksums so, of course, the process generated an “Error” message; but it also loaded some strange program steps.

The HP-67 also uses one byte for each program step. It has a lot of functionality so 250 of those 256 possible codes are used. Users had a lot of fun finding out what the remaining 6 codes were, and what they did. The fairly famous in these circles Eric Smith, or one of his predecessors, even found key combinations (pressing two buttons at once) that allowed you to directly enter the reserved codes (see the bottom of http://www.brouhaha.com/~eric/hpcalc/hp67/67_hex_table.html. Note: his instructions have a typo. There’s more details in hp67 unused program codes.

Now, whilst they were only discovered with the HP-67, the HP-25 is riddled with them.

I don’t know if they do anything useful (probably not) but there is a lot less functionality in a HP-25 and proportionally more unused codes. Maybe people have already explored this and I just wasn’t paying attention at the time; but there are definitely things to explore here.

There is also an unlabelled function that you can key in, as normal keystrokes, from the keyboard. This is “g ∑”. It doesn’t exist as a label on the key, but you can sure key it in to a program. It even comes up with a matching keycode. Does it do anything? I don’t know, as yet.

So, I think my decision to skip the HP-25 as “already done” was a poor one.

You’re likely to see a HP-25 emulator on this site soon.