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

[dmh]

I've recently noticed that a number of emulators do not correctly display the geese (forwards or backwards) when using synthetic programming (eg page 80, Flying the Goose Backwards, from the book Synthetic Programming on the HP-41C by Wickes).

I assume the emulators are running the original 41c ROMs so is this due to a special/corner case that is not handled in the hardware emulation?

[rprosperi]

I'm pretty sure the DM41X does show it; is it possible you are running on FAST mode and it's simply too brief to even see it? Set SLOW mode and try it again.

[dmh]

I can clearly see the characters and they are wrong (no geese).

I’m using the latest firmware.

(03-26-2024 12:19 PM)rprosperi Wrote:  I'm pretty sure the DM41X does show it; is it possible you are running on FAST mode and it's simply too brief to even see it? Set SLOW mode and try it again.

[ThomasF]

Hi,

Tried myself, and no, I can't see the backward goose on the DM41X, only the normal flying one ...

I tried the modified CODE example by Wickes in his book.

Edit: As have been mentioned before, the DM41 handles characters differently than the original. Hopefully this will be handled in the next update, let's see ...

Cheers,
Thomas

[ThomasF]

(03-26-2024 02:45 PM)ThomasF Wrote:  Edit: As have been mentioned before, the DM41 handles characters differently than the original. Hopefully this will be handled in the next update, let's see ...

As said, the DM41X behaves strange when it comes to "synthetic" characters. What it actually shows depends on the display mode, if text is in focus or even if SHIFT is pressed or not.
Some are discussed here at SwissMicros forum, but there are other examples as well.

Just for reference I tried the same example on my Pico device, where I emulate the LCD display.
This is done by tracing the instruction on the bus, and catching all instructions that updates the display, and then I try to draw the same on a small OLED display.

The video shows the updated CODE running on a 41CV with the Tiny41 board attached, and it shows that emulating the backward goose shouldn't be a problem.
(Why running CODE with the example from page 81 in Wickes book ("0100E00C000013") is so slow I don't know ... )

Video of backward goose on Pico

Cheers,
Thomas

[J-F Garnier]

Can you try this simpler test (from Wickes' book too):
CF 28 , CF 29 , FIX 10
(the FIX 10 can be easily typed with ZENROM, otherwise it can created by synthetic technics)

Now type 1.234567891 EEX 13 ENTER
What do you see?

Wickes wrote:

Quote:'1.234567891 E13' will display in this mode as '1"#$%&'()!'

I checked this is correct on a 41CV and 41CX but I can't reproduce it in my Emu41 or in V41 or even in nonpareil 0.77 ...
These (otherwise excellent) emulators are displaying '1234567891' instead and so are failing for this special case, indeed.

J-f

[derekamos]

Hi all,
It figures that Syntho' code, or merged rpn codes are a step to far to program in emulators etc.
DA

[dmh]

The DM41X does exactly the same for your test below.

I had already tried simple tests just to show both geese in a simple program.

V41 doesn't work either.

So which emulators handle this correctly and what is required to fix the others (ie what is the case not being handled so others can fix their emulators)?

(03-26-2024 09:33 PM)J-F Garnier Wrote:  Can you try this simpler test (from Wickes' book too):
CF 28 , CF 29 , FIX 10
(the FIX 10 can be easily typed with ZENROM, otherwise it can created by synthetic technics)

Now type 1.234567891 EEX 13 ENTER
What do you see?

Wickes wrote:

Quote:'1.234567891 E13' will display in this mode as '1"#$%&'()!'

I checked this is correct on a 41CV and 41CX but I can't reproduce it in my Emu41 or in V41 or even in nonpareil 0.77 ...
These (otherwise excellent) emulators are displaying '1234567891' instead and so are failing for this special case, indeed.

J-f

[ThomasF]

(03-27-2024 01:08 AM)dmh Wrote:  The DM41X does exactly the same for your test below.

I had already tried simple tests just to show both geese in a simple program.

V41 doesn't work either.

So which emulators handle this correctly and what is required to fix the others (ie what is the case not being handled so others can fix their emulators)?

Hi,

I can confirm that the go41cx emulator for Android also fails to emulate the special characters (like the backward goose).
It behaves just like the DM41X (and other emulators).

The goose (left and right) are not really part of the character set, and the character code for these are normally used to show punctuation (, ; : etc) in the display.
When writing to the display chip, the upper bits indicates if punctuation should be shown or not, that is how I do when I update the display, and that seems to work.
I don't do any magic - I just followed the specification for the display driver in the IC specification.

Cheers,
Thomas

[J-F Garnier]

(03-27-2024 07:56 AM)ThomasF Wrote:  The goose (left and right) are not really part of the character set, and the character code for these are normally used to show punctuation (, ; : etc) in the display.
When writing to the display chip, the upper bits indicates if punctuation should be shown or not, that is how I do when I update the display, and that seems to work.
I don't do any magic - I just followed the specification for the display driver in the IC specification.

The problem is not specifically the goose, it is the FIX 10 mode.

If I understand well, your Tiny41 board is capturing Nut opcodes and manages a duplicate display.
There is no CPU simulation in your Tiny41 board, just simulation of a HP-41C display.
This explains why you get the same display as the 41C, the problem is not in the display simulation, but in the Coconut simulations that are failing to reproduce the problem of the 41C display building in FIX 10.

(03-27-2024 01:08 AM)dmh Wrote:  So which emulators handle this correctly and what is required to fix the others (ie what is the case not being handled so others can fix their emulators)?

As Wickes himself wrote:

Quote:'FIX 10' has a moderately useful practical applications as a means to display only the mantissa of a number with a positive exponent. Unfortunately, the method isn't quite clean: if the exponent is 10, 11, 12, or 13, when taken modulo 14, some of the mantissa digits will be represented in the display by character from row 2 of the Byte Table rather than by the proper number characters from row3.

So we could argue that the emulators are providing the most sensible results (correct mantissa of the number), and that it's the physical HP-41C which shows a buggy display for certain numbers.

But that's not completely true, the emulators can also show an abnormal mantissa, for instance (still in FIX 10 , CF 28):
'1.234567891E10' displayed as '1234567()! ,'
when the physical 41C displays '1234567()!@:'

J-F

[ThomasF]

(03-27-2024 10:26 AM)J-F Garnier Wrote:  If I understand well, your Tiny41 board is capturing Nut opcodes and manages a duplicate display.
There is no CPU simulation in your Tiny41 board, just simulation of a HP-41C display.
This explains why you get the same display as the 41C, the problem is not in the display simulation, but in the Coconut simulations that are failing to reproduce the problem of the 41C display building in FIX 10.

Hi J-F,

Yes, that is (almost) true, I trace and follow most instructions, not only the display, but the display I try simulate completely.

But I don't think that the problem lies in the simulation of the Nut CPU. When setting the FIX NN, we are basically only changing the flags in register 14 (d).
The difference between FIX 0 and FIX 10 is that in the first case flag 36-39 are all clear (0000) and in FIX 10 flag 36 and 38 are set (1010). That's it.

(Setting a FIX larger than 16 (i.e. > 0x0F) causes other problems, since then other flags outside of 36-39 are also changed by the command.)

So, and this is my interpretation from examining traces and the VASM, it is the routine that formats the number and sends it to the display that has to handle a case that is not defined, and we get a NNN sent to the display.

I don't think that there is a hidden state or missed case in the CPU simulation, it just boils down to how the format routine is implemented, which causes a undefined rounding and shifting of the number since the case with FIX 10 is undefined - so if the display is correctly simulated, then we would all get the same result.

I.e. if we could trace the display commands in e.g. a DM41X, they would most likely be identical to what a real 41 would produce with the same FIX settings.

To prove my case I collected a trace from the calculator with the NNN "0100E00C000013" from Wickes book in X register.
FIX 10 is called and the number is formatted and then sent to the display.
Note that only 3 display commands are used (SRLDB, SRLDA and SRLDC), so it should be easy to verify in any emulator:

The value written followed by the display command:
00232222222222 SRLDB (MSB)
000100E00C0000 SRLDA (LSB)
00000000000000 SRLDC (upper bits)

The character is combined by the values in A and B, so 4 different characters are written in this case: 0x20 (space), 0x31 ("1"), 0x2E (right goose) and 0x2C (left goose)
C is clear, so none of these should be shown as a punctuation.

This is the extract from the log, showing the last part of the trace.
(Note that data on bus (column 3) lags in regards to the command.)

Code:


This is in the end of routine DSPCRG - Output Reg.C to LCD

Enable LCD Chip
   4220>009D|044004206AB001 *x 07F6 (Q 1:3F6) 130 - LDI S&X
   4221>009D|044004206AB001  x 07F7 (Q 1:3F7) 010 - CON: 010 (0020)
   4222>009D|044004206AB001 *x 07F8 (Q 1:3F8) 270 - RAM SLCT
   4223>009C|044004206AB010 *x 07F9 (Q 1:3F9) 130 - LDI S&X
   4224>009C|044004206AB010  x 07FA (Q 1:3FA) 0FD - CON: 0FD (0375)
   4225>009C|044004206AB010 *x 07FB (Q 1:3FB) 3F0 - PRPH SLCT
 D 4226>009C|044004206AB0FD *x 07FC (Q 1:3FC) 3E0 - RTN


 D 4227>009D|044004206AB0FD *x 0B2F (Q 2:32F) 0EE - C<>B     ALL
 D 4228>009D|044004206AB0FD *x 0B30 (Q 2:330) 125 - -->
 D 4229>009D|23222222222233  x 0B31 (Q 2:331) 026 - ?NC GO 0949

Jump to RFDS55

Display only 12 digits
 D 422A>009D|23222222222233 *x 0949 (Q 2:149) 3D2 - RSHFC    P-Q
 D 422B>009D|23222222222233 *x 094A (Q 2:14A) 3D2 - RSHFC    P-Q

Shift into display reg B
 D 422C>009C|02322222222223 *x 094B (Q 2:14B) 068 - SRLDB

 D 422D>009C|00232222222222 *x 094C (Q 2:14C) 0AE - A<>C     ALL
 D 422E>009C|00232222222222 *x 094D (Q 2:14D) 3D2 - RSHFC    P-Q
 D 422F>009C|0100E00C000000 *x 094E (Q 2:14E) 3D2 - RSHFC    P-Q

Shift into display reg A
 D 4230>009D|00100E00C00000 *x 094F (Q 2:14F) 028 - SRLDA

Clear display reg C
 D 4231>009D|000100E00C0000 *x 0950 (Q 2:150) 04E - C=0      ALL
 D 4232>009D|000100E00C0000 *x 0951 (Q 2:151) 0A8 - SRLDC

Disable LCD chip and return
 D 4233>009D|00000000000000 *x 0952 (Q 2:152) 046 - C=0      S&X
 D 4234>009D|00000000000000 *x 0953 (Q 2:153) 3F0 - PRPH SLCT
   4235>009D|00000000000000 *x 0954 (Q 2:154) 270 - RAM SLCT
   4236>009C|00000000000000 *x 0955 (Q 2:155) 3E0 - RTN

After this the display contains [ 1 } { ] (should be read as right and left goose)

Again, I don't see what could be the problem in the emulators, since I think this is quite straight forward emulation, and it would be interesting to hear about what could be wrong there.
Since the normal goose is flying as expected but the left one is left behind, I assume all are based on the same display emulation with some part missing - but I have not digged further into that ...

Cheers,
Thomas

[J-F Garnier]

(03-26-2024 09:33 PM)J-F Garnier Wrote:  Can you try this simpler test (from Wickes' book too):
CF 28 , CF 29 , FIX 10
(the FIX 10 can be easily typed with ZENROM, otherwise it can created by synthetic technics)

Now type 1.234567891 EEX 13 ENTER
What do you see?

Wickes wrote:

Quote:'1.234567891 E13' will display in this mode as '1"#$%&'()!'

I checked this is correct on a 41CV and 41CX but I can't reproduce it in my Emu41 or in V41 or even in nonpareil 0.77 ...
These emulators are displaying '1234567891' instead and so are failing for this special case, indeed.

(03-27-2024 01:08 AM)dmh Wrote:  The DM41X does exactly the same for your test below.

V41 doesn't work either.

So which emulators handle this correctly and what is required to fix the others (ie what is the case not being handled so others can fix their emulators)?

We don't have yet a result for the 41CL. It will be interesting since it's another simulation (re-creation) of the NUT CPU.
My bet is that it will exhibit he same behaviour as Emu41/V41/Nonpareil/DM41, i.e. different from the 41C.

J-F

[Sylvain Cote]

(03-26-2024 09:33 PM)J-F Garnier Wrote:  CF 28 | CF 29 | FIX 10 | 1,234567891 EEX 13 | ENTER | What do you see?

41CL → '1234567891'

I did a Memory Lost just before doing the test.
41CLv5 | port #1: Time module | port #2: serial-plug | port #3: ZenROM module | port #4: empty | MMU disabled | FDBVER? → 20231126

(03-27-2024 01:55 PM)J-F Garnier Wrote:  We don't have yet a result for the 41CL. It will be interesting since it's another simulation (re-creation) of the NUT CPU.
My bet is that it will exhibit he same behaviour as Emu41/V41/Nonpareil/DM41, i.e. different from the 41C.

You win!

[ThomasF]

(03-27-2024 10:26 AM)J-F Garnier Wrote:  ... but in the Coconut simulations that are failing to reproduce the problem of the 41C display building in FIX 10.

Hi again,

Maybe you are up to something J-F!

I traced my 41CV and compared the trace with V41 and found one thing that differs!

Note - this is just a quick check - so I might be wrong - hopefully someone can spot the error!

My problem is that I don't have control of all CPU registers, I only see C register sometimes. But lets go ...

41C8>009D|9100E00C000000 *d 0B22 (Q 2:322) 3D0 - LC 15 (F)
41C9>009D|9100E00C000000 *d 0B23 (Q 2:323) 3DC - PT=PT+1
41CA>009D|F100E00C000000 *d 0B24 (Q 2:324) 0A2 - A<>C @PT
41CB>009D|F100E00C000000 *d 0B25 (Q 2:325) 3E0 - RTN

We are supposed to swap A[MS] with C[MS] (PT = 0x0D)
It looks ok, since F disappear on the bus, so I assume that A[MS] is now 'F'.
This is crucial - and in the next trace - I can't see that A register changes ...

41CC>009D|0100E00C000000 *d 0AAC (Q 2:2AC) 055 - -->
41CD>009D|0100E00C000000 d 0AAD (Q 2:2AD) 02C - ?NC XQ 0B15

41CE>009C|0100E00C000000 *d 0B15 (Q 2:315) 0E0 - SLCT Q
41CF>009C|0100E00C000000 *d 0B16 (Q 2:316) 2DC - PT= 13
41D0>009C|0100E00C000000 *d 0B17 (Q 2:317) 120 - ?P=Q
41D1>009D|0100E00C000000 *d 0B18 (Q 2:318) 01F - JC +03 [0B1B]

41D2>009D|0100E00C000000 *d 0B1B (Q 2:31B) 0A0 - SLCT P
41D3>009D|0100E00C000000 *d 0B1C (Q 2:31C) 3E0 - RTN

41D4>009D|0100E00C000000 *d 0AAE (Q 2:2AE) 3D4 - PT=PT-1
41D5>009D|0100E00C000000 *d 0AAF (Q 2:2AF) 214 - ?PT= 2
41D6>009D|0100E00C000000 *d 0AB0 (Q 2:2B0) 047 - JC +08 [0AB8]

So far so good!
But now, we decrement A[MS] with one, and then we jump on no carry ...
41D7>009D|0100E00C000000 *d 0AB1 (Q 2:2B1) 1BE - A=A-1 MS
41D8>009C|0100E00C000000 *d 0AB2 (Q 2:2B2) 3E3 - JNC -04 [0AAE]

But! We don't jump! So carry must have been set by A=A-1 MS when A[MS] = 0xF!

41D9>009C|0100E00C000000 *d 0AB3 (Q 2:2B3) 3D4 - PT=PT-1
41DA>009C|0100E00C000000 *d 0AB4 (Q 2:2B4) 214 - ?PT= 2

When tracing exactly the same scenario on V41, the jump at 0x0AB2 is taken, and we get a different result --> no goose in the display!

Did FIX 10 change the CPU somehow so that carry is set when A=A-1 MS and A[MS] = F ... or am I missing something obvious here?

One thing is that DEC mode is active, so A=A-1 MS should be executed in decimal mode, could that be the problem?

Please help me out ... !

Cheers,
Thomas

[ThomasF]

(03-27-2024 03:32 PM)ThomasF Wrote:  One thing is that DEC mode is active, so A=A-1 MS should be executed in decimal mode, could that be the problem?

Helping myself out of this ...

I wrote a small test-code that tried this, and yes, my assumption was correct!

Code:

   4F79>009C|00E0080E1B80B8 *d E1B8           2A0 - SETDEC
   4F7A>009C|00E0080E1B80B8 *d E1B9           130 - LDI S&X
   4F7B>009C|00E0080E1B80B8  d E1BA           20F - CON: 20F (1017)
   4F7C>009D|00E0080E1B80B8 *d E1BB           33C - RCR 1
   4F7D>009D|0000000000000F *d E1BC           10E - A=C      ALL
   4F7E>009D|F00E0080E1B820 *d E1BD           1BE - A=A-1    MS
   4F7F>009D|F00E0080E1B820 *d E1BE           017 - JC       +02 [E1C0]

   4F80>009D|F00E0080E1B820 *d E1C0           0AE - A<>C     ALL
   4F81>009C|F00E0080E1B820 *d E1C1           10E - A=C      ALL
   4F82>009C|800E0080E1B820 *d E1C2           1BE - A=A-1    MS

When A[MS] = F and we execute A=A-1 [MS], the carry is set and A[MS] is changed to 8.

If my assumption is correct, I thinbk this answers the original question ...

(03-27-2024 01:08 AM)dmh Wrote:  So which emulators handle this correctly and what is required to fix the others (ie what is the case not being handled so others can fix their emulators)?

Could someone verify this? Does the emulators set the carry when decrementing "F" in decimal mode?
IMHO I think not, this is a special corner case, triggered by the FIX 10, and unclear documentation regarding the instruction.

Is there any emulator or simulator that handles this case? Or is it easy to fix?

Cheers, and happy Easter!
Thomas

[dmh]

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.

(03-27-2024 07:07 PM)ThomasF Wrote:  

(03-27-2024 03:32 PM)ThomasF Wrote:  One thing is that DEC mode is active, so A=A-1 MS should be executed in decimal mode, could that be the problem?

Helping myself out of this ...

I wrote a small test-code that tried this, and yes, my assumption was correct!

Code:

   4F79>009C|00E0080E1B80B8 *d E1B8           2A0 - SETDEC
   4F7A>009C|00E0080E1B80B8 *d E1B9           130 - LDI S&X
   4F7B>009C|00E0080E1B80B8  d E1BA           20F - CON: 20F (1017)
   4F7C>009D|00E0080E1B80B8 *d E1BB           33C - RCR 1
   4F7D>009D|0000000000000F *d E1BC           10E - A=C      ALL
   4F7E>009D|F00E0080E1B820 *d E1BD           1BE - A=A-1    MS
   4F7F>009D|F00E0080E1B820 *d E1BE           017 - JC       +02 [E1C0]

   4F80>009D|F00E0080E1B820 *d E1C0           0AE - A<>C     ALL
   4F81>009C|F00E0080E1B820 *d E1C1           10E - A=C      ALL
   4F82>009C|800E0080E1B820 *d E1C2           1BE - A=A-1    MS

When A[MS] = F and we execute A=A-1 [MS], the carry is set and A[MS] is changed to 8.

If my assumption is correct, I thinbk this answers the original question ...

(03-27-2024 01:08 AM)dmh Wrote:  So which emulators handle this correctly and what is required to fix the others (ie what is the case not being handled so others can fix their emulators)?

Could someone verify this? Does the emulators set the carry when decrementing "F" in decimal mode?
IMHO I think not, this is a special corner case, triggered by the FIX 10, and unclear documentation regarding the instruction.

Is there any emulator or simulator that handles this case? Or is it easy to fix?

Cheers, and happy Easter!
Thomas

[agarza]

(03-27-2024 07:07 PM)ThomasF Wrote:  When A[MS] = F and we execute A=A-1 [MS], the carry is set and A[MS] is changed to 8.

If my assumption is correct, I thinbk this answers the original question ...

Thomas

Thomas, You are Correct!!!

I just did a quick and dirty patch for A=A-1, when A[MS] = F and in decimal arithmatic to force A[MS]=8.

Now I can see the goose (left and right).

[dmh]

I've just tested this fix on the px41c and it works - I can see forward and backward geese now :-)

Thanks to Thomas for the quick and thorough analysis to find the issue and thanks to Alex for quickly applying the fix to test.

Hopefully this can now be replicated in all the emulators.

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?

(03-28-2024 12:03 AM)agarza Wrote:  

(03-27-2024 07:07 PM)ThomasF Wrote:  When A[MS] = F and we execute A=A-1 [MS], the carry is set and A[MS] is changed to 8.

If my assumption is correct, I thinbk this answers the original question ...

Thomas

Thomas, You are Correct!!!

I just did a quick and dirty patch for A=A-1, when A[MS] = F and in decimal arithmatic to force A[MS]=8.

Now I can see the goose (left and right).

[agarza]

(03-28-2024 12:36 AM)dmh Wrote:  Thanks to Thomas for the quick and thorough analysis to find the issue and thanks to Alex for quickly applying the fix to test.

And thanks to Darren... for persistently reminding me that the reverse geese did not work on the PX41C.

[agarza]

(03-28-2024 12:03 AM)agarza Wrote:  

(03-27-2024 07:07 PM)ThomasF Wrote:  When A[MS] = F and we execute A=A-1 [MS], the carry is set and A[MS] is changed to 8.

If my assumption is correct, I thinbk this answers the original question ...

Thomas

Thomas, You are Correct!!!

I just did a quick and dirty patch for A=A-1, when A[MS] = F and in decimal arithmatic to force A[MS]=8.

Now I can see the goose (left and right).

More tests...
It seems the arithmetic mode doesn't really matter.

Patching A=A-1 (1BE) as:
if A[MS] = 0xF then A[MS] = 0x8
and it still works.


BTW: '1.234567891 E13' is displayed as '1"#$%&'()!'