Threaded Mode | Linear Mode

ThomasF · (This post was last modified: 03-28-2024 09:39 PM by ThomasF.)

Hi all!

(03-27-2024 11:07 PM)dmh Wrote: Wow! Excellent work Thomas!

Out of interest, what did you use to write and run your test case?

Hopefully the emulators can be easily updated to test and fix this.

I'm developping on a Ubuntu platform, but that could just have been a Windows or other.
My main tool is the Pico board (described in other threads on this forum) connected to the HP41 for downloading code (modules) and tracing the bus.
To write my code (I have my own "test module" (tf-rom.src) with some routines I test) I just use a editor (Visual Code in my case), compile and link it with sdk41 (I had to update it to run on Ubuntu and to fit new instructions in the Blinky).
So, the complete iteration to write and test looks like this:

Code:

Edit and save the file (tf-rom.src)

../a41/a41 -r -o tf-rom   # Compile the assembly file

../l41/l41 tf-rom         # Link the file to a ROM image

./flash.sh tf-rom.rom 14  # "Insert" the module (in page 0xE) on the Tiny41 board

Then I powercycle the board and can execute the function - so about 10 seconds turnaround time from save to execution!

(03-28-2024 12:36 AM)dmh Wrote: I've just tested this fix on the px41c and it works - I can see forward and backward geese now :-)
...
I wonder if this special case needs to support A through F and not just F. It may never actually occur in real life though. Thomas, would it be easy for you to test these as well?

Perfect! Then you have the most accurate emulation of the 41!
I'm still surpriced that it has not been looked into before - it's over 40 years since the left goose was found ... Wink

I did some quick tests, and I think we really found a corner case. I'll try to summarize my findings here, please let me know if I should test some other cases as well ...
All tests done in DEC-mode and with C=C-1 or A=A-1 on specified field.

Code:

Reg   Field  Contents Result Carry

C     S&X    00F       008    No

C     S&X    00E       007    No

C     S&X    00D       006    No

C     S&X    00C       005    No

C     S&X    00B       004    No

C     S&X    00A       009    No

C     S&X    008       007    No

C     S&X    005       004    No

C     S&X    FFF       998    Yes

C     S&X    EEE       887    Yes

C     S&X    DEE       787    Yes

C     S&X    CEE       687    Yes

C     S&X    AEE       487    Yes

C     S&X    9EE       987    No

C     S&X    A01       400    Yes

C     S&X    A00       999    No

C     S&X    000       999    Yes

C     S&X    3EE       387    No

C     MS       F         8    Yes

C     MS       E         7    Yes

A     MS       F         8    Yes

A     MS       E         7    Yes

A     MS       D         6    Yes

A     MS       C         5    Yes

A     MS       B         4    Yes

A     MS       A         9    No

So, from this I would say that if the most significant nibble of the field contains [A..F] when we decrement, then carry is set, otherwise not (apart from other cases like 0 and field wraps) - but it is not as easy as that!
Note that C[X] = A00 becomes 999 - it wraps but carry is NOT set!

Is there someone here with good knowledge about the NUT CPU who can explain the logic (or lack of) when dealing with decimal arithmetics?

In the all ROM's, the developers has taken care of this, that's why all emulators etc works fine, it is just in some very specific cases - like the backward goose and the FIX 10 mode - that the formatting code in the calculator didn't handle.
Still I don't know of any other cases where the real 41 differs from the emulators - but I guess that all other FIX NN or other syntethic instructions could still hide some surprises ... Wink

I would classify this as a real Easter Egg provided by HP in the NUT!
Who will crack the last part of this and come up with a nice and simple solution to decrement a HEX-value in DEC-mode on a given field?

Edit: Thanks to Mike I corrected a typo for C[X] = B and C.
List should be correct now!

Happy Easter and Happy Coding!

Cheers,
Thomas

Christoph Giesselink · 03-28-2024, 07:50 PM

(03-28-2024 08:16 AM)Thomas paid='185426 Wrote:Perfect! Then you have the most accurate emulation of the 41!
I'm still surprised that it has not been looked into before - it's over 40 years since the left goose was found ...

I did some quick tests, and I think we really found a corner case. I'll try to summarize my findings here, please let me know if I should test some other cases as well ...
All tests done in DEC-mode and with C=C-1 or A=A-1 on specified field.

Code:

Reg Field Contents Result Carry C S&X 00F 008 No C S&X 00E 007 No C S&X 00D 006 No C S&X 00C 005 No C S&X 00B 004 No C S&X 00A 009 No C S&X 008 007 No C S&X 005 004 No C S&X FFF 998 Yes C S&X EEE 887 Yes C S&X DEE 787 Yes C S&X CEE 687 Yes C S&X AEE 487 Yes C S&X 9EE 987 No C S&X A01 400 Yes C S&X A00 999 No C S&X 000 999 Yes C S&X 3EE 387 No C MS F 8 Yes C MS E 7 Yes A MS F 8 Yes A MS E 7 Yes A MS D 6 Yes A MS C 5 Yes A MS B 4 Yes A MS A 9 No

So, from this I would say that if the most significant nibble of the field contains [A..F] when we decrement, then carry is set, otherwise not (apart from other cases like 0 and field wraps) - but it is not as easy as that!
Note that C[X] = A00 becomes 999 - it wraps but carry is NOT set!

Is there someone here with good knowledge about the NUT CPU who can explain the logic (or lack of) when dealing with decimal arithmetics?

I think this has nothing to do with logic, only with gate logic. May think you're a hardware developer creating CPU designs in gate logic. You should design a new CPU and you get a specification sheet. There's standing something about arithmetic, having to modes calculation to base 16 and to base 10. So you get a gate design. So what happens when you now have a HEX value in a register, the CPU is working to base 10, so what's happen when you do an arithmetic operation on this register?

The behavior is not documented in specification sheet, so it happens what happen. Dependent on the optimized gate logic the CPU is doing something for what it wasn't designed. The only rule, the gate logic has not to stall on such operations.

So back to our DECR sample. We can extrapolate the results what's happen when we do a subtraction with more than one. Is the expected result this was the CPU return?

But gimme more...

Who believe that on an A[S&X] content with "00B" the result after a A=A+1 in decimal mode is "00C"?

When I try to fix a bug I think over the borders and which opcode maybe affected by a similar behavior. I would never claim this as a CPU bug, It's only undocumented behavior. And so long an answer isn't random and has a predictable result we should rebuild this result in a CPU emulation.

Happy Easter and Happy Coding!

Christoph