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

[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