HP97 The journey begins

[teenix]

Hi all,

I have coded all of the 256 steps based on the available key entries and about 50% of the resulting functions.

I coded Jump and GTO so you can key in GTO 0 - 9, but the software will determine which program is active and re-code the entry to g Jump [prgm] 0 - 9

I haven't got that far yet, but the prgm mode display will show GTO 0 - 9 or g Jump 0-9 as appropriate, depending on the active program.

GTO A-D and Jump A-D will code and show as is.

cheers

Tony

[brouhaha]

(10-13-2024 08:31 AM)teenix Wrote:  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.

Gven the scarcity of the HP-95C, and how anyone lucky enough to have one is unlikely to be able to ever get another, I can understand an owner not being willing to potentially sacrifice a unit, even with assurances that it will not be damaged. I've offered to demonstrate the technique on a less scarce Topcat like a 97 or 91, but apparently neither that nor by background with publishing Nonpareil was convincing enough. Still, that leaves two other 95C owners, one of whom is known to be receptive to the idea. Even so, I will actually insist on demonstrating it to them with a 91 or 97 first, either one of theirs, or one of mine.

It's also probably not reassuring for an owner to hear that we would be able to replace any damaged chip in the 95C, or even the entire main board. The owner of a 95C wouldn't particuarly want newly engineered replacement innards. if they could avoid doing anything they thought might have a chance of necessitating such replacment.

But in general, I am 100% in agreement with you regarding archiving the genuine HP ROM code (and PIK character generator bits), as being the only way to have a hope of longer-term preservation.

[teenix]

(10-14-2024 03:35 AM)brouhaha Wrote:  Still, that leaves two other 95C owners, one of whom is known to be receptive to the idea.

Makes me wonder if I should continue developing the 95C code, it's a huge task and might end up being a waste of time if the lucky owner decides to allow the ROM dump.

The original code would be great, but either way is good as my working 91/92 board will bring it to life. I have plenty of room in the processor to accommodate the extra code. I've already partially set it up, so it might just be a matter to re-flash the ROM and away it goes. Of course, the PIK ROM will need attention, I only guessed the codes.

[teenix]

More progress, I have all the 95C functions working except for Linear Regression and Linear Estimate. These will take a bit of fiddling.

I still have to do the PRGM mode keys and the printer operation. Both will take some time to sort out though.

cheers

Tony

[brouhaha]

(10-14-2024 04:35 AM)teenix Wrote:  Makes me wonder if I should continue developing the 95C code, it's a huge task and might end up being a waste of time if the lucky owner decides to allow the ROM dump.

It's not likely that we'll get the 95C soon. I am not physically near any of the owners, so a substantial trip will have to be made after I convince one to support the attempt. Currently I am not able to go on any trips for financial reasons. I only was able to go to the HHC 2024 conference thanks to generous financial support from a close friend.

[teenix]

No worries, I'll keep plodding on.

I completed the Linear Regression and Linear Estimate functions, somewhat of a task.

That means all of the functions are completed. I still have STO(i) and RCL(i) to do but shouldn't take long. Just a bit of code to determine if I <=15 and if so STO/RCL the appropriate register.

The next two areas will take some time though, the Program and Printer functions.

The code I wrote to decode the key presses already generates the program step value and then this is used to steer into the required function, so this value can be stored direct to program memory and when recalled, it will also steer into the required function.

The printer is a bit crazy. I wrote a small program which inputs the program step and it will generate the required data for C register which gets fed to the PIK chip. This should make coding a bit easier as I won't have to manually decode the steps myself.

Just for interest's sake, this is what's required if the SQRT key is pressed

Printer ROM addresses for the character data are 6 bits each ($00 - $3F)
EOL = $3F
BLANK = $3B
SQRT = $11
X = $12

SQRT X = 11 12

2 blanks are inserted to make the total print = 4 characters before any numbers are printed

Blank Blank SQRT X = 3B 3B 11 12

An end of line character (EOL) is required to tell the PIK chip to speed up the motor and return the carriage Because the printer prints right to left, the EOL is placed at the start of the data. If this is not included, the Topcat printer will slam into the left side of the printer and probably burn out the stalled motor or strip the gears. Printers like the 19C will just keep the carriage going left and right until the power is turned off.

EOL Blank Blank SQRT X = 3F 3B 3B 11 12

The C register only works with 4 bit nibbles, so the 6 bit printer data needs to be split

3F 3B 3B 11 12
To binary
111111 111011 111011 010001 010010

Join it all up
111111111011111011010001010010

Split to 4 bits
11 1111 1110 1111 1011 0100 0101 0010

The data is less than the 14 nibbles that make up the C register, so pad with 1 bits (ends up as EOL's)
1111 1111 1111 1111 1111 1111 1111 1111 1110 1111 1011 0100 0101 0010

Register C Nibbles 13 down to 0 then become FFFFFFFFEFB452

Register C is sent to the PIK chip via the data bus which starts printing what it received and will return the carriage when it gets to the EOL. However, while this is printing, the HP code is busy preparing any numerical information to be printed on the same line (ie number entry). Once formatted into the C register the data is again sent to the PIK chip. This is actually completed before the PIK gets to the previous EOL character. That EOL is then ignored, and the printer keeps printing the following numeric data until the new EOL is found.

HP Code to prepare the data might look like...

Code:


  binary
  0 -> c[w]        / C = 00000000000000
  c - 1 -> c[w]    / C = FFFFFFFFFFFFFF
  5 -> p
  load constant 14
  load constant 15
  load constant 11
  load constant 4
  load constant 5
  load constant 2 / C = FFFFFFFFEFB452

cheers

Tony

[teenix]

Hi all,

It took a bit of work, but I created the PIK chip's 64 character ROM for the 95C and based on that coded all of the 266 separate print texts for each of the functions. Some of the printed codes appear in the attached image. Generating the HP code to decipher these was quite a task and the full set of step codes took up the better part of a whole ROM, but looking at the HP-97 code, it uses up pretty much the same.

Next, I have to create the code that prints the entered numbers next to these codes, and also if TRC is enabled the formatted calculation result will appear with *** on a separate line.

There's quite a bit to go, but getting there.

cheers

Tony

[teenix]

Just fiddling with the 95C a bit and I realize it is a bit cumbersome to edit programs. There doesn't appear to be a mechanism to jump to a specific line in a program, just labels. If you have a long program in between labels, then getting to the middle of the code could require a hundred or more SST's. I guess having variable length multiple programs may have made this difficult.

cheers

Tony

[brouhaha]

(11-10-2024 03:16 AM)teenix Wrote:  Just fiddling with the 95C a bit and I realize it is a bit cumbersome to edit programs. There doesn't appear to be a mechanism to jump to a specific line in a program, just labels. If you have a long program in between labels, then getting to the middle of the code could require a hundred or more SST's. I guess having variable length multiple programs may have made this difficult.

It seems strange that it wouldn't have the typical non-programmable "GTO . nnn". The document the use of GTO . A etc. Maybe they had GTO . nnn but forgot to put it in the manual?

[teenix]

(11-11-2024 12:05 AM)brouhaha Wrote:  It seems strange that it wouldn't have the typical non-programmable "GTO . nnn". The document the use of GTO . A etc. Maybe they had GTO . nnn but forgot to put it in the manual?

Possibly, there is a brief mention of using GTO. 0-9 on page 111 but nothing more that I can see, so I assume it positions the program pointer to LBL 0-9 in that program. As the 95C was never released, maybe the manual is still in a prototype stage.

I can always add GTO.nnn, which would have to compute an index from the start of a program and ignore the request if outside the range.

This is turning out to be way more complicated than I first thought it would be, very time consuming and I reckon I'm only half way through. Many times, when I think I'm making progress, a new situation pops up and the thing crashes or a routine goes astray, very frustrating at times :-)

I've been going through the HP code for the 97 and it is crazy. So many twists and turns, multiple re-use points in and out of various code blocks. It must have been a real head scratcher to put it all together and test. Understandable though, due to the limited ROM they could use. The 91 seems worse with multiple jumps between the ROMs just to do a simple function

I also found a bug in the 97 HP code that stopped the ISZ DSZ working properly. This is only from my emulator, but the code is supposed to be a ROM dump, so not sure what happened there.

[teenix]

(11-11-2024 03:52 AM)teenix Wrote:  I can always add GTO.nnn, which would have to compute an index from the start of a program and ignore the request if outside the range.

It turns out that this is not practical because there are already key sequences for GTO. [0-9].

A key sequence for this type of function would have to be something like, [g][Jump][000-199] which should work as the normal use of [g][Jump] has [A B C or D] following.

cheers

Tony

[RPNerd]

(11-12-2024 05:58 PM)teenix Wrote:  It turns out that this is not practical because there are already key sequences for GTO. [0-9].

The HP 15C had the same problem but it was overcome by using [GTO][CHS]nnn to do the same thing.