HP97 The journey begins

[rprosperi]

Thanks for the heads-up Tony, I will start my search now for a -91 or -92 that can be upgraded to a 95C when your board is complete. Never even realistically hoped to own one, but this would indeed be the next best thing!!

[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

[Dreato]

My experience throughout life has been:

When you open a can of worms, the only way to get them back in is to use a bigger can.

Please take this as a word of encouragement!

[brouhaha]

(10-10-2024 08:14 AM)teenix Wrote:  HP calculator code is a bit of a head scratcher.

As a fellow reverse-engineer of HP calculator microcode, I would say that you have made a very polite understatement.

:-)

I continue to be impressed with how much progress you have made!

One trick I've been using to understand some of the HP microcode better is to modify the code to run on a more abstract calculator processor, which is similar to those of HP, but lifts many restrictions, and in particular the various limitations on branch and subroutine calls of actual HP processors. I modify the HP firmware by juggling blocks to remove jumps made unnecessary, so that related code is collected together rather than scattered all over. However, doing this is so much work that I'm not completely certain that it was a worthwhile exercise.

[teenix]

(10-11-2024 12:48 AM)brouhaha Wrote:  I continue to be impressed with how much progress you have made!

However, doing this is so much work that I'm not completely certain that it was a worthwhile exercise.

A lot of that is based on what others have done in the past, which helped me get started. Peter Monta probably lit the fuse by showing the HP-35 ROM bits :-) I get that feeling sometimes, but the challenges help keep the old grey matter going.

Over the last few hours (lots) I figured out how to left shift a range of RAM registers one bit at a time. I also managed to figure out how to get the address of a single bit where 4 RAM registers hold the 9th bit for the HP-95C's 200 steps. The address is returned as RAM address, the nibble (0-13) in that address and the bit position as either 8, 4, 2 or 1. This can form the basis of inserting the 9th bit of a program step.

I still have to do a right shift which can be used for deleting steps. I also have to do the harder coding which is to shift part of a nibble left or right to insert or delete a single bit. As mentioned, single bit operations are not supported by the ACT, so it sure takes some figuring out.

Just as an example, the code below is for finding the bit address in RAM, assuming the code starts at location $xx00 in a ROM page. It can take a few seconds to complete depending on which bit it needs to find. This is probably why the 95C manual mentions there are delays when modifying a program.

Code:


      0 -> c[x]
      1 -> p
      load constant 3
      c -> data address
      2 -> p
      load constant 6
      load constant 2
      load constant 15
      c -> data register 3
      binary
      0 -> c[x]
      2 -> p
      load constant 1
      load constant 3
      load constant 9
      c -> data register 4
      data register 2 -> c
      a exchange c[x]
      data register 3 -> c
      a - c -> c[x]
      if c[x] = 0
            then go to $31
      2 -> p
      data register 3 -> c
      c - 1 -> c[p]
      if no carry go to $1D
      load constant 6
      1 -> p
      c - 1 -> c[wp]
      c -> data register 3
      2 -> p
      data register 4 -> c
      c + c -> c[p]
      if no carry go to $0F
      load constant 1
      3 -> p
      c + 1 -> c[p]
      a exchange c[p]
      0 -> c[p]
      load constant 14
      p + 1 -> p
      if a >= c[p]
            then go to $2D
      a exchange c[p]
      go to $0F
      0 -> c[p]
      1 -> p
      c - 1 -> c[wp]
      go to $0F
      return

This could be frustrating to use if you have to wait a few seconds for each step to be processed, so I'm wondering now (and to save a ton of time) whether I just use 256 steps and no 9th bit, or create a couple of bit processing (ACT) instructions to speed things up. The latter sounds better to me as the calculator can run normal like the 97. As I cannot know the original code, this will always be a simulation rather than an emulation regardless of what I do. Not so far fetched as the HP-65 has [memory delete] and [memory insert] instructions.

cheers

Tony

[AnnoyedOne]

I once tried to understand some Microchip PIC assembler code for a product. Few comments. Fortunately it wasn't a product I was responsible for. The original author(s) was/were gone (the company had been purchased by the one I worked at many years before).

Subsequent engineers had translated this code into 'C' for a different processor. Direct translation. Evidently they couldn't make it out either. Except for one (who'd had no part in that) they were gone too.

So making head-tail of someone elses code can be quite challenging to say the least. My guess, is that like the above PIC code, there were many limitations (RAM/ROM/speed) that the author(s) had to overcome.

I wish teenix all the luck in the world on his quest.

A1

[teenix]

(10-11-2024 03:14 PM)AnnoyedOne Wrote:  I wish teenix all the luck in the world on his quest.

I've been writing PIC assembler for many years, I like it over C, which I am never going to learn, for PC work, I use Pascal.

Much appreciated for the comment, it helps me push forward, thank you

cheers

Tony

[AnnoyedOne]

Tony,

PIC assembler wasn't the issue. It was more so how do you get from here to there? No comments to explain that.

At least with the HP-97 you have some idea.

As an aside I once wrote self-test/startup code for a product. All inline assembler using registers (only). I had lots of comments explaining what I was doing/references to hardware datasheets etc. Not long before I left the company I checked the source files in the version control system. All my comments had been deleted including my name etc.

Good luck.

A1

[brouhaha]

(10-11-2024 01:25 AM)teenix Wrote:  I also managed to figure out how to get the address of a single bit where 4 RAM registers hold the 9th bit for the HP-95C's 200 steps.

I have, at least until now, thought that the 95C only used 8 bits per program step, like all of the APD/CVD programmable calculators other than the HP 9100 and HP-65. Almost exactly two years ago, I enumerated the programmable operations as best I could from the 95C manual, and only found 256. I compiled a list int a spreadsheet, which I've now put into a github repository.

Of course, if you've added any instructions, that would explain the need for a ninth bit. Or if I have missed any operations in my enumeration.

If more than 8 bits are necessary, I'd suggest just going to 12 or 16, since the Woodstock processor is so much better at dealing with multiples of four bits. If you use 16, and put the extra 8 in a side buffer, rather than all 16 together, then you can reuse the normal HP insert and delete program step routines seen in other models, but using it twice. Put the side buffer at an address that's an exact multiple of 16 (0x10) away from the main program buffer, and then you can just call the existing routine, select the RAM containing the side buffer, call the existing routine again, and reselect the main buffer. That's what I've been doing in my work on enhancing the 12C and 16C firmware.

[Digression: The 15C already has a mix of one-byte and two-byte instructions, which is causing me considerable grief. Given that I've already increased the available program space, I'm considering making all instructions two bytes, but split into a primary and side buffer as previously descripted. That would allow for 999 steps with no restrictions, or possibly 1999, and eliminate all of the complicated variable-length program step code.]

Thus far, for my enhanced firmware, I've tried to stick to the normal Nut processor instruction set, such that the enhanced firmware could run on a real calculator with "only" the ROM replaced and RAM increased. Restricting myself to that is perhaps silly ("A foolish consistency is..."), but I chose that path back in 2004 when I first started hacking Voyager firmware, and haven't yet had a good enough reason to change. Back in 2005 I hacked up a physical 15C to run my firmware. I considered making a tiny enough add-on board to actually wedge inside a 15C, but I never got around to designing that, because only a few of the usual suspects expressed interest. Today, it makes even less sense, since the main audience for enhanced Voyager firmware would be those using the latest HP or Swiss Micros ARM- and flash memory-based hardware. Given that you're replacing the entire main PCB, I think the same reasoning applies to your 95C work.

Regarding other recent comments in this thread, my late co-conspirator Richard Ottosen and I both have done a huge amount of PIC programming, and the isntruction set does take a little getting used to, but it really isn't that bad. The midrange 14-bit instruction set is better than the original 12-bit, and the 16-bit (PIC18) is better yet. Rich and I did all of our early "DIYRPN" prototypes using PIC processors, before we switched to ARM Cortex in 2010 (originally Energy Micro EFM32, whcih is now Silicon Labs).

[teenix]

It looks like your listing has 1 extra 10^X, and you omitted 0 - 9 and (.)

So overall, that adds up to 266 programmable steps.

I can whittle it down to 252 codes if I use the following...

LBL 0 - 7 instead of 0 - 9.
GTO 0 -7
GSB0 - 7
JMP ABCD 0 - 7

No extra "goodies" in this project, I think the goodie is the project ;-)

If as you suggest, I use shadow RAM for the 9th bit of the 200 steps, then I need another 30 RAM registers, which is a bit wasteful for the era, but probably doable as there are 3 extra 14 pin ICs on the board compared to the 97. I'm not sure what these are, but they could be extra RAM - 10 registers each was common, 10 x 3 = 30, Hmm - seems to fit.

Off the top of my head, for something simple in code, I could set the Status[15] bit as a flag to determine if a step is 8 or 9 bits. That bit is not used so far in this application. That would determine what to store in the shadow RAM. On recall, s15 is set if the shadow RAM is non-zero.

I'll stick to PICs. I'm too old to go with new development platforms :-)

cheers

Tony

[brouhaha]

(10-12-2024 05:58 AM)teenix Wrote:  It looks like your listing has 1 extra 10^X, and you omitted 0 - 9 and (.)
So overall, that adds up to 266 programmable steps.

Good catches. I stand corrugated. I've updated the spreadsheet. I may spend some time soon poring over through the manual again, to see if there are any restrictions on operands I might have missed, since it still seems quite surprising that they wouldn't restrict it to 256 programmable operation codes.

Quote:If as you suggest, I use shadow RAM for the 9th bit of the 200 steps, then I need another 30 RAM registers,

Possibly only 29. The A partition marker doesn't have to be stored, as it is always to the first step. It's possible that the B, C, and D markers aren't stored as program steps either; based on HP's usual microcode programming style, it's likely that the register that contains the D end pointer (end of used program memory) also contains the B, C, and D start pointers, so that they don't ever have to search for the markers. (In the same way the return stack, or at least part of it, is usually stored in the same register as the program step pointer.)

Quote:there are 3 extra 14 pin ICs on the board compared to the 97. I'm not sure what these are, but they could be extra RAM - 10 registers each was common, 10 x 3 = 30, Hmm - seems to fit.

I think you mean 16-pin, which are 5061-0549 chips. Only the Classic series used 10-register chips. Because Woostock uses binary rather than BCD addressing of the storage registers, they came in 8-, or more commonly, 16-register chips. These ones contain 16 storage registers each. The ROM/Anode driver, as usual, contains no storage reigsters, but the 95C also doesn't have any ROM/RAM chips as the 97 has, only 1K ROM chips, so the 95C has exactly 48 addressable storage registers. Pins 13 and 14 are definitely address selection inputs, and probably pins 12 and 15 are addition address selection inputs, un unused and grounded in the 95C.

Quote:Off the top of my head, for something simple in code, I could set the Status[15] bit as a flag to determine if a step is 8 or 9 bits. That bit is not used so far in this application. That would determine what to store in the shadow RAM. On recall, s15 is set if the shadow RAM is non-zero.

Sounds very reasonable.

[teenix]

(10-12-2024 07:27 AM)brouhaha Wrote:  so the 95C has exactly 48 addressable storage registers.

I should have looked at Tony Duell's drawing a bit closer, but yes that is the case. Then it stands to reason that HP used single bits to define the 9th bit. This gets back to the sluggish response mentioned in the manual because the bit manipulation takes a bit of time to execute.

I have already written code to insert or remove a bit stored in 4 RAM registers depending on the program pointer position, but I created 2 new instructions to do the bit shifts so it operates quickly.

However, a mem usage map might be:

$00-$0F = user storage
$13 - $2F for 200 step program

That leaves 3 registers for:
4 registers for the 9th bit patterns - already out of memory

3 level stack
Continuous Memory bit pattern, or RAM ignores [Clear Registers] unless new power up
pgm pointer
B, C, and D program pointers
Last X
I register
Number key format entry register
Flags for DEG RAD GRD and FIX SCI ENG

Not going to fit

I'm wondering if the manual (being for a prototype) does not truly reflect the capabilities of the physical calculator.

Reducing the LBLs GTO's etc. from 0-9 to 0-7 would alleviate all the storage problems, 252 steps, and it would fit with the actual hardware.

[AndiGer]

Tony,
Just an idea: if you store the content of the 200 9th bits as a BCD number? Every position added according to its content if bit = 1 or not if bit = 0? Left to right or right to left?
This would add up to max 20100 if every 9th bit contains 1. So you could store it in 16 bits but that‘s more than one register required. Handling insert / delete will be challenge, too, I think … Maybe calling MOD function if it is there could be your friend …
Good luck
Andi

[brouhaha]

The 95C apparently having more than 256 programmable operations has been nagging at me. I woke up in the middle of the night with a possible solution. The key observation is that it is exactly 256 plus 10, suggesting that something with a zero to nine operand is extraneous.

Hypothesis:
GTO 0-9 is encoded internally as JUMP <current program> 0-9

[brouhaha]

(10-12-2024 03:38 PM)AndiGer Wrote:  Just an idea: if you store the content of the 200 9th bits as a BCD number? Every position added according to its content if bit = 1 or not if bit = 0? Left to right or right to left?
This would add up to max 20100 if every 9th bit contains 1. So you could store it in 16 bits but that‘s more than one register required. Handling insert / delete will be challenge, too, I think … Maybe calling MOD function if it is there could be your friend …

That's an interesting idea, but unfortunately the possible combinations of the extra bits don't "add up to max 20100". They multiply up, so the number is 2^200, which is 1606938044258990275541962092341162602522202993782792835301376. That takes 200 bits to store in binary, or 244 bits to store in BCD (61 digits).

[teenix]

(10-12-2024 06:26 PM)brouhaha Wrote:  The 95C apparently having more than 256 programmable operations has been nagging at me. I woke up in the middle of the night with a possible solution. The key observation is that it is exactly 256 plus 10, suggesting that something with a zero to nine operand is extraneous.

Hypothesis:
GTO 0-9 is encoded internally as JUMP <current program> 0-9

Nice idea. I did some more manual reading, and it has something similar.

"If you are keying in instructions in program A and try to key in, say g JMP A2, the instruction that is actually keyed in will be GTO 2 (keycode 63 2), since that is actually the instruction you are trying to load."

This would suggest that GTO 2 is valid and g JMP A2 is valid but only from programs B-D, so both are separate step codes.

Also, GTO 0- 9 and JPn 0 - 9 have individual printouts, same for the key combinations on the display.

It would appear that perhaps the manual is not 100% correct. I'm still wondering if LBL's 0 - 7 are only supported.

There is supposed to be a 95C or two floating around, probably locked up in Fort Knox, firing one up and having a play would be the only real solution.

On re-reading the manual, the operational delay I mentioned was for deleting a long program, not so much wrapped up in 9th bit processing as I guessed. I suppose the software has to call a [Delete Step] subroutine in a loop that has to shift multiple steps backward many times and keep the other programs in tact.

It's amazing (and frustrating at times) how the brain keeps working on a problem while unconscious :-)

cheers

Tony

[brouhaha]

(10-12-2024 10:46 PM)teenix Wrote:  "If you are keying in instructions in program A and try to key in, say g JMP A2, the instruction that is actually keyed in will be GTO 2 (keycode 63 2), since that is actually the instruction you are trying to load."

This would suggest that GTO 2 is valid and g JMP A2 is valid but only from programs B-D, so both are separate step codes.

Also, GTO 0- 9 and JPn 0 - 9 have individual printouts, same for the key combinations on the display.

It would appear that perhaps the manual is not 100% correct. I'm still wondering if LBL's 0 - 7 are only supported.

The manual is only describing what the user experiences, which obviously has implications for the internal operation but doesn't fully specify it.

I only meant that the INTERNAL code in program B for GTO 3 would be the code for JUMP B 3. I didn't suggest that the user would enter it that way, or that the code would be displayed or printed that way.

My.hypothesis is the the code translation of GTO n to the code for JUMP <current-prog> n would happen on input, and that the inverse translation would occur on output (display and print).

In other words, there would be a single internal code for JUMP B 3, but in the display and print, it would show in programs A, C, and D as JUMP B 3, yet in program B it would display and print as GTO 3.

Quote:There is supposed to be a 95C or two floating around, probably locked up in Fort Knox, firing one up and having a play would be the only real solution

I know three owners of working 95C units. There might be a few others, but if so, they've kept a very low profile.

I'll try to convince them to try a few test cases, such as trying to key JUMP B 3 into program B, to see whether it is:
1) rejected
2) accepted, but prints as GTO 3
3) accepted, and prints as JUMP B 3

One 95C owner has denied my request to dump the microcode from it. One has expressed willingness with some reservations. The other I have not yet asked.

Since the 95C is not cancelled, just on "production hold", HP might start up manufacturing them at any moment!
:-)

Quote:On re-reading the manual, the operational delay I mentioned was for deleting a long program, not so much wrapped up in 9th bit processing as I guessed. I suppose the software has to call a [Delete Step] subroutine in a loop that has to shift multiple steps backward many times and keep the other programs in tact.

They might have done as you say just to save ROM space, compared to a general delete-n-steps routine, which would be more complex and thus somewhat longer.

The simple method of iterating over a one-step-delete means that step deletion can be done very similarly to that of the 67/97 and 19C/29C, though instead of only adjusting the end pointer, it may have to adjust 0 to 3 start pointers as well, depending on from which program the step is deleted.

Quote:It's amazing (and frustrating at times) how the brain keeps working on a problem while unconscious :-)

Yes. I've only rarely awakened to as good a potential solution, but I think sleep may also help process a problem in ways less obvious than suddenly having a complete solution.

[teenix]

(10-13-2024 06:34 AM)brouhaha Wrote:  One 95C owner has denied my request to dump the microcode from it. One has expressed willingness with some reservations. The other I have not yet asked.

I think it would be a good idea. Having the code means they can stay alive pretty much forever in one form or another. If the ROMs degrade, which they will, then the code will be lost forever.

[rprosperi]

(10-13-2024 06:34 AM)brouhaha Wrote:  In other words, there would be a single internal code for JUMP B 3, but in the display and print, it would show in programs A, C, and D as JUMP B 3, yet in program B it would display and print as GTO 3.

What a clever solution!! Although it costs some ROM space for the code to "hide" / "show" the JUMP as you describe, it's almost certainly worthwhile if it will keep the instruction count to 256.

I'm glad you don't sleep well, or at least when you do, the thinking keeps going at some level!

[teenix]

Hi all,

With Eric's brilliant insight, I assigned the program steps as follows:

Code:


00  R/S
01  1/X
02  XSQR
03  SQRTX
04  %
05  Sig+
06  YTOX
07  f LN
08  g eX
09  f SIN
0A  f COS
0B  f TAN
0C  f ->R
0D  g ->P
0E  RCLSIG
0F  f RTN
10  0
11  1
12  2
13  3
14  4
15  5
16  6
17  7
18  8
19  9
1A  .
1B  ENTER
1C  CHS
1D  EEX
1E  Print X
1F  f SIG%
20  f FIX 0
21  f FIX 1
22  f FIX 2
23  f FIX 3
24  f FIX 4
25  f FIX 5
26  f FIX 6
27  f FIX 7
28  f FIX 8
29  f FIX 9
2A  f PAUSE
2B  g N!
2C  f xBar
2D  g S
2E  f Sig-
2F  g DELT%
30  f SCI 0
31  f SCI 1
32  f SCI 2
33  f SCI 3
34  f SCI 4
35  f SCI 5
36  f SCI 6
37  f SCI 7
38  f SCI 8
39  f SCI 9
3A  f LOG
3B  g 10TOX
3C  f INT
3D  g SIN-1
3E  g COS-1
3F  g TAN-1
40  f ENG 0
41  f ENG 1
42  f ENG 2
43  f ENG 3
44  f ENG 4
45  f ENG 5
46  f ENG 6
47  f ENG 7
48  f ENG 8
49  f ENG 9
4A  f ABS
4B  g FRAC
4C  g Yhat
4D  f L.R.
4E  X<->Y
4F  f LASTX
50  RCL 0
51  RCL 1
52  RCL 2
53  RCL 3
54  RCL 4
55  RCL 5
56  RCL 6
57  RCL 7
58  RCL 8
59  RCL 9
5A  RCL .0
5B  RCL .1
5C  RCL .2
5D  RCL .3
5E  RCL .4
5F  RCL .5
60  STO 0
61  STO 1
62  STO 2
63  STO 3
64  STO 4
65  STO 5
66  STO 6
67  STO 7
68  STO 8
69  STO 9
6A  STO .0
6B  STO .1
6C  STO .2
6D  STO .3
6E  STO .4
6F  STO .5
70  STO / 0
71  STO / 1
72  STO / 2
73  STO / 3
74  STO / 4
75  STO / 5
76  STO / 6
77  STO / 7
78  STO / 8
79  STO / 9
7A  CLx
7B  +
7C  -
7D  X
7E  /
7F  f PRSPC
80  STO - 0
81  STO - 1
82  STO - 2
83  STO - 3
84  STO - 4
85  STO - 5
86  STO - 6
87  STO - 7
88  STO - 8
89  STO - 9
8A  f ->HMS
8B  f HMS->
8C  f HMS+
8D  f HMS-
8E  f S(i)
8F  f R(i)
90  STO + 0
91  STO + 1
92  STO + 2
93  STO + 3
94  STO + 4
95  STO + 5
96  STO + 6
97  STO + 7
98  STO + 8
99  STO + 9
9A  f PRSTK
9B  ROLDN
9C  ROLUP
9D  f DEG
9E  f RAD
9F  f GRD
A0  STO x 0
A1  STO x 1
A2  STO x 2
A3  STO x 3
A4  STO x 4
A5  STO x 5
A6  STO x 6
A7  STO x 7
A8  STO x 8
A9  STO x 9
AA  f PI
AB  f CLREG
AC  f PRREG
AD  f PRSIG
AE  f ISZ
AF  g DSZ
B0  GSB 0
B1  GSB 1
B2  GSB 2
B3  GSB 3
B4  GSB 4
B5  GSB 5
B6  GSB 6
B7  GSB 7
B8  GSB 8
B9  GSB 9
BA  GSB A
BB  GSB B
BC  GSB C
BD  GSB D
BE  g CLSTK
BF  g CLSIG
C0  f LBL 0
C1  f LBL 1
C2  f LBL 2
C3  f LBL 3
C4  f LBL 4
C5  f LBL 5
C6  f LBL 6
C7  f LBL 7
C8  f LBL 8
C9  f LBL 9
CA  GTO A
CB  GTO B
CC  GTO C
CD  GTO D
CE  f x!=y?
CF  f x=y?
D0  f x>y?
D1  f x<=y?
D2  g x!=0?
D3  g x=0?
D4  g x>0?
D5  g x<0?
D6  RCL I
D7  STO I
D8  g JPA0
D9  g JPA1
DA  g JPA2
DB  g JPA3
DC  g JPA4
DD  g JPA5
DE  g JPA6
DF  g JPA7
E0  g JPA8
E1  g JPA9
E2  g JPB0
E3  g JPB1
E4  g JPB2
E5  g JPB3
E6  g JPB4
E7  g JPB5
E8  g JPB6
E9  g JPB7
EA  g JPB8
EB  g JPB9
EC  g JPC0
ED  g JPC1
EE  g JPC2
EF  g JPC3
F0  g JPC4
F1  g JPC5
F2  g JPC6
F3  g JPC7
F4  g JPC8
F5  g JPC9
F6  g JPD0
F7  g JPD1
F8  g JPD2
F9  g JPD3
FA  g JPD4
FB  g JPD5
FC  g JPD6
FD  g JPD7
FE  g JPD8
FF  g JPD9

I have implemented quite a few now and are functional on the calculator, hopefully get more done today. I've also added the SEE 0 and SEE 5 errors, so on a new power on, you get SEE 0, and for general errors like DIV by 0, SEE 5 is displayed.

cheers

Tony