It’s a friendly enough statement; but what is it doing in the microcode of Woodstock calculators?

It’s actually there – as an executable instruction. You can see it in the microcode that emulators for the HP-21, HP-25, HP-25C, HP-29 and HP-67 calculators use. You can see it in patents for the original calculators. It has an actual bit sequence (001760) and it gets run – but what does it do?

Most of us thought: “nothing”, and that may still be the case, but there is something interesting about where the instruction got placed. I never noticed the significance of its position until I came upon it from the opposite direction.

The first obvious guess is: it’s to protect against running Woodstock microcode on earlier (or later) processors. The “woodstock” instruction would generate an error on other processors.

Unfortunately, that doesn’t make a lot of sense because the earlier (and later?) processors just ignored unrecognised instructions. A (classic cpu) HP-65 added a card reader circuit that added instructions to the processor. The (woodstock) HP-67 does the same but with an enhanced set of instructions. There’s no light on the processor, or alarm that goes off – if the microcode includes an unknown instruction. The processor just assumes something else will handle it – perhaps a card reader, maybe a printer, maybe something else.

My second guess was: it’s like those assemblers for x86 architectures where you include a “.286” pseudo op to turn on features for 80286 processors rather than 8086 processors.

The catch with that one is: it was always a pseudo op; never a real instruction for a CPU. And this instruction gets executed. If it’s a pseudo op it should never appear in the assembled program.

Like, I suspect, many others who wondered about this instruction; I ignored it as it didn’t seem to affect anything. Emulators worked. Real calculators worked. It didn’t seem to do anything. So I moved on to other things.

One of the other things was an upgrade to my HP-25 microcode emulator. Version 1.03 got released today (19 Sep 19) and one of the improvements was to allow pasting in not just a program, but data and state information too. This is like with the HP-67 calculator where it saves the angle mode (DEGrees, RADians or GRaDians), display mode (FIXed, SCIentific or ENGineering), display precision and flag settings. The HP-25 doesn’t have flags, but it does have everything else – and sometimes some programs require the display or angle mode to be set a certain way to run properly. It just made sense to include that with what you can paste in for a HP-25 emulator.

Changing the state in an emulator can be really interesting (if you’re that way inclined) as you poke values into parts of memory, into parts of internal CPU registers and adjust internal flag settings. The power of what you could change is enormous. However, there was one small downside. If I changed the display setting and the calculator was in its WaitLoop, nothing seemed to happen. As far as it knew, it had displayed a value correctly and now it was waiting for a key press or a switch to be slid between PRGM and RUN. Me changing the values didn’t let it know that it should update the display to use them.

The obvious alternate approach is to press emulator keys to do, on a HP-25 for example: “f”, “FIX”, “3” as if you’d pressed those keys yourself. The calculator (emulator) would know something was happening because it’d know that keys had been pressed. It would show the current X value in the updated display format and all would be well. I liked poking bits into the internals but I did want the emulator to use any changed display settings so, in the end I settled on a combination of the two approaches. Rather than pressing “f” “FIX” “3” to change to that display setting, I poke values where they go, and then slide the RUN switch to PRGM and back. That gets me out of the WaitLoop to the PrgmLoop and then back to the WaitLoop via code that shows the current X value using the current (poked in) display settings. It’s a little simpler.

The catch with pressing multiple keys, and with sliding a switch more than once; is you need to give the microcode time to notice and complete the action, before you do the next action. In my case: it needs to get to the PrgmLoop before I slide the switch back. I needed to know when it was waiting for a keypress / switch change in, at least, program mode. Traditionally, this is done by checking if the microcode PC matches one of the addresses in the PrgmLoop. It is messy because each calculator is different so you have to check for different addresses for each one. It’s times like this that you get tempted to patch the microcode to jump to some fixed address never used by the real thing and then back into the loop. You’d check for the fixed address. The purist in me stops me going down that path and, in my case, it might not work anyway. For performance reasons, if I’m not tracing individual instructions, I’ll often run a set of 80 instructions in a single go. Checking at the end of 80 is no guarantee that it didn’t pass through the fixed address at some point during the 80. I’d need to check for every address in the PrgmLoop to know I was in that loop and ready for a keypress / switch slide. It’s still very messy.

Another approach would be to patch the microcode so a special instruction gets included in the loop. That wouldn’t be an instruction a real calculator would run but running it in the emulator would let you know that you’d gotten to the PrgmLoop (and you could add it into the WaitLoop too to check for either spot where the calculator is ready for a keypress).

I was still reluctant to modify the microcode from “the real thing”.

It was at about that point when I remembered always seeing the “hi i’m woodstock” instruction after every function I’d traced for the HP-67 and for the HP-25 (and probably for the HP-29 and HP-21).

It wasn’t in the PrgmLoop. It wasn’t in the WaitLoop. However, it always happened about the time of those loops.

On the HP-25, it only occurs once and it happens to be just two instructions before both of those loops. The instruction immediately after “hi i’m woodstock” is a test which takes you to the PrgmLoop; or to the WaitLoop. It happens to be (coincidently?) in exactly the best possible place to signify “ready for a keypress / switch slide”.

My guess is: HP included it there for automated testing during the development of the microcode. In their testing on mainframes or minicomputers, that was the point where they could feed an automated keypress into the application under test (the calculator). HP made a lot of test equipment so it wouldn’t surprise me if “hi i’m woodstock” got included for this reason. Automated testing must have been a fairly new concept back then; but that wouldn’t rule HP out of designing for it.

The other possible option here is: this’d be an ideal location in the microcode to send a reset signal to key/switch circuitry. It might be mundane like that.

I do think that “hi i’m woodstock” almost begs a handshake and perhaps that’s what does – whether for automated testing during development, or for the connected circuitry.

In my case, I modified the emulation for “hi i’m woodstock” from doing nothing to setting a “ready” flag to true. If I want to send a keypress to the calculator or to slide the PRGM-RUN switch, I set “ready” to false, do the action, and wait for “ready” to be true again before I do anything more. It is a much nicer solution than I’d thought possible but I can’t help thinking that this is because HP already thought of it.

It always seemed strange, if “hi i’m woodstock” was intended to guard against use on the wrong processor, for the instruction not to be the very first one in the microcode (at location 00000). Having it indicate “ready” or do a reset / start the next conversation, fits much better with where it IS located.