Threaded Mode | Linear Mode

Thomas Klemm · (This post was last modified: 05-15-2022 08:47 AM by Thomas Klemm.)

For a description of the bug see: CHS and Stack Lift

TL;DR: CHS doesn't enable the stack lift when the X-register is 0.

The line 07117 is responsible for the CHS-bug. When the mantissa of the X-register is all 0 then the program jumps to line 00250.
But then the flag 9 which disables the stack-lift is not cleared in line 07127. Thus the stack-lift keeps disabled.

Code:

        1372 ? c<>0  m

        1241 ?nc goto 00250

        0002

        0611 ?nc call 05142

        0050

        1314 ? s=0 13

        0321 ?c  goto 31064

        0313

        1276 c=-c-1  s

        1104 s=0 9

        0360 c<>n

        1663 ?nc goto 07117

But line 07117 is also used with short branches, probably to save some precious bytes. Thus we have to adjust these as well.
And then there are two short branches to line 07127 which we have to consider.

This is the patch I came up with:

Code:

        1372 ? c<>0  m

        0103 ?nc goto 07127

        0611 ?nc call 05142

        0050

        1314 ? s=0 13

        0321 ?c  goto 31064

        0313

        1276 c=-c-1  s

        0360 c<>n

        1104 s=0 9

        1241 ?nc goto 00250

        0002

Thus the long jump to line 00250 was moved down.
The commands s=0 9 and c<>n got swapped so we can only enable the stack-lift.
Unfortunately the distance from line 07027 is now too long for a short branch.
Instead of using a long jump I decided to do it in two steps:

Code:

        0414 ? s=0 8

        0027 ?c  goto 07031

        0510 s=1 6

        0773 ?nc goto 07130

So far the fix works fine. I just hope that I haven't introduced other bugs.
Keep a copy of the original ROM!

Instructions to apply the patch:

unzip the attached file hp-15c-chs-bug.zip:
unzip hp-15c-chs-bug.zip
apply the patch:
patch 15c.obj hp-15c-chs-bug.patch

Kind regards
Thomas

Marcus von Cube · 12-13-2015, 08:59 AM

You should send the information to Michael Steinmann so he can update the DM15 firmware.

**Katie Wasserman** · 12-13-2015, 04:39 PM

Nice work, Thomas!

(12-13-2015 08:59 AM)Marcus von Cube Wrote: You should send the information to Michael Steinmann so he can update the DM15 firmware.

Since the original can't be fixed, then fixing any emulator will mean that it's no longer a true emulation. Given how long this bug has existed, I think that should be left as is.

matthiaspaul · 12-13-2015, 05:48 PM

(12-13-2015 04:39 PM)Katie Wasserman Wrote:
(12-13-2015 08:59 AM)Marcus von Cube Wrote: You should send the information to Michael Steinmann so he can update the DM15 firmware.

Since the original can't be fixed, then fixing any emulator will mean that it's no longer a true emulation. Given how long this bug has existed, I think that should be left as is.

Well, at least the alternative ROM images could be made available alongside the original images. There are also patched images with support for 192 or 224 registers (instead of 64)...

Ideally, but it makes sense only for rather local and short patches and requires some special-casing in the emulator, patches could be dynamically inserted and removed by a flag user-configurable in the emulator.

Greetings,

Matthias

matthiaspaul · 12-13-2015, 08:08 PM

Thomas, thank you for the patch! Given that the HP-11C and HP-16C share some amount of code with the HP-15C, do you plan to port your patch to these calculators as well?

Greetings,

Matthias

Thomas Klemm · 12-13-2015, 10:29 PM

(12-13-2015 08:08 PM)matthiaspaul Wrote: Given that the HP-11C and HP-16C share some amount of code with the HP-15C, do you plan to port your patch to these calculators as well?

To be honest: no. I'm driven by curiousity and interest, not by plans.
But yeah, I'll probably have a look at these two models as well.

Cheers
Thomas

Thomas Klemm · (This post was last modified: 12-22-2015 10:32 PM by Thomas Klemm.)

The fix for these two models was similar or maybe even a little simpler.
I'm just posting the change I made to the HP-11C since the code for the HP-16C is similar:

original:

Code:

 1372 ? c<>0  m

 1145 ?nc goto 00231

 0002

 1276 c=-c-1  s

 1104 s=0 9

 0360 c<>n

 1733 ?nc goto 07110

patched:

Code:

 1372 ? c<>0  m

 0033 ?nc goto 07113

 1276 c=-c-1  s

 0360 c<>n

 1104 s=0 9

 1145 ?nc goto 00231

 0002

A few short branches had to be adjusted but this time they stayed within the reach. Both patch files are attached in the file hp-11c-16c-chs-bug.zip.

Kind regards
Thomas

Massimo Gnerucci · 12-14-2015, 09:49 PM

...nothing for the 10C and 12C??? :D :D

**rprosperi** · 12-14-2015, 10:23 PM

(12-14-2015 09:49 PM)Massimo Gnerucci Wrote: ...nothing for the 10C and 12C???

Earlier research revealed the 10C and 12C do not have this problem. Likely because they actually wrote the code for the 10C and 12C, rather than porting the 34C code to the 11C/15C/16C, where it appears the bug originated.

Whoda thought?

Thomas Klemm · 12-14-2015, 10:39 PM

(12-13-2015 04:39 PM)Katie Wasserman Wrote: fixing any emulator will mean that it's no longer a true emulation.

This reminds me a little of the Ship of Theseus. On the one hand we complain that bugs in the HP-35S or HP-15C LE aren't fixed. But then we value an HP-35 containing the exp-bug more than a fixed one. Isn't hat strange?

Can we improve the HP-15C by fixing its bugs? Or is changing the ROM heresy? I have the utmost respect for the programmers of these ROMs. You can not simply rewrite the code to fix a bug because the ROM is full. Moving lines means recalculating branches. Thus I'm happy I could find a solution by only moving a few of them. I feel it's done in the spirit of the original programmers.

Using an emulator we can use both: the original and the fixed ROM. Thus why not provide it as an option as Matthias suggested?
But then we can probably agree that it's not a serious bug. So you might just as well think: who cares?

Kind regards
Thomas

Thomas Klemm · 12-14-2015, 11:39 PM

(12-14-2015 10:23 PM)rprosperi Wrote: Earlier research revealed the 10C and 12C do not have this problem. Likely because they actually wrote the code for the 10C and 12C, rather than porting the 34C code to the 11C/15C/16C, where it appears the bug originated.

This is the relevant code of the HP-12C:

Code:

 1276 c=-c-1  s

 0707 ?c  goto 01246

...

 0371 ?nc goto 00076

...

 1104 s=0 9

 1404 s=0 1

 0240 sel p

 1625 ?nc call 03745

 0034

 0055 ?nc call 10413

 0104

...

 1372 ? c<>0  m

 0027 ?c  goto 10416

 0116 c=0     w

 1240 set dec

Compared to the other calculators the sign is negated unconditionally (line 01155) and only much later it's checked whether the mantissa is 0 (line 10413).
If so the whole register c is set to 0 (line 10415).

It could be interesting to compare this code to even earlier implementations of CHS.

Cheers
Thomas

Thomas Klemm · 12-16-2015, 10:24 PM

(12-16-2015 05:24 PM)Mike (Stgt) Wrote: How do you disasemble the whole ROMs?

Based on the source of Nonpareil I wrote a romdump program that reads a ROM and writes the corresponding assembler code. But it currently works only for the nut-processor familly.

Quote:Another question: may you show the HP10C code too?

Unfortunately I don't have the corresponding ROM. If someone is willing to send it to me I can do that as well.

Best regards
Thomas

Didier Lachieze · 12-16-2015, 10:37 PM

(12-16-2015 10:24 PM)Thomas Klemm Wrote: Based on the source of Nonpareil I wrote a romdump program that reads a ROM and writes the corresponding assembler code. But it currently works only for the nut-processor familly.

Any reason for not using D41 from the SDK41?

Thomas Klemm · 12-17-2015, 01:45 AM

(12-16-2015 10:37 PM)Didier Lachieze Wrote: Any reason for not using D41 from the SDK41?

Umh, probably not. I wasn't aware that this would work. Are the ROMs for the HP-41C and HP-15C in the same format?
The output could be slightly different. My program uses the same methods that are used in Trace mode. This makes it easy to find the corresponding lines in the ROM.
And then I'm using Nonpareil with Linux. I can still use SDK41 in a VMware image. But it's a little laborious.

Cheers
Thomas

Thomas Klemm · 12-17-2015, 09:09 PM

(12-17-2015 05:32 PM)Mike (Stgt) Wrote: Nice, and how do you find out what is code and what could be data structures?

Not sure if I understand you correctly. What do you mean by data structures? Commands that consist of two words?

Quote:BTW, in your patch for the 11C you preplace at 0E29 0FF with 127 JC +24. I doubt a bit, as it would jump to 0E4D what is the second word of NCGO 0099. So I set at 0E29 a 11F JC +23. Please check.

I can't check at the moment but it could very well be that I made an error calculating the new adresses for the jumps. Thus thanks for pointing that out. I'll check tomorrow but I assume you're correct. I can confirm that it should of course jump to the first word of NCGO 0099.

Kind regards
Thomas

Tugdual · 12-17-2015, 09:54 PM

Hi Thomas, my question is a bit off topic: how did you disassemble the Rom?

Thomas Klemm · 12-17-2015, 10:08 PM

(12-17-2015 09:54 PM)Tugdual Wrote: Hi Thomas, my question is a bit off topic: how did you disassemble the Rom?

Mike already asked the same question in post: #13.

The code to disassemble the ROM is already there in Nonpareil. All I had to do is read the ROM line by line and pass the data to the correct function.

Cheers
Thomas

Tugdual · 12-17-2015, 11:51 PM

(12-17-2015 10:08 PM)Thomas Klemm Wrote:
(12-17-2015 09:54 PM)Tugdual Wrote: Hi Thomas, my question is a bit off topic: how did you disassemble the Rom?

Mike already asked the same question in post: #13.

The code to disassemble the ROM is already there in Nonpareil. All I had to do is read the ROM line by line and pass the data to the correct function.

Cheers
Thomas

Thanks Thomas, I had not seen the former question, sorry for double post.
Nonpareil is a fantastic, tool, I'd like to rewrite a version using qml, but I digress.

toml_12953 · 12-18-2015, 01:07 PM

(12-14-2015 10:39 PM)Thomas Klemm Wrote:
(12-13-2015 04:39 PM)Katie Wasserman Wrote: fixing any emulator will mean that it's no longer a true emulation.

This reminds me a little of the Ship of Theseus. On the one hand we complain that bugs in the HP-35S or HP-15C LE aren't fixed. But then we value an HP-35 containing the exp-bug more than a fixed one. Isn't hat strange?

But then we can probably agree that it's not a serious bug. So you might just as well think: who cares?

Kind regards
Thomas

Some programmers write code that takes advantage of some bugs. If you fix the bugs, you break their code. They might care.

Tom L

Thomas Klemm · 12-22-2015, 10:40 PM

(12-17-2015 05:32 PM)Mike (Stgt) Wrote: BTW, in your patch for the 11C you preplace at 0E29 0FF with 127 JC +24. I doubt a bit, as it would jump to 0E4D what is the second word of NCGO 0099. So I set at 0E29 a 11F JC +23. Please check.

You were of course right. I was off one line. But the same error happened at 3 jumps.
Here's the difference of the hp-11c-chs-bug.patch file:

Code:

3607c3607

< 0e0f:1f7

---

> 0e0f:1ef

3609c3609

< 0e11:1e3

---

> 0e11:1db

3633c3633

< 0e29:127

---

> 0e29:11f

Meanwhile I've updated the attachment hp-11c-16c-chs-bug.zip in my previous post HP-11C and HP-16C: Fixing the CHS and Stack Lift Bug.

Thanks for taking the time to verify the bug-fix.

Cheers
Thomas