WP-34S --> WP-30S: Reduce / Reuse / Repurpose

[Sanjeev Visvanatha]

As mentioned in this other thread, I came up with a concept for reducing the feature set of the Mighty WP-34S. My intention is to learn, and also to configure a real 30B with this alternate layout for my own use.

Layout is as follows.
   
It contains 3 new catalogs (HYP, CLEAR and PARTS). I tried to make the keyboard basic, but familiar. Catalogs are on the far right, so you always know where to look for extra functions / settings.

So far, I have many of the key assignments made in the Windows Emulator. Following is a current status of key assignments that are working (Green Colour), and not implemented yet (Red Colour). Further, Stubs for new catalogs are in Dark Green Colour.
   

My next challenge is to redefine the previous shift keys [f] [g] and [h]. I have not spent enough time to learn what changes to make there. Also, the BST and SST keys are not working, and I suspect they too have some special considerations that I need to look at further.

Comments and suggestions are welcome, especially with respect to the challenges I presented above for the remaining keys.

[Paul Dale]

I wouldn't worry about the various shifts. Just don't map them to keys and leave the code alone.

LastX was replaced by RCL L. You could add a LastX command but it gets fairly involved and there really isn't any benefit apart from the screen nemonic.

SST and BST don't come back as key-codes from memory, they are specials are intercepted outside of xeq().

Adding catalogues should be straightforward, you might have to remove existing catalogues to make space in the bitfield for the new numbers.


- Pauli

[Sanjeev Visvanatha]

(01-29-2014 04:13 AM)Paul Dale Wrote:  I wouldn't worry about the various shifts. Just don't map them to keys and leave the code alone.

From what I can see, Shifts are mapped to keys via this code in keys.h:

Code:

typedef enum {
K00 = 0, K01 = 1, K02 = 2, K03 = 3, K04 = 4, K05 = 5,
K10 = 6, K11 = 7, K12 = 8,
#define K13 9 /* Shift keys aren't in the enum since they are handled */
#define K14 10 /* Directly in the main key processing loop */
#define K15 11
K20 = 12, K21 = 13, K22 = 14, K23 = 15, K24 = 16,
K30 = 18, K31 = 19, K32 = 20, K33 = 21, K34 = 22,
K40 = 24, K41 = 25, K42 = 26, K43 = 27, K44 = 28,
K50 = 30, K51 = 31, K52 = 32, K53 = 33, K54 = 34,
K60 = 36, K61 = 37, K62 = 38, K63 = 39, K64 = 40,
} keycode;
#define K_UNKNOWN -1
#define K_F K13
#define K_G K14
#define K_H K15
#define K_ARROW K04
#define K_CMPLX K05

I changed K_H to be K50 (using H shift as the single shift key), and this works for defining my new shift key. However, I am at a loss as to how to redefine K13-K15.

(01-29-2014 04:13 AM)Paul Dale Wrote:  LastX was replaced by RCL L. You could add a LastX command but it gets fairly involved and there really isn't any benefit apart from the screen nemonic.

OK - I will see about this one. I may rethink adding LastX if it becomes involved.

WIth respect to your other suggestions, thank you for the help. I will tackle those after I get the 3 previous shifts dealt with.

[Sanjeev Visvanatha]

(01-29-2014 04:13 AM)Paul Dale Wrote:  LastX was replaced by RCL L. You could add a LastX command but it gets fairly involved and there really isn't any benefit apart from the screen nemonic.

Actually, I tried this when processing a key code after H shift , and this seems to work for LastX:

Code:


        // Row 3
        RARG(RARG_RCL, regL_idx),    // LAST X

[Paul Dale]

That is what I meant. That is the keycode for RCL L being generated.
Since, you're not doing programming, you'll only notice a difference if you press and hold the key to see what it is going to execute.

- Pauli

[Sanjeev Visvanatha]

(01-30-2014 04:04 AM)Paul Dale Wrote:  That is what I meant. That is the keycode for RCL L being generated.
Since, you're not doing programming, you'll only notice a difference if you press and hold the key to see what it is going to execute.

Ah, I misunderstood you. Yes, when it is executed, I see "RCL L".

[Jonathan Cameron]

Sanjeev,

Is your code available? I would like to see what you have done.

Thanks

-Jonathan

[Sanjeev Visvanatha]

(02-01-2014 06:05 PM)Jonathan Cameron Wrote:  Sanjeev,

Is your code available? I would like to see what you have done.

Thanks

-Jonathan

I do not have the code hosted anywhere. I plan on publishing my modifications when they are more complete.

[Sanjeev Visvanatha]

   

So, keyboard is fully working in Primary, Shifted, Register and Alpha (for catalogs)! I have reduced some catalogs to fit functions I want (e.g. MODE catalog). But I have not been able to introduce a new catalog after some tinkering last night. I get "NOP" displayed when I should get the first catalog entry.

In regards to the Alpha placement on the keyboard I chose to keep XYZT in the same respective places as the WP-34S.

I will likely move catalogs from being on Primary functions (CONV and PARTS) since catalog navigation gets broken then. However, I will wait until I can add my own catalog before reconfiguring the key placement.

Fun times!

[Sanjeev Visvanatha]

(01-29-2014 04:13 AM)Paul Dale Wrote:  Adding catalogues should be straightforward, you might have to remove existing catalogues to make space in the bitfield for the new numbers.

Yes, I had to remove catalogues not needed to make space for my new ones.

Is there a way to specify that a particular catalog be presented in a pre-determined order, rather than Alphabetic?

[Bit]

(02-04-2014 02:32 AM)Sanjeev Visvanatha Wrote:  Is there a way to specify that a particular catalog be presented in a pre-determined order, rather than Alphabetic?

It can be done but you'd need to fix up catalog navigation, see the second paragraph in post 14 here: http://www.hpmuseum.org/forum/thread-591...ml#pid4226
Maybe there's a better way... I'm sure Pauli will know.

[Paul Dale]

Catalogues are sorted as part of the build process. This would have to be changed.

There are also run time checks in some of the emulators to verify that the catalogues are properly sorted & these would have to go (or maybe I removed them when the build process included the sorting step).

Also, navigation relies on the ordering and would break.

So, yes it would be possible to change the catalogue order but it would be a bit of a retrograde step.


Pauli

[Sanjeev Visvanatha]

Pauli, Thank you for the explanation. The reason I asked is the HYP catalog in my layout would be ordered as ACOSH, ASINH, ATANH, COSH, SINH, TANH. It doesn't feel right. I may have to revisit using HYP and HYP-1 as the WP-34S does.

Also, another application would be to group related functions together in a catalog (e.g. MODES catalog with ALL, FIX, SCI, ENG grouped together amongst other functions).

[Sanjeev Visvanatha]

I am renaming this alternate layout as the WP-30S.

[Sanjeev Visvanatha]

WP-30S is working in the Windows Emulator. However, I am now trying to build the file for flashing the calculator using flash.cmd script. This is throwing a few errors. Being pretty inexperienced in this area, does anyone have some ideas / pointers I could try?

Code:


arm-none-eabi-gcc.exe (GNU Tools for ARM Embedded Processors) 4.8.3 20131129 (release) [ARM/embedded-4_8-branch revision 205641]
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

mingw32-make[1]: Entering directory 'D:/sanjeev/HP30B/WP-30S/trunk/decNumber'
arm-none-eabi-gcc -c -mthumb -mcpu=arm7tdmi -Os -fira-region=one -Wall -Werror -g -fno-common -fno-exceptions  -DREALBUILD -Dat91sam7l128 -Iatmel -DNO_BACKUP_INIT -DNO_RAM_COPY  -o ../windows32_realbuild/obj/decNumber.o decNumber.c
In file included from c:\program files\gnu tools arm embedded\4.8 2013q4\lib\gcc\arm-none-eabi\4.8.3\include\stdint.h:9:0,
                 from c:\program files\gnu tools arm embedded\4.8 2013q4\lib\gcc\arm-none-eabi\4.8.3\include-fixed\sys\cdefs.h:54,
                 from c:\program files\gnu tools arm embedded\4.8 2013q4\arm-none-eabi\include\string.h:12,
                 from decNumber.c:163:
c:\program files\gnu tools arm embedded\4.8 2013q4\arm-none-eabi\include\stdint.h:79:21: error: conflicting types for 'int32_t'
 typedef signed long int32_t;
                     ^
In file included from decNumber.h:32:0,
                 from decNumber.c:161:
decContext.h:41:15: note: previous declaration of 'int32_t' was here
 typedef int   int32_t;
               ^
In file included from c:\program files\gnu tools arm embedded\4.8 2013q4\lib\gcc\arm-none-eabi\4.8.3\include\stdint.h:9:0,
                 from c:\program files\gnu tools arm embedded\4.8 2013q4\lib\gcc\arm-none-eabi\4.8.3\include-fixed\sys\cdefs.h:54,
                 from c:\program files\gnu tools arm embedded\4.8 2013q4\arm-none-eabi\include\string.h:12,
                 from decNumber.c:163:
c:\program files\gnu tools arm embedded\4.8 2013q4\arm-none-eabi\include\stdint.h:80:23: error: conflicting types for 'uint32_t'
 typedef unsigned long uint32_t;
                       ^
In file included from decNumber.h:32:0,
                 from decNumber.c:161:
decContext.h:45:23: note: previous declaration of 'uint32_t' was here
 typedef unsigned int  uint32_t;
                       ^
decNumber.c:167:12: error: conflicting types for 'powers'
 const uInt powers[10]={1, 10, 100, 1000, 10000, 100000, 1000000,
            ^
In file included from decNumber.c:162:0:
decNumberLocal.h:135:21: note: previous declaration of 'powers' was here
   extern const uInt powers[10];
                     ^
Makefile:33: recipe for target '../windows32_realbuild/obj/decNumber.o' failed
mingw32-make[1]: *** [../windows32_realbuild/obj/decNumber.o] Error 1
mingw32-make[1]: Leaving directory 'D:/sanjeev/HP30B/WP-30S/trunk/decNumber'
make: *** [windows32_realbuild/obj/libdecNum34s.a] Error 2

[Bit]

(02-05-2014 03:23 AM)Sanjeev Visvanatha Wrote:  This is throwing a few errors. Being pretty inexperienced in this area, does anyone have some ideas / pointers I could try?

I ran into this, too. The types in stdint.h conflict with some of the types declared in the WP 34S source. The right thing to do would be to modify the WP 34S source so it doesn't try to override standard types if stdint.h is available, but I haven't yet gotten around to creating a proper fix.

However, the below patch contains some ugly hacks that'll allow you to get past this problem. (You'll probably have to revert the patch before trying to compile the emulator in the same source tree.) The patch also provides the pointers you asked for in case you'd like to work on a better solution.

Code:

diff -ur wp34s-code_revision-3470_20140127_original/Makefile wp34s-code_revision-3470_20140127_integer_type_fix/Makefile
--- wp34s-code_revision-3470_20140127_original/Makefile    2014-01-27 21:38:32.991789124 -0500
+++ wp34s-code_revision-3470_20140127_integer_type_fix/Makefile    2014-02-04 23:28:16.336463245 -0500
@@ -31,7 +31,7 @@
 #INFRARED = 1
 endif
 
-BASE_CFLAGS := -Wall -Werror -g -fno-common -fno-exceptions 
+BASE_CFLAGS := -Wall -Werror -g -fno-common -fno-exceptions -DINT32_IS_LONG
 OPT_CFLAGS := -Os -fira-region=one
 USE_CURSES := -DUSECURSES
 
diff -ur wp34s-code_revision-3470_20140127_original/decNumber/decContext.h wp34s-code_revision-3470_20140127_integer_type_fix/decNumber/decContext.h
--- wp34s-code_revision-3470_20140127_original/decNumber/decContext.h    2014-01-27 21:38:32.691789132 -0500
+++ wp34s-code_revision-3470_20140127_integer_type_fix/decNumber/decContext.h    2014-02-04 23:28:16.332463246 -0500
@@ -38,11 +38,19 @@
 
 typedef signed char        int8_t;
 typedef short int        int16_t;
+#ifndef INT32_IS_LONG
 typedef int            int32_t;
+#else
+typedef long            int32_t;
+#endif
 typedef long long int        integer64_t;
 typedef unsigned char        uint8_t;
 typedef unsigned short int    uint16_t;
+#ifndef INT32_IS_LONG
 typedef unsigned int        uint32_t;
+#else
+typedef unsigned long        uint32_t;
+#endif
 #ifdef FIX_LINUX_64_BITS
 typedef unsigned long int    uint64_t;
 #else
diff -ur wp34s-code_revision-3470_20140127_original/xeq.c wp34s-code_revision-3470_20140127_integer_type_fix/xeq.c
--- wp34s-code_revision-3470_20140127_original/xeq.c    2014-01-27 21:38:32.995789124 -0500
+++ wp34s-code_revision-3470_20140127_integer_type_fix/xeq.c    2014-02-04 23:28:16.336463245 -0500
@@ -3443,7 +3443,7 @@
  *  Fix the pointer alignment on the go.
  */
 #ifdef REALBUILD
-typedef unsigned long uintptr_t;
+typedef unsigned uintptr_t;
 #else
 #include <stdint.h>
 #endif

[Paul Dale]

The 34S sources are meant to be compiled without standard libraries or headers.


- Pauli

[Marcus von Cube]

I have to check what is going wrong here when I'm back home. The error message doesn't lock quite right to me.

Edit: I checked the output again and it looks like the Makefile is trying to compile the decNumber library with the cross compiler. This should not happen because the cross compiler is meant to compile the complete source tree in one go. decNumber is included as source, not linked in.

OTH, decNumer is compiled with the host compiler to create the utilities which in turn produce some of the input files for the cross compiler. Check, if you did accidentally provide the wrong name for the host compiler in your Makefile.

On more remark: I had bad luck with any ARM-GCC version beyond 4.6.0. The code produced is smaller but does not work properly.

[Bit]

(02-05-2014 09:33 AM)Paul Dale Wrote:  The 34S sources are meant to be compiled without standard libraries or headers.

decNumber/decNumber.c and atmel/slcdc.c pull in string.h for example.

You just get lucky with some compiler environments that define (u)int32_t using int rather than long and uintptr_t the other way around, or where string.h doesn't depend on stdint.h, so there's no conflict. Avoiding standard libraries and most of the headers makes sense, but I wouldn't redefine standard integer types if at all possible.

[Sanjeev Visvanatha]

(02-05-2014 04:39 AM)Bit Wrote:  I ran into this, too. The types in stdint.h conflict with some of the types declared in the WP 34S source. The right thing to do would be to modify the WP 34S source so it doesn't try to override standard types if stdint.h is available, but I haven't yet gotten around to creating a proper fix.

However, the attached patch contains some ugly hacks that'll allow you to get past this problem. (You'll probably have to revert the patch before trying to compile the emulator in the same source tree.) The patch also provides the pointers you asked for in case you'd like to work on a better solution.

Thank you very much for this patch! I learned how to use 'patch' today..... another first for me. That worked very well, and I successfully created the BIN file, and flashed my 30B into a WP-30S. I need to make one more change to main.c file which I forgot to do, but otherwise it seems the calculator is responding as expected.

I will take this opportunity to thank (in no particular order) Pauli, Walter and Marcus - each who have provided me with assistance in getting this far. Thank you!

I will post a video later today, after I take care of the snow that was dumped on my driveway.