I’ve typed in the partial HP-65 source code from U.S. patent 4,099,246. It’s only the first half of the code, unfortunately, so it won’t really do much good in CASMSIM until I can dump the remainder out of the real calculator. The file (hp65.asm) is in the Subversion repository in case anyone is interested.

Dumping the ROMs from the first- and second-generation HP calculators is difficult. They don’t have any self-test like the third- and most of the fourth-generation models, so it’s basically not possible to just clip probes onto the clock, instruction and data lines and passively capture all of the ROM data. You could clip on and try to put the calculator through its paces, and probably capture a lot of the ROM that way, but not all of it. It’s analagous to the code test coverage problem.

In particular, all branch instructions are conditional on the carry bit, though most instructions clear the carry so many of the branches are really unconditional. And some instructions that do potentially set the carry are used in circumstances in which the register data is within known ranges so that a carry will never actually be produced. Thus there are code sequences that end in a branch, but you can’t easily tell whether the branch might fall through under some conditions you haven’t encountered.

It’s probably worthwhile to try to capture as much of the ROM as practical in that manner anyhow, then get the rest by one of several ways:

1. Decap the chips and read the ROM optically. This is how Peter Monta read the HP-35 ROMs. But most of the calculators do NOT use metal-can ROMs, so the process is somewhat more destructive. I wouldn’t want to do this on any of the relatively rare/expensive models.
2. Disconnect the instruction address line between the processor and the ROMs, so I can inject addresses. This is probably the easiest method. Requires cutting a trace on the PCB, but that can be bridged afterward.
3. Start with a list of addresses that couldn’t be dumped using the manual technique, and a suitably programmed microcontroller. Have the microcontroller watch for an address of the form (target’ - 1), where target’ is the target address with one bit flipped. When the microcontroller sees that, on the next instruction cycle it will overdrive the address bit for just the few microseconds needed for the ROM to see the desired value. Overdriving logic signals is normally bad, but when done in a carefully controlled way, there is no risk of damage. The CPU has weak PMOS drivers, and overdriving them with a modern CMOS buffer for a few microseconds will override the value without raising the temperature of the buffer in the CPU significantly. This technique has actually been used in some in-circuit-emulators.

I should instrument CASMSIM for code coverage, to see what percentage of the ROMs I’ve already got can be easily gotten by exercising the calculator. It might be a fun challenge to try to find a minimal sequence of key operations for the HP-35 that executes every instruction (767 out of the 768 possible, one ROM word is unused).