Complex Lock mode for WP-34s

[Nigel (UK)]

This post presents a "complex lock" mode for the WP-34s. At the end of the post are links to a firmware patch file (taken relative to build 3769), a zip file of the windows emulator that runs this firmware, a calc.bin file containing the firmware, and some documentation of the features of this new mode.

Complex lock mode has been developed jointly by Jeff O (motivation, lots of user interface suggestions and bug-spotting) and myself (coding).

The WP-34s already has wonderful support for complex numbers. However, doing a long series of such calculations is not as easy as it could be. Real and imaginary parts have to be entered in reverse order, a zero imaginary part is needed even when a number is purely real, and CPX must be pressed before each operation. This complex lock mode doesn't try to add any totally new features, but rather tries to make it easier to use the powerful features that the WP-34s already has.

Turning on complex lock mode for the first time is a two-step process. On a calculator or an emulator running the new firmware, execute CPXYES from the Mode menu. Then pressing (right-arrow) + CPX enters the new mode. (The small "=" sign lights up to show that the mode has been entered.) Pressing (right-arrow) + CPX again returns to normal mode; executing CPXNO from the Mode menu prevents the mode being reactivated until CPXYES is executed once more.

The reason for the two-step process is to stop a user from entering the mode accidentally. If this isn't a concern, one can execute CPXYES and forget about doing it again, at least until the calculator is reset.

To do the calculation (40+12i)*(3+5i), press:

Code:


40 CPX 12 ENTER 3 CPX 5 *

Here's the screen as the first "4" is pressed ...



and after CPX is pressed ...



and just before ENTER is pressed ...



and after ENTER is pressed ...

.

CPX separates the real and imaginary parts of a number. To multiply the result of this calculation by 3, simply press

Code:


3 *

The imaginary part is automatically set to zero. To multiply by 4i, press

Code:


CPX 4 *

and the real part is automatically entered as zero.

Number entry can be terminated with CPX instead of ENTER. Pressing

Code:


40 CPX 12 CPX

puts 40+12i "on the stack", leaving stack lift set. So the first calculation can equally well be done as

Code:


40 CPX 12 CPX 3 CPX 5 *

The difference is that this second method of doing the calculation doesn't push anything off the top of the stack until entry of the second number begins.

When entering complex lock mode the stack is automatically set to 8 levels (the prior setting is saved, and restored later). The real and imaginary parts of complex numbers are stored in pairs of registers just as they would be normally, so that there is always a four-level stack for complex number calculations.

Most functions on the keyboard do their normal "complex" thing - so to find the square root of 4+2i, press

Code:


4 CPX 2 D

Memory operations have been restricted to even register numbers, so that trying to store a number in register 01 will give an error. This stops complex numbers in memory from overlapping and corrupting each other.

There is also a polar entry mode available in which complex numbers are entered and displayed as (modulus, argument) pairs. In this mode the real and imaginary parts of complex numbers are still stored in the stack so that all of the WP-34s functions continue to work correctly. See the attached Word document for details of this and other features. Here's a picture:


Finally - and this is the icing on the cake for all you electrical engineers out there - there are two more commands in the Mode menu, CPXI and CPXJ. CPXJ displays complex numbers with a "j" instead of an "i". Great!

What's not to like? Several things.

• Memory. The firmware is now significantly bigger and so there is less flash memory available for program storage. The firmware including the crystal and the printer is currently too big to fit in the available space, although it may be possible to fix this.
• Flags. When coding this I needed flags; lots of them. I have taken them from the user flags. To stop user programs changing these flags and accidentally entering complex lock mode this firmware prevents users from setting or resetting flags 80-99 from the keyboard or from a program, both in and out of complex lock mode. (This firmware actually only uses flags 92-99; I put 80 as the limit to see the extent of flag deprival that people would be willing to tolerate!)
• Registers. In complex lock mode, registers J and K are used for various purposes. Their contents will be overwritten when using the mode, but they remain perfectly accessible otherwise.
• Existing programs corrupted. Jeff O has found that when loading the new firmware the programs stored in his calculator sometimes change and need to be edited or re-entered. This is probably due to op-code changes, although I did try to avoid these. Be aware of this if your calculator contains precious programs that are not yet backed up.
• Complex numbers. This is a complex lock mode. If you don't use complex numbers, this mode won't be at all helpful! (Obviously.)
  

Here are some comments on the code for anyone who wants to look at it:

• Errors. Complex lock mode adds two new error messages. The latter part of the code in errors.h seems to double in size each time a new error message is added. I've re-written it so that this doesn't happen; I'm not claiming that my solution is elegant, but it does seem to work. The original code is still there as a comment.
• Flags. The flag restriction code can be separated out and used independently of the rest if anyone else wants to write a firmware extension that makes use of user flags. I haven't done this because I am sure that other people can do it better. To find the flag code, look for LIMIT_FLAGS in the source code.
• Improvements. These are clearly possible; I'm not a programmer and I don't have an understanding of the finer aspects of the WP-34s firmware. Feel free to suggest or to make them, especially anything that makes the compiled code smaller!
  

We'd like to hear what you think - what do you want from a complex mode? How can this one be improved? Is the whole approach fundamentally wrong? We both like it and we hope that some of you will, too, but we don't imagine that the current system is the final word.

Nigel (UK) and Jeff O

Edit: slightly updated version (12/04/15, or 04/12/15 for the US!).

• Entry of numbers in polar display mode is now slightly faster.
• Entering a constant from the constant menu accessed via h + ENTER completes the entry of the number currently being entered before adding the constant to the stack.
• If the constant menu is accessed via f + ENTER then numeric entry is not completed before the constant is entered. This allows complex numbers to be built up with constants in the real and/or imaginary parts.
• The unpopular "Mod:" and "Arg:" have been replaced by "Length:" and "Angle:".
  

Edit: another small update (13/04/15) incorporating a suggestion from Pauli for improving entry speed in polar display mode.

Edit: another small update (19/04/15) incorporating another polar display mode speed-up, some bug fixes, and firmware that no longer uses user flags.

Edit: code tidying and a fix for a bug that prevented the QT emulator from compiling.

The downloads below have been updated.

• Link to calc.bin file.
• Link to calc_xtal.bin file
• Link to zip file containing windows emulator.
• Link to patch file - accidentally omitted first time around!
• Link to wp34s.op file
  
  

[Jeff O.]

(03-16-2015 08:03 PM)Nigel (UK) Wrote:  ...Complex lock mode has been developed jointly by Jeff O (motivation, lots of user interface suggestions and bug-spotting) and myself (coding).

Rest assured that Nigel did all of the hard work. I just asked for features and tested the versions he developed.

The process started quite a while ago. I believe I first contacted Nigel back in January 2013, regarding the 2-line display mode that he had developed and introduced at the Forum. We corresponded a few times, and I eventually decided to ask him if he could implement something I had really, really wanted for a long time, some sort of complex operating mode for the wp34s. Nigel was receptive to the idea, but of course could not promise anything. I inquired once (around November 2013) regarding progress. He said he had done some work and actually had a preliminary version with a complex lock feature. I was glad to hear that, but did not want to be a pest so I did not inquire again.

I had kind of forgotten about it, when out of the blue on January 3rd, 2015, Nigel sent me a message asking if I was still interested in a complex mode for the wp34s. I replied that I certainly was, and he soon sent me his first version. I tested, requested changes, Nigel complied with most requests and/or improved on my suggestions and/or added new features that he thought of and sent new versions. We repeated this process for a few rounds. Nigel was very patient with my many requests. I thought we were about done, when again, out of the blue, he sent me a version with the polar entry/display mode. I had certainly wanted such a mode, but figured that would be over-the-top and had never even asked for it. A couple more rounds of testing and bug finding and we arrived at the version Nigel just presented.

I think it is a very useful addition to the capabilities of the wp34s. I hope that at least some wp34s users will find it useful. I'll try to answer any questions or offer input as to why it does this or that.

Thanks again Nigel. Fantastic work!

[BarryMead]

I downloaded and experimented with the windows emulator version of this program, and I have to say, I love this feature! It makes the WP-34s even more convenient with complex numbers than the HP-15C, because you can see both parts of the number at the same time. Also there is no confusion about which part of the number you are entering with the "Real" and "Imag" labels. Nice implementation! After reading your initial posting on this feature I did have two questions:

1. Are the patch files (source changes) available for download so that one could make changes, or compile a Linux Qt version of the emulator? Source is also essential if you want feedback on possible improvements.
2. If you changed the op codes, do you have a copy of the altered "wp34s.op" file, so that users of the assembler and library tools can automate the compilation of their programs to match these op code changes?

Thanks

I do have one suggestion. In the "Polar" entry mode, I think the labels "Length:" and "Angle:" would be more descriptive of the polar coordinates being entered than "Mod" and "Arg" for most people.

[Paul Dale]

Great work. Well thought out and implemented.

There is no alternative to stealing code space from the libraries in flash, which we tried to avoid as far as possible to keep the 34S as flexible as possible. Still, many people would consider the flash well spent. Just how much library space is left after this modification?

However, it should be possible to steal some RAM away from program memory instead of the user flags (another resource we avoided using, although it would have made life easier to use them liberally several times). You are using eight bits worth of flags which is one instruction with another eight bits to spare. There are still a couple of bits in the system flags space still (two without printer support and a third without Y-reg display) which are saved and restored by STOM / RCLM. These would suffice for the complex mode enabled/disabled and the complex mode on/off. Not sure where i/j display fits in.


Thought about a 34C branch? Maybe 34i is a better name to avoid confusion (34j is just plain wrong . I am always happy to give people SVN access to the project if they can make genuine contributions which this clearly is.


And please release your source code, the project is GPL which means code changes must be made available if the binaries are.


- Pauli

[Nigel (UK)]

(03-17-2015 07:31 AM)Paul Dale Wrote:  Great work. Well thought out and implemented.

There is no alternative to stealing code space from the libraries in flash, which we tried to avoid as far as possible to keep the 34S as flexible as possible. Still, many people would consider the flash well spent. Just how much library space is left after this modification?

However, it should be possible to steal some RAM away from program memory instead of the user flags (another resource we avoided using, although it would have made life easier to use them liberally several times). You are using eight bits worth of flags which is one instruction with another eight bits to spare. There are still a couple of bits in the system flags space still (two without printer support and a third without Y-reg display) which are saved and restored by STOM / RCLM. These would suffice for the complex mode enabled/disabled and the complex mode on/off. Not sure where i/j display fits in.


Thought about a 34C branch? Maybe 34i is a better name to avoid confusion (34j is just plain wrong . I am always happy to give people SVN access to the project if they can make genuine contributions which this clearly is.


And please release your source code, the project is GPL which means code changes must be made available if the binaries are.


- Pauli

So sorry about the missing source code - I hope it's clear from my first post that I omitted it by mistake. I've added a link to the patch file and also to the wp34s.op file that goes with it.

I like the idea of a branch. It avoids cluttering up the main code with lots of extra compiler directives and given the size of the standard firmware there isn't really room for something like this in it by default. With the calc.bin file loaded my calculator reports "FL 2686" free.

Thank you for your helpful comments. I think I still have SVN access from a previous occasion on which I contributed some code but I won't use it without letting you know first!

Nigel (UK)

[Nigel (UK)]

(03-17-2015 12:51 AM)BarryMead Wrote:  I downloaded and experimented with the windows emulator version of this program, and I have to say, I love this feature! It makes the WP-34s even more convenient with complex numbers than the HP-15C, because you can see both parts of the number at the same time. Also there is no confusion about which part of the number you are entering with the "Real" and "Imag" labels. Nice implementation! After reading your initial posting on this feature I did have two questions:

1. Are the patch files (source changes) available for download so that one could make changes, or compile a Linux Qt version of the emulator? Source is also essential if you want feedback on possible improvements.
2. If you changed the op codes, do you have a copy of the altered "wp34s.op" file, so that users of the assembler and library tools can automate the compilation of their programs to match these op code changes?

Thanks

I do have one suggestion. In the "Polar" entry mode, I think the labels "Range:" and "Angle:" would be more descriptive of the polar coordinates being entered than "Mod" and "Arg" for most people.

Thank you for your comments. Source code is now linked to from the first post (sorry - its omission was my mistake) and the wp34s.op file is now there too.

I have no objection to Range: and Angle:. Is this a US thing? My background is physics and to me "modulus" and "argument" are the natural terms. Jeff O also wanted Range: and Angle: so it's 2-1 at the moment. In the source code the names are defined somewhere in display.c in the annunciators function, so they are easy to change.

Nigel (UK)

[Sanjeev Visvanatha]

(03-17-2015 07:31 AM)Paul Dale Wrote:  Thought about a 34C branch? Maybe 34i is a better name to avoid confusion (34j is just plain wrong .

I suggest 34cx.

[Jeff O.]

(03-17-2015 11:28 AM)Nigel (UK) Wrote:  I have no objection to Range: and Angle:. Is this a US thing? My background is physics and to me "modulus" and "argument" are the natural terms. Jeff O also wanted Range: and Angle: so it's 2-1 at the moment. Nigel (UK)

I actually would prefer "magnitude" (Mag) and Angle, but that may be an EE thing. But it is no big deal. The only (weak) argument I have against Mod is that there is of course a "Mod" function on the calculator, and it seems like the same three letters should not have two uses or meanings on the same machine.

[BarryMead]

(03-17-2015 11:48 AM)Jeff O. Wrote:  

(03-17-2015 11:28 AM)Nigel (UK) Wrote:  I have no objection to Range: and Angle:. Is this a US thing? My background is physics and to me "modulus" and "argument" are the natural terms. Jeff O also wanted Range: and Angle: so it's 2-1 at the moment. Nigel (UK)

I actually would prefer "magnitude" (Mag) and Angle, but that may be an EE thing. But it is no big deal. The only (weak) argument I have against Mod is that there is of course a "Mod" function on the calculator, and it seems like the same three letters should not have two uses or meanings on the same machine.

I agree that "Mod" is a confusing choice for the (Vector Length, Range, Magnitude) part of the polar pair for the reason you gave, and for one additional reason. Vector Length's don't repeat, but Angular components repeat themselves modulo 2 PI or 360 degrees so when I saw the label "Mod" I was confused thinking it might represent the angular component of the polar coordinate pair. Anyway "Mod" and "Arg" don't give any clue as to weather they represent length or angular properties, that is why I suggested "Range" and "Angle" which clearly do.

Any of the following Label sets would work equally well and be easier for users, perhaps ask Jeff and a few other people which sounds better to them:
1. "Range" "Angle"
2. "Length" "Angle"
3. "Mag" "Angle"

I like 1 and 2 better than 3, but it is more of a personal preference kind of thing.

About the history of the terms Range and Angle. I think they may have originated from Artillary, or Submarine backgrounds. The "Range" to target is a Distance component and the "Angle" is an angular aiming component. The words are relatively short, and descriptive which is why I suggested them as data entry labels. I come from an Electronics Engineering background myself.

[BarryMead]

I downloaded the patch file "cmode.patch" and attempted to apply these patches to the source for both SVN versions 3767 (shown in patch files) and 3769 (shown in posting), and NEARLY ALL of the patch hunks FAILED.

I tried from the wp34s-3769/ directory with patch --ignore-whitespace -p0 <cmode.patch and from the wp34s-3769/trunk/ directory with patch --ignore-whitespace -p1 <cmode.patch and neither worked. I also tried the patch file with and without stripping out the non-unix carriage returns at the end of each line of the patch file, and the result was the same.

Do you have any patching instructions that you can CONFIRM work? Have you performed a fresh checkout of the source tree and test run of your patch files to confirm that they are built correctly and work as expected?

Thanks for your hard work and I appreciate any assistance you can provide in passing these source changes on to others to experiment with.

[Nigel (UK)]

(03-17-2015 08:26 PM)BarryMead Wrote:  I downloaded the patch file "cmode.patch" and attempted to apply these patches to the source for both SVN versions 3767 (shown in patch files) and 3769 (shown in posting), and NEARLY ALL of the patch hunks FAILED.

I tried from the wp34s-3769/ directory with patch --ignore-whitespace -p0 <cmode.patch and from the wp34s-3769/trunk/ directory with patch --ignore-whitespace -p1 <cmode.patch and neither worked. I also tried the patch file with and without stripping out the non-unix carriage returns at the end of each line of the patch file, and the result was the same.

Do you have any patching instructions that you can CONFIRM work? Have you performed a fresh checkout of the source tree and test run of your patch files to confirm that they are built correctly and work as expected?

Thanks for your hard work and I appreciate any assistance you can provide in passing these source changes on to others to experiment with.

Sorry about this - as you can probably tell, I'm not an expert. I made the patch file by first updating to 3767 (mistake in post, sorry), executing svn diff on each of the source code files that I had modified, and concatenating the outputs from these runs. I didn't check it would work before posting.

However, I've checked it now and it does work, for me at least. This is what I've done.

• First, I checked out a completely fresh copy of build 3769. This went into a directory called wp34s_latest - i.e., directories such as trunk, artwork, branches etc. are all subdirectories of this.
• I copied cmodes.patch into this directory and opened a DOS command window.
• I then typed svn patch cmodes.patch and the patches were applied correctly. There were small offsets of 5 and 3 lines for files keys.c and xeq.c (reflecting the differences between 3767 and 3769) but everything went through smoothly and the windows emulator builds.
  

I hope this helps. Maybe the problem is that my directory names don't include the version number as yours do?

Nigel (UK)

[Nigel (UK)]

(03-17-2015 07:19 PM)BarryMead Wrote:  I agree that "Mod" is a confusing choice for the (Vector Length, Range, Magnitude) part of the polar pair for the reason you gave, and for one additional reason. Vector Length's don't repeat, but Angular components repeat themselves modulo 2 PI or 360 degrees so when I saw the label "Mod" I was confused thinking it might represent the angular component of the polar coordinate pair. Anyway "Mod" and "Arg" don't give any clue as to weather they represent length or angular properties, that is why I suggested "Range" and "Angle" which clearly do.

Any of the following Label sets would work equally well and be easier for users, perhaps ask Jeff and a few other people which sounds better to them:
1. "Range" "Angle"
2. "Len" "Ang"
3. "Mag" "Ang"

I like 1 and 2 better than 3, but it is more of a personal preference kind of thing.

About the history of the terms Range and Angle. I think they may have originated from Artillary, or Submarine backgrounds. The "Range" to target is a Distance component and the "Angle" is an angular aiming component. The words are relatively short, and descriptive which is why I suggested them as data entry labels. I come from an Electronics Engineering background myself.

Out of the three choices above, I prefer "Range" and "Angle". As you say, they are descriptive and unambiguous.

I chose "Mod" and "Arg" - short for modulus and argument - because that's what I've always called these two properties of a complex number; I think they are standard mathematical terms. I'm quite happy to change, though.

Nigel (UK)

[Jeff O.]

(03-17-2015 07:19 PM)BarryMead Wrote:  Any of the following Label sets would work equally well and be easier for users, perhaps ask Jeff and a few other people which sounds better to them:
1. "Range" "Angle"
2. "Len" "Ang"
3. "Mag" "Ang"

I like 1 and 2 better than 3, but it is more of a personal preference kind of thing.

About the history of the terms Range and Angle. I think they may have originated from Artillary, or Submarine backgrounds. The "Range" to target is a Distance component and the "Angle" is an angular aiming component. The words are relatively short, and descriptive which is why I suggested them as data entry labels. I come from an Electronics Engineering background myself.

I will admit to never having heard of the term "range" used in this context. So I like 2 and 3 better than 1, with 3 being my preference.

(03-17-2015 10:13 PM)Nigel (UK) Wrote:  I chose "Mod" and "Arg" - short for modulus and argument - because that's what I've always called these two properties of a complex number; I think they are standard mathematical terms. I'm quite happy to change, though.

Nigel (UK)

Let's use another flag to pick our preference! (Just kidding, I'm perfectly satisfied with Mod and Arg, or Mag and Ang, or Abs and Ang, or Abs and Arg, or Len and Ang...)

[Jonathan Cameron]

(03-17-2015 07:19 PM)BarryMead Wrote:  Any of the following Label sets would work equally well and be easier for users, perhaps ask Jeff and a few other people which sounds better to them:
1. "Range" "Angle"
2. "Len" "Ang"
3. "Mag" "Ang"

I like 1 and 2 better than 3, but it is more of a personal preference kind of thing.

I prefer options 3 or 2.

-Jonathan

[BarryMead]

(03-17-2015 09:58 PM)Nigel (UK) Wrote:  Sorry about this - as you can probably tell, I'm not an expert. I made the patch file by first updating to 3767 (mistake in post, sorry), executing svn diff on each of the source code files that I had modified, and concatenating the outputs from these runs. I didn't check it would work before posting.

However, I've checked it now and it does work, for me at least. This is what I've done.

• First, I checked out a completely fresh copy of build 3769. This went into a directory called wp34s_latest - i.e., directories such as trunk, artwork, branches etc. are all subdirectories of this.
• I copied cmodes.patch into this directory and opened a DOS command window.
• I then typed svn patch cmodes.patch and the patches were applied correctly. There were small offsets of 5 and 3 lines for files keys.c and xeq.c (reflecting the differences between 3767 and 3769) but everything went through smoothly and the windows emulator builds.
  

I hope this helps. Maybe the problem is that my directory names don't include the version number as yours do?

Nigel (UK)

Originally the svn 1.6 included with my Debian Wheezy Linux, did not have the "svn patch" sub-command that you used. The "svn patch" sub-command was not added until svn 1.7. I found a special wheezy port of svn 1.7 and managed to install it described here. Now I have access to the "svn patch" sub-command and patching works as you described. Thanks for the tip.

[Sanjeev Visvanatha]

I tried the Windows emulator. This is a more natural way of using Complex numbers, IMO. In your Word documentation, I think g+up-arrow should refer to Px,y and f+up-arrow should refer to Cx,y.

[BarryMead]

(03-18-2015 02:13 AM)Sanjeev Visvanatha Wrote:  I tried the Windows emulator. This is a more natural way of using Complex numbers, IMO. In your Word documentation, I think g+up-arrow should refer to Px,y and f+up-arrow should refer to Cx,y.

Adding to what Sanjeev said, the actual calculator (and emulator) DO work the logical way "g ^" is Polar "Py,x" and "f ^" is Complex "Cy,x" it's only backwards in the word document.

[Bit]

This looks like a very useful feature indeed!

[Nigel (UK)]

(03-18-2015 02:49 AM)BarryMead Wrote:  

(03-18-2015 02:13 AM)Sanjeev Visvanatha Wrote:  I tried the Windows emulator. This is a more natural way of using Complex numbers, IMO. In your Word documentation, I think g+up-arrow should refer to Px,y and f+up-arrow should refer to Cx,y.

Adding to what Sanjeev said, the actual calculator (and emulator) DO work the logical way "g ^" is Polar "Py,x" and "f ^" is Complex "Cy,x" it's only backwards in the word document.

Thanks for this - now corrected.

Nigel (UK)

[Jeff O.]

(03-18-2015 02:50 AM)Bit Wrote:  This looks like a very useful feature indeed!

Bit, you seem to be very adept at code optimization. If you have the time, willingness, and desire to do so, please take a look at the code for possible improvements in code size, to preserve library space and space for crystal and printer options. Also, the polar mode operating speed is a little sluggish for certain operations (principally on entry of a new polar value), so that could also be a candidate for optimization.

This request should in no way be interpreted as expressing dissatisfaction with Nigel's work. I checked with Nigel first, he said he would not be insulted if I asked you to take a look at the code, because as said above, you are very adept.