Threaded Mode | Linear Mode

Claudio L. · 11-20-2015, 03:07 AM

(11-20-2015 01:18 AM)Han Wrote: Not sure if this is a bug worth reporting since OFF is not fully implemented, but if you press RightShift, and then press and hold the ON key only to release ON right around when hold-press would register, you can actually get the off sequence to flash off then back on.

It's worth reporting. The OFF routine waits for all keys to be released before turning the power off. If it comes back on immediately, something is wrong. There might be an interrupt waiting to be serviced, but it's also supposed to clean that up before going off, or perhaps your keyboard is bouncy, and triggers the wake-up interrupt. I'll have to investigate that, perhaps introducing a debounce delay before cutting the power will help.

Claudio L. · 11-20-2015, 03:25 AM

(11-19-2015 11:54 PM)Helix Wrote:
(11-19-2015 03:52 AM)Han Wrote: Yet another idea

Here's yet another idea that popped into mind while I am typing. Create two menus: a main one and a secondary one. Use a single key (maybe HIST or TOOL or something) to toggle the menu focus. Make the main menu on top, and the secondary menu on bottom. All keys affecting any menus (whether loading a menu or pressing NXT) would affect the currently focused menu (which would appear with black background so that it is clear to the user which one is in focus). Or you could even make the VAR key so that it behaves like NXT if the secondary menu is visible and presumably dedicated to variables (as proposed in paragraph 3). Error messages stay at the bottom, drawn over the menus. Create a single-row status area up at the top that can be used for things like auto-complete, time of day, path, memory, user mode, etc. This leaves the same amount of display area for the stack, since the current setup uses three rows at the bottom for menus.

The secondary menu doesn't even have to be dedicated to the variables. In fact, I think it would be even more useful to have the secondary menu be exactly that: a second menu. So if you wanted to, you could simply keep the second menu solely on variables. But you could theoretically could have, say, your variables and custom menu be your two menus, or say one menu show the matrix commands while another shows vector commands (i.e. two different categories). Having typed this, I am starting to think that having a menu dedicated to variables seems a bit restrictive.

I have to read again the various ideas, but I think that this version of dual menu would be very convenient too.

My opinion on this idea is mixed. It's nice to be able to use F1-F6 for both menus, but then you can't really use them both at once, if you have to press a key to "switch", there's no difference with pressing VARS to use the variables, and PREV to go back, the way it is now.
Since you can only use one at a time, I don't see much advantage on displaying both at once on the screen, just press the switch key and you'll see the other menu.
It also fragments the status line. I think 2 lines and almost half the screen width is barely usable, and we can expand with pop-ups when we need more space. If you have one single line on top, the status area is much less usable/attractive, and we lose the option to expand it by covering the menu.

Now the second paragraph, where the second menu becomes a fully independent menu, not just variables, I do like. Once I do a generic menu framework I should be able to apply it to all keys, and have 2 fully independent menus, both active at the same time (no "switch" key).
However, we'll need a way to choose which menu will be targeted when you select let's say SYMB, or TIME. The switch key perhaps is a good idea, but the "current" selection only affects when a program wants to show a menu. F1-F6 will always be the top menu and G-L will always be the second menu.
Instead of the switch, perhaps we could make the menu change always affect the second menu, unless it's off. So to send a menu to the first one you'd have to use the VARS key to hide the second one, change the menu, then reactivate VARS. This way we save a key, but it seems cumbersome. This would make the top menu something you seldom change, and menu 2 changes all the time.
Any other ideas?

Helix · (This post was last modified: 11-21-2015 06:17 PM by Helix.)

Indeed, autocomplete suggestions should not appear at the top of the screen…

I agree that your proposal in the second paragraph seems a bit cumbersome. Perhaps we could keep the switch idea, and use a long press on one key for switching between the two menus, in the same way that VAR works. What about a long press on NXT for example? Since both menus will be directly accessible, the switch has no reason to be frequently used.

Han · 11-21-2015, 06:46 PM

The status line need not be at the top (nor the autocomplete). By making the secondary menu span an entire row, one could still use the bottom three rows (2 for menus and the third for status including the autocomplete)

Francois Lanciault · 11-22-2015, 05:31 AM

Ok this is my first impressions on newRPL

I very much like the VAR menu and the quick access the the first six variables. Good idea. I also like the ALPHA behavior.

So I decided to key in my first program, a typical benchmark program that I have implemented on all my calculators. No success as it used some not implemented yet functions.

BTW I think I have found a bug. The function IP returns 0 if the number is not an integer > 1 but works as it should if the number is an integer or smaller than 1.

For example:
31.5 IP returns 0 (not ok)
31.5. IP returns 0. (not ok)
0.5 IP returns 0 (ok)
0.5. IP returns 0. (ok)
668 IP returns 668 (ok)
668. IP returns 668. (ok)

Now for my personal wish list:

Implement MOD so I can enter my benchmark program ! (I know I can use "x DUP y / IP y * -" but it would not be the same benchmark... and IP does not work ;-)

Binds more keys like x^2, srt_x(y), LN e^x, etc as I want to use the HP-50 with newRPL at work!

Make the PI symbol something that can be worked with for the same reason as above.

Good work!

François

(11-19-2015 07:31 PM)Claudio L. Wrote:
(11-19-2015 05:33 PM)Francois Lanciault Wrote: Works now!!

Good to hear! thanks for reporting back.

Helix · (This post was last modified: 11-22-2015 09:11 PM by Helix.)

I'm still thinking about the two independent menus. I think it would be great, because since the beginning I'm not comfortable with the variable menu assigned to the G..L keys. I would prefer to have the variable menu associated to the A..F keys, and the command menu to the G..L keys. Just a matter of preference.

But this raises several questions.

When one menu is a command menu and the other a variable menu, in principle there is no difficulty: something like left Shift PRG will affect the command menu, and something like UPDIR will affect the variable menu. But which menu will be changed by CST for example?

And how to display two command menus?

When two command menus are displayed, we need a way to know which menu will be changed, so a switching method must be implemented.

Then, what to do to return to a variable menu? VAR is not possible, because it has become command in this situation. Perhaps a long press on VAR, but it is already used for masking the second menu. Or this latter action should be shifted to another key: APPS, MODE, TOOL?

Han · (This post was last modified: 11-23-2015 04:48 AM by Han.)

(11-22-2015 09:00 PM)Helix Wrote: I'm still thinking about the two independent menus. I think it would be great, because since the beginning I'm not comfortable with the variable menu assigned to the G..L keys. I would prefer to have the variable menu associated to the A..F keys, and the command menu to the G..L keys. Just a matter of preference.

But this raises several questions.

When one menu is a command menu and the other a variable menu, in principle there is no difficulty: something like left Shift PRG will affect the command menu, and something like UPDIR will affect the variable menu. But which menu will be changed by CST for example?

And how to display two command menus?

When two command menus are displayed, we need a way to know which menu will be changed, so a switching method must be implemented.

Then, what to do to return to a variable menu? VAR is not possible, because it has become command in this situation. Perhaps a long press on VAR, but it is already used for masking the second menu. Or this latter action should be shifted to another key: APPS, MODE, TOOL?

I never really cared for "longpress" and in fact generally disliked that feature. For me, it too often messed with my quick, two-thumb typing because it would force me to change my tempo. However, I think that the longpress could be the "key" (see what I did there?) to our two menu system. For quick access, I prefer a quick touch of a key -- especially for loading menus. So I am of the opinion that the "main" menu be set via a regular "short" press. To load the same menu, but onto the "secondary" menu, one would simply use a longpress. (Or if you prefer, swap the behavior.) In sum, use longpress to affect the menu that would be less likely to be changed and shortpress to affect the menu that we would change most often.

EDIT: Could this scheme also enable us to use only the keys F1-F6 for both menu levels? Short presses for the main menu and longpress for the secondary?

Han · 11-23-2015, 09:10 PM

My experience with OFF: Using new batteries, my calculator seemed to only last maybe a few days -- most of the time it was OFF. I do not have any equipment to test current draw, but I suspect that there are some underlying issues with OFF, still.

Claudio L. · 11-23-2015, 10:31 PM

(11-23-2015 09:10 PM)Han Wrote: My experience with OFF: Using new batteries, my calculator seemed to only last maybe a few days -- most of the time it was OFF. I do not have any equipment to test current draw, but I suspect that there are some underlying issues with OFF, still.

That's strange, I put fresh batteries on mine when I fixed the Off function, and it's been going for a week now. This past Saturday I was doing some work and the calc was On, next to my keyboard for nearly 2 hours straight (I forgot that it doesn't have auto-off yet). Still no sign of the low-bat symbol (I'm using NiMH rechargeables).

I'd like somebody to measure the current, please. If there's something leaking I'll have to review the state of the ports and pullup resistors when it goes off. But I didn't notice mine getting power hungry.

Claudio L. · 11-23-2015, 10:43 PM

(11-22-2015 05:31 AM)Francois Lanciault Wrote: Ok this is my first impressions on newRPL

I very much like the VAR menu and the quick access the the first six variables. Good idea. I also like the ALPHA behavior.

Finally, somebody who likes the UI! (just joking)

(11-22-2015 05:31 AM)Francois Lanciault Wrote: So I decided to key in my first program, a typical benchmark program that I have implemented on all my calculators. No success as it used some not implemented yet functions.

BTW I think I have found a bug. The function IP returns 0 if the number is not an integer > 1 but works as it should if the number is an integer or smaller than 1.

For example:
31.5 IP returns 0 (not ok)
31.5. IP returns 0. (not ok)
0.5 IP returns 0 (ok)
0.5. IP returns 0. (ok)
668 IP returns 668 (ok)
668. IP returns 668. (ok)

Yes, that was a bug, now fixed (will come out in the next update). Thanks for the report.

(11-22-2015 05:31 AM)Francois Lanciault Wrote: Now for my personal wish list:

Implement MOD so I can enter my benchmark program ! (I know I can use "x DUP y / IP y * -" but it would not be the same benchmark... and IP does not work ;-)

Binds more keys like x^2, srt_x(y), LN e^x, etc as I want to use the HP-50 with newRPL at work!

Done, and done. It will come out in the next update (in a couple of days).

(11-22-2015 05:31 AM)Francois Lanciault Wrote: Make the PI symbol something that can be worked with for the same reason as above.

Constants are not implemented yet. However, if you look at the autocomplete suggestion, you'll notice when you type the symbol pi, it suggests "π0". π0 is a command that returns the numeric value of π, with twice the number of digits you have currently selected in the system. It's not really a constant, you can't use it in a symbolic, but for quick calculations you can use it.
In case you are wondering why the extra digits, it's so you can subtract constants close to π from π0 and still get full precision on the answer.

Claudio L. · (This post was last modified: 11-23-2015 10:56 PM by Claudio L..)

(11-22-2015 09:00 PM)Helix Wrote: I'm still thinking about the two independent menus. I think it would be great, because since the beginning I'm not comfortable with the variable menu assigned to the G..L keys. I would prefer to have the variable menu associated to the A..F keys, and the command menu to the G..L keys. Just a matter of preference.

But this raises several questions.

When one menu is a command menu and the other a variable menu, in principle there is no difficulty: something like left Shift PRG will affect the command menu, and something like UPDIR will affect the variable menu. But which menu will be changed by CST for example?

And how to display two command menus?

When two command menus are displayed, we need a way to know which menu will be changed, so a switching method must be implemented.

Then, what to do to return to a variable menu? VAR is not possible, because it has become command in this situation. Perhaps a long press on VAR, but it is already used for masking the second menu. Or this latter action should be shifted to another key: APPS, MODE, TOOL?

I think you are hitting the right nail. I believe we can solve your problem with one key (and only one).

Here's how:

One key will "SWAP" the first and second menus.
One flag will determine whether the commands (like CST) change the first or the second menu.

For example, initially the second menu will be VARS, and all menu changes will go into menu 1.
If you wanted to change the VARS menu to be the first, just hit the menu swap key, and if you want, change the flag so all changes affect the second menu, so your VARS doesn't change.
If you wanted to change VARS into some other command menu, you could just SWAP, change, then SWAP again.

This way, we achieve the following:

No additional keypresses to use the menus (vs. the hp48)
One menu becomes semi-permanent, the other one changes all the time, but both menus can change arbitrarily.
You can use VARS in whichever menu you want.
We need only one extra key

Claudio L. · 11-23-2015, 11:01 PM

(11-23-2015 04:44 AM)Han Wrote: I never really cared for "longpress" and in fact generally disliked that feature.

I agree, long press makes typing very slow. It can be used to access a GUI for plotting, or the GUI for mode settings, or the filer, or to hide the second menu (as it is now). But for soft menus, commands, etc., I'm in general against long press (against delays in general).

(11-23-2015 04:44 AM)Han Wrote: EDIT: Could this scheme also enable us to use only the keys F1-F6 for both menu levels? Short presses for the main menu and longpress for the secondary?

It would be painfully slow to use the second menu.

Helix · 11-24-2015, 12:05 AM

(11-23-2015 10:54 PM)Claudio L. Wrote: I think you are hitting the right nail. I believe we can solve your problem with one key (and only one).

Here's how:

One key will "SWAP" the first and second menus.

One flag will determine whether the commands (like CST) change the first or the second menu.

For example, initially the second menu will be VARS, and all menu changes will go into menu 1.
If you wanted to change the VARS menu to be the first, just hit the menu swap key, and if you want, change the flag so all changes affect the second menu, so your VARS doesn't change.
If you wanted to change VARS into some other command menu, you could just SWAP, change, then SWAP again.

This way, we achieve the following:

No additional keypresses to use the menus (vs. the hp48)

One menu becomes semi-permanent, the other one changes all the time, but both menus can change arbitrarily.

You can use VARS in whichever menu you want.

We need only one extra key

I like it!!
We still need another "key" to call the VARS menu when it is not displayed (that’s the reason why I suggested a long press on VAR). But that shouln't be a big problem, and your solution seems easy to use and perfectly valid.

Claudio L. · 11-24-2015, 12:44 AM

(11-24-2015 12:05 AM)Helix Wrote: I like it!!
We still need another "key" to call the VARS menu when it is not displayed (that’s the reason why I suggested a long press on VAR). But that shouln't be a big problem, and your solution seems easy to use and perfectly valid.

I agree, now that we can remove the VARS menu, it's natural that the VAR key brings it back. Disabling the second menu could be any key, really.

Time to put it in code.

Han · 11-24-2015, 12:52 AM

(11-24-2015 12:05 AM)Helix Wrote:
(11-23-2015 10:54 PM)Claudio L. Wrote: I think you are hitting the right nail. I believe we can solve your problem with one key (and only one).

Here's how:

One key will "SWAP" the first and second menus.

One flag will determine whether the commands (like CST) change the first or the second menu.

For example, initially the second menu will be VARS, and all menu changes will go into menu 1.
If you wanted to change the VARS menu to be the first, just hit the menu swap key, and if you want, change the flag so all changes affect the second menu, so your VARS doesn't change.
If you wanted to change VARS into some other command menu, you could just SWAP, change, then SWAP again.

This way, we achieve the following:

No additional keypresses to use the menus (vs. the hp48)

One menu becomes semi-permanent, the other one changes all the time, but both menus can change arbitrarily.

You can use VARS in whichever menu you want.

We need only one extra key

I like it!!
We still need another "key" to call the VARS menu when it is not displayed (that’s the reason why I suggested a long press on VAR). But that shouln't be a big problem, and your solution seems easy to use and perfectly valid.

I like this idea as well. I'm looking forward to testing it out in the future. One item that I am not clear on though is the "NXT" key for each menu. Will the 6th softkey be the "NXT" key for each menu if there are 7 or more menu items?

Claudio L. · 11-24-2015, 01:18 PM

(11-24-2015 12:52 AM)Han Wrote: I like this idea as well. I'm looking forward to testing it out in the future. One item that I am not clear on though is the "NXT" key for each menu. Will the 6th softkey be the "NXT" key for each menu if there are 7 or more menu items?

I think NXT needs to be a soft-key, for menus to work well on both menu positions without requiring a second "NXT" key or a long keypress.
I think losing one slot is no big deal.
This also makes it more portable, for example if there's a future version running on Prime hardware, there's no need for a NXT key, as you can slide the menu with touch.

Claudio L. · 12-02-2015, 08:23 PM

It's ROM update time.

This one brings:
* Fixed the IP command bug
* Added SQ, LOG and ALOG commands
* Bound 10^X, LOG, LN, EXP, SQ, XROOT to the corresponding keys
* Implemented new menu framework (not visible to the users).

For now, the first menu is also VARS, simply because for the time being there's no other menu to show.

Claudio L. · 12-02-2015, 09:47 PM

(11-23-2015 09:10 PM)Han Wrote: My experience with OFF: Using new batteries, my calculator seemed to only last maybe a few days -- most of the time it was OFF. I do not have any equipment to test current draw, but I suspect that there are some underlying issues with OFF, still.

Have you noticed any more current draw? It's been another week, and my calculator is still on the same set of batteries. I didn't use it much during the holidays but there was no apparent leak either.

Guenter Schink · 12-02-2015, 10:56 PM

(12-02-2015 09:47 PM)Claudio L. Wrote:
(11-23-2015 09:10 PM)Han Wrote: My experience with OFF: Using new batteries, my calculator seemed to only last maybe a few days -- most of the time it was OFF. I do not have any equipment to test current draw, but I suspect that there are some underlying issues with OFF, still.

Have you noticed any more current draw? It's been another week, and my calculator is still on the same set of batteries. I didn't use it much during the holidays but there was no apparent leak either.

I can confirm that so far I haven't seen any issue with excessive standby battery drain. Since you published the binaries with "off" function, the batteries are still alive.

Günter

Han · 12-02-2015, 11:02 PM

(12-02-2015 10:56 PM)Guenter Schink Wrote:
(12-02-2015 09:47 PM)Claudio L. Wrote: Have you noticed any more current draw? It's been another week, and my calculator is still on the same set of batteries. I didn't use it much during the holidays but there was no apparent leak either.

I can confirm that so far I haven't seen any issue with excessive standby battery drain. Since you published the binaries with "off" function, the batteries are still alive.

Günter

Since that last batch of batteries, I have not had the chance to do further testing (did not have any more on hand so I had put it off). I will test both the prior release and the newly posted on to see if there is any difference once I get a fresh set of AAA's again (this weekend, in fact).