HP Forums

Full Version: HP-15C: Fixing the CHS and Stack Lift Bug
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
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:
07116:        1372 ? c<>0  m
07117:        1241 ?nc goto 00250
07120:        0002
07121:        0611 ?nc call 05142
07122:        0050
07123:        1314 ? s=0 13
07124:        0321 ?c  goto 31064
07125:        0313
07126:        1276 c=-c-1  s
07127:        1104 s=0 9
07130:        0360 c<>n
07131:        1663 ?nc goto 07117

But line 07117 is also used with short branches, probably to safe 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:
07116:        1372 ? c<>0  m
07117:        0103 ?nc goto 07127
07120:        0611 ?nc call 05142
07121:        0050
07122:        1314 ? s=0 13
07123:        0321 ?c  goto 31064
07124:        0313
07125:        1276 c=-c-1  s
07126:        0360 c<>n
07127:        1104 s=0 9
07130:        1241 ?nc goto 00250
07131:        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:
07026:        0414 ? s=0 8
07027:        0027 ?c  goto 07031
07030:        0510 s=1 6
07031:        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:
  1. unzip the attached file hp-15c-chs-bug.zip:
    unzip hp-15c-chs-bug.zip
  2. apply the patch:
    patch 15c.obj hp-15c-chs-bug.patch


Kind regards
Thomas
You should send the information to Michael Steinmann so he can update the DM15 firmware.
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.
(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
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
(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
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:
07107: 1372 ? c<>0  m
07110: 1145 ?nc goto 00231
07111: 0002
07112: 1276 c=-c-1  s
07113: 1104 s=0 9
07114: 0360 c<>n
07115: 1733 ?nc goto 07110

patched:
Code:
07107: 1372 ? c<>0  m
07110: 0033 ?nc goto 07113
07111: 1276 c=-c-1  s
07112: 0360 c<>n
07113: 1104 s=0 9
07114: 1145 ?nc goto 00231
07115: 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
...nothing for the 10C and 12C??? :D :D
(12-14-2015 09:49 PM)Massimo Gnerucci Wrote: [ -> ]...nothing for the 10C and 12C??? Big Grin Big Grin

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?
(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
(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:
01155: 1276 c=-c-1  s
01156: 0707 ?c  goto 01246
...
01246: 0371 ?nc goto 00076
...
00076: 1104 s=0 9
00077: 1404 s=0 1
00100: 0240 sel p
00101: 1625 ?nc call 03745
00102: 0034
00103: 0055 ?nc call 10413
00104: 0104
...
10413: 1372 ? c<>0  m
10414: 0027 ?c  goto 10416
10415: 0116 c=0     w
10416: 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
(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
(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?
(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
(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
Hi Thomas, my question is a bit off topic: how did you disassemble the Rom?
(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
(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.
(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
(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
Pages: 1 2
Reference URL's