WP 34S and 31S bugs and fixes

[Nigel (UK)]

Mini-bug in r3716 and probably earlier ones too:

With the calc_full.bin firmware, the X.FCN catalogue has a ??? entry in between sRCL and TIME (where the STOPW application would be). Executing this gives an "Undefined op-code" error, which should never happen according to the manual! A problem caused by this is that searches for commands near the end of the alphabet get stuck at this point, rather than reaching the correct command.

Nigel (UK)

[Bit]

I've committed a change to optionally allow entering four-digit exponents in double precision mode. The same set of rules governing exponent entry are available as in single precision mode (except there's no debug option) and rules for double precision mode can be independently configured.

I don't expect this feature to be enabled in mainline as Walter said he didn't like the idea of displaying four-digit exponents on the screen of the 34S. And I'm not sure how much practical value being able to enter four-digit exponents offers as such very large or small numbers probably aren't needed often in practice in a pocket calculator. Nevertheless, since I created the code some time ago, I've added it for the sake of completeness. As usual, it has no cost in terms of firmware size or speed if disabled.

I've attached a 34S flash image and a Windows binary to demo the new features. It has a similar configuration as the previous ones I attached with these exceptions:
- Warnings occupy both lines during number entry so this behavior can be directly compared to the other one.
- Exponents are right justified and padded with zeros so the digits don't move when we switch from three to four digits in the exponent.
- If flag D is set and the mantissa is zero, any exponent can be entered (+/-999 or +/-9999 in double precision mode).

[Bit]

(12-23-2014 08:50 PM)Nigel (UK) Wrote:  Mini-bug in r3716 and probably earlier ones too:

With the calc_full.bin firmware, the X.FCN catalogue has a ??? entry in between sRCL and TIME (where the STOPW application would be). Executing this gives an "Undefined op-code" error, which should never happen according to the manual! A problem caused by this is that searches for commands near the end of the alphabet get stuck at this point, rather than reaching the correct command.

Nigel (UK)

I couldn't reproduce this issue.

Which binary were you using? Did you compile it yourself? If so, which compiler did you use and what was in features.h?

[walter b]

Hmmh, the subject is "WP 34S and 31S bugs and fixes". Entering four-digit exponents doesn't fix a bug IMHO.

d:-/

[Bit]

(12-24-2014 01:35 PM)walter b Wrote:  Hmmh, the subject is "WP 34S and 31S bugs and fixes". Entering four-digit exponents doesn't fix a bug IMHO.

d:-/

True, but the bigger part of the code is just an extension of the work that I've done on exponent entry so I thought I'd just mention it here. We can split off the discussion to another thread should this feature generate a lot of feedback, which I don't expect.

[Nigel (UK)]

(12-24-2014 01:11 PM)Bit Wrote:  

(12-23-2014 08:50 PM)Nigel (UK) Wrote:  Mini-bug in r3716 and probably earlier ones too:

With the calc_full.bin firmware, the X.FCN catalogue has a ??? entry in between sRCL and TIME (where the STOPW application would be). Executing this gives an "Undefined op-code" error, which should never happen according to the manual! A problem caused by this is that searches for commands near the end of the alphabet get stuck at this point, rather than reaching the correct command.

Nigel (UK)

I couldn't reproduce this issue.

Which binary were you using? Did you compile it yourself? If so, which compiler did you use and what was in features.h?

I used the calc_full.bin binary. I compiled it myself; the gcc version is 4.8.1 from MinGW and 4.7.2 from the yagarto installation. (I'm doing this on Windows.) I'd need to look at the makefile to be sure which one is actually being used; you are probably much more familiar with this than I am. I haven't done anything with the compiler since I first installed it a couple of years ago. Before compiling I made a fresh checkout of version 3716 into a clean directory, making no changes to features.h before compiling.

Nigel (UK) (Edited for clarity)

[walter b]

You can count the participants of this discussion easily. The silent majority seems to like the WP 34S as it is.

d:-)

[Bit]

(12-24-2014 03:10 PM)walter b Wrote:  You can count the participants of this discussion easily. The silent majority seems to like the WP 34S as it is.

d:-)

That could very well be the case. Then again, most people probably don't know which options exist or how they can be obtained. The WP 34S is the best non-graphing pocket calculator ever made IMO, regardless of any optional features, so it's easy to be happy with it (I am and was even before I made any changes). Unless multiple alternative versions are provided that are equally well advertised, I'm not sure we have meaningful data about the true preferences of the majority.

In any case, I don't see it as a popularity contest. Most of what I contributed are bugfixes or features like Y register display that clearly benefit everyone, as I believe the new exponent entry code (for single precision mode) will, too. The extra features can be reserved for those who want them or just enjoy tweaking things. It's because I like to tweak things that I create any patches at all, it comes in a single package.

Happy Holidays!

[Bit]

(12-24-2014 03:00 PM)Nigel (UK) Wrote:  

(12-24-2014 01:11 PM)Bit Wrote:  I couldn't reproduce this issue.

Which binary were you using? Did you compile it yourself? If so, which compiler did you use and what was in features.h?

I used the calc_full.bin binary. I compiled it myself; the gcc version is 4.8.1 from MinGW and 4.7.2 from the yagarto installation. (I'm doing this on Windows.) I'd need to look at the makefile to be sure which one is actually being used; you are probably much more familiar with this than I am. I haven't done anything with the compiler since I first installed it a couple of years ago. Before compiling I made a fresh checkout of version 3716 into a clean directory, making no changes to features.h before compiling.

Nigel (UK) (Edited for clarity)

As explained by Marcus earlier, and I can confirm based on my own experience, you shouldn't use anything but Yagarto GCC 4.6.0 because other builds or versions of GCC could create subtly broken binaries. Please check if you can reproduce the problem with Yagarto 4.6.0.

Edit: Those who use Yagarto under Linux with Wine will notice that compiling the constants (libconst.a) takes a lot of time. That's because GCC is invoked for some 107 small source files one at a time and starting up an application through Wine involves a lot of overhead. Since those files only have some very simple static data in them but no code, it makes no difference which GCC you use and you can change compile_consts.c to invoke a faster native GCC. I have verified that e.g. the CodeSourcery build of GCC 4.6.1 (which is known to create broken binaries otherwise) compiles the constants correctly and the .rodata sections (the only thing that matters) are completely identical to those produced by Yagarto 4.6.0.

[Nigel (UK)]

(12-24-2014 04:36 PM)Bit Wrote:  As explained by Marcus earlier, and I can confirm based on my own experience, you shouldn't use anything but Yagarto GCC 4.6.0 because other builds or versions of GCC could create subtly broken binaries. Please check if you can reproduce the problem with Yagarto 4.6.0.

Same problem with Yagarto 4.6.0. I will try to downgrade the gcc version provided by MinGW to 4.6.0. and see if the problem persists.

Nigel (UK)

[Nigel (UK)]

(12-24-2014 06:03 PM)Nigel (UK) Wrote:  

(12-24-2014 04:36 PM)Bit Wrote:  As explained by Marcus earlier, and I can confirm based on my own experience, you shouldn't use anything but Yagarto GCC 4.6.0 because other builds or versions of GCC could create subtly broken binaries. Please check if you can reproduce the problem with Yagarto 4.6.0.

Same problem with Yagarto 4.6.0. I will try to downgrade the gcc version provided by MinGW to 4.6.0. and see if the problem persists.

Nigel (UK)

MinGW doesn't offer a gcc version of 4.6.0 - there's a 4.5.2 and 4.6.1 . Can anyone recommend a version of gcc (in MinGW, not Yagarto) to use that works?

Merry Christmas! No immediate replies expected :-)

Nigel (UK)

[Marcus von Cube]

(12-24-2014 07:00 PM)Nigel (UK) Wrote:  MinGW doesn't offer a gcc version of 4.6.0 - there's a 4.5.2 and 4.6.1 . Can anyone recommend a version of gcc (in MinGW, not Yagarto) to use that works?

The host GCC version is relatively unimportant, all it creates is some C code to be compiled later by the target GCC. The main problem with later ARM gcc version is that they seem to "over optimize" the code so that it no longer runs flawlessly on the Atmel chip.

I'll check the catalog problem on a real 30b with the latest non xtal build.

EDIT: Checked. The software works as advertised. Can you just do a new check out of the repository and rebuild again?

[Nigel (UK)]

(12-24-2014 08:06 PM)Marcus von Cube Wrote:  

(12-24-2014 07:00 PM)Nigel (UK) Wrote:  MinGW doesn't offer a gcc version of 4.6.0 - there's a 4.5.2 and 4.6.1 . Can anyone recommend a version of gcc (in MinGW, not Yagarto) to use that works?

The host GCC version is relatively unimportant, all it creates is some C code to be compiled later by the target GCC. The main problem with later ARM gcc version is that they seem to "over optimize" the code so that it no longer runs flawlessly on the Atmel chip.

I'll check the catalog problem on a real 30b with the latest non xtal build.

EDIT: Checked. The software works as advertised. Can you just do a new check out of the repository and rebuild again?

I have checked out build 3717 into a new folder and built the firmware files using a yagarto with gcc version 4.6.0 . I have loaded calc.bin (and yes, it is the new one and not an older one!) into a calculator, erasing rather than updating. The problem is still there - opening X.FCN and then pressing 3 (to go to the Version command) brings up ???. This didn't always happen - checking the version after flashing new firmware is something that I normally do. I'm currently checking out revision 3687 to see if the problem has arisen since then.

Nigel (UK)

[Marcus von Cube]

(12-24-2014 10:37 PM)Nigel (UK) Wrote:  I have checked out build 3717 into a new folder and built the firmware files using a yagarto with gcc version 4.6.0 . I have loaded calc.bin (and yes, it is the new one and not an older one!) into a calculator, erasing rather than updating. The problem is still there - opening X.FCN and then pressing 3 (to go to the Version command) brings up ???. ...

Strange. Can you post catalogues.h after a compile of calc.bin? I will compare it against my local copy. What are your steps to compile the stuff? Are you using the .cmd files provided?

[Nigel (UK)]

(12-25-2014 12:51 AM)Marcus von Cube Wrote:  

(12-24-2014 10:37 PM)Nigel (UK) Wrote:  I have checked out build 3717 into a new folder and built the firmware files using a yagarto with gcc version 4.6.0 . I have loaded calc.bin (and yes, it is the new one and not an older one!) into a calculator, erasing rather than updating. The problem is still there - opening X.FCN and then pressing 3 (to go to the Version command) brings up ???. ...

Strange. Can you post catalogues.h after a compile of calc.bin? I will compare it against my local copy. What are your steps to compile the stuff? Are you using the .cmd files provided?

Going back to old builds (3500 or so) which I know compiled correctly at the time the problem persists. The calc.bin file provided in the older builds is fine; the one I compile myself with an unmodified features.h file has the problem described above. The procedure I have followed is:

• Make a new directory
• Use svn to check out the latest build into that directory
• Make the same changes to create_revision.c and wp34s_asm.pl that I have been making for the past two years. In create_revision.c I put in an explicit temporary file name to replace the automatically generated one that doesn't work; in wp34s_asm.pl I change the line
  Code:
  

  my $preproc_fallback_dir = "";
  to
  Code:
  

  my $preproc_fallback_dir = "C:/Users/nd/wp34s/stop_test_3/trunk/tools/";
  where the directory I've typed is the correct one on my computer.
• Run makeflash
  

The calc.bin file generated in this way has the ??? entry in X.FCN described above when loaded onto my calculator

I have attached catalogues.h (renamed). I really don't know what has changed to cause this problem. Thank you for trying to help!

Nigel (UK)

[Marcus von Cube]

(12-25-2014 09:08 PM)Nigel (UK) Wrote:  Run makeflash

Have you changed the PATH statement in makeflash.cmd according to your Yagarto installation?

Your catalogues.h file is identical to mine but this is due to the fact that makeflash creates all three variants and thus overwrites this file with each build. Can you just run the first step from the batch file? I'll do the same here, then.

[Nigel (UK)]

(12-26-2014 06:18 AM)Marcus von Cube Wrote:  

(12-25-2014 09:08 PM)Nigel (UK) Wrote:  Run makeflash

Have you changed the PATH statement in makeflash.cmd according to your Yagarto installation?

Your catalogues.h file is identical to mine but this is due to the fact that makeflash creates all three variants and thus overwrites this file with each build. Can you just run the first step from the batch file? I'll do the same here, then.

My yagarto installation is in C:\yagarto\bin; this is in my path anyway. Just to be sure, I edited the PATH in makeflash; no difference.

I have now run just the first step from the batch file; only calc.bin was generated. I have attached the catalogues.h file.

Nigel (UK)

[Marcus von Cube]

(12-26-2014 11:31 AM)Nigel (UK) Wrote:  I have attached the catalogues.h file.

This is definitely the wrong one. I've investigated the make process and found something fishy with the creation of this file. An updated Makefile is available on SourceForge. Attached is the catalogues.h file as it should be after the compile of calc.bin alone. The zip file contains a script to build calc.bin.

[Nigel (UK)]

(12-26-2014 03:57 PM)Marcus von Cube Wrote:  

(12-26-2014 11:31 AM)Nigel (UK) Wrote:  I have attached the catalogues.h file.

This is definitely the wrong one. I've investigated the make process and found something fishy with the creation of this file. An updated Makefile is available on SourceForge. Attached is the catalogues.h file as it should be after the compile of calc.bin alone. The zip file contains a script to build calc.bin.

Success! I've updated the Makefile with svn and now the calc.bin that I have built no longer has the question marks in it. Thank you!

I've given a WP-34S containing firmware with the question mark problem to someone as a Christmas present. Apart from the unnecessary menu entry, are there likely to be any more problems with it?

Nigel (UK) (out to a party now!)

[Marcus von Cube]

(12-26-2014 06:12 PM)Nigel (UK) Wrote:  I've given a WP-34S containing firmware with the question mark problem to someone as a Christmas present. Apart from the unnecessary menu entry, are there likely to be any more problems with it?

I'd bet there are. It is better to update the device if possible.