WP43 News

This area is for discussion about these families of custom high-end Scientific Calculator applications for SwissMicros devices.
User avatar
Walter
Posts: 3070
Joined: Tue May 02, 2017 11:13 am
Location: On a mission close to DRS, Germany

Re: 43S News

Post by Walter »

We'd appreciate if you check repeatability of your observations before reporting an error. And please record the boundary conditions you found necessary to reproduce said error. Thanks in advance!
WP43 SN00000, 34S, and 31S for obvious reasons; HP-35, 45, ..., 35S, 15CE, DM16L S/N# 00093, DM42β SN:00041
HPMike
Posts: 439
Joined: Fri Jul 21, 2017 11:01 pm
Location: DFW, Texas

Re: 43S News

Post by HPMike »

Walter wrote:
Tue Mar 29, 2022 11:37 pm
We'd appreciate if you check repeatability of your observations before reporting an error. And please record the boundary conditions you found necessary to reproduce said error. Thanks in advance!
OK. First off the configuration of my emulator is default, except that Flag I (complex mode) is set. I have one small program that I listed in a previous post, and a few 3x3 matrices that have not been indexed. When I place one of these matrices in the X stack register and execute MATX I+ (increment Row index i), I get an Out of Range error, because the matrix has not been indexed. I clear this error with ← , and proceed to XEQ my little program EigenAB, which works fine. I then commit the same MATX I+ error again with an unindexed matrix, XEQ my little program again, and this time there is a delay and Windows briefly reports that the emulator program is not responding. So, I exit the emulator normally, updating the backup.bin file, then restart it at which point all the memory errors reported in my previous post occur. These errors appear duplicated, suggesting that the fault occurred the first time I created the Out of Range condition.

Now, as to repeatability, I can eventually get this fault to occur, but sometimes it requires several repetitions of the I+ Out of Range error, before execution of any program causes problems.

Update: It's getting worse. Now all I have to do is run programs several times, it starts to slow down and become unresponsive, then close and reopen the program for the memory errors to appear. I guess at this point I just need to set this program aside, and work on other calculators or emulators that work reliably.
DM15L, S/N 00548. DM42, SN: 00159. DM41X, SN: 00973. DM32, SN 00054.
HPMike
Posts: 439
Joined: Fri Jul 21, 2017 11:01 pm
Location: DFW, Texas

Re: 43S News

Post by HPMike »

Well, I've decided to bite the bullet, delete backup.bin to reset memory and re-enter all my programs and data manually, instead of restoring them from the wp43s.sav file. If that stops the crashes, then it would seem that the problem was a corrupt wp43s.sav file. It's getting late, so I'm going to bed, but I'll report back when I have a chance.
DM15L, S/N 00548. DM42, SN: 00159. DM41X, SN: 00973. DM32, SN 00054.
HPMike
Posts: 439
Joined: Fri Jul 21, 2017 11:01 pm
Location: DFW, Texas

The backup.bin file is the problem

Post by HPMike »

OK, so I think I've found the root cause of the problem here. It has nothing to do with any actions or operations when using the emulator, but instead when closing the program the updated backup.bin file is getting corrupted such that when the program is re-started it becomes unstable. So, here is what I have done:

1) Deleted the backup.bin file and started the emulator with cleared memory.
2) Laboriously manually re-entered all my programs and data.
3) Ran programs repeatedly and performed various operations w/o any problems or errors.
4) Saved the contents of memory in a new wp43s.sav file.
5) Closed the program normally (Right mouse EXIT), which created a new backup.bin file
6) Started the emulator again, and ran the FACT (factorial) program several times until the following messages appeared in the GTK session "DOS" box:

***Free memory regions overlap !
***This suggests there was double-free !
Free blocks (8):
0 starting at 51: 1 blocks = 4 bytes
.
.
7 starting at 1730: 11832 = 47328 bytes
In function regInRange:
local register .00
is not defined !

At this point the emulator is unstable, and either runs very slowly or shuts down.

7) Deleted the backup.bin file and started the emulator with cleared memory.
8) Restored memory from the wp43s.sav file.
9) Repeated steps 3, 5 and 6 with the same result.

I might add, that even if I start with a Reset emulator without adding any programs or data, and with the default settings, I can still reproduce this problem.
Last edited by HPMike on Thu Mar 31, 2022 4:38 am, edited 1 time in total.
DM15L, S/N 00548. DM42, SN: 00159. DM41X, SN: 00973. DM32, SN 00054.
User avatar
Walter
Posts: 3070
Joined: Tue May 02, 2017 11:13 am
Location: On a mission close to DRS, Germany

Re: 43S News

Post by Walter »

Thanks a lot! Well worth 8 points. Your records should allow us to pin down the underlying problem.
WP43 SN00000, 34S, and 31S for obvious reasons; HP-35, 45, ..., 35S, 15CE, DM16L S/N# 00093, DM42β SN:00041
HPMike
Posts: 439
Joined: Fri Jul 21, 2017 11:01 pm
Location: DFW, Texas

Problem saving named variables in wp43s.sav file

Post by HPMike »

Due to the problem with the backup.bin file, I've been loading the emulator w/o a backup.bin file with cleared memory, and restoring the memory contents from the wp43s.sav file. When I STO something in an alpha string named variable XYZ, it gets STOred during the session and can be RCLed, but when I save memory in the wp43s.sav file, close the program w/o creating a backup.bin file, re-open and restore memory from the wp43s file, and try to again RCL this variable I get the error message:

In function _tamProcessInput:
String 'XYZ' is not a named variable.

This does not occur if I use one of the built-in characters A,B,C,D, only if I create a string name using the α prefix key.
DM15L, S/N 00548. DM42, SN: 00159. DM41X, SN: 00973. DM32, SN 00054.
User avatar
Walter
Posts: 3070
Joined: Tue May 02, 2017 11:13 am
Location: On a mission close to DRS, Germany

Re: 43S News

Post by Walter »

Thanks. Indeed, here's something wrong with variable recovery. Filed. May take a while to repair.
WP43 SN00000, 34S, and 31S for obvious reasons; HP-35, 45, ..., 35S, 15CE, DM16L S/N# 00093, DM42β SN:00041
User avatar
Walter
Posts: 3070
Joined: Tue May 02, 2017 11:13 am
Location: On a mission close to DRS, Germany

Re: 43S News

Post by Walter »

A little poll for in between:

We have three free shifted locations on our bezel still - what do you want to see there? Which three labels should show up there? They may be functions or menus. Please give reasons why you want the three labels of your choice appearing.

Please take into account what's featured already.
WP43 SN00000, 34S, and 31S for obvious reasons; HP-35, 45, ..., 35S, 15CE, DM16L S/N# 00093, DM42β SN:00041
HPMike
Posts: 439
Joined: Fri Jul 21, 2017 11:01 pm
Location: DFW, Texas

Re: 43S News

Post by HPMike »

y^x , x^2

These are very often used, so I don't see the need to use the EXP menu. I would place x^2 and y^x on the same key as sqrt(x), and you could move α and α.fcn somewhere else, perhaps the 7 key. y^x would be the primary key, with x^2 and sqrt(x) being shifted items. As to the third item, how about %, instead of using the FIN menu.
DM15L, S/N 00548. DM42, SN: 00159. DM41X, SN: 00973. DM32, SN 00054.
User avatar
GeisiX
Posts: 14
Joined: Thu Mar 18, 2021 11:47 pm
Location: Bavaria

Re: 43S News

Post by GeisiX »

A few posts back, the "x^2"-topic has been discussed to some extent already. Having this as a shifted function would be no benefit from the "ENTER+product"-solution.

But I am with HPMike to have y^x as the more universal primary function, making SQRT(x) a shifted one.

Coming back to Walter's initial question regarding the currently vacant shifted spaces:
Maybe a direct access to MyMenu would be convenient. Although, with the current menu concept, you are never too far away from it, i. e. the highest level of menues, a quicker way to switch between two (or more) menues directly would come in handy. With proper use of MyMenu items, this way, one would never be more than two clicks away (at least) from the main set of functions.

I know I've been rifing this train before, but for me, personally, MyMenu is one of the design decisions that make this calculator extremely useful. If used properly, most of the discussions what item should go where and what should become primary or shifted becomes less relevant. Every user does have his/her very own preferences and it will hardly be possible to get it right for everyone out of the box. With the possibility to set up MyMenu (potentially even creating your own functions by running programs from there), most of these personal preferences could be satisfied. And with a quicker (direct or shifted) access to it, this personalization of the calculator would even be working without having to change physical keys.

As a continuation of that train of thought, another option for the vacant shifted functions could be call-ups for user items (items, programs etc.) directly.
Post Reply