WP 34S --> WP 31S

[Jeff O.]

(04-04-2014 12:37 PM)walter b Wrote:  The yReg display will be toggled by YDOFF / YDON. Probable default will be YDOFF on both the WP 34S and the WP 31S.

That sounds great. Thanks!

[BarryMead]

Does anyone know when the emulator is scheduled to be rebuilt?
I keep checking but the most recent build is still 4-days old.

[Jonathan Cameron]

(04-04-2014 10:02 PM)BarryMead Wrote:  Does anyone know when the emulator is scheduled to be rebuilt?
I keep checking but the most recent build is still 4-days old.

Barry,

I think a new build of the windows emulator should be out in the next day or two. Pauli has committed a fix for the ->RECT problem as well as some further y-display fixes. Try checking again tomorrow!

-Jonathan

[walter b]

(04-05-2014 09:17 AM)fhub Wrote:  But the fix for the non-working 8-level stack is still missing, too.

Seems I've missed something. What doesn't work?

d:-?

[walter b]

(04-05-2014 10:22 AM)fhub Wrote:  ... executing SSIZE8 simply does nothing, you still have only 4 stack levels (in the current WP31s).

Ooops, we'll look into that. Thanks for reporting.

d:-)

[Paul Dale]

(04-05-2014 11:03 AM)walter b Wrote:  Ooops, we'll look into that. Thanks for reporting.

I've found the errant line in question. Line 433 of xeq.c which is the conditional test in this code snippet:

Code:

int stack_size(void) {
    if (! UState.stack_depth || (! XromFlags.xIN))
        return 4;
    return 8;
}

The equivalent test on the 34S is:

Code:

    if (! UState.stack_depth || (is_xrom() && ! XromFlags.xIN))

The in xrom test has been lost along the line somewhere and the code thinks we're always in xrom with a small stack size


- Pauli

[John Smitherman]

I just flashed version 3597 successfully. :-)


John

[Jonathan Cameron]

(04-05-2014 05:20 PM)John Smitherman Wrote:  I just flashed version 3597 successfully. :-)

Marcus has just rebuilt the windows emulator for the 31s which includes a few fixes (the 8-level stack issue, requiring only one press of 0 to STO-0 or RCL-0, trig fixes), etc. It is version 3598. The realbuild flash image will probably be rebuilt soon.

Thanks Marcus!

-Jonathan

[supernumero]

(04-04-2014 08:46 AM)walter b Wrote:  

(04-04-2014 08:00 AM)Paul Dale Wrote:  I'd prefer an unlimited stack

An unlimited stack has a significant drawback: there's no top level which can be repeated. IMHO, 8 levels are a nice practical compromise connecting the best of two worlds.

Okay, this may be a radical suggestion, but I have given it some thought and I think it would be marvelous. So here it goes.

The convenience of the top-level-replication is largely (or exclusively) due to the following fact: when levels y,z,t (or y,z,t,a,b,c,d) have the same value (probably different from x), and if any binary operation (let us say multiplication y*x) is performed on x & y, then the answer y*x is placed in x, while y stays unchanged.

In fact, some binary operations such as Delta% and %T (percentage of total) have standard RPN implementations that put the answer in x while leaving y undisturbed, because this is often more convenient.

The same behavior is very useful in other contexts, precisely when top-level-replication comes in handy.

How could these advantages be realized without top-level-replication? Well, they could easily be achieved if we could "force" a binary operation such as multiplication * to behave in the manner that Delta% or %T behave. Therefore, corresponding to, say, ordinary multiplication * there should be a different binary operation # that, applied to the stack, leaves y unchanged while placing the product y*x in x.

For instance, Horner's algorithm to evaluate pz^2 + qz + r would read

Code:


z [ENTER]
p [ENTER]
#
q
+
#
r
+

This will leave the answer in x and the original value r in y.

Internally, every regular binary operation such as +, -, *, / , ^, etc, would have a counterpart that leaves y undisturbed. More esoteric functions such as nCr (combinations) may perhaps not be worth the effort of being given a counterpart.

The trick would be using the regular operation * as well as # in a sensible manner in practice. Here I offer some ideas:

A semi-long press of the * key (say, at least 0.5s but less than 1s) would call the function # instead of * (while >1s would NULL).

An alternative idea is using flags. There could be a single flag that changes the default behavior of binary operations to act as I have explained. A much better idea would be having a separate flag for each operation. A simple SF* or CF* would enable or disable the new behavior for the multiplication operation *. Perhaps even better, pressing the corresponding key * for 0.5s would have the effect of *toggling* the flag, so subsequent uses of the key would have the opposite behavior. There could also be a global flag disabling this new behavior to avoid confusing users unfamiliar with it.

For me, the motivation is to have a uniform way to deal with all binary functions that may or may not leave y undisturbed at the user's choice. Perhaps these ideas can materialize in the 43s, which I would absolutely rather have an infinite-height stack---the lack of top-level replication seems a weak argument to have a fixed-height stack.

SuperNumero

[Jonathan Cameron]

(04-05-2014 05:24 PM)Jonathan Cameron Wrote:  Marcus has just rebuilt the windows emulator for the 31s which includes a few fixes (the 8-level stack issue, requiring only one press of 0 to STO-0 or RCL-0, trig fixes), etc. It is version 3598. The realbuild flash image will probably be rebuilt soon.

Marcus has also rebuilt the WP-31s flash image with the latest fixes (version 3599). It is available at: http://sourceforge.net/p/wp34s/code/HEAD...hes/wp31s/ in the 'realbuild' directory.

Note that this version includes the two mode commands YDON and YDOFF to turn on and off the y-display option.

Thanks again Marcus, Pauli, Walter, Bit, and Sanjeev for these updates and fixes!

Give it a try!

-Jonathan

P.S. If you would like a corresponding build of the QtGui, please PM me.

[BarryMead]

I just downloaded the whole svn tree for the wp34s and it also has the YDON/YDOFF feature, as well as other new improvements. Now when you convert rectangular to polar or visa versa it shows two values
in the display range/angle (to polar) or X/Y (to rectangular). I really like this new feature, so I sent an email to Pascal Meheut asking him if he could rebuild the QT version of the emulator to the latest revision.

Pascal has already rebuilt the new QT emulator.

[Paul Dale]

The 34S team is still open to constructive suggestions. Especially when they include code patches.


- Pauli

[anetzer]

(04-05-2014 05:24 PM)Jonathan Cameron Wrote:  The realbuild flash image will probably be rebuilt soon.

I am amazed how fast this machine is evolving. This team is incredible!

Is there any indication if Eric Rechlin will start producing WP 31S vinyl overlays anytime soon?

[BarryMead]

(04-06-2014 07:12 AM)Paul Dale Wrote:  The 34S team is still open to constructive suggestions. Especially when they include code patches.
- Pauli

I never bothered to submit my wp34s suggestion about saving both halves of the Polar/Rectangular
objects with setlastXY() until I read this posting, because I knew that the WP34S project was
closed to new ideas. But when I read this posting I turned it in, only to discover that I shouldn't have.

Oh Well I don't pretend to understand politics, only science!

[Marcel Samek]

(04-09-2014 09:52 PM)BarryMead Wrote:  

(04-06-2014 07:12 AM)Paul Dale Wrote:  The 34S team is still open to constructive suggestions. Especially when they include code patches.
- Pauli

I never bothered to submit my wp34s suggestion about saving both halves of the Polar/Rectangular
objects with setlastXY() until I read this posting, because I knew that the WP34S project was
closed to new ideas. But when I read this posting I turned it in, only to discover that I shouldn't have.

Oh Well I don't pretend to understand politics, only science!

Well, if suggestions are being taken, one of the things that I would like is to have stosum & rclsum instructions which would take a register reference and allow one to store the summation registers to a register block starting at the specified reference, or load the summation registers from a register block starting at the specified reference.

That would allow me to have a program that has more that one set of summations going at a time.

I've been meaning to look at the code to see the viability of doing something like that, but since we are taking requests , why not ask?

In all seriousness, even if the team is not interested in such an addition, I'd love to hear your thoughts on the feasibility if I were to undertake it in my own version.

[Jonathan Cameron]

(04-09-2014 11:12 PM)Marcel Samek Wrote:  Well, if suggestions are being taken, one of the things that I would like is to have stosum & rclsum instructions which would take a register reference and allow one to store the summation registers to a register block starting at the specified reference, or load the summation registers from a register block starting at the specified reference.

That would allow me to have a program that has more that one set of summations going at a time.

Let me remind you that the WP-31s has no programming capability so it does not make sense to add these functions for programming purposes.

One of the ways the WP-31s was simplified was to trim the storage down to the alpha registers and registers 0-9. That doesn't leave much room to save the summation registers!

-Jonathan

[Paul Dale]

It wouldn't be difficult to code stosum and rclsum. There would be format conversions between the statistical accumulations and the registers and the register code would have to deal with bounds checking and single and double precision properly.


- Pauli

[BarryMead]

(04-09-2014 11:12 PM)Marcel Samek Wrote:  Well, if suggestions are being taken, one of the things that I would like is to have stosum & rclsum instructions which would take a register reference and allow one to store the summation registers to a register block starting at the specified reference, or load the summation registers from a register block starting at the specified reference.

That would allow me to have a program that has more that one set of summations going at a time.

I've been meaning to look at the code to see the viability of doing something like that, but since we are taking requests , why not ask?

In all seriousness, even if the team is not interested in such an addition, I'd love to hear your thoughts on the feasibility if I were to undertake it in my own version.

I assume you are planning to add these commands to your own custom version of the WP-34S not the
WP-31S. Johanathan, Paul, and Pascal have generously sent me detailed instructions on how to
set up my own tool chain so that I can compile custom versions of the calculator firmware, and
emulators. ( I am still in the process of getting that tool chain setup ) If you are interested in having
me forward those emails from Jonathan, Paul and Pascal to you let me know.

[Marcel Samek]

(04-10-2014 12:22 AM)BarryMead Wrote:  Johanathan, Paul, and Pascal have generously sent me detailed instructions on how to
set up my own tool chain so that I can compile custom versions of the calculator firmware, and
emulators. ( I am still in the process of getting that tool chain setup ) If you are interested in having
me forward those emails from Jonathan, Paul and Pascal to you let me know.

I would definitely like to have those. I actually have successfully put together that tool chain in the past, compiled my own version (albeit without any meaningful changes) and flashed my calculator to it. However it was a while back, on a different machine, and I remember flailing around for a while before I figured it out. So, any notes would be appreciated!

[Marcel Samek]

(04-10-2014 12:04 AM)Paul Dale Wrote:  It wouldn't be difficult to code stosum and rclsum. There would be format conversions between the statistical accumulations and the registers and the register code would have to deal with bounds checking and single and double precision properly.

I think I have seen mentioned on this forum that the WP-34s is very tight on remaining memory and instruction space. How much is currently left?