New compile-time options for WP-34S



#2

Since revision 3361 there are some new compile-time options for the WP34S firmware. As the phrase "compile-time" suggests, these options will only be available to those of you who compile the WP34S firmware from source on your own computer. I thank Pauli, Walter, and Marcus for allowing these patches to be included as part of the project.

These patches can be enabled by uncommenting the relevant #define directives in features.h . There is some documentation for them in the file wp34s_ND_patches_readme.txt in the doc directory of the project.

Here's a list:

INCLUDE_EEX_PI

This option changes the behaviour of the EEX key so that if it is pressed when beginning a numeric entry, it enters PI without the need for a shift key.

INCLUDE_CASIO_SEPARATOR

This option changes the fraction separator to the old Casio form of _|.

INCLUDE_DOUBLEDOT_FRACTIONS

This option makes (for example) 4..7 enter the fraction 4/7, rather than 4 0/7, as on the HP-32Sii and other HP calculators.

INCLUDE_SIGFIG_MODE

Have you ever wanted to work to a particular number of significant figures, but didn't want your display cluttered up with trailing zeros or exponent notation? If so, then this option is for you. It takes over ALL mode so that ALL n displays (n+1) significant figures. So, for example, in ALL 3 mode the number 7 would be displayed as 7; 12345 would be displayed as 12350; 2.3 would be displayed as 2.3; pi would be 3.142; and so on. (There is the option to display trailing zeroes if desired.)

INCLUDE_YREG_CODE

This option causes the y-register contents to be displayed at all times (except in integer modes), rather than only after a complex operation.

There are a couple of other cosmetic options as well.

Nigel (UK)


#3

All these are useful options that can make life easier for the one or other user - some more so, some less. However, now there are three different ways to set user preferences: directly (e.g. decimal dot or comma), within the mode menu (e.g. thousands separator, date display) and now also within the source code.

Let's take a look at the way this is handled on other portable devices, for instance digital cameras: there is a set of user-definable settings (so-called custom functions) where personal preferences can be set. For instance the exposure display (full, 1/2 or 1/3 steps), key assignments etc. On a calculator like the 34s, thirty different settings with sixteen options (= 4 bit) each can be stored in 15 Bytes. Alternatively a set of system flags could be defined to store such settings - like it was done in the 41-series. The 34s currently has 100+ flags, so 20 or 30 less reserved for internal use would not hurt.

Dieter

Edited: 27 Jan 2013, 10:04 a.m.


#4

Quote:
On a calculator like the 34s, thirty different settings with sixteen options (= 4 bit) each can be stored in 15 Bytes. Alternatively a set of system flags could be defined to store such settings - like it was done in the 41-series. The 34s currently has 100+ flags, so 20 or 30 less reserved for internal use would not hurt.

OK - no problem from the UI side - extra variability in "online" settings will cost some bytes on the code side, however.

d:-)


#5

Quote:
extra variability in "online" settings will cost some bytes on the code side, however.

And being compile-time options these nice features will certainly be unusable by 99% of all WP34s users!

Who would really want (or be able) to download a complete C-compiler package and the whole source project just for making his own preferred vereion?

So I can only agree with Dieter - all those useful features should indeed be user-definable mode settings (at the cost of a few flags).

Franz


#6

I think that this is a problem without a solution. There's a limit to the configurability of any calculator, and (in an open-source project like this) someone will always add features that aren't part of the standard set-up.

I'd agree that vital features (e.g., date format, stack size, dot or comma) must be configurable by the user, but my changes aren't vital. The calculator is fine without them and I feel that they wouldn't merit the extra space needed to fit them in alongside the standard behaviour. Also, making them part of the standard calculator would mean that Pauli, Walter, and Marcus would have to maintain and document code that they didn't write. Having them available as compile-time options seems like a good compromise.

Incidentally, downloading the compiler and using it is not as hard as one might expect. I won't pretend it was trivial to get it working (see this link for my experience) but it wasn't impossible either.

Finally: if you want to see what the calculator is like with these modifications, without compiling the code yourselves, you can look here. You'll find the windows emulator and various bin files that you can copy onto your calculator. These are build 3361 with all my compile-time patches turned on.

Nigel (UK)


#7

Quote:
Finally: if you want to see what the calculator is like with these modifications, without compiling the code yourselves, you can look here. You'll find the windows emulator and various bin files that you can copy onto your calculator. These are build 3361 with all my compile-time patches turned on.

Thanks Nigel, great service! :-)

Franz

#8

Quote:
Finally: if you want to see what the calculator is like with these modifications, without compiling the code yourselves, you can look here. You'll find the windows emulator and various bin files that you can copy onto your calculator. These are build 3361 with all my compile-time patches turned on.

Good idea for sure - eases further discussion.

d:-)

#9

I am not sure if I get you right, but just to be sure: there is no need to reflect each and every setting in a user command. Take a look at the 41-series:

  • The decimal marker (comma/dot) and thousands separator are controlled by two flags. There is no special command like "E3ON" or "E3OFF" or RDX./RDX, since a simple CF28 / SF29 will do.

  • The printer can be set to double-wide and/or lower case printing. There are no special commands for this - simply set/clear flag 12 resp. flag 13.

  • The 41's user mode may be set directly by pressing the [USER] key. There is no programmable command for this. Instead, a program may simply set or clear (or toggle) the respective flag 27. Or test its status to determine whether user mode is on or off.

  • The angular mode is set directly by DEG, RAD and GRAD. This setting is also reflected by two flags that can be tested under program control to return the current mode. In this case, the 41-series does not allow to set/clear these flags directly, but this does not mean the 34s would have to do so either.
So not each and every custom setting requires a special command. Actually everything could be handled by flags, and only the most important settings may offer an additional convenient access by a dedicated command.

Dieter


#10

Quote:
... there is no need to reflect each and every setting in a user command. Take a look at the 41-series:
  • The decimal marker (comma/dot) and thousands separator are controlled by two flags. There is no special command like "E3ON" or "E3OFF" or RDX./RDX, since a simple CF28 / SF29 will do.

  • The printer can be set to double-wide and/or lower case printing. There are no special commands for this - simply set/clear flag 12 resp. flag 13.

  • The 41's user mode may be set directly by pressing the [USER] key. There is no programmable command for this. Instead, a program may simply set or clear (or toggle) the respective flag 27. Or test its status to determine whether user mode is on or off.

  • The angular mode is set directly by DEG, RAD and GRAD. This setting is also reflected by two flags that can be tested under program control to return the current mode. In this case, the 41-series does not allow to set/clear these flags directly, but this does not mean the 34s would have to do so either.
So not each and every custom setting requires a special command. Actually everything could be handled by flags, and only the most important settings may offer an additional convenient access by a dedicated command.

Dieter, I concur. But nevertheless you'll (actually: we'll) need some code like 'if flagXY then ... else ...' for each such option. This will add to the code we already maintain - not much but >0 for sure. At that very moment we (!) have to ask if it's worth it and what will be the cost.
  1. I fullheartedly agree that radix marks and thousand separators etc. can be controlled by flags. That will open the gate for those lovely posts we had in the past "my HP-xy shows such strange dots. How do I get rid of them? Any help appreciated." Of course people *could* search the documentation for the flag table - but seems they simply do *not do* it.
  2. Stressing your argument, you can reduce the command set massively by setting flags instead. I doubt it's handy for sensible commands.
  3. Now you force me assessing those compile time options - but I don't like to. Just let me say who wants a Casio shall use one. And ... no, I stop here.
  4. Compile time options cost next to no space. Anything else will cost more.
As usual, that's strictly my personal opinion. YMMV

d:-)


#11

Source available. Go ahead and recode the newly provided compile time options into flag-based options. :)

That actually seems like a reasonable/fun thing to do if you've never worked on the WP34S code before and would like to get your hands dirty... Both sets of code are there in front of you, plus other flag-dependent code elsewhere, so you have everything you could ask for to get your feet wet.

Cheers,

Doug

#12

Quote:
That will open the gate for those lovely posts we had in the past "my HP-xy shows such strange dots. How do I get rid of them? Any help appreciated."

Do you really think it makes a difference whether the answer is "Look into the MODE menu, and scroll down to SEPON resp. SEPOFF" or "Simply SF or CF 99" ?-)
Come on...
Quote:
Stressing your argument, you can reduce the command set massively by setting flags instead. I doubt it's handy for sensible commands.

Walter, I did not say that every possible setting should be handled by flags exclusively. For instance RDX. and RDX, or E3ON/E3OFF may remain available as separate commands. But this is not required for every single possible user preference. Especially not for those you once set and then forget.
Quote:
Compile time options cost next to no space. Anything else will cost more.

Of course every new and additional setting that is handled by flags will require some additional code, compared to a compiler directive that procuces a hard-coded firmware which does not allow any changes (except a new compiler run). On the other hand, the one or other configuration command could be dropped.

Finally - maybe most important:

Quote:
Compile time options cost next to no space

And can be used by next to no users.

Dieter


#13

I'm against the flag setting method as long as we don't have enough code space to offer a menu like the RPL machines which show each setting in clear text while the implementation relies on flags. The only option I can see is to use dedicated commands which you can identify by their name in the mode menu. We could have decided to map the flags to these settings so that they serve double duty (flag and mode setting) but this can have strange side effects if you don't know exactly the position in the flag array and the logical limits imposed on the values. Remember PEEK and POKE?

BTW, with RCLM, bit manipulation, and STOM, you can cause some havoc if you need to but this is not recommended.

OTH, it might be an option to make the newly available options dependent on the named flags, such as I, J, K, L, X, Y or Z. T is already reserved for such a setting (Trace mode in the printer enabled builds). Flags A, B, C and D already have special meanings, too.

#14

Thanks for those nice features. As a user I would like to have YREG runtime selectable (e.g. DISPXYON, DISPXYOFF). I like it when working with tuple like data, but find it distracting in other situations.

Personally, I also find the casio separator easier to grasp, because it is easier to distinguish from digits.

One more proposal: How about having a summary mode setting to return all mode settings to sane defaults? This would be helpful for users getting lost in some accidental mode setting (c.f. the troubleshooting guide.) How about [h] [mode] DONTPANIC?


#15

Quote:
How about having a summary mode setting to return all mode settings to sane defaults? This would be helpful for users getting lost in some accidental mode setting (c.f. the troubleshooting guide.) How about [h] [mode] DONTPANIC?

:-D There's already a command called RESET ;-) And as long as you backup your important data regularly there's no need to lose your towel. BTW, command names are limited to six characters on the WP 34s.

d:-)


#16

Even better, do ON (& hold) STO STO to save your current state and ON (& hold) RCL RCL to restore it. All mode settings, registers and RAM programs are saved and restored this way.

I generally do this right after flashing to save custom mode settings etc.


- Pauli


#17

Nice, I didn't know about this one yet, thanks. I knew about about RESET, but sometimes that's just... too much reset.

And thank you both for this very nice calculator. It surprises me all the time how many things about it "just feel right." It must have been a lot of work to get to this point.


Possibly Related Threads...
Thread Author Replies Views Last Post
  [WP-34S] Unfortunate key damage with update to V3 :( svisvanatha 5 353 12-10-2013, 11:37 PM
Last Post: Les Bell
  WP-34S (Emulator Program Load/Save) Barry Mead 1 194 12-09-2013, 05:29 PM
Last Post: Marcus von Cube, Germany
  DIY HP 30b WP 34s serial flash/programming cable Richard Wahl 2 269 12-04-2013, 11:14 AM
Last Post: Barry Mead
  [HP Prime]How to get Discrete-Time Fourier Transform uklo 0 222 11-18-2013, 08:02 PM
Last Post: uklo
  WP 34S/43 ?'s Richard Berler 3 290 11-10-2013, 02:27 AM
Last Post: Walter B
  My FrankenCulator (wp-34s) FORTIN Pascal 4 301 11-09-2013, 06:18 PM
Last Post: FORTIN Pascal
  WP 34S Owner's Handbook Walter B 5 442 11-09-2013, 05:34 PM
Last Post: Harald
  wp 34s overlay and programming. FORTIN Pascal 6 374 11-08-2013, 01:28 PM
Last Post: Nick_S
  m.dy in display of WP-34S Harold A Climer 3 212 11-05-2013, 11:28 AM
Last Post: Andrew Nikitin
  WP 34s : An old problem coming back Miguel Toro 2 216 11-05-2013, 03:00 AM
Last Post: Marcus von Cube, Germany

Forum Jump: