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

[Sanjeev Visvanatha]

Here is a video of the WP-30S in action. Yes, very amateur quality video, and overlay (not to mention amateur hatchet job on the code)

Very similar to the WP-31S in the other thread

Introducing the WP-30S

The BIN File is available to anyone wishing to try it out. I can put it somewhere if there is interest.

[Jonathan Cameron]

(02-06-2014 12:28 AM)Sanjeev Visvanatha Wrote:  Here is a video of the WP-30S in action.

Nice job!

-Jonathan

[Sanjeev Visvanatha]

Current Layout and Catalog Contents:

   


CONV
As in WP-34S

CONST
As in WP-34S

HYP
ACOSH ASINH ATANH COSH SINH TANH

CLEAR
CLALL CLREG CLS CLSTK RESET

MODE
GRAD ALL RDX, RDX. BestF ExpF
LinF LogF PowerF DENANY DENMFAC DENFIX
DENMAX DISP E3OFF E3ON SEPOFF SEPON
D.MY M.DY Y.MD SSIZE4 SSIZE8 FRACT
STOM RCLM

PROB
As in WP-34S

STAT
As in WP-34S with s xbar yhat and r

SUMS
As in WP-34S

PARTS
BATT FP IP LCM MOD NEXTP
PRIME? RMDR SSIZE? VERS WDAY DDays
DAYS+ MRR

LAST x
(Keyboard representation only - corresponds to RCL L in WP-34S)


BIN File for anyone interested in flashing a 20B/30B into this basic RPN:


  WP-30S_5-Feb-2014.zip (Size: 82.67 KB / Downloads: 14)

[walter b]

Very nice and coherent work!

Some remarks in random order (what I'd do differently - but it's your 30S anyway):

• Drop LASTx. You've got RCL L anyway.
• Rename PARTS to X.FCN - that's what it does.
• Living in a part of the former British Empire, you probably must make CONV primary, don't you?
• I wouldn't put any menu on a key top here.
  

I don't have any alternate layout suggestions - as mentioned above you made it quite coherent. I just came across those points. YMMV.

Enjoy your snow.

d:-)

[Jonathan Cameron]

What version of Sourcery_G++_Lite are you using?

I'm some having issues with the version I downloaded.

Thanks

-Jonathan

[Jonathan Cameron]

(02-06-2014 05:12 AM)Jonathan Cameron Wrote:  I'm some having issues with the version I downloaded.

I ended up switching to Sourcery G++ Lite 2011.03-42 which seems to work okay. I had tried the Sourcery CodeBench Lite 2013.11-24 verson but ran into some build problems.

The 2011.03-42 version seems to work fine. I don't have a programming cable yet, so I have not tested the newly generated flash image.

-Jonathan

[Sanjeev Visvanatha]

(02-06-2014 04:49 AM)walter b Wrote:  Very nice and coherent work!

Some remarks in random order (what I'd do differently - but it's your 30S anyway):

• Drop LASTx. You've got RCL L anyway.
• Rename PARTS to X.FCN - that's what it does.
• Living in a part of the former British Empire, you probably must make CONV primary, don't you?
• I wouldn't put any menu on a key top here.
  

I don't have any alternate layout suggestions - as mentioned above you made it quite coherent. I just came across those points. YMMV.

Enjoy your snow.

d:-)

Thank you for your kind words and suggestions. I certainly gleaned many ideas from looking at older calculators and following some discussions going on here.

Regarding Last x: This is a personal pet peeve of mine with the WP-34S, as I have not been able to train my brain to quickly use RCL L. Using a 15C LE at work daily since its introduction, I have grown used to this treatment of Last x. And this is the beauty of the work that you, Pauli and Marcus (and the rest) have created - it is fairly easily customizable to another's needs.

[Bit]

(02-05-2014 09:40 PM)Sanjeev Visvanatha Wrote:  Thank you very much for this patch! I learned how to use 'patch' today..... another first for me.

I'm glad I could help. I suggest you heed Marcus's advice about GCC versions though. Trying to debug compiler bugs is probably not the best way to start out if you're new to programming.
You probably won't need my patch if you switch to an older GCC.

[Bit]

(02-05-2014 04:26 PM)Marcus von Cube Wrote:  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.

Does this mean you've had bad experience with GCC versions 4.6.x (where x > 0)?

[Sanjeev Visvanatha]

Bit, thank you for your help as well. I will see what to do about my compiler, but at the moment things are working.

[Jeff O.]

(02-06-2014 04:05 AM)Sanjeev Visvanatha Wrote:  BIN File for anyone interested in flashing a 20B/30B into this basic RPN:

Downloaded and flashed. Overall, I like it. A little hard to use with no overlay, I have to refer to your layout picture. I like that the shift key is where it is on the 30b, as well as the up and down arrows. With practice, maybe I could memorize the function locations. At least I can always just hold the key down to get the function name and keep holding to null it out if I guess wrong.

Just a couple of minor comments/questions:

Do we really need both a SHOW command, which lets you scroll through and view the lettered and numbered registers, and a VIEW command that lets you view any individual register? If not, then SHOW could behave like SHOW on the 42S (and f-PREFIX on the 15C) to show the full mantissa.

Have you considered incorporating Bit's two-line display mode? I think that would be welcome on a basic or beginner’s calculator, so you can see the x and y registers and what happens to them for various operations.

I see that the "h" is lit when you press the shift key. Classically speaking (for example, on the 31E) if there was only one shift key, it was the "f" key, which also was the yellow shift key as you depict. So could we get an "f" instead of an "h"?

Thanks for your efforts.

[Marcus von Cube]

(02-06-2014 04:42 PM)Bit Wrote:  Does this mean you've had bad experience with GCC versions 4.6.x (where x > 0)?

I'm using Yagarto. The latest version that produces working binaries is 4.6.0. The later 4.7.2 creates more compact but non working code. I never had luck with any version of CodeSourcery. It used to produce more compact code than the official GCC with the same version number but obviously introduces some bugs, at least for the Atmel processor in the 20b/30b. I suspect that these optimizations were added to the official GCC later, creating the same problems. So we're stuck with 4.6.0.

[Sanjeev Visvanatha]

(02-06-2014 05:47 PM)Jeff O. Wrote:  Downloaded and flashed. Overall, I like it. A little hard to use with no overlay, I have to refer to your layout picture. I like that the shift key is where it is on the 30b, as well as the up and down arrows. With practice, maybe I could memorize the function locations. At least I can always just hold the key down to get the function name and keep holding to null it out if I guess wrong.

Just a couple of minor comments/questions:

Do we really need both a SHOW command, which lets you scroll through and view the lettered and numbered registers, and a VIEW command that lets you view any individual register? If not, then SHOW could behave like SHOW on the 42S (and f-PREFIX on the 15C) to show the full mantissa.

Have you considered incorporating Bit's two-line display mode? I think that would be welcome on a basic or beginner’s calculator, so you can see the x and y registers and what happens to them for various operations.

I see that the "h" is lit when you press the shift key. Classically speaking (for example, on the 31E) if there was only one shift key, it was the "f" key, which also was the yellow shift key as you depict. So could we get an "f" instead of an "h"?

Thanks for your efforts.

I am glad you tried it, and am thankful for your feedback. In terms of an overlay, perhaps if there is enough interest, a community solution will present itself. I had not paid any attention to the 30b keys, but I did look at the Pioneers where similar key placement was made. Looking at the 30b now, some keys would only need labels on shift positions, and we could use the same blue colour for Shift.

In terms of View and Show, I could utilize the WP-34S command for showing the entire number, in lieu of Show, thereby satisfying your request. I think that is a good idea actually. Keyboard command could still be Show.

I had not considered Bit's Y register addition, but that is a fantastic idea. Perhaps also for the planned 31S.

Yes, i recognize that H shift is displayed, but classically speaking, it should be F shift. Blame this on me, and my tinkering with the code, where I saw it easier to make the primary shift key as H. This also led me down the path of making the Hyp catalog, instead of a Hyp key. Doing this again, i would use the code for F shift instead as the Primary shift key.

[Sanjeev Visvanatha]

(02-06-2014 10:09 PM)Marcus von Cube Wrote:  

(02-06-2014 04:42 PM)Bit Wrote:  Does this mean you've had bad experience with GCC versions 4.6.x (where x > 0)?

I'm using Yagarto. The latest version that produces working binaries is 4.6.0. The later 4.7.2 creates more compact but non working code. I never had luck with any version of CodeSourcery. It used to produce more compact code than the official GCC with the same version number but obviously introduces some bugs, at least for the Atmel processor in the 20b/30b. I suspect that these optimizations were added to the official GCC later, creating the same problems. So we're stuck with 4.6.0.

I am also using Yagarto.

[Bit]

(02-06-2014 10:09 PM)Marcus von Cube Wrote:  

(02-06-2014 04:42 PM)Bit Wrote:  Does this mean you've had bad experience with GCC versions 4.6.x (where x > 0)?

I'm using Yagarto. The latest version that produces working binaries is 4.6.0. The later 4.7.2 creates more compact but non working code. I never had luck with any version of CodeSourcery. It used to produce more compact code than the official GCC with the same version number but obviously introduces some bugs, at least for the Atmel processor in the 20b/30b. I suspect that these optimizations were added to the official GCC later, creating the same problems. So we're stuck with 4.6.0.

Is it immediately obvious in your experience if a binary is not working well? Or do you know of a way to verify it quite reliably? Or is it really tricky to check?

[Paul Dale]

(02-07-2014 03:26 AM)Bit Wrote:  Is it immediately obvious in your experience if a binary is not working well? Or do you know of a way to verify it quite reliably? Or is it really tricky to check?

No it isn't. Some functions will just stop working properly, most things continue working fine. Marcus likely knows more but we didn't notice problems immediately.


- Pauli

[Marcus von Cube]

(02-07-2014 04:32 AM)Paul Dale Wrote:  Marcus likely knows more but we didn't notice problems immediately.

Not really. We had some bug reports in the past and reverting to the previous compiler fixed them. I'm not proficient enough in ARM assembly to identify the exact source of the problem.

[Paul Dale]

I wonder if it is worth a revisit? I have some experience with ARM & THUMB assembly.


- Pauli

[Marcus von Cube]

(02-08-2014 11:12 AM)Paul Dale Wrote:  I wonder if it is worth a revisit? I have some experience with ARM & THUMB assembly.

Certainly, but what would be the consequences? If the compiler is broken it's broken. If it's just a single optimization which can be disabled it will probably produce the same code as the previous version and we do not gain anything. OTH, the GCC project might benefit from our finding.

The main task is identifying the location in the code where something goes wrong. It will most probably need some hardware debugging to find out.

[Sanjeev Visvanatha]

Switched to an older Yagarto to use gcc 4.6.0. This fixed the issues I had earlier, and I no longer need to use Bit's patch.