Wow -- I participated in a thread a few months ago talking about a simpler version of a 34s, and while I was gone, you went and did it! I really need to subscribe to some of these threads. So, I'm late to the party.

It looks very nice to me, and I'm going to want to make one to try a hardware version. The emulation is working well so far.

I concur. The result would be a two-shift-key device somewhere between the 31S and the 34S. A second shift key will open the possibility to add TVM as a built-in function, too.

As I probably expressed before, in 30 years in a development lab environment, programability has never been worth much to me on a handheld calculator. Having a simple, less cluttered, fast RPN interface where I can easily get to the main functions with trig, sqrt, and 1/x is a blessing for me (aka HP21/25). For the lab jobs I've had, any programming is better off done on a spreadsheet or other tool on a laptop, where it then can be much more easily documented for IP requirements.

I do like your 34s, and so far the 31s looks nice and streamlined and reminds me a bit of the 42s/32s (which I like), but I haven't had a chance to use it very much as yet, other than the emulator.

(07-16-2014 01:18 AM)nsg Wrote: [ -> ]Tried the emulator. My screen is 768 pixels tall and the "medium" skin shows only top half of a calculator. Is the a "small" skin?

Hello nsg,

maybe this helps a little bit. Because I like the compact skin too, I made a quick
and dirty solution for myself. You can find two files (wp31s_compact.bmp and
2 Compact 31s.skin) in the appended file wp31s_compact.zip. Unzip this file into
the directory of your wp31s. After you start the wp31sgui.exe you can select
the compact skin via the menu.

I've ported the patch to the WP 31S (attached) that was originally created to make data entry faster when using Y register display on the WP 34S. For more information on how it works, see post #66 in the Enhanced Y register display thread.

I've tried the patch on an HP 30b just for a few seconds to confirm that it indeed speeds up data entry even on the WP 31S. I hope the WP 31S community will find this patch useful, but I'm not very familiar with either the code or the behavior of the WP 31S, so someone else will need to take it up from here and test it thoroughly if it's to be integrated into the mainline.

(11-13-2014 05:11 AM)Bit Wrote: [ -> ]I've ported the patch to the WP 31S (attached) that was originally created to make data entry faster when using Y register display on the WP 34S...

Any chance you could provide a compiled binary of the wp31s firmware with your patch? (I wish I had the knowledge to apply your patch and compile it myself, but I'm sure it is easier for you to compile it for me rather than teach me how to do it )

(11-13-2014 05:11 AM)Bit Wrote: [ -> ]I've ported the patch to the WP 31S (attached) that was originally created to make data entry faster when using Y register display on the WP 34S...

Any chance you could provide a compiled binary of the wp31s firmware with your patch? (I wish I had the knowledge to apply your patch and compile it myself, but I'm sure it is easier for you to compile it for me rather than teach me how to do it )

I've attached a binary. Keep in mind, however, that unlike with the WP 34S, I don't really know what I'm doing here. I've never used the 31S, so I cannot test if everything works correctly in the patched version.

Edit: The patch 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.

(11-13-2014 01:22 PM)Bit Wrote: [ -> ]I've never used the 31S, so I cannot test if everything works correctly in the patched version.

You could use the emulator, couldn't you?

d:-?

I did that and even flashed the WP 31S on real hardware to give it a quick try. I could certainly notice very obvious problems. However, without spending a lot of time on actually using the WP 31S (which I don't intend to as I prefer the 34S), I may not be able to notice subtle problems or those that occur only rarely. That's why it'd be useful if those who use the 31S regularly could do the testing. I'll help with debugging or fixing any issues found.

If you browse the STAT catalog when no statistical data is available, certain entries that invoke sigma_val() from stats.c set an error code in the background that will cause a bogus error message to appear after the next command or key press.

(11-16-2014 04:35 AM)Bit Wrote: [ -> ]I would like to suggest that the LOGx function be made available in the MORE catalog. I think it's a pretty basic and useful operation and would fit well into the philosophy of the 31S.

Another idea: Currently if you press the [f] [a b/c] key again when already in fraction mode, nothing happens. I think it'd be logical and useful if that key switched between proper and improper fraction modes, since that's much faster and more convenient than using the menus.

A patch to achieve this and precompiled binaries for testing are available in the attached file in the first post here.

(11-17-2014 01:52 AM)Bit Wrote: [ -> ]Another idea: Currently if you press the [f] [a b/c] key again when already in fraction mode, nothing happens. I think it'd be logical and useful if that key switched between proper and improper fraction modes, since that's much faster and more convenient than using the menus.

I think that this makes a lot of sense. It does not affect the current functionality since it is a NOP in the current builds. The addtional functionality could be folded into the 31s documentation whenever Walter wishes.

(11-17-2014 01:52 AM)Bit Wrote: [ -> ]Another idea: Currently if you press the [f] [a b/c] key again when already in fraction mode, nothing happens. I think it'd be logical and useful if that key switched between proper and improper fraction modes, since that's much faster and more convenient than using the menus.

A patch to achieve this and precompiled binaries for testing are available in the attached file in the first post here.

There's another obvious (and IMO necessary) UI improvement possible besides [a b/c]: ->DEG and ->RAD need not depend on the current angular mode since only two modes, and thus two conversions, are supported. I've explained it under 'Easy angular conversions' in this post and provided a patch. Since this only modifies operations that are effectively NOPs, it isn't a disruptive change. I recommend it for inclusion in the official builds.