newRPL: [UPDATED April 27-2017] Firmware for testing available for download

[Han]

(11-11-2016 03:54 AM)Claudio L. Wrote:  

(11-11-2016 12:26 AM)Han Wrote:  The HP48 even allows for «1 2 + as a "valid" program since it will autocomplete where possible. So creating 3x3 matrix could be achieved with [[1 2 3] 4 5 6 7 8 9. Even the syntactically incorrect entry: [[1 2 3] 4 5 6 7 8 9] would work, too.

I'm not really in favor of allowing auto-corrections, on your example [[1 2 3] 4 5 6 7 8 9 you don't know if the user meant:
[[1 2 3]] 4 5 6 7 8 9
[[1 2 3] [4 5 6]] 7 8 9
[[1 2 3] [4 5 6] [7 8 9]]

So it's best if we tell the user and let him decide what to fix.

I am fine with either method. The HP48 way makes it so that we can be a bit lazier with our input, but I do agree it can be too ambiguous as you described.

[Helix]

Thank you Bruno and Claudio for your precise answers.
I'm pleased to learn that more than one person is working on newRPL.

(11-10-2016 02:40 PM)Claudio L. Wrote:  

(11-10-2016 02:30 AM)Helix Wrote:  - It would be nice if the help text could also display the entire name of the command, especially for long names that are partially masked in the soft menus.

It was like that at the very beginning, but explaining some commands in only 3 lines of text is really hard, so I decided to use the entire space for help. Perhaps I should be thinking of making the help fullscreen.

Yes, there is no reason to display the help text in only three lines. If the entire screen is used, it could be useful also for viewing more content of large objets (lists, programs…)
In the HP50g, Right Shift / Down cursor displays the names of the current menu. A similar solution could be adopted. I think that a fullscreen help would be better though.

(11-10-2016 02:40 PM)Claudio L. Wrote:  

(11-10-2016 02:30 AM)Helix Wrote:  - Currently the commands are displayed in the first soft menu (the black one). Is there a flag which would allow the commands to appear directly in the white soft menus?

Yes! Go to: Main menu / System / Settings / Flags
The fourth menu item changes the currently active menu. Change it to 2 and next time you press SYMB it will go into the white menu.

Great !!
Now, I'm requesting another improvement: if the active menu is set to menu 2, then when the second menu is hidden the active menu is no more visible. I think that in this case the active menu should always be visible, regardless of the setting of menu 1 / menu 2.

(11-10-2016 02:40 PM)Claudio L. Wrote:  

(11-10-2016 02:30 AM)Helix Wrote:  - for the MENUSWAP shortcut, I don't like having to press too keys at the same time. I would prefer for example Right shift then Right cursor (I don't remember if this sequence is already used somewhere). On the other hand, I suppose I'll be able to make my own shortcuts when key assignments are implemented.

You will be able to reassign everything, of course. However, the On+Key combination is used for other system settings, so it made sense to use it for this case.
Right-Shift+right cursor is not currently assigned, because it's reserved to activate the viewer for large objects in the stack. It will enter into a scrolling mode to properly view objects.

I understand. Furthermore, On+VAR is consistent with ON+VAR long press, so it makes sense.

[matthiaspaul]

(11-10-2016 09:35 PM)Claudio L. Wrote:  

(11-10-2016 09:09 PM)Han Wrote:  UPDATE: Well, I finally tried the 2MB_215.bin file in the ROM 2.15 distribution and this fixed the problem with getting the calc back to life.

Oh, of course!
Somewhere up in this thread this was clearly explained: you cannot go back using the normal ROM image, it *has* to be the 2MB one.

(11-10-2016 09:59 PM)Claudio L. Wrote:  I'm sure I wrote somewhere that the 2 MB ROM was needed, but couldn't find it, so I'll make a note to modify the download page in the website with clear instructions on how to go back to stock firmware.

See:

http://www.hpmuseum.org/forum/thread-656...l#pid60366

Greetings,

Matthias

[Han]

Another question of curiosity:

Is there any intention in keeping the firmware size to any particular maximum (e.g. 2MB)? I understand that once SD support is finalized, then we can simply run programs from the SD card. So maybe the firmware could take up all of the flash chip. However, I am curious if you (Claudio) foresee the flash ROM size becoming an obstacle in the future.

[Helix]

I'm not convinced by the way directories and submenus are marked:

- In the first menu, I can barely see the grey line at the bottom of the black rectangles.

- In the second menu, there is confusion between the second row and the third row of menus: a grey line at the bottom of the second row indicates this not a directory, but a grey line at the bottom of the third row tells this is a directory. I understand the logic behind this choice, but visually I find the result confusing.

I've thought about that, and I can't see how to improve that without adding a line for each row of menus, and use this additional line to display a small tab, like in the HP50g. It will remove a height of 3 pixels for the stack, but after all the remaining space will be the same than with the 50g.

[Han]

(11-12-2016 01:05 AM)Helix Wrote:  I'm not convinced by the way directories and submenus are marked:

- In the first menu, I can barely see the grey line at the bottom of the black rectangles.

- In the second menu, there is confusion between the second row and the third row of menus: a grey line at the bottom of the second row indicates this not a directory, but a grey line at the bottom of the third row tells this is a directory. I understand the logic behind this choice, but visually I find the result confusing.

I've thought about that, and I can't see how to improve that without adding a line for each row of menus, and use this additional line to display a small tab, like in the HP50g. It will remove a height of 3 pixels for the stack, but after all the remaining space will be the same than with the 50g.

Why not keep the menu item height as is, but just use the top row for a "directory tab" (rather than adding an extra line of pixels per menu row). The main menu's top row of pixels doesn't actually serve any purpose, and every letter only goes as high as the 2nd line of pixels. So I propose that we make the first line of pixels for tabs (e.g only 3rd through say 7th pixels from the left border of a menu item).

Since the secondary menu uses light borders already, a directory could simply correspond to dark borders. In fact, I think the light borders could be made as light as the "SD" icon (bottom right) and a directory could be made fully dark (border).

As for the long-press for help, could we not use a shift to do that instead? (I personally tend to avoid long-press imply because it takes longer.)

Anyway, I noticed a small aesthetic bug: when an error message is displayed, and a help screen is immediately generated, the timer for the display of the error message is applied to the help message so that it is partially displayed even after the release of a long-press. Example: tap FLOOR and immediately follow up with a long-press on FLOOR. You will see an insufficient args error, followed by the help. As soon as the help text appears, release the FLOOR menu key and you will see what I mean.

[Helix]

(11-12-2016 01:31 AM)Han Wrote:  Why not keep the menu item height as is, but just use the top row for a "directory tab" (rather than adding an extra line of pixels per menu row). The main menu's top row of pixels doesn't actually serve any purpose, and every letter only goes as high as the 2nd line of pixels. So I propose that we make the first line of pixels for tabs (e.g only 3rd through say 7th pixels from the left border of a menu item).

The main menu's top row of pixels improves readability. In the first versions of newRPL this line was blank, and I remember that the look of the names was rather unpleasant for me. I think that someone else also complained about this fact. At least in my opinion, this first line is useful.

(11-12-2016 01:31 AM)Han Wrote:  Since the secondary menu uses light borders already, a directory could simply correspond to dark borders. In fact, I think the light borders could be made as light as the "SD" icon (bottom right) and a directory could be made fully dark (border).

I think we could go even further, and remove entirely the grey borders!
Also, even the main menu could be blank, like the secondary menu. For some reason, I find that black letters just below a black line are still easily readable, but white letters below a white line are more difficult to read.

[Claudio L.]

(11-12-2016 12:45 AM)Han Wrote:  Another question of curiosity:

Is there any intention in keeping the firmware size to any particular maximum (e.g. 2MB)? I understand that once SD support is finalized, then we can simply run programs from the SD card. So maybe the firmware could take up all of the flash chip. However, I am curious if you (Claudio) foresee the flash ROM size becoming an obstacle in the future.

ROM will be limited to 2MB on the 50g target, just because that's the physical limit. Even if we implement a VMM (Virtual Memory Manager) to use the SD card as a RAM extension, that doesn't apply to the ROM. We could map a portion of RAM right after the ROM as well to make it appear larger, but it will use up RAM to temporarily hold the pages so it's probably not a good idea.
In any case I don't see the 2MB limit as being an issue (yet). The firmware with core libraries was 1.4MB just because 1 MB is taken by the tables for transcendental functions. Right now with more than a third of the commands implemented we are at 1.6 MB. If the 2MB limit becomes a problem, I'll have to use different methods to compute the transcendental functions that use less storage, that's it.

[Han]

(11-12-2016 02:19 AM)Helix Wrote:  The main menu's top row of pixels improves readability. In the first versions of newRPL this line was blank, and I remember that the look of the names was rather unpleasant for me. I think that someone else also complained about this fact. At least in my opinion, this first line is useful.

Hmm... what about using the left-most column of pixels per menu item, then? Have the tab be half the height. Maybe this would cost too much real estate for labels. Speaking of which, I really think the menu fonts should be a 3-pixel width (max) so we can fit more letters into the labels. Some letters are just too wide. I did not mind the mini-font from Jazz. It was quite usable.

(11-12-2016 02:19 AM)Helix Wrote:  I think we could go even further, and remove entirely the grey borders!
Also, even the main menu could be blank, like the secondary menu. For some reason, I find that black letters just below a black line are still easily readable, but white letters below a white line are more difficult to read.

What happens when two menu items have labels that are too long to display? I suppose it wouldn't be too bad, but I was thinking that labels might run into each other. I will probably try some mock-ups to see for myself.

[Helix]

(11-12-2016 07:07 AM)Han Wrote:  Hmm... what about using the left-most column of pixels per menu item, then? Have the tab be half the height. Maybe this would cost too much real estate for labels.

That could be a solution too…

(11-12-2016 07:07 AM)Han Wrote:  Speaking of which, I really think the menu fonts should be a 3-pixel width (max) so we can fit more letters into the labels. Some letters are just too wide. I did not mind the mini-font from Jazz. It was quite usable.

It's my opinion too, and this is why I've made a font with compact characters for the menu labels. Claudio has chosen a larger font for these alpha releases, but a font better suited for the menus will certainly appear sooner or later.

[Guenter Schink]

About command completion

Typing "E" and subsequent ALPHA DN gives the following list

Code:

EVAL
EVAL1
EXP
EGVL
EGV
END
ELSE
END
END
END
END
END
ELSE
EVAL1NEXT
EXITRPL

I guess this is owed to the different END statements with respect to the various loop functions residing in different libs. Yet it looks odd somehow. Same for the duplicate ELSE. Any chance to deal with it?

Typing "→’" (arrow right) and consecutive ALPHA DN shows the commands starting with "→’" (arrow right) this is convenient to scroll through the various conversion commands. Would it be feasible to show also the commands with a trailing "→’" (arrow right)?
Günter

[Claudio L.]

(11-12-2016 07:07 AM)Han Wrote:  I will probably try some mock-ups to see for myself.

Yes, please! It would be quite easy for anyone to open the project newrpl-ui and start playing with halRedrawMenu1() and halRedrawMenu2() to see what other possible looks we can get. I'm not 100% convinced about the current look, but then there's only a few pixels we can use, and I'm not exactly good at UI design, so instead of posting, you should try a few looks in the simulator and capture the screens, then have a poll here in the forum.
Same thing with the choice of fonts, they can be changed from halInitScreen(). As Helix pointed out, he created a narrow font 6m specially for menus. The regular font, however, has most characters narrow, except a few ones that need to be wider for readability. In the first 4 characters in the menu, you normally only save 1 to 3 pixels, which is not even enough to fit one extra letter. For that reason I left the normal font, which reads a little better, in most cases wasting only 1 pixel.
The 5-pixel font is also a good choice, but readability might suffer.

[Claudio L.]

(11-12-2016 04:45 PM)Guenter Schink Wrote:  About command completion

Typing "E" and subsequent ALPHA DN gives the following list

Code:

EVAL
EVAL1
EXP
EGVL
EGV
END
ELSE
END
END
END
END
END
ELSE
EVAL1NEXT
EXITRPL

I guess this is owed to the different END statements with respect to the various loop functions residing in different libs. Yet it looks odd somehow. Same for the duplicate ELSE. Any chance to deal with it?

Typing "→’" (arrow right) and consecutive ALPHA DN shows the commands starting with "→’" (arrow right) this is convenient to scroll through the various conversion commands. Would it be feasible to show also the commands with a trailing "→’" (arrow right)?
Günter

Yes, that needs refinement. Internally, ENDs are all different, they just look the same but they all show up as different commands. I'll have to figure out how to fix that.
I'll soon add a flag to control if the user wants to see the different ENDs when decompiling.

[Guenter Schink]

(11-12-2016 05:21 PM)Claudio L. Wrote:  

(11-12-2016 04:45 PM)Guenter Schink Wrote:  About command completion

Typing "E" and subsequent ALPHA DN gives the following list

Code:

EVAL
EVAL1
EXP
EGVL
EGV
END
ELSE
END
END
END
END
END
ELSE
EVAL1NEXT
EXITRPL

I guess this is owed to the different END statements with respect to the various loop functions residing in different libs. Yet it looks odd somehow. Same for the duplicate ELSE. Any chance to deal with it?

Typing "→’" (arrow right) and consecutive ALPHA DN shows the commands starting with "→’" (arrow right) this is convenient to scroll through the various conversion commands. Would it be feasible to show also the commands with a trailing "→’" (arrow right)?
Günter

Yes, that needs refinement. Internally, ENDs are all different, they just look the same but they all show up as different commands. I'll have to figure out how to fix that.
I'll soon add a flag to control if the user wants to see the different ENDs when decompiling.

Thanks. Any comment on the arrow?
Günter

[Helix]

(11-12-2016 07:07 AM)Han Wrote:  I will probably try some mock-ups to see for myself.

I've drawn some virtual screenshots, and I think I got interesting results. I'll post them tomorrow.

[Claudio L.]

(11-12-2016 05:28 PM)Guenter Schink Wrote:  

(11-12-2016 05:21 PM)Claudio L. Wrote:  Yes, that needs refinement. Internally, ENDs are all different, they just look the same but they all show up as different commands. I'll have to figure out how to fix that.
I'll soon add a flag to control if the user wants to see the different ENDs when decompiling.

Thanks. Any comment on the arrow?
Günter

I'm not sure, autocomplete tries to continue your typing to accelerate it, but if you type an arrow and commands ending in arrow are suggested it would take you longer to find the command that you are looking for, just because a lot of commands will show up as suggestion. So there's a risk that by making broader suggestions the autocomplete tool will become less useful and will be ignored by the users.

[Francois Lanciault]

The latest firmware is a big improvement!

Here are a few comments:

When the user choose to hide the second menu (ON-VAR long press), the setting goes back to dual menus when:

- The calculator is switch OFF-ON
- A help description of a menu item was viewed (long press on that item)

It would be nice if the "one menu" setting would survive the above events. The idea is that if the user choose to hide the second menu, he must have a good reason to do it (more stack visibility) and right now the setting is reset back to two menus too frenquently.

Also I have noticed there is a "back" menu item in the symbolic menu (currently empty beside the back item). It would be nice if a "back" item could be included in all menus/sub-menus. Sometimes the user just want to go back one level. Unless there is back button I don't know about? But even with a back button, a "back" menu item would be nice.

Another small comment:

There is no help text for the ACK command

Best regards

François

[Han]

Some quick notes:

1. [[1 2 3][0 1 3][2 4 6]] RREF complains of a bad opcode
2. long-press HIST for PURGE and short-press HIST for STO seems like a bad combination for accidental deletion. I recommend forcing a shift key for PURGE and having long-press show the variable menu or perhaps later on showing the history of commands once that feature gets implemented (or will it be?)

[Etienne Victoria]

Using SETLOCALE through menus, I expected the following:

Code:


",./:" SETLC

to yield Comma for decimal, dot for thousands, Slash for Fractions and : for Arg

Instead, I get "Invalid Locale string"

I'll experiment again as I must be doing something wrong.

Claudio, your newRPL project prompted me to purchase my first Hp-50g a couple of months ago and I've been using it with great pleasure, thanks for this !

Etienne.

[Bruno]

(11-14-2016 07:16 PM)Han Wrote:  1. [[1 2 3][0 1 3][2 4 6]] RREF complains of a bad opcode

Not yet implemented.