HP-10 (KISS) Emulator

[teenix]

Hi all,

Not sure if this has ever been accomplished before, but an emulator for the HP-10 (Keep it simple stupid- KISS) calculator is available from teenix.org

For the purists, the code is not original as I don't think it is easily obtainable given that the code is locked away inside a large chip package which would probably have to be destroyed to get it out.

Anyway, all I had to go on was the owners manual and wrote the microcode for this calculator from scratch. As far as I can tell it produces the exact results that the book demonstrates including the print outs.

I must say, that my hat is definitely off to the original engineers who had to create code for these calculators. Especially back in the day when these concepts, processors circuits and ideas were all new an untested. Its not an easy task getting your head around the programming concepts of these processors - not for my old brain anyway :-)

cheers

Tony

[Alejandro Paz(Germany)]

Great work ! I assume it is a woodstock-based machine, did you use a woodstock core or a classic core ?
Is there a photo of the board ?
I find the whole concept, not only the processors very efficient. A bit of simplicity seems to get lost when going into the voyager series (regarding the display. It seems unnecessarily convoluted, most probably the result of being a stripped down nut core.

[Harald]

Wow!!!

So now I know why you have been so busy lately

Cheers,
Harald

PS: I have tried selecting the 2.02 bug version of the HP35 in your emulator, but if I do it crashes.

(11-15-2016 12:28 PM)teenix Wrote:  Hi all,

Not sure if this has ever been accomplished before, but an emulator for the HP-10 (Keep it simple stupid- KISS) calculator is available from teenix.org

For the purists, the code is not original as I don't think it is easily obtainable given that the code is locked away inside a large chip package which would probably have to be destroyed to get it out.

Anyway, all I had to go on was the owners manual and wrote the microcode for this calculator from scratch. As far as I can tell it produces the exact results that the book demonstrates including the print outs.

I must say, that my hat is definitely off to the original engineers who had to create code for these calculators. Especially back in the day when these concepts, processors circuits and ideas were all new an untested. Its not an easy task getting your head around the programming concepts of these processors - not for my old brain anyway :-)

cheers

Tony

[teenix]

(11-15-2016 02:19 PM)Alejandro Paz(Germany) Wrote:  Great work ! I assume it is a woodstock-based machine, did you use a woodstock core or a classic core ?
Is there a photo of the board ?
I find the whole concept, not only the processors very efficient. A bit of simplicity seems to get lost when going into the voyager series (regarding the display. It seems unnecessarily convoluted, most probably the result of being a stripped down nut core.

Yes, it is based on Woodstock as it was introduced in the same period as the HP-19C. The display interface was simplified a bit, "kiss" modelling :-) and doesn't use a mask in the B register.

Sorry I forgot. Yes, there is an inside view now. There is not much info on the web that I could find.

I'm a bit surprised they didn't use a simple Binary to 7 segment decoder. Maybe not thought of back then.

cheers

Tony

[teenix]

(11-15-2016 02:20 PM)Harald Wrote:  Wow!!!

So now I know why you have been so busy lately

Cheers,
Harald

PS: I have tried selecting the 2.02 bug version of the HP35 in your emulator, but if I do it crashes.

Yes, the coding was a bit more difficult than I first thought. Heaven knows how they coped before "delayed select rom" instructions.

Sorry, I should have mentioned on the web page that the new HP35 module needs to be uploaded with cce33.zip for the HP35 bug code to work.

cheers

Tony

[Harald]

(11-16-2016 12:20 AM)teenix Wrote:  Sorry, I should have mentioned on the web page that the new HP35 module needs to be uploaded with cce33.zip for the HP35 bug code to work.

cheers

Tony

I tried that just now and I still get a "List file Error" and a "Range Check Error".

The HP10 didin't work at first either, but that was due to the modified dsplab.dat file you have sent me (which obviously can't contain date for the HP10 yet).

Cheers,
Harald

[teenix]

(11-16-2016 08:09 AM)Harald Wrote:  I tried that just now and I still get a "List file Error" and a "Range Check Error".

The HP10 didin't work at first either, but that was due to the modified dsplab.dat file you have sent me (which obviously can't contain date for the HP10 yet).

Cheers,
Harald

Is this file in your cce33 working directory ? [cal35bug.pfl]

This is the data file for the 35 bug code.

cheers

Tony

[Harald]

(11-16-2016 10:01 AM)teenix Wrote:  

(11-16-2016 08:09 AM)Harald Wrote:  I tried that just now and I still get a "List file Error" and a "Range Check Error".

The HP10 didin't work at first either, but that was due to the modified dsplab.dat file you have sent me (which obviously can't contain date for the HP10 yet).

Cheers,
Harald

Is this file in your cce33 working directory ? [cal35bug.pfl]

This is the data file for the 35 bug code.

cheers

Tony

No, it wasn't! I must have downloaded a file that had beed cached. I downloaded again and now it works. Thanks!

[[kby]]

I haven't read the manual, but I'm sure this isn't in there. It is an odd effect of the fact that the HP-10 (sort of) rounds internally to the display. Unfortunately, I don't have access to Windoze machine to actually try the emulator, so I post this for those who might wish to try (and report back) with the emulator as wella s other HP-10s. Key sequence:

Code:

Keys             Displays              Comments
<Gold> 3          0.000                ;set display to FIX 3
1.240             1.240                ;enters number
+=                1.240
.001               .001                ;enters .001
-                 1.239                ;Subtraction
<Gold>2           1.24                 ;sets display to FIX 2; also rounds number
<Gold>8           1.24000000           ;FIX 8
.001               .001
+=                1.24000000           ;!

Note that directly adding 1.240 + .001 yields the expected 1.241.

Another oddity: MR always displays in Automatic (floating decimal point) mode,
regardless of the current display mode.

[ Moderator note: Edited to make the table above more readable ]

[teenix]

I entered the data into the emulator and the answer came up as 1.24000000

I didn't know about the MR key effect so I will try to amend things but changing this type of HP code can be thought provoking. I'll see if I remember how to do it :-)

cheers

Tony

(10-14-2020 10:38 PM)[kby] Wrote:  I haven't read the manual, but I'm sure this isn't in there. It is an odd effect of the fact that the HP-10 (sort of) rounds internally to the display. Unfortunately, I don't have access to Windoze machine to actually try the emulator, so I post this for those who might wish to try (and report back) with the emulator as wella s other HP-10s. Key sequence:

Keys Displays Comments
<Gold> 3 0.000 ;set display to FIX 3
1.240 1.240 ;enters number
+= 1.240
.001 .001 ;enters .001
- 1.239 ;Subtraction
<Gold>2 1.24 ;sets display to FIX 2; also rounds number
<Gold>8 1.24000000 ;FIX 8
.001 .001
+= 1.24000000 ;!

Note that directly adding 1.240 + .001 yields the expected 1.241.

Another oddity: MR always displays in Automatic (floating decimal point) mode,
regardless of the current display mode.

[[kby]]

You have obviously done a pretty good job of emulating the code even without seeing it. I can’t even figure out how it happens. FYI, using RND on a -67 yields the expected result (1.241).-kby

[teenix]

(10-15-2020 04:48 AM)[kby] Wrote:  You have obviously done a pretty good job of emulating the code even without seeing it. I can’t even figure out how it happens. FYI, using RND on a -67 yields the expected result (1.241).-kby

I wouldn't go that far ;-)

My code stores the original FIX 8 number in M1 (1.239) It uses this for future operations not the FIX 2 (1.24) which is displayed, which is why I get 1.239 + .001 = 2.400

This would seem feasible for describing the 1.24 result, but I think this approach is wrong as I cannot see the original HP-10 doing what is described below.

[GOLD] 3
2.456 [+=]
[GOLD] 2
2.46
[GOLD] 3
2.460
.001 [+=]
I should get 2.461 but I get 2.457

It was hard to judge this type of behavior as the manual did not have any examples of this type of data manipulation.

cheers

Tony

[[kby]]

Which is the same behavior as the real calculator and now I think I know what is happening in both cases.
The first += puts the original 4-digit number in the summation register (think of it like a stack lift on a normal HP calc, so the number is copied (actually added to) “y” and stored there. The changing of the display does affect the display register (aka the “x” register), which IS different than a normal HP calculator, but it doesn’t affect the “y” register (the summation register) so by the time you actually add something you’re back in fix 3 mode and the addition acts as if there wasn’t any intermediate rounding.
I’m not sure if this is “expected” behavior, but at least I understand it now.-kby

[teenix]

Well, what do you know.

Thanks for the clarification :-)

cheers

Tony

[[kby]]

Is your M1 what I referred to as the accumulator register? Apologies, but I’m not familiar with the appropriate nomenclature scheme.-kby

[teenix]

(10-15-2020 05:33 PM)[kby] Wrote:  Is your M1 what I referred to as the accumulator register? Apologies, but I’m not familiar with the appropriate nomenclature scheme.-kby

Yes, that is the job it does. I had no idea what actual registers or register names were in the processor chip, so I just had to make do with what appeared to work. It was useful for [M1 -> C] and [M1 Exchange C] instructions for the code routines.

Just thinking, I wonder if the [Auto Constant] works in the same way.

[GOLD] 3
1.555 [+=]
[GOLD] 2
1.56
[+=]
3.11
[+=]
4.67 (Actually 4.665)

Otherwise the display should read 4.68 (1.56 + 1.56 + 1.56]
cheers

Tony

[[kby]]

I assume the numbers you typed were display (not input) unless after a “[gold]”

With that interpretation, I get 3.12 on the first +=
I get 4.68 on the second.
If I follow this by [gold] 3, display shows 4.680, but += then yields 6.235, as if 1.555 is still in the constant.-kby

[teenix]

Sorry, I should have been more exact with keyed entries.

new switch on...

[GOLD] 3
number entry -> 1.555
[+=]
[GOLD] 2
display -> 1.56
[+=]
display -> 3.11
[+=]
display -> 4.67 (Actually 4.665)

if 4.68 was displayed, then the "Constant" value will have been rounded to 1.56 at the time of addition, which should be the right way.

Page 36 of the manual explains this. Entered numbers and answers are rounded to the FIX value when addition and subtractions are performed.

I'll have to modify the code to round the constant before addition/subtraction takes place.

Thanks.

cheers

Tony

[[kby]]

Ok, I interpreted correctly. To reiterate, 2nd addition (first “adds” to 0) yields 3.12 (not 3.11). Second addition yields 4.68.

[teenix]

(10-16-2020 03:07 AM)[kby] Wrote:  Ok, I interpreted correctly. To reiterate, 2nd addition (first “adds” to 0) yields 3.12 (not 3.11). Second addition yields 4.68.

The thinking cap will have to go on now, writing this type of HP machine code offers a few challenges to the grey matter :-)

Thanks again.

cheers

Tony