why don't emulators such as the DM41X and V41 display the synthetic geese?

[Christoph Giesselink]

(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