The [R/S] key is supposed to allow you to Run and Stop a user entered program. That, by itself, is useful. However, it also allows you to stop a program at a predetermined point and allow data to be keyed in. That is also very useful. When you’ve keyed in (or calculated) the value, you just press [R/S] to resume the program.

But it doesn’t work.

Well, it probably does on the real thing; but it doesn’t on the few microcode emulators available on the internet. You see, the available microcode doesn’t work.

The available microcode for [R/S] looks like this:

01000 goto 01242     ; 000 nop   (start prog code jump table)
...
01042 goto 01101     ; 042 R/S
...
01101	0 -> c[m]
01102	delayed select group 1
01103	c <-> m
01104	c -> stack
01105	goto 01237

Line 01103 is actually the first line for the ENTER function.

It makes no sense at all to have R/S progress into ENTER. If you’ve keyed a number in and hit R/S, you don’t want a second copy going into the Y register in the stack.

Having a delayed instruction before a goto is pretty common given the limits inherent in the processor of the time. But, having it in one path (R/S) and not in another (ENTER) is unlikely. It is possible but everything would have to be in exactly the right locations for that to work. Move one bit (ie to fix or add something during development) and the whole lot would fail.

It’s unlikely.

I am sure that HP fixed it in the real thing and that the microcode in the real thing doesn’t look like that. It’s either a transcription error somewhere or an earlier version of the microcode. I had a pretty good look at what could have been mistyped but I couldn’t see it. My guess is the “earlier version” and that someone said, “oh my, that doesn’t work” and fixed it. Unfortunately I don’t know what they did to make the fix. There is limited space in the real thing. They’ve used up all of the 3K of ROM space. There are some “nops” in the code that might be useable. They might have even had to rewrite or move chunks around to fit in a few extra instructions.

Fundamentally, the [R/S] function is quite simple. It comes down to:

if not running             if s8 = 0
goto make_it_run           goto here+5
; it is running
clear the running flag     0 -> s8
goto the wait loop         1 -> f3     ; update display
                           c <-> m     ; X to C, settings to M
                           goto 00622
make_it_run:
set the running flag       1 -> s8
goto the wait loop         goto 02107

It needs 8 instructions where only 2 will fit. HP will have solved it and their version might even be fancier and longer than my version. What’s more, they will have fitted it into the constraints of the hardware (10 bit instructions, 8 bit jumps, 3K of ROM). It is a very impressive feat.

These days memory is cheap and emulated memory is even cheaper. For my emulator, I was able to tack the additional instructions in address space 06000-06377 – a ROM that doesn’t exist. I also added a microcode instruction that I bet they wished every day that they had – a “gofar address” that will directly jump to any location in any ROM in any group from any location.

Neither the 06000 address space nor the gofar instruction match the real hardware. They simply let me patch the pre-release microcode so that it works. If I ever get a copy of the final version I’ll be delighted to use that instead.

The “gss-hp65” microcode emulator has been updated today (13 Dec 2015) with the patch and basic testing suggests that the [R/S] function is now working in this latest version.

How do you know if it is working in your copy, or another microcode emulator? Press [R/S]. If it has the buggy instructions the screen will blank for ages. It may eventually show a countdown. In the debug screen (for those emulators that have one) you’ll see it stuck in a loop somewhere in the 05000’s.

With the above fix you’ll get more sensible results. I did a (f CL PRGM) “LBL A, 1, +, R/S, GTO A” program and pressed [A]. Every time you press [R/S] it resumes and adds 1 again.

It's only fair to share...