Threaded Mode | Linear Mode

Claudio L. · 01-07-2016, 10:51 PM

A new version of the firmware was posted, with the following additions since last time:

* Finished soft-menu engine

The menu engine is quite more flexible than the old one.You can read more here.

There aren't any useful menus yet, mainly because I tried to add the first menu and it's a pain to assemble the lists by hand, so I need to figure out a more practical way to add menus (see below).

To play with the menu engine, the TMENU command is ready to go. Changes only apply to the first menu.
Some examples:
{ { "ONE" 1 "This is the number one" } { << IF -1 FC? THEN "DOWN" ELSE "UP" END >> << IF -1 FC? THEN "GOING DOWN..." ELSE "GOING UP..." END >> "This is an UP/DOWN example" } }

You can try -1 SF and -1 CF to see how it affects the second item.

Any bugs, comments, etc. are always welcome.

Claudio L. · (This post was last modified: 01-09-2016 08:09 PM by Claudio L..)

(01-07-2016 10:51 PM)Claudio L. Wrote: A new version of the firmware was posted, with the following additions...

Forgot to mention, it's likely that some internal opcodes changed due to a massive code refactoring (nothing cool for the user, but the build system now automatically extracts the commands from the libraries).
This may (possibly) make binary programs incompatible with the previous version. If you see crashes or strange behavior when running your programs after upgrading this is likely the cause. You need to do a reset with full memory wipe (On-A-F then press all 3 shifts at once, while you press the "Clear Mem" soft key).

To avoid wiping the memory, you could instead save the source code of any programs by converting to a string before flashing the new rom. After the upgrade, you can recompile them back.

EDIT: I changed the key sequence to On-A-F, used to say On-A-C but that was incorrect.

Claudio L. · 01-09-2016, 12:25 AM

(12-16-2015 04:55 PM)Francois Lanciault Wrote: ... I found the bug: Because new RPL does not return exactly 0 for LN(1) as it should, the program was doing one additional iteration.

Something you intent to correct ?

The latest rom (uploaded yesterday) should return exactly 0 for LN(1). I went over other transcendental functions as well to make sure these trivial cases were handled properly.

Francois Lanciault · 01-09-2016, 02:07 AM

(01-09-2016 12:25 AM)Claudio L. Wrote:
(12-16-2015 04:55 PM)Francois Lanciault Wrote: ... I found the bug: Because new RPL does not return exactly 0 for LN(1) as it should, the program was doing one additional iteration.

Something you intent to correct ?

The latest rom (uploaded yesterday) should return exactly 0 for LN(1). I went over other transcendental functions as well to make sure these trivial cases were handled properly.

Thank you Claudio,

I will download the latest version and report. But first I need to remember how to translate my program to strings like you suggest in your previous mail.

Francois

Claudio L. · 01-09-2016, 08:08 PM

(01-09-2016 02:07 AM)Francois Lanciault Wrote: I will download the latest version and report. But first I need to remember how to translate my program to strings like you suggest in your previous mail.

There's 2 ways to do that:

Edit the program in the command line, add double quote at the beginning, another one at the end and hit enter.
Put your program on the stack and use ->STR

Just store it in a variable, and after you do the update, you can recompile using STR->.

Francois Lanciault · 01-11-2016, 05:33 PM

(01-09-2016 08:08 PM)Claudio L. Wrote: There's 2 ways to do that:

Edit the program in the command line, add double quote at the beginning, another one at the end and hit enter.

Put your program on the stack and use ->STR

Just store it in a variable, and after you do the update, you can recompile using STR->.

I did the update, everything went smoothly.

My programs were restored from strings as expected.

I notice that by "long pressing" any of the vars keys (not the top row, but the six other keys), a three lines preview of the variable content is displayed. Very useful! Maybe it was there before I don't know. Consequently, long pressing the "var" key does not show/hide the var soft menu anymore. As this function been moved to another key ?

The thing I like the most is that it is now easy to re-edit program. No more "not-implemented" to erase. Thank you.

With the LN(1) function fixed, I was able to run my floating point benchmark. I used SETPREC to have all calculations done with 16 digits to be more in line with the real HP-50G and Prime.

Quote:So your code is just integers and loops, 2 things that newRPL excels at, which justifies the high multiples you got. When you start throwing in floating point operations, the decimal library brings the speed more in line with reality (about 100x vs the 50g).

With floating points calculations I get a quite different speedup than what you implied.

newRPL is about 4.6X faster than the HP-50G
newRPL is about 23X slower than the Prime.

I am still very happy with the speed, I am just reporting my findings to add new data to your benchmark analysis.

Next I will try to play with the new menu features.

Best regards,
François

Claudio L. · (This post was last modified: 01-11-2016 07:07 PM by Claudio L..)

(01-11-2016 05:33 PM)Francois Lanciault Wrote: I did the update, everything went smoothly.

My programs were restored from strings as expected.

I notice that by "long pressing" any of the vars keys (not the top row, but the six other keys), a three lines preview of the variable content is displayed. Very useful! Maybe it was there before I don't know. Consequently, long pressing the "var" key does not show/hide the var soft menu anymore. As this function been moved to another key ?

Yes, it will be relocated, not sure where yet. It had to be removed for consistency: All soft-menu keys now have the long-press assigned to help.
For the VARS menu, the help shows a preview of the contents of the variable, as you discovered.

(01-11-2016 05:33 PM)Francois Lanciault Wrote: With floating points calculations I get a quite different speedup than what you implied.

newRPL is about 4.6X faster than the HP-50G
newRPL is about 23X slower than the Prime.

The 100x I mentioned is pure floating point (as in the four basic operations). Transcendental functions are slower, so it depends on how many of them your benchmark has.
Transcendental functions in a benchmark were discussed here, where the speedup of a mix of floating point and transcendental functions shows about twice what you got. Your benchmark shows it is more transcendental-intensive than the benchmark I ran.
Many speed optimizations used to compute transcendental functions simply don't translate well to variable precision, or they need very large amounts of precomputed tables.
Still, once everything is finished I'll be able to spend some time to optimize the speed on these functions. For now, slow and accurate is still better than nothing.

Helix · 01-11-2016, 09:48 PM

I'm wondering if it would be possible (in a distant future) to implement additional routines with fixed precision, for a default precision setting. For example, with 16 SETPREC, the functions would use common (and fast) algorithms, and with any other precision setting they would use the variable precision library. I think that 99% of calculations don't need variable precision, and this solution would make newRPL more comparable to the Prime, as far as speed is concerned.

Anyway, as François noted, the speed improvement is already very satisfying.

Claudio L. · 01-11-2016, 11:02 PM

(01-11-2016 09:48 PM)Helix Wrote: I'm wondering if it would be possible (in a distant future) to implement additional routines with fixed precision, for a default precision setting. For example, with 16 SETPREC, the functions would use common (and fast) algorithms, and with any other precision setting they would use the variable precision library. I think that 99% of calculations don't need variable precision, and this solution would make newRPL more comparable to the Prime, as far as speed is concerned.

Anyway, as François noted, the speed improvement is already very satisfying.

Yes, it's a good possibility that in the end, the default precision of 32 digits could use optimized code, then other precisions fall back to the general routine.

Francois Lanciault · 01-12-2016, 05:57 PM

(01-11-2016 07:06 PM)Claudio L. Wrote: The 100x I mentioned is pure floating point (as in the four basic operations). Transcendental functions are slower, so it depends on how many of them your benchmark has.
Transcendental functions in a benchmark were discussed here, where the speedup of a mix of floating point and transcendental functions shows about twice what you got. Your benchmark shows it is more transcendental-intensive than the benchmark I ran.

As a matter of fact, my benchmark is mainly a succession of transcendental functions, one after the other...

I tried the TMENU functionality. Very powerful. For now I am just using it for quick unit entry and conversion but I see the potential.

I guess that in an upcoming revision, it would be the perfect time implement a basic mathematical soft key menu accessible by pressing the MTH key. For now it would only offer the mathematical function already implemented but its functionality would grow with each new rev...

François

Claudio L. · 01-12-2016, 10:11 PM

(01-12-2016 05:57 PM)Francois Lanciault Wrote: As a matter of fact, my benchmark is mainly a succession of transcendental functions, one after the other...

That explains the poor performance.

(01-12-2016 05:57 PM)Francois Lanciault Wrote: I tried the TMENU functionality. Very powerful. For now I am just using it for quick unit entry and conversion but I see the potential.

I guess that in an upcoming revision, it would be the perfect time implement a basic mathematical soft key menu accessible by pressing the MTH key. For now it would only offer the mathematical function already implemented but its functionality would grow with each new rev...

Actually, unit menu will be the first to be implemented, since the units module is finished. Others will follow quickly.
I have just finished the new standalone newRPL compiler, and incorporated it into the build process. Now I can write menus directly in RPL, so I can go much quicker and is easier to modify the menus to add more commands.
But the menus need to include "help" for each command, and that needs to be easily translatable to other languages, and that is another thing I need to figure out how to do.

The goal is: everyone should be able to modify the menus in ROM (since it's plain RPL) and recompile a rom to their liking.

Nigel (UK) · 01-17-2016, 08:44 PM

Another new user! I've just installed newRPL on my HP-49g+ with no trouble at all. When the "WAIT RESET" screen appeared I pulled out one of the batteries for a few seconds, put it back in, and everything went smoothly. (Paperclip reset never seems to work for me - maybe I just can't bring myself to press hard enough!)

The keyboard is fine with no multiple bounce problems. Everything seems to be working and I look forward to using it over the next few days.

Two points:

How can I hide the VAR menu? Earlier posts in this thread suggest that long-press VARS will do this, but it doesn't, at least not for me. If I can't hide it this isn't a problem - there's plenty of space - but I wondered whether this might be a problem with the HP-49g+ keyboard.
I've made a menu with TMENU. The text in the "black blocks" goes right up to the top line of black pixels, making it harder to read than if there was one more line of black. Is this deliberate?

Also, is it possible to change the display format of numbers yet?

Congratulations on a brilliant piece of work!

Nigel (UK)

Claudio L. · 01-18-2016, 03:55 AM

(01-17-2016 08:44 PM)Nigel (UK) Wrote: The keyboard is fine with no multiple bounce problems. Everything seems to be working and I look forward to using it over the next few days.

Good to hear the 49G+ keyboard works fine too. The keyboard driver was originally written on one, but mine broke down many years ago, so there was no way for me to test it.

(01-17-2016 08:44 PM)Nigel (UK) Wrote: Two points:

How can I hide the VAR menu? Earlier posts in this thread suggest that long-press VARS will do this, but it doesn't, at least not for me. If I can't hide it this isn't a problem - there's plenty of space - but I wondered whether this might be a problem with the HP-49g+ keyboard.

No problem with your keyboard. In this last version I removed it from the keyboard because the long press is now used by the menu help. I still don't know where to relocate it, but that functionality will be back in short.

(01-17-2016 08:44 PM)Nigel (UK) Wrote:

I've made a menu with TMENU. The text in the "black blocks" goes right up to the top line of black pixels, making it harder to read than if there was one more line of black. Is this deliberate?

Well, it deliberately saves one pixel, the intent wasn't to make it hard to read, though. With 3 lines of menus, 3 lines of pixels would have to go. It's doable, if I get more complaints about that I can lose those 3 pixels.

(01-17-2016 08:44 PM)Nigel (UK) Wrote: Also, is it possible to change the display format of numbers yet?

Not yet from the user side, I still don't know how to easily expose that to the user, as the new formatting is far more flexible.
Right now there's no command to modify it, but the hidden '.Settings' directory has the variable 'NumFmt'.
This variable is list that contains the following:
{
"Locale string"
SmallFmt
MidFmt
LargeFmt
SmallLimit
LargeLimit
}

Where SmallFmt, MidFmt and LargeFmt are integer numbers that combine the many flags, number of digits, etc. that control the appearance of a number.
SmallLimit and LargeLimit are real numbers. The SmallFmt applies to all numbers when abs(number) < SmallLimit. LargeFmt applies to all numbers larger than LargeLimit, and MidFmt applies in between.

You could go into the .Settings directory and change this list with STO. But the flags aren't documented anywhere yet :-)

I'll probably provide a single command where you provide the list above to change all settings at once, rather than the archaic FIX, ENG, SCI, etc., which will still exist as convenient preselected formats.

fhub · 01-18-2016, 03:43 PM

Is there any way to convert this KinpoUpdate file (newrplfw.bin) to a usual *.ROM file which can be loaded into the HP-50 emulator (emu48.exe)?

Franz

Claudio L. · 01-18-2016, 04:06 PM

(01-18-2016 03:43 PM)fhub Wrote: Is there any way to convert this KinpoUpdate file (newrplfw.bin) to a usual *.ROM file which can be loaded into the HP-50 emulator (emu48.exe)?

Franz

Emu48 cannot run newRPL. The only emulator able to run newRPL is x49gp. In the Makefile, just replace the name of the firmware file to point to newrplfw.bin and it will run with no problems.

But the Windows simulator has just been updated, both the ROM and simulator are in sync.

Claudio L. · 01-18-2016, 04:28 PM

A new rom version was posted to the download site. Minor changes:
[list]
[*] Command MENUSWAP enabled
[*] New command TMENULST, activates a menu on the menu that the user used last. In contrast, TMENU always affects the currently active menu.
[*] Units menu was enabled (RS-6, the usual place).
[*] Using IDENT argument with TMENU becomes a more dynamic menu.

MENUSWAP simply exchanges the position of the two menus.
TMENULST is needed to activate submenus. For example, let's say you have a menu item that calls a submenu using TMENU.
If you MENUSWAP so that the menu is not in the currently active menu, then TMENU will open the submenu in the other menu. To correct this, TMENULST always opens the menu in the soft-menu that the user used last. This means when you call TMENULST from inside a menu handler, you always open the submenu in the same soft-menu.

The last item also needs clarification: The classic TMENU behavior when given an IDENT as argument is to RCL and use the contents as the menu. The new behavior is to store the IDENT as the custom menu, and it is RCL'd every time the menu needs to be displayed. Storing a new list to the variable causes an immediate menu update.

fhub · 01-18-2016, 04:31 PM

(01-18-2016 04:06 PM)Claudio L. Wrote: Emu48 cannot run newRPL. The only emulator able to run newRPL is x49gp. In the Makefile, just replace the name of the firmware file to point to newrplfw.bin and it will run with no problems.

Well, there's no ready-to-use EXE-file for this emulator, so it' s unusable for an average Windows user.

Quote:But the Windows simulator has just been updated, both the ROM and simulator are in sync.

Yes, I've already downloaded and tried it - in priciple it is working, but it's very uncomfortable to use it without actually having the HP49/50 keyboard in sight.
I've even opened a window with the HP50 image at the same time, but it would of course be much better being able to really 'use' the HP50 keyboard (as in the usual emulator).
Would it be hard to implement KML scripting (incl. a HP50 BMP) into your simulator?

Franz

Claudio L. · 01-18-2016, 09:07 PM

(01-18-2016 04:31 PM)fhub Wrote: Yes, I've already downloaded and tried it - in priciple it is working, but it's very uncomfortable to use it without actually having the HP49/50 keyboard in sight.
I've even opened a window with the HP50 image at the same time, but it would of course be much better being able to really 'use' the HP50 keyboard (as in the usual emulator).
Would it be hard to implement KML scripting (incl. a HP50 BMP) into your simulator?

Franz

Good to hear the installer works.
I see what you mean, I often open the 50g picture from Wikipedia in my browser, has a nice resolution and you can read all keys just fine.
At one point I started creating a blank image of the 50g keyboard, to print the newRPL labels on. But the project took more than a weekend, so it was abandoned.
Implementing KML scripts is probably not too hard, but it's a whole project on its own. I'm not sure it's reasonable for me to spend too much time on the simulator, I'd rather spend the little time I have on the newRPL core.

Nigel (UK) · 01-18-2016, 09:46 PM

I have installed the new firmware on the HP-49g+. To start with it didn't work, but leaving all batteries out for ten minutes fixed the problem. I couldn't clear the RAM with the ON-A-C key sequence mentioned in post #39 - on my calculation, this brings up a screen saying "EXCEPTION - RPL break requested" and "clear memory" isn't one of the options shown. Is there a way to clear the RAM on a HP-49g+ without taking all the batteries out and waiting?

One possible bug: y^x gives an incorrect answer if asked for a fractional power of a negative number (e.g., try -529 0.5 y^x). I don't know whether y^x is intended to give complex results from real inputs, but it should probably throw an error (like sqrt does) if not.

Nigel (UK)

Claudio L. · 01-18-2016, 11:27 PM

(01-18-2016 09:46 PM)Nigel (UK) Wrote: I have installed the new firmware on the HP-49g+. To start with it didn't work, but leaving all batteries out for ten minutes fixed the problem. I couldn't clear the RAM with the ON-A-C key sequence mentioned in post #39 - on my calculation, this brings up a screen saying "EXCEPTION - RPL break requested" and "clear memory" isn't one of the options shown. Is there a way to clear the RAM on a HP-49g+ without taking all the batteries out and waiting?

Sorry, the instructions should read On-A-F.
On-A-C = Break sequence when your program locks up in an infinite loop. Similar to pressing "On" on a 50g, but with a confirmation screen before it interrupts the program, and an option to warmstart or reset.

On-A-F = Similar to the 50g, this is the nuclear option. It allows you to clear the memory but only if you press all 3 shifts when you choose that option in the menu.

In both cases, for warmstart or reset you need at least one shift pressed (to avoid accidents).

(01-18-2016 09:46 PM)Nigel (UK) Wrote: One possible bug: y^x gives an incorrect answer if asked for a fractional power of a negative number (e.g., try -529 0.5 y^x). I don't know whether y^x is intended to give complex results from real inputs, but it should probably throw an error (like sqrt does) if not.

Nigel (UK)

Complex mode is not implemented yet. When I wrote that command I was planning to implement it quickly, so I didn't bother with the error. Then I guess I moved on to something else and I forgot, so it ended up being published like that (sorry). I think it's about time I implement full complex mode for all commands.

I'll start a new thread to discuss some ideas about complex mode.