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

02072015, 09:05 PM
Post: #21




RE: Bit's WP 34S and 31S patches and custom binaries (version: r3747 201502071)
I've updated the builds and added a new feature: Significant figures display modes. As requested, I now publish wp34s.op and wp34slib.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 infraredenabled 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. 

03042015, 01:18 PM
(This post was last modified: 03042015 01:23 PM by Dieter.)
Post: #22




RE: Bit's WP 34S and 31S patches and custom binaries (version: r3747 201502071)
(02072015 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 ^{0}. So the display looks like SCI 1, but X is rounded as in SCI 0. Another DISP 8 yields 3,14159265 ^{0}, like in SCI 8. So the first "DISP 8" indeed seems to have set the 31s to SCI mode. Dieter 

03042015, 01:57 PM
Post: #23




RE: Bit's WP 34S and 31S patches and custom binaries (version: r3747 201502071)
(03042015 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 ^{0}. So the display looks like SCI 1, but X is rounded as in SCI 0. Another DISP 8 yields 3,14159265 ^{0}, 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 Code: diff ur wp31s_r3757/keys.c wp31s_fix_DISP_in_SIG_modes_r3757_20150304/keys.c 

05232015, 09:42 PM
Post: #24




Matrix Inversion Crashes: WP 34S custom binary (version: r3747 201502071)
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)\] 

05232015, 11:17 PM
Post: #25




RE: Bit's WP 34S and 31S patches and custom binaries (version: r3747 201502071)
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 

05242015, 06:27 PM
Post: #26




RE: Bit's WP 34S and 31S patches and custom binaries (version: r3747 201502071)
(05232015 09:42 PM)DMaier Wrote: With this build, the calculator crashes (Bye...) when inverting a matrix. The matrix I tried: Such matrix is singular, perhaps calling M1 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. 

05242015, 06:51 PM
Post: #27




RE: Bit's WP 34S and 31S patches and custom binaries (version: r3747 201502071)
(05242015 06:27 PM)emece67 Wrote: Such matrix is singular, perhaps calling M1 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 reinvert 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 

05262015, 05:51 AM
Post: #28




RE: Bit's WP 34S and 31S patches and custom binaries (version: r3747 201502071)
(05242015 06:27 PM)emece67 Wrote:(05232015 09:42 PM)DMaier Wrote: With this build, the calculator crashes (Bye...) when inverting a matrix. The matrix I tried: 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. 

05262015, 07:05 AM
Post: #29




RE: Bit's WP 34S and 31S patches and custom binaries (version: r3747 201502071)
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 

06022015, 12:45 PM
Post: #30




RE: Bit's WP 34S and 31S patches and custom binaries (version: r3747 201502071)
Reducing the maximum matrix size to 9x9 seems to solve the issue.
Regards. 

07102015, 11:58 PM
Post: #31




RE: Bit's WP 34S and 31S patches and custom binaries (version: r3747 201502071)
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? 

07112015, 12:09 AM
Post: #32




RE: Bit's WP 34S and 31S patches and custom binaries (version: r3747 201502071)
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 

08062015, 02:20 AM
Post: #33




RE: Bit's WP 34S and 31S patches and custom binaries (version: r3747 201502071)
(07102015 11:58 PM)emece67 Wrote: I'm having trouble with the UNIVERSAL_DISPATCH feature. Confirmed. Very weird, thank you for reporting it. I'll investigate it further when I have some time. 

08062015, 02:32 AM
Post: #34




RE: Bit's WP 34S and 31S patches and custom binaries (version: r3802 201508051)
I've updated the binaries based on the latest source from SVN, no new features this time.


« Next Oldest  Next Newest »

User(s) browsing this thread: 1 Guest(s)