JM-15S - feedback welcome

[jwm]

Hi all, I have been working on yet another alternative firmware for the HP-30b and was curious if anyone had any feedback.

The main difference between this and the WP series is that the feel is based on the voyager series (15C) rather than the 42S, in particular, there are no catalogs. Everything the calculator can do is on the label or on the cheat sheet on the back or is a user program. The goal is to be a 15C with some 12C and 35S features added in terms of functionality.

In order to get the most out of a limited set of keys and faceplate real-estate, a few techniques are employed. it utilizes 2 shift keys + XEQ.

- an unlimited stack, meaning I can do without shortcut functions, [2][y^x] behaves the same as [f][x^2]. Additionally, special keys for entering complex and vectors are not as important, as they can just be slurped off the stack. [3][ENTER][4][y+ix] to enter 3 + i4. A 'FILL' register is used to fill in past the end of the stack so various tasks depending on duplicating T still work.

- whenever a menu is active, the [f] and [g] keys don't do anything. so they behave as the up and down rather than having dedicated up and down keys. The menu is used to navigate the same info that is on the back cheat sheet, rather than necessary for normal usage.

- some keys on the 15C exist only to have special meaning when used by STO/RCL, I explicitly include STO/RCL behavior on the faceplate and use the same mechanism for setting other system options. such as current base, modular arithmetic mod, fill register, etc. They are labeled pink above the keys.

The keys are not quite complete, I am pretty sure I could use some more stack manipulation keys and something for the SST functionality in particular.

   

and the back cheat sheet

   

[walter b]

A couple of nice ideas What's [beta] and [beta]^x on your keyboard? And what's the pink MOD= up there?

And some nitpicky remarks:

• You're missing two sums (xlny and ylnx) you'll need for L.R.
• I'd move R/S right of trigs. At its present position it looks a bit lost.
• Pink labels?!? Please think about another color.
• You wrote:

  Quote:- an unlimited stack, ... A 'FILL' register is used to fill in past the end of the stack so various tasks depending on duplicating T still work.

  Now what is it what you want? :-?
• You wrote:

  Quote:- an unlimited stack, meaning I can do without shortcut functions, [2][y^x] behaves the same as [f][x^2].

  I don't see the link. :-?
  

d:-)

[jwm]

(08-04-2014 06:31 AM)walter b Wrote:  A couple of nice ideas What's [beta] and [beta]^x on your keyboard? And what's the pink MOD= up there?

Beta is just the base of logarithm used for the keys that would normally be used for 10^x and LOG_10. I often need 2 instead for instance when doing information theory calculations, other times I want it to follow whatever the current base is. 16 for hex, etc. The idea is you can stick whatever you want in the Beta register and it will use that, if you set it to zero it will follow the base.

The MOD= is a register that sets the modular arithmetic field. as in, put 7 in there and all calculations will take place in the field (mod 7). This implies integral mode, and can be used to simulate specific bit widths by setting it to 2^n for some n, but can be set to any value for arbitrary modular arithmetic.

Quote:[*]You're missing two sums (xlny and ylnx) you'll need for L.R.

are they not the last two values under LSUMS or do you mean something else?
are collecting the inverses useful for a type of linear regressions as well? as in Sigma_1/x and so forth.

Quote:[*]I'd move R/S right of trigs. At its present position it looks a bit lost.

sure.

Quote:[*]Pink labels?!? Please think about another color.

Yeah, was chosen somewhat randomly because 34S green did not turn out easy to read on my inkjet printer. Will fiddle with colors, other than the gold and blue f and g of course.

Quote:[*]You wrote:

Quote:- an unlimited stack, ... A 'FILL' register is used to fill in past the end of the stack so various tasks depending on duplicating T still work.

Now what is it what you want? :-?

So, on the 15C, when you perform an operation consuming a stack value, the T register is duplicated to keep a full stack but you are limited to 4 spots. This is useful when calculating polynomials for instance. On the 50g you have an unlimited stack but it beeps annoyingly when you reach the end of it. With this I want to combine the best of both behaviors. The stack will be unlimited but when you reach the end of it instead of producing an error, it will pretend it has an infinite number of whatever value is in FILL on the stack. so, put zero in FILL and it will be zeros all the way down.

Quote:[*]You wrote:

Quote:- an unlimited stack, meaning I can do without shortcut functions, [2][y^x] behaves the same as [f][x^2].

I don't see the link. :-?

On some HPs like the 35s, it has keys like [f][x^2]. as in, squaring underneath a shift key. However, it also have a top level y^x, making the x^2 redundant. [2][y^x] is exactly as many keystrokes as [f][x^2]. The only reason for it to exist is that on a limited stack machine, [2][y^x] will clobber the 'T' value. with an unlimited stack this isn't an issue. I added the top level \sqrt{x}{y} to make square roots easy in the same way.

So, I don't have R+ and R-, but i was thinking of adding 'PUSH' and 'POP' which will take the current x value and push it onto an alternate stack or pop a value off of it. This will allow you to traverse up and down the stack like with r+ and r- but not rely on the wraparound rotation behavior. you would just be shuffling values to the alternate stack and back to the primary one.

John

[jwm]

Some Changes

- Added keys to swap stack with alternate stack and push value to alternate stack and pop value off alternate stack (under cos and tan). The alternate stack will be saved and restored on XEQ so you can use it to store values you don't want clobbered, additionally it will be the staging area for constructing/editing vectors and matrixes. right now via the A,B,8 keys. I am unsure how the symbols should look to be obvious what they are doing.

- Since [XEQ][A] is just as easy as [g][A], I moved the user definable names off of a shift key freeing up some prime real estate. A 'USER' mode like the 15C can be used for even easier access.

- Made use of that big gap between the 2nd and 3rd row to put all the special registers. This also frees up the top row for use with STO/RCL and equation solving, such as the time-value-money 12C feature. By putting PREC on STO and LASTx on RCL, changing the precision is [n][STO][STO] and LASTx is [RCL][RCL] which are both quite easy. This makes hiding the display mode under a menu less painful as you can easily change precision while keeping the display mode the same. (image has LASTx in old position)

- use squiggly arrows when a numerical operation happens vs a straight arrow for just pushing values around.

- switched the colors to save printer ink and be easier to read when the black ink bleeds over, when printing on vinyl different colors can be used. I feel it looks much less cluttered now. I need to heuristically expand some of the math fonts as the nth-root and integral and ye^{ix} don't quite pop as I'd like.

   

Using a paper overlay for testing is surprisingly usable. I can feel and press the keys through the paper just fine without losing the nice tactile switch.

   

[walter b]

(08-04-2014 07:21 PM)jwm Wrote:  Using a paper overlay for testing is surprisingly usable. I can feel and press the keys through the paper just fine without losing the nice tactile switch.

No wonder it's recommended by the author of the WP 34S manual since 2011

IF you want to gain followers for your keyboard layout, a short form user's guide might help. And some ironing may as well (concerning design, typography and fonts, revising key and label locations, etc.). OTOH, ink consumption for overlay prints is neglectible IMHO.

d:-)

BTW, what did poor old STO, RCL, and x[swap] do to you that they were sentenced to be printed in bloody red?
Beware: Like all other statements I make here, the ones above reflect my personal opinion only. YMMV.

[JimP]

(08-04-2014 05:05 AM)jwm Wrote:  The main difference between this and the WP series is that the feel is based on the voyager series (15C) rather than the 42S, in particular, there are no catalogs. Everything the calculator can do is on the label or on the cheat sheet on the back or is a user program. The goal is to be a 15C with some 12C and 35S features added in terms of functionality.

Interesting! When you say "some 12C features" do you mean a TVM type application built into firmware? (rather than as a program, which would make it different from the WP34S in that sense at least) -- that could make it a very nice little machine. Some iphone apps (eg 11C Pro, 12C Pro) have an 11C layout but the enhanced financial functions or trig functions respectively are accessible by menu, on a hardware calculator platform that's harder to achieve, but if you can do this then you might have a feature set that only the HP27 and HP27s type machines had up to now.

[jwm]

(08-05-2014 01:45 AM)JimP Wrote:  Interesting! When you say "some 12C features" do you mean a TVM type application built into firmware? (rather than as a program, which would make it different from the WP34S in that sense at least) -- that could make it a very nice little machine.

Yeah, the time/value calculation is the main one I want to get in there. I'd like it to be part of the general equation solver, in that it will have the same interface but may have an optimized implementation.

The way I was thinking it would work would be the registers A-F would set and recall variables in the current equation. So if you set the current equation to time-value then [4][STO][A] would store 4 in the n register. This will require one more keypress than the 12C in that you would need to explicity press [STO] or [RCL] to indicate what you want to do with the var, but other than that the interface should be just as nice to work with.

Quote: Some iphone apps (eg 11C Pro, 12C Pro) have an 11C layout but the enhanced financial functions or trig functions respectively are accessible by menu, on a hardware calculator platform that's harder to achieve, but if you can do this then you might have a feature set that only the HP27 and HP27s type machines had up to now.

Yeah, an overriding goal is that _everything_ the calculator does is on the front panel or fits on the back cheat sheet, no catalogs. The limiting factor isn't really power since the WP-34s shows you can do quite a bit with the hardware, but what I add depends a lot on how intuitive I can make the UI with the buttons on hand.

I'm open to any features of more advanced calcs that fit nicely within that, but something I want to push the limit of is "freebies", as in, we have a key for setting the base, why limit it to 2,8,10, and 16 like every other calculator. It takes no more key-estate to allow arbitrary bases so it should "just work". Another example is I have complex numbers, so might as well just let them be used in matricies generally rather than the 15C workarounds. No more keys needed, but more functionality in an intuitive way for free.

John

[jwm]

(08-04-2014 08:06 PM)walter b Wrote:  No wonder it's recommended by the author of the WP 34S manual since 2011

On the shoulders of giants....

Quote:IF you want to gain followers for your keyboard layout, a short form user's guide might help. And some ironing may as well (concerning design, typography and fonts, revising key and label locations, etc.). OTOH, ink consumption for overlay prints is neglectible IMHO.

Well, first I need a firmware image I can give out to people that follows the new keys. I am in the process of developing it, I am basing it on another RPN language core I wrote called 'levity' for an internal project a long time ago. The main thing I am salvaging is the nice compacting GC, so I can use space inefficient but oh so easy to manage linked lists for the youngest generation that lives in the 6k of ram, then garbage collect it compiling it down to linear arrays and compressed bytecode that live in the 2K that are backed up. A further GC moving stuff to flash that has existed at least a day is even possible. But a nice thing about the generic GC core is stack items can be any size, vectors, matricies, complex numbers, it doesn't matter because they are structs in memory that are only compacted when they exist for a certain amount of time.

Quote:BTW, what did poor old STO, RCL, and x[swap] do to you that they were sentenced to be printed in bloody red?

Heh. the front panel image is auto-generated from the source as I work on the firmware so is in flux, but coming together. The newest version is attached which is hopefully more aethetically pleasing.

   

John

[walter b]

(08-05-2014 02:54 AM)jwm Wrote:  

(08-04-2014 08:06 PM)walter b Wrote:  IF you want to gain followers for your keyboard layout, a short form user's guide might help. And some ironing may as well (concerning design, typography and fonts, revising key and label locations, etc.).

Heh. the front panel image is auto-generated from the source as I work on the firmware so is in flux ...

Let's wait and watch the flux.

[Marcus von Cube]

(08-05-2014 02:54 AM)jwm Wrote:  The main thing I am salvaging is the nice compacting GC, so I can use space inefficient but oh so easy to manage linked lists for the youngest generation that lives in the 6k of ram, then garbage collect it compiling it down to linear arrays and compressed bytecode that live in the 2K that are backed up.

The WP 34S battery saving algorithm is based on turning the core off while the device is waiting for a key. The same holds for HPs firmware for the same chip (10bii+, 12C+, 15C LE, 20b/30b). This saves a lot of energy but it looses the 4KB RAM between keystrokes. Your GC would be quite busy if you were doing it in a similar way. Running the GC would probably cost more then turning the chip off could save.

Are you planning an emulator so that more people will try the user interface?

[jwm]

(08-05-2014 04:26 PM)Marcus von Cube Wrote:  The WP 34S battery saving algorithm is based on turning the core off while the device is waiting for a key. The same holds for HPs firmware for the same chip (10bii+, 12C+, 15C LE, 20b/30b). This saves a lot of energy but it looses the 4KB RAM between keystrokes. Your GC would be quite busy if you were doing it in a similar way. Running the GC would probably cost more then turning the chip off could save.

Well, the main reason for the GC is not to get things into that 2k, but to give them a much smaller representation and only spend time and cycles on things that will last a while. Most values are consumed right after they are produced, so coming up with a compact memory footprint isn't important and can cost extra cycles to pack and unpack values, however, some are long lived and end up as part of programs or stored in registers. There is a tension between these two desires for a compact representation and an easy to work with one, that a compacting/optimizing GC can solve. It only takes the extra effort to come up with compact representations for things that are going to live a while, but the hundreds of thousands of intermediate values do not need to be reclaimed and can be stored in memory in their most efficient to manipulate representation.

The GC before shutting down the core can be very fast, the invarient that pointers from saved ram can only point to saved ram or flash, and flash can only point to flash, means that as soon as we see a pointer into something other than dynamic ram we can stop. meaning that in almost all cases during normal usage, the GC will go no further than the few values on the stack itself because everything else will have been commited to long term storage on a previous GC and all the intermediate results of calculations done are simply discarded and not traversed. It will occasionally have more to do, such as when the 2K itself is filled and it needs to clean house with a full GC or move things to flash, but that will be exceedingly rare, only after some dedicated programming or data entereing time when there is more that actually needs to be saved.

So, it will still GC and shut down between keystrokes, which will likely just store a single stack value and not traverse any further, but during the execution of programs it will have the full 6K to scribble on.

Quote:Are you planning an emulator so that more people will try the user interface?

Very probably. The core is based on a language that already is a standalone linux program. I'd actually like to make the emulator be in the form of an android app. Since that will be just useful in general, but it has been a while since I have done android programming, will have to look into it. Everything will be open sourced of course.

John

[Jake Schwartz]

Way off topic - In case it hasn't happened yet, congratulations Walter on your 1000th posting in the forum :-)

Jake