Complex Lock mode for WP-34s

[Nigel (UK)]

New build now committed - changes only made to the complex branch, so no-one else need worry! The .bin files for the calculator and the emulator file are compiled without ENTRY_RPN turned on, so if you want to see the effect of this addition you'll have to define this option in features.h and compile the code yourself! (If anyone wants a bin file to experience ENTRY_RPN on their calculator I am happy to provide one.)

However, before you all rush in I should tell you that there is a Problem. So far as I can see the emulator works perfectly. However, calculating the inverse normal distribution (e.g., 0.4 [g] [4]) on the calculator fails. Two similar but incorrect numbers are returned to the stack, and the calculator switches to double-precision mode. This happens on the calculator when the firmware is compiled with INCLUDE_C_LOCK defined, and not otherwise. As I've said, it doesn't happen in the emulator.

I don't know the reason for this. It isn't the fault of ENTRY_RPN! (The problem also doesn't appear if I compile with EXTRA_FLAGS turned on but with INCLUDE_C_LOCK undefined.) The C_LOCK code is fairly innocent, consisting mostly of extra menu entries and added functions, so I'm not sure what problem it is causing. A workaround might be to revert the relevant xrom files (where the normal distribution code lives) to earlier versions (there was a big change at version 3751) but there is no guarantee that this will fix the problem.

I certainly don't expect anyone else to work on this - it's 2019, not 2015, and people have moved on. But if anyone has any idea of the sort of issue that could cause this problem on the calculator but not on the emulator, that might be helpful.

Nigel (UK)

[Jaco@cocoon-creations.com]

I compiled and tested all the new compile options (and a few older ones) at once and flashed into a 30B. Except for the suspect behaviour mentioned, it works as expected.

I noticed that the new WP34C emulator graphic (with blue slant and above key labels) was not included in the release though. For convenience I re-attach it here in a zip file, now complete with the skin file.

In addition, I attach a similar WP34S skin file which I use, as I prefer the labels above key. Maybe that can be added too.

Testing of different firmware follows below. Bottom line is that not only the WP34C (complex lock) is influenced by this inverse normal distrubution problem, but also the distributed WP34S binary files work differently from my new re-compiled WP34S binaries. This to me point to either compiler issues or the WP34S features I included (stopwatch, universal dispatch, easter, factors, eex_pi, doubledot, warning upper line, SIGFIG, YREG ON, Datemode 1). I haven't had time to isolate the problem.

Hardware tests:
I get the same IDENTICAL behaviour from 0.4 [g] [4] on the following firmware. The values are not pushed onto the stack, but displayed, and upon pressing anything, even [f] only, the values are removed from the screen. The remaining X after the operation content is not consistent. The calculator is changed to, and left in DOUBLE mode:

Code:


D0.25381275
-1.63336609383

a. original unmodified WP34C distributed 3901 calc_full.bin.
b. my WP34C hack with eRPN, based on 3901 back in Feb 2019, both calc.bin & calc-full.bin.
c. new WP34S 3901 re-compiled yesterday.
d. new WP34C 3902 compiled with all new options and INCLUDE_C_LOCK defined.


The WP34S distributed versions produce the result on the stack, as do the emulators below.

e. WP34S 3844
f. WP34S 3901

Code:


0
-0.25334710314

Emulators:
The WP34S 3901 emulators produce different IDENTICAL results. The value is pushed onto the stack. The calculator is not left in DOUBLE mode:

0
-0.25334710314

a. WP34S 3901 re-compiled yesterday.
b. WP34S 3844 distributed calc-full.bin.
c. WP34C 3902 re-compiled yesterday.



  WP34C emulator skin4 (branches).zip (Size: 193.19 KB / Downloads: 10)
  WP34S emulator skin5 (trunk).zip (Size: 190.62 KB / Downloads: 10)

[Nigel (UK)]

Universal dispatch it is! Commenting this out in features.h removes the problem. I've been using it because it saves 280 bytes (important for Complex Lock mode) (and it sounds cool!) and I'd never noticed a problem until now.

I shall shortly post an update including this, along with the emulator skins that I forgot to include previously.

Nigel (UK)

[Nigel (UK)]

Build 3903 now committed. Once again, no changes to the main branch. I've included Entry RPN versions of the Complex Lock Mode emulator and calculator firmware files for those who are interested. There are also new emulator skins from Jaco@cocoon-creations.com for both the main and complex branches.

The problem with the inverse normal distribution has been present in all versions of complex lock mode. It seems that Universal Dispatch was the cause, and this is why the same problem appeared in the main branch when compiled with this option.

Enjoy!

Nigel (UK)

[Jaco@cocoon-creations.com]

Bad news. I tested the eRPN builds and found that since the Universal Dispatch is gone, eRPN is breaking something in the Complex Lock mode.

It can easily be seen in both the emulator and real calculator when (with a clear stack), [2] [ENTER] [3] [+] results in 3. Weirder results happen when there are other numbers in the stack.

With Complex Lock off, all is well and 2 + 3 = 5.

I will try get more clarity on how the bug behaves, and even try follow the flow of your Complex logic. I will be out of town for a few days, so this will happen later only.

Just to confirm, the issue is only in the newly fiddled with code in the Complex Branch and no issues are in the WP34S main build.

[Nigel (UK)]

Good news! I've found the problem and committed what I believe to be a fix (version 3904). An extra piece of entry_rpn-only code was needed in the dispatch routine for niladic functions in xeq.c; this code wasn't called previously when universal dispatch was in place.

I have tested different combinations of complex lock and entry rpn in the emulator and things seem to work; I haven't had a chance to try this on the calculator yet.

Nigel (UK)

[Jaco@cocoon-creations.com]

I testing both on real calculators and on emulators using Nigel's latest committed complex Branch source and I can find no anomalies in the complex lock and eRPN operations.

A. In the process of testing complex chain calc's, I did however find an error in my text on both my WP34S and WP34C vinyl stickers and emulator skin graphics, which was so annoying that I just had to fix it. I scrapped the batch of vinyls and re-ordered a fixed batch. The error was that [f] [->] & [g] [->], aka R<>P, had the colours / arrows the wrong way, which adds a whole additional dimension of mental housekeeping when doing a chain of complex sums. It is now fixed, and the skins are re-done and in the linked file.

I added a third skin without "eRPN", so the new skins available are:

- 1. Complex Branch Emulator: "WP34C eRPN SCIENTIFIC", with "ENTRY RPN" bottom text.
- 2. Complex Branch Emulator: "WP34C RPN SCIENTIFIC".
- 3. Main (Trunk) Emulator: "WP34S RPN SCIENTIFIC".


B. I've been using Complex lock for some time now and I added two defines for two irritating features:

B1. there is no way of easily converting computed X, Y values to a complex number. This must be done by exiting complex mode to real mode [->] [CPX], calculating an angle, leaving it in Y, and also a length in X, returning to complex mode with [->] [CPX], then handling the P>R. This is ok, but a few times I got caught and lost complex numbers in the stack when returning to a 4 level stack in real mode. I fixed this by including a default 8 level stack.

#define DEFAULT_TO_SSIZE8

B2. the complex mode trig works in radians (I wish not), I often need to convert RAD <> DEG, and also change modes RAD or DEG for this reason. To make this easier, I copied Bit's "reverse arrow" method verbatim to the Complex Branch, to more easy do RAD <> DEG conversions in both ways. This works in both complex and real modes.

#define REVERSE_ARROW // This is Bit's method Reverse angular conversions

C. Furthermore, I added a default to set the date format to YMD as the existing define DEFAULT_DATEMODE define seemed to have an issue.

#define DEFAULT_DATE_YMD
#define DEFAULT_DATE_MDY


D. I added registry files and readme, such as to edit the files for emulator path and file name, then it will adjust the registry to make Windows call the WP34C emulator when "Calc" is pressed on the Windows keyboard.

E. Finally, I did a patch file. I hope I understood that right, i.e. that the patch file is just a text file containing the DIFF between the last published version and the edits made. I quite like the colour coding in the patch file, so I also include a PDF file for readability.

F. The files, i.e. the skins, source files and patch files are linked. There is no hurry, but if it is not too sloppy, include it next time. At least add the skin updates, they are quite nice:

http://www.cocoon-creations.com/download...0patch.zip


Jaco


Edit: corrected skin title A.3 to ‘WP34S’.

[Nigel (UK)]

Build 3905 now committed. This corrects an anomaly in the behaviour of entry RPN, adds the updated skin files, and includes an option to set the Windows calc key to call this calculator by default.

Many thanks to Jaco for this, to Jeff O for his huge input into the original complex lock mode design, and to everyone else involved with the WP34S project, which continues to give me and others great pleasure even after all this time!

Nigel (UK)