[WP 34S] Enhanced Y register display: fractions, bugfixes etc.

[Bit]

I've created a patch to improve the Y register display in the WP 34S. Really good Y register display is impossible on the measly screen of the HP 30b but even a less than perfect implementation can improve usability. Not only is it a reminder of what's been entered or which numbers the next operation will work on (if it requires two arguments) but it provides feedback on whether or not a stack lift occurred. Because of the latter it could be especially useful in simplified versions of the WP 34S targeting users who are new to RPN.

Bugs fixed:
* Both YREG_CODE and RP_PREFIX cut off the last digit in certain cases. This could lead to incorrect rounding at best, or totally wrong exponent shown at worst. The numbers 1.123456178 and 1.234567e311 will reproduce the problem.
* YREG_CODE often interferes with viewing complex numbers.
[CPX] [h] [VIEW] [Z] will reproduce the problem.
* If the X register was erased (thus stack lift disabled) and a new number is being entered, the original YREG_CODE will display a zero (the erased X register) instead of the Y register.
[1] [ENTER] [<-] [1] will reproduce the problem.

The original code directly manipulated the horizontal position (the 'x' variable) in set_status_sized() in order to align the number displayed. This seemed like an ad-hoc solution that wouldn't scale to support new features with different alignment requirements so I came up with something else. The '\007' character (the gradian symbol) starts an escape sequence that specifies the width of the next character explicitly and whether the big or the small font should be used.

By default the Y register is displayed even if a shift key and/or the CPX key have been pressed, and both indicators are squeezed into the 7 pixel wide area on the left. This makes the Y register display much nicer because it isn't flashing on and off while one performs basic operations. There's no longer any visual indication of the date mode, but it's unlikely anyone would change the date mode often after they configured it to their liking so I don't think it's a big loss. The old behavior (disabling Y register display whenever a shift key or the CPX key is pressed) is available via a compile time option.

Whether the Y register display can be turned on or off at run time using the J flag has been made into a compile time option. Disabling both this and the old behavior mentioned above eliminates some code paths and makes the firmware slightly smaller. I see little value in being able to turn off the Y register display at run time (once it works well) but I kept the option in case someone needs it.

The new code supports fraction mode. The 'Gt' and 'Lt' indicators are changed into '>' and '<' in small font and they're removed if the fraction wouldn't fit in the display otherwise. If the fraction still doesn't fit, the number is displayed as decimals.

HMS mode is also supported. The overflow indicator and the fractional part of the second are cut off if necessary to make everything fit in the display. There's no need to fall back to displaying decimals.

Being able to control the width of individual characters and the font used made another feature possible: stack size indication without repurposing the BEG annunciator. If it's enabled at compile time, a small '.' on the left side of the display will indicate a 4-level stack and a small ':' an 8-level one. The idea is that single vs. double dots indicate normal vs. double stack size. If someone can think of a neater way to do it, let me know.

Besides changing set_status_sized() and some other minor changes, I had to revamp the structure of annunciators() in order to avoid lots of code duplication within #ifdef's. I was trying to be careful and not increase the firmware size unnecessarily. With all Y register related features disabled, i.e. configured for equivalent functionality as the official firmware, the ARM machine code generated from the new version is actually a few bytes shorter. The default configuration that comes with the patch (most new features enabled) makes the firmware roughly half a kilobyte bigger.

This is still a work in progress but at this point it may be of interest to others. The image below shows what the new Y register display looks like. Any feedback is welcome.

Edit: Uploaded a fixed version of the patch.

[Paul Dale]

(02-04-2014 03:14 AM)Bit Wrote:  I've created a patch to improve the Y register display in the WP 34S. Really good Y register display is impossible on the measly screen of the HP 30b but even a less than perfect implementation can improve usability.

When the Y register display was implemented, I vaguely remember working out the absolute worst case and it was zero or one significant digits of the mantissa being visible -- double precision, negative number with large negative exponent or some such.

Quote:The original code directly manipulated the horizontal position (the 'x' variable) in set_status_sized() in order to align the number displayed. This seemed like an ad-hoc solution that wouldn't scale to support new features with different alignment requirements so I came up with something else. The '\007' character (the gradian symbol) starts an escape sequence that specifies the width of the next character explicitly and whether the big or the small font should be used.

Yeah, I didn't like this much at the time but it squeezed a fraction more out of the pixel section of the display and it wasn't going into the real 34S firmware release ever so we let it pass. I'm not sure I entirely like specifying the character width using an escape code either. All the display driving on the 34S is character based and this was done intentionally. Well, it was before Marcus implemented the printer support and the registers holding graphical data were allow to be displayed.

One point which I felt was important for the 34S dot matrix display is that nothing ever bounces around. e.g. the gradian indicator always stays in exactly the same position regardless of what is before it. Likewise for all the other annunicators, not even a single pixel of motion. To me, this looks more professional and streamlined -- it makes the firmware look finished. The y-register display code broke this, specifically with the aforementioned x position modification.


Still, it looks like you are making great progress understanding and modifying the 34S firmware. I am glad for this.


- Pauli

[Paul Dale]

Would it be possible to put the complex indicator 'c' or arrow at the top and f-shift '<', g-shift '>' and h-shift '_' in the same two pixel wide position?

Using characters we didn't have space, but if you're going to graphics, it would be possible.

Code:


xx    xx    xx    x     x     x
x     x     x      x     x     x
xx    xx    xx    x     x     x

 x    x           x     x
xx    xx    xx   xx     xx    xx

This would allow some space for the display of Y without things bouncing around. It also leaves space for the complex result indicator:

Code:


xx
x
x
x
xx

I don't know if there is enough distinction between these to make things obvious or not. That was always Walter's department.


- Pauli

[walter b]

IIRC, our WP 34S character set already used all character codes available. Did I miss anything?

d:-?

[Paul Dale]

The 34S uses all available character codes, however there is the possibility of implementing the status displays not using character codes or using the proposed escape character (for extra character positions). My comment above is a possibility to display the shift key status, the complex indicator and the right arrow in fewer pixels by not relying on characters for graphics. As the 34S stands, there aren't character slots available for anything extra. This is a dangerous door to open of course but it might result in a viable Y register display.

I'd really like to see an ultimate 31S non-programmable calculator. Taking out programming, would leave some amount of flash for extra commands if the effort is made to sensibly remove dead code (which isn't just removing commands, many internal commands rely on programmability). We'd lose binary compatibility but how much better could we do than the 34S once programmability is gone? I suspect quite a bit -- the 34S was always intended as a high end RPN programmable (which I believe it has achieved and exceeded).

I doubt we can do much better for a programmable RPN device than the 34S, at least within the 30b hardware. I wish I could have a stab at the WP-35S howeever. A decent display, lots of RAM and a nice keyboard. The 35S is lacking ROM space but that can be worked with given sufficient effort.


- Pauli

[walter b]

(02-04-2014 10:29 AM)Paul Dale Wrote:  I doubt we can do much better for a programmable RPN device than the 34S, at least within the 30b hardware.

Certainly we pushed the HP-30b to its limits with the WP 34S.

(02-04-2014 10:29 AM)Paul Dale Wrote:  I wish I could have a stab at the WP-35S howeever. A decent display, lots of RAM and a nice keyboard. The 35S is lacking ROM space but that can be worked with given sufficient effort.

Assume you meant the HP-35S. Then I'd prefer to have a stab at the HP-17bii Silver - it returns the LCD of the HP-42S at least and it's keyboard fits my needs better than the one of HP-35S. It would allow for softkeys which the HP-35S can't support to the same extent. I don't know, however, about its ROM and RAM. Anyway, all such thoughts are even thinner vapourware than the 43S.

d:-)

[Bit]

(02-04-2014 05:56 AM)Paul Dale Wrote:  When the Y register display was implemented, I vaguely remember working out the absolute worst case and it was zero or one significant digits of the mantissa being visible -- double precision, negative number with large negative exponent or some such.

The worst case I could reproduce was three significant digits for double precision numbers like -2.345e-2345. Fewer significant digits appear only if rounding makes it necessary, e.g. for 1.99999e200, but that's unavoidable. This was already handled well by the original Y register code (aside from cutting off the last digit occasionally). Maybe you remember an older state of affairs? If not, I'd really like to know how to trigger the worst case scenario you mentioned. If it still happens, I'm quite sure it can be fixed.

(02-04-2014 05:56 AM)Paul Dale Wrote:  I'm not sure I entirely like specifying the character width using an escape code either.

I couldn't think of another way to do it without significantly increasing the size of the firmware. The gradian symbol was chosen because it's only used for a single purpose in a single place and, as far as I could tell, it isn't part of any catalog, so it's easy to make sure an escape sequence is never created unintentionally. The gradian symbol can still be displayed, it just has to be part of an escape sequence. All of the escape magic is within #ifdef's or code branches that are guaranteed to be optimized away if unused. None of it is compiled in unless some feature selected needs it.

(02-04-2014 05:56 AM)Paul Dale Wrote:  One point which I felt was important for the 34S dot matrix display is that nothing ever bounces around.

I completely agree and I believe the new Y register display code achieves the same. If it doesn't, it's a bug I intend to fix.

[Bit]

(02-04-2014 07:48 AM)Paul Dale Wrote:  Using characters we didn't have space, but if you're going to graphics, it would be possible.

Actually all of my code is based on character display, it's just that the font can be selected and the width overriden for each individual character. What you suggested would need entirely new code branches or sacrificing some already existing characters.

The new Y register code reserves a 7 pixel wide area on the left side for various indicators (the last column is always blank). This allows displaying the indicators for double precision mode, gradian mode, stack sizes, complex result ('i'), Cartesian result ('y') and polar result ('<') relatively nicely. Most of the time the blank space between indicators and the number is more than 1 pixel wide. What you suggested requires 3 columns (2 + 1 blank). A small 'i' for complex results would fit into that space and I guess we could squeeze in a tiny 'd' for DP mode (although it'd have to be a character that doesn't currently exist), but there'd be no more gradian, 'y' or '<', and the number would always be separated from the indicators by a 1 pixel wide strip only.

Reserving four pixels (3 + 1 blank) might be better: It'd allow DP mode indication, a tiny 'G' for gradian, 'y', maybe even '<'.

(02-04-2014 07:48 AM)Paul Dale Wrote:  It also leaves space for the complex result indicator:

I think a small 'i' would be better and that'd fit just as well.

(02-04-2014 07:48 AM)Paul Dale Wrote:  I don't know if there is enough distinction between these to make things obvious or not.

I think it'd be pushing the limits of what's easily legible. The question is whether reducing the horizontal space required from 7 pixels to 4 or maybe 3 would be worth it.

[Jeff O.]

(02-04-2014 03:14 AM)Bit Wrote:  

I've created a patch to improve the Y register display in the WP 34S...This is still a work in progress but at this point it may be of interest to others. The image below shows what the new Y register display looks like. Any feedback is welcome.

I'd be happy to try out and provide feedback. Would it be possible to provide a compiled version of the firmware with your patch for those of us who don't have the ability to compile?

[Bit]

(02-04-2014 06:02 PM)Jeff O. Wrote:  I'd be happy to try out and provide feedback. Would it be possible to provide a compiled version of the firmware with your patch for those of us who don't have the ability to compile?

I could compile the firmware but I'm very new to the WP 34S and still don't have the tools to load the firmware into a HP 30b, so you'd be the first to test it on real hardware.
I could also compile Linux versions of the emulator.

I'm just not sure where to upload the files because the attachment size on this forum is very limited. Ideas?

[walter b]

(02-04-2014 06:10 PM)Bit Wrote:  I'm just not sure where to upload the files because the attachment size on this forum is very limited. Ideas?

That's what SVN was made for. Please ask Pauli for access rights.

d:-)

[Jeff O.]

(02-04-2014 06:10 PM)Bit Wrote:  I could compile the firmware but I'm very new to the WP 34S and still don't have the tools to load the firmware into a HP 30b, so you'd be the first to test it on real hardware.

If you provide a compiled bin file, I'm sure a lot of users would give it a try.

(02-04-2014 06:10 PM)Bit Wrote:  I'm just not sure where to upload the files because the attachment size on this forum is very limited. Ideas?

The bin file is only 120 kB max, can you not attach that here?

[Bit]

(02-04-2014 08:26 PM)Jeff O. Wrote:  The bin file is only 120 kB max, can you not attach that here?

Here it is until the SVN access that Walter mentioned is sorted out.

It has the default Y register configuration you'll find in the patch and it's the build that doesn't require the quartz crystal so you can give it a try even with unmodified hardware. Good luck!

Edit: Enhanced Y register display has been incorporated into the official build and also into my builds. There's no longer any need for the binary I attached here, so I've deleted it.

[Jeff O.]

(02-05-2014 01:44 AM)Bit Wrote:  Here it is until the SVN access that Walter mentioned is sorted out.
MD5: 9dafd76c60dcbf6412ac8dd90ef7a30b

It has the default Y register configuration you'll find in the patch and it's the build that doesn't require the quartz crystal so you can give it a try even with unmodified hardware. Good luck!

Downloaded and implanted into a spare 30b. Played around with it a bit, so far I like. When I press f, g, or h, a question mark appears at the beginning of the second line. When I press CPX, a question mark followed by the small raised c appears, which does not change if f, g, or h is pressed. Is this the intended behavior?

[Bit]

(02-05-2014 05:09 PM)Jeff O. Wrote:  Downloaded and implanted into a spare 30b. Played around with it a bit, so far I like. When I press f, g, or h, a question mark appears at the beginning of the second line. When I press CPX, a question mark followed by the small raised c appears, which does not change if f, g, or h is pressed. Is this the intended behavior?

No, that isn't intended. You found a bug: something behaves differently in the real device than in the emulator. The fifth screen at the bottom of the image I posted shows what you should see when a shift key and the CPX key are pressed.

Once I can load the firmware into a 30b (hopefully soon) I'll be able to debug such problems much more easily.

[Bit]

(02-05-2014 05:55 PM)Bit Wrote:  

(02-05-2014 05:09 PM)Jeff O. Wrote:  Downloaded and implanted into a spare 30b. Played around with it a bit, so far I like. When I press f, g, or h, a question mark appears at the beginning of the second line. When I press CPX, a question mark followed by the small raised c appears, which does not change if f, g, or h is pressed. Is this the intended behavior?

No, that isn't intended. You found a bug: something behaves differently in the real device than in the emulator. The fifth screen at the bottom of the image I posted shows what you should see when a shift key and the CPX key are pressed.

Once I can load the firmware into a 30b (hopefully soon) I'll be able to debug such problems much more easily.

I've found the problem, applied a quick fix and uploaded a new binary (which doesn't display the question marks) into the original post. I'd be interested in feedback about the new version.

[Sanjeev Visvanatha]

I like the behaviour. It is a bit confusing when in GRAD mode, and you also press G-Shift. A bit more 42s-like. Nice work!

[Bit]

(02-06-2014 03:17 AM)Sanjeev Visvanatha Wrote:  I like the behaviour. It is a bit confusing when in GRAD mode, and you also press G-Shift. A bit more 42s-like. Nice work!

There's a compile time option to enable or disable the gradian symbol. If it's disabled, the only indication that you're in gradian mode is that both the RAD and the 360 annunciators are off. Do you think that would be better? If anyone has an idea about how to deal with this in a more user-friendly way, I'd like to hear about it.

Gradians are rarely used AFAIK (correct me if I'm wrong), so it probably doesn't matter a lot how they're indicated.

[walter b]

(02-06-2014 04:51 PM)Bit Wrote:  There's a compile time option to enable or disable the gradian symbol. If it's disabled, the only indication that you're in gradian mode is that both the RAD and the 360 annunciators are off. Do you think that would be better? If anyone has an idea about how to deal with this in a more user-friendly way, I'd like to hear about it.

Gradians are rarely used AFAIK (correct me if I'm wrong), so it probably doesn't matter a lot how they're indicated.

Surveyors use gradians - no idea whether that's a rare species or not.

d;-)

[Jeff O.]

(02-06-2014 02:39 AM)Bit Wrote:  I've found the problem, applied a quick fix and uploaded a new binary (which doesn't display the question marks) into the original post. I'd be interested in feedback about the new version.

I like the y-register display behavior in general, and the way you handle the f, g, h and ^c annunciators. I like the way you display a y at the beginning of the 2nd line display after a Polar to Rectangular conversion, and the angle symbol after a Rectangular to Polar to conversion. This is remarkably similar to a two-line display mode developed by our friend Nigel Dowrick (see this old Forum thread).

(02-06-2014 04:51 PM)Bit Wrote:  There's a compile time option to enable or disable the gradian symbol. If it's disabled, the only indication that you're in gradian mode is that both the RAD and the 360 annunciators are off. Do you think that would be better? If anyone has an idea about how to deal with this in a more user-friendly way, I'd like to hear about it.

Gradians are rarely used AFAIK (correct me if I'm wrong), so it probably doesn't matter a lot how they're indicated.

The conflict with the G annunciator while in grads mode does not bother me because I have never and likely never will use grads mode. The option to leave it out and only indicate grads by the absence of both the RAD and 360 annunciators would be fine. Or maybe indicate by lighting both of those at the same time - the cognitive dissonance evoked by having both lit might be a better reminder than having both unlit.

The only other comment I have is, is it my imagination, or is response to keystrokes a little sluggish? When entering a multi-digit value, it seems like the numbers appear in the display relatively slowly, especially if I am using both thumbs to key in the value. Not a big deal, just wondering if it is really there.