Bit's WP 34S and 31S patches and custom binaries (version: r3802 20150805-1)

[Bit]

I've updated the builds and added a new feature: Significant figures display modes. As requested, I now publish wp34s.op and wp34s-lib.dat files for those who'd like to use library functions in the emulator or compile programs.

The version reported by VERS indicates with a 'B' that it's a modified binary and the following notation is used to differentiate various builds: The printer symbol before the SVN revision number indicates infrared-enabled binaries as usual, 'C' indicates a binary that requires the crystal oscillator (whether or not it has the stopwatch included), 'N' indicates a binary that doesn't support the crystal and won't use it even if present, and no symbol indicates a binary that can optionally make use of the crystal.

[Dieter]

(02-07-2015 09:05 PM)Bit Wrote:  I've updated the builds and added a new feature: Significant figures display modes.

There is an issue in SIG mode if the DISP function is used. It noticed this on a 31s with version 1.2 3748. Set SIG 5 and press the pi key. You get the expected 3,14159. Set DISP 7 to get 3,1415927 which is fine either. Now try DISP 8 and the display shows 3,0 ⁰. So the display looks like SCI 1, but X is rounded as in SCI 0. Another DISP 8 yields 3,14159265 ⁰, like in SCI 8. So the first "DISP 8" indeed seems to have set the 31s to SCI mode.

Dieter

[Bit]

(03-04-2015 01:18 PM)Dieter Wrote:  There is an issue in SIG mode if the DISP function is used. It noticed this on a 31s with version 1.2 3748. Set SIG 5 and press the pi key. You get the expected 3,14159. Set DISP 7 to get 3,1415927 which is fine either. Now try DISP 8 and the display shows 3,0 ⁰. So the display looks like SCI 1, but X is rounded as in SCI 0. Another DISP 8 yields 3,14159265 ⁰, like in SCI 8. So the first "DISP 8" indeed seems to have set the 31s to SCI mode.

Thank you for reporting this issue!

The argument limit for the DISP command wasn't handled correctly: there needs to be a special case for SIG and SIG0 there. Fortunately it's quite easy to fix, see the two patches below. I don't have more time to work on this right now, but I'll commit the fixes to SVN and update my binaries at some later point.

Code:

diff -ur wp34s_r3757/keys.c wp34s_fix_DISP_in_SIG_modes_r3757_20150304/keys.c
--- wp34s_r3757/keys.c    2015-02-07 13:09:17.000000000 -0500
+++ wp34s_fix_DISP_in_SIG_modes_r3757_20150304/keys.c    2015-03-04 08:49:19.086944778 -0500
@@ -1248,10 +1248,15 @@
 }
 
 static int arg_digit(int n) {
+    int lim;
+#ifdef INCLUDE_SIGFIG_MODE
+    int dispmode = get_dispmode_digs(&lim);
+    const unsigned int base = (State2.runmode && CmdBase == RARG_DISP && (dispmode == MODE_SIG || dispmode == MODE_SIG0) ? RARG_SIG : CmdBase);
+#else
     const unsigned int base = CmdBase;
+#endif
     const unsigned int val = State2.digval * 10 + n;
     const int is_reg = argcmds[base].reg || State2.ind;
-    int lim;
     
     if (State2.local) {
         // Handle local registers and flags
diff -ur wp34s_r3757/xeq.c wp34s_fix_DISP_in_SIG_modes_r3757_20150304/xeq.c
--- wp34s_r3757/xeq.c    2015-02-07 13:09:17.000000000 -0500
+++ wp34s_fix_DISP_in_SIG_modes_r3757_20150304/xeq.c    2015-03-04 08:42:44.882954272 -0500
@@ -2195,8 +2195,11 @@
 
     if (op != RARG_DISP)
         dispmode = (op - RARG_STD) + MODE_STD;
-    dispdigs = arg;
-    set_dispmode_digs(dispmode, dispdigs);
+    else if ((dispmode == MODE_SIG || dispmode == MODE_SIG0) && arg >= 8) {
+        err(ERR_RANGE);
+        return;
+    }
+    set_dispmode_digs(dispmode, arg);
 #else
     UState.dispdigs = arg;

Code:

diff -ur wp31s_r3757/keys.c wp31s_fix_DISP_in_SIG_modes_r3757_20150304/keys.c
--- wp31s_r3757/keys.c    2015-02-07 13:09:33.000000000 -0500
+++ wp31s_fix_DISP_in_SIG_modes_r3757_20150304/keys.c    2015-03-04 08:49:26.186944606 -0500
@@ -826,10 +826,15 @@
 }
 
 static int arg_digit(int n) {
+    int lim;
+#ifdef INCLUDE_SIGFIG_MODE
+    int dispmode = get_dispmode_digs(&lim);
+    const unsigned int base = (State2.runmode && CmdBase == RARG_DISP && (dispmode == MODE_SIG || dispmode == MODE_SIG0) ? RARG_SIG : CmdBase);
+#else
     const unsigned int base = CmdBase;
+#endif
     const unsigned int val = State2.digval * 10 + n;
     const int is_reg = argcmds[base].reg || State2.ind;
-    int lim;
 
     if (State2.local) {
         // Handle local registers and flags
diff -ur wp31s_r3757/xeq.c wp31s_fix_DISP_in_SIG_modes_r3757_20150304/xeq.c
--- wp31s_r3757/xeq.c    2015-02-07 13:09:33.000000000 -0500
+++ wp31s_fix_DISP_in_SIG_modes_r3757_20150304/xeq.c    2015-03-04 08:42:59.254953926 -0500
@@ -1692,8 +1692,11 @@
 
     if (op != RARG_DISP)
         dispmode = (op - RARG_STD) + MODE_STD;
-    dispdigs = arg;
-    set_dispmode_digs(dispmode, dispdigs);
+    else if ((dispmode == MODE_SIG || dispmode == MODE_SIG0) && arg >= 8) {
+        err(ERR_RANGE);
+        return;
+    }
+    set_dispmode_digs(dispmode, arg);
 #else
     UState.dispdigs = arg;
     if (op != RARG_DISP)

[DMaier]

With this build, the calculator crashes (Bye...) when inverting a matrix. The matrix I tried:

\[ \left( \begin{array}{ccc}
11 & 22 & 33 \\
44 & 55 & 66 \\
9 & 8 & 7 \end{array} \right)\]

[Paul Dale]

This will, most likely, be the stack running into the volatile variables. The matrix routines are pushing closest to the limit of available memory.

It might be possible to rearrange the layout of the volatile RAM to prevent this. Reducing the maximum matrix size to 9x9 should also work.


- Pauli

[emece67]

(05-23-2015 09:42 PM)DMaier Wrote:  With this build, the calculator crashes (Bye...) when inverting a matrix. The matrix I tried:

\[ \left( \begin{array}{ccc}
11 & 22 & 33 \\
44 & 55 & 66 \\
9 & 8 & 7 \end{array} \right)\]

Such matrix is singular, perhaps calling M-1 over it is not a good idea.

In any case, the flash image compiled from the current SVN sources (3791) also resets when forced to invert that matrix, so, perhaps, Bit's patches are not the culprit.

Regards.

[Dieter]

(05-24-2015 06:27 PM)emece67 Wrote:  Such matrix is singular, perhaps calling M-1 over it is not a good idea.

I tried this matrix with the "offiical" version 3.3 3742. Here DET returns 3,63 E–31 which of course means that the determinant is zero. But the 34s does not throw a "Singular Error", like it does when you try to invert and then re-invert this matrix. Yes, the 34s actually does the inversion, but of course the result is meaningless.

In any case the device does not turn off or reset. Maybe the firmware should display a warning if the determinant is that close to zero. But where is the limit, and what about matrices whose determinant indeed is that small?

Dieter

[DMaier]

(05-24-2015 06:27 PM)emece67 Wrote:  

(05-23-2015 09:42 PM)DMaier Wrote:  With this build, the calculator crashes (Bye...) when inverting a matrix. The matrix I tried:

\[ \left( \begin{array}{ccc}
11 & 22 & 33 \\
44 & 55 & 66 \\
9 & 8 & 7 \end{array} \right)\]

Such matrix is singular, perhaps calling M-1 over it is not a good idea.

Excellent point. However, the same thing happens with this matrix, which is not singular:

\[ \left( \begin{array}{ccc}
11 & 22 & 33 \\
44 & 55 & 66 \\
8 & 8 & 7 \end{array} \right)\]

The inverse is actually calculated before the calculator crashes. I believe this is consistent with what Pauli is saying.

[Paul Dale]

There are ways to verify the stack/volatiles clash.

Reduce the maximum matrix size and the inversion code will use less RAM. This would identify the issue but not help fix it (unless smaller matrices are okay 10x10 is pretty large).

Another option would be to rework the Doolittle LU decomposition to use decimal64's for the intermediate matrix rather than decimal128's. Again, this will show if memory is running out and provide a solution where the accuracy is reduced but the matrix operations still work up to 10x10.


- Pauli

[emece67]

Reducing the maximum matrix size to 9x9 seems to solve the issue.

Regards.

[emece67]

I'm having trouble with the UNIVERSAL_DISPATCH feature.

Enabling it, rebuilding and then calling Norml (with DBL mode disabled), with J=0, K=1 and X=3 returns the correct answer, but enables DBL mode. This also happens with other prob functions, such as t(x) (but not with any input parameters, only with some combinations of them).

At first I thought the problem was in the LN[GAMMA] code, but after fixing an issue with this code, the odd behavior in Norml remains. The only way I've found to solve it is disabling UNIVERSAL_DISPATCH.

This only happens in the real machine, the emulator works OK.

Can anybody confirm this?

[Paul Dale]

I suspect this is an interaction between the XROM xIN and xOUT commands and the universal dispatch. I've had a quick look at the code but found nothing obvious. Bit might have a better idea what's going on.

The main builds don't use this feature at this point, even though it is a better dispatch mechanism in many ways.


- Pauli

[Bit]

(07-10-2015 11:58 PM)emece67 Wrote:  I'm having trouble with the UNIVERSAL_DISPATCH feature.

Enabling it, rebuilding and then calling Norml (with DBL mode disabled), with J=0, K=1 and X=3 returns the correct answer, but enables DBL mode. This also happens with other prob functions, such as t(x) (but not with any input parameters, only with some combinations of them).

At first I thought the problem was in the LN[GAMMA] code, but after fixing an issue with this code, the odd behavior in Norml remains. The only way I've found to solve it is disabling UNIVERSAL_DISPATCH.

This only happens in the real machine, the emulator works OK.

Can anybody confirm this?

Confirmed. Very weird, thank you for reporting it. I'll investigate it further when I have some time.

[Bit]

I've updated the binaries based on the latest source from SVN, no new features this time.