HP97 The journey begins

[teenix]

Well, the worms are definitely out of the can. As I mentioned it will be a step or two forward and one or more backward and that seems to be the case. I got so far and realized I had not accounted for the many functions associated with some keys. This meant I had to rip out a lot of the code I had done already and start again.

For example, looking at the [1] key, it obviously enters 1 into the calculator, plus there are the shifted f and g functions (INT) and (FRAC). This key and the other number keys actually have about 20 functions attached to each, such as STO 1 STO.1, STO+1, GSB 1, JUMP A1, FIX 1 etc etc. The code I wrote didn't account for this yet, but I thought it would not be a problem - not so. Plus things like, STO.1 is legitimate, but STO. Enter is not, so invalid key combinations have to be detected also. In this case STO. is eliminated, and just the Enter is used.

HP calculator code is a bit of a head scratcher. In a lot of cases you can't just pull out code and insert it into another spot. Doing so can upset the way the code actually works. You have to be careful what you modify, and it takes some thought. Hence having to back track.

The positive side is I get more practice at putting it together, and one of the aims is to make the code compact so it fits in the available ROMs. The HP engineers did this to the nth degree, and it is difficult to follow what is going on sometimes. To save ROM space, there is a lot of reused code where one routine calls a part of another, that in turn may call a part of another, etc. so, if you move some code this can all break. Even just inserting an extra code line can upset a bunch of jump statements because the target addresses have moved. Although I will write a lot of the code my way, it is not worthwhile reinventing the wheel for writing functions like SIN, Y to X, etc. The only other way is to pick apart known code and try to figure it out. This is time consuming obviously because as mentioned, the code is not in defined blocks, it is a hotch-potch maze with code tentacles all over the place.

Anyway, I'm making progress, but it will take a while. Function decoding, printing, running programs, error handling etc etc.

I also decided to implement every programmable step for the 95C as listed in the user manual, which means there are more than 256. This is a problem because the other programmable models of this era only used up to 8 bits to define a step. (The HP-65 was different - 6 bits) In the 95C's case, 9 bits are required. This creates issues, because there needs to be storage for the 9th bit and the ACT is not really set up to work at the single bit level, it works with 4 bit nibbles, 14 per 56 bit register., or storage for 7 steps. With 200 steps available, there needs to be additional storage for the 200 single bits. This will take up 4 RAM registers, which are available in the 95, and is probably why the user memory only allows storage in R0 to R.5 (16 total). The 95C manual states that it takes some time to delete and insert steps, so having to manipulate single bits may be the reason. This will be a brain teaser.

cheers

Tony