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

[Guenter Schink]

(05-06-2017 07:44 PM)smartin Wrote:  

(05-06-2017 04:08 PM)compsystems Wrote:  Photo album about NewRPL



https://plus.google.com/+JamelTayeb/posts/gmERBRFatdg

Too bad you can't get the 50g for $50 anymore.

It seems they are now harder to come by, even used.

Simply join the HHC 2017 at Nashville. I'll put a 50G flashed with newRPL on the table of door prizes. Perhaps after giving an update on newRPL.

Günter

Provided I don't forget it at home

[compsystems]

Testing NewRPL (win demo) https://sourceforge.net/projects/newrpl/files/demos/

A suggestion: The alphabetical QWERTY keyboard of a computer, it must place letters in uppercase on virtual LCD, for to write for example command names: [1 2 3] PROOT, instead of primary functions (white label) of the calculator

In the skin that I made for emu48+
Please check it http://www.hpmuseum.org/forum/thread-803...l#pid70357

I use the [control]+[alpha keys] key to write the primary functions of the calculator for example
[Ctrl-Hold]+[S] EQUAL [SIN]
[Ctrl-Hold]+[R] EQUAL [ROOT]
[Ctrl-Hold]+[N] EQUAL [EVAL]
...
[A,...Z] -> [A,...Z]
and with [shift]+[alpha keys] type lowercase letters.
[Shift-Hold]+[N] EQUAL n
[Shift-Hold]+[E] EQUAL e
[Shift-Hold]+[I] EQUAL i

[The Shadow]

Thanks for your replies, Claudio.

I've noticed that GETI and PUTI aren't working right. When the index reaches the end of the list, it's supposed to loop back around to 1 - this is great for DO...UNTIL loops. Instead it just keeps growing and throws errors.

Also, what does EVAL1NEXT do?

[Claudio L.]

(05-08-2017 05:58 AM)The Shadow Wrote:  Thanks for your replies, Claudio.

I've noticed that GETI and PUTI aren't working right. When the index reaches the end of the list, it's supposed to loop back around to 1 - this is great for DO...UNTIL loops. Instead it just keeps growing and throws errors.

Also, what does EVAL1NEXT do?

GETI/PUTI are being rewritten as we speak: all those functions were written for lists only (before other objects were available), now they are being moved to a more generic composites library and rewritten to support vectors/matrices, etc. Just looked at the new code and they do proper wrapping and set the flag as they should.

EVAL1NEXT is internal, I'll probably remove its user-friendly name so it doesn't show up in autocomplete. It does EVAL1 on the next object in the runstream. It's used for user-defined functions with the syntax:

Code:

<< -> X Y 'X^2+Y^2+1' >>

Internally, they get compiled as something like:

Code:

<< -> X Y << EVAL1NEXT 'X^2+Y^2+1' >> >>

It's necessary so algebraic functions do proper argument replacement before returning a result. If that function is called FUNC, using 'FUNC(Z+1,4)' EVAL will EVAL each argument, then call the program FUNC. FUNC needs to do EVAL1 to guarantee the arguments are replaced in the expression, so it returns: '(Z+1)^2+4^2+1' as expected (provided Z doesn't exist, otherwise the first EVAL would do a fully recursive replace).

[Nigel (UK)]

Current consumption on my HP49g+ is still a problem.

I've reflashed the calculator to HP ROM 2.15; current consumption when off is 18 microamps and about 11mA when on and not doing anything. These numbers seem normal.

However, reflashing to the latest version of newRPL gives me a current consumption when turned on of about 40 mA, and a current consumption when turned off of either 4 mA (SD card in slot) or 10 mA (SD card not in slot).

On my HP50g also running newRPL current consumption is about 24 microamps when off; when turned on, the current is between 40 mA and 50 mA.

Nigel (UK)

[The Shadow]

I've been playing around with key assignments, and I'm wondering what contexts are currently available other than 0, for applying in all circumstances.

[Claudio L.]

(05-09-2017 04:19 PM)Nigel (UK) Wrote:  Current consumption on my HP49g+ is still a problem.

I've reflashed the calculator to HP ROM 2.15; current consumption when off is 18 microamps and about 11mA when on and not doing anything. These numbers seem normal.

However, reflashing to the latest version of newRPL gives me a current consumption when turned on of about 40 mA, and a current consumption when turned off of either 4 mA (SD card in slot) or 10 mA (SD card not in slot).

On my HP50g also running newRPL current consumption is about 24 microamps when off; when turned on, the current is between 40 mA and 50 mA.

Nigel (UK)

I double checked that newRPL is following the recommended practice when it comes to pins in sleep mode. There was no more progress in that regards, so there's no reason to expect any different measurements.

[Claudio L.]

(05-09-2017 05:03 PM)The Shadow Wrote:  I've been playing around with key assignments, and I'm wondering what contexts are currently available other than 0, for applying in all circumstances.

CONTEXT_ANY=0,
CONTEXT_INEDITOR=1,
CONTEXT_STACK=2,
CONTEXT_INTSTACK=4,


This might change when the UI is complete, as more might be needed but for now here's the plan:
User contexts will be multiples of 32, so there will be 5 bits reserved for states within a context.
For example, if a user program sets the context at USER_APP_CONTEXT=64, then 64 = USER_APP_CONTEXT+CONTEXT_ANY = anywhere within the application, 65 = USER_APP_CONTEXT+CONTEXT_INEDITOR, whenever you have the editor open inside your application, etc.

Right now there's only one system context = 0 = ANY. That might also change as perhaps the initial system context should be 32, so you could define keys that only work anywhere on the system interface, but not within an application. If the key is defined with 0+CONTEXT_STACK, then it will be active inside the stack even when embedded inside an application.

Since there's no gui applications yet, you can only play with these flags in context 0.

[The Shadow]

5 bits reserved, but only 3 in use thus far. What will the other 2 be used for? I'm guessing one will be the graphing environment.

[Nigel (UK)]

(05-09-2017 05:58 PM)Claudio L. Wrote:  I double checked that newRPL is following the recommended practice when it comes to pins in sleep mode. There was no more progress in that regards, so there's no reason to expect any different measurements.

Searching online I find that v1.20 of the HP49g+ firmware caused a large current drain when the calculator was off, similar to what is happening now, but that this was fixed in firmware v1.22. Would it be worth asking in the main part of the forum to see if anyone (perhaps a HP employee) might know (or might know of someone who knows) what the problem was back then? If you think this might help I'd be happy to post.

Nigel (UK)

[Claudio L.]

(05-10-2017 09:45 AM)Nigel (UK) Wrote:  Searching online I find that v1.20 of the HP49g+ firmware caused a large current drain when the calculator was off, similar to what is happening now, but that this was fixed in firmware v1.22. Would it be worth asking in the main part of the forum to see if anyone (perhaps a HP employee) might know (or might know of someone who knows) what the problem was back then? If you think this might help I'd be happy to post.

Nigel (UK)

I already checked that, newRPL does the same as the fixed ROM, which does the same as every rom that came afterwards. I couldn't find a link to download the 1.20 ROM to do a diff with 1.22 and see exactly what they fixed, though.

[pier4r]

I like ebay and similar sites (even if a lot of people do prefer to throw functional stuff away instead of selling it) so I may snatch a 50g for a relatively low price. Then I can have a newRPL dedicated system finally, that is more motivating to explore.

(the same is with the HP prime app on android, I know that it is great but without the calculator I defer its usage too much).

Snatched for 43 €, within the budget. NewRPL machine only coming!

[Vtile]

I'll remove my txt-file attachment now from page 31, since the wiki took the wind under the wings. There is nothing on the index that isn't in the wiki except the Ruleapply command and maybe ANGLES AS OBJECTS.

Here is the copy of the index, if it somehow gives any ideas.

Quote:
SYSTEM ABSTACT
UI NAVIGATIONS
TERMINOLOGY
HARDWARE LIMITS
LIBRARY STRUCTURE

BASIC OPERATIONS
ARITHMETICS
REALS
INTEGERS
FRACTIONS
VARIABLE PRECISION
NUMBER SYSTEMS (BASE)
COMPLEX NUMBERS
BASIC SYMBOLIC EXPRESSIONS
MATRIX AND VECTOR OPERATIONS
LISTS

SYSTEM - THE SECOND LOOK
MENUS AND CUSTOM KEYBOARD
CONSOLE
UNIT SYSTEM
COORDINATE SYSTEM
ANGLES AS OBJECTS
POLAR VECTORS
POLAR COMPLEX NUMBERS
RULE SYSTEM ( RULEAPPLY )
BRANCHING
DEBUGGING

FILESYSTEM
STRINGS WITH UTF8
SD-CARD USAGE

[Claudio L.]

(05-16-2017 09:31 PM)Vtile Wrote:  I'll remove my txt-file attachment now from page 31, since the wiki took the wind under the wings. There is nothing on the index that isn't in the wiki except the Ruleapply command and maybe ANGLES AS OBJECTS.

RULEAPPLY was only partially implemented, and since it was taking too much time to create a proper rules engine, it was put on hold until other areas are complete. It will be included in the "Symbolic expressions" section of the wiki, but only after it actually works.
There is a section on Angles in the wiki, that should cover all there is to know about working with angles.

[smartin]

RPL programs can be stored in files on an SD card easily from the 50g using the command SDSTO, and when retrieving via SDRCL the program appears perfectly on the stack. But it doesn't appear as a simple ASCII/text file when examining the SD card from a PC, although there is a 'NRPL' in the header. Is there a preferred way to encode RPL program files on the PC that can be easily loaded on the 50g under newRPL?

Cheers,
Steve

[Claudio L.]

(05-28-2017 02:40 AM)smartin Wrote:  RPL programs can be stored in files on an SD card easily from the 50g using the command SDSTO, and when retrieving via SDRCL the program appears perfectly on the stack. But it doesn't appear as a simple ASCII/text file when examining the SD card from a PC, although there is a 'NRPL' in the header. Is there a preferred way to encode RPL program files on the PC that can be easily loaded on the 50g under newRPL?

Cheers,
Steve

SDSTO/SDRCL work with binary files, adding the NRPL header only. They don't decompile objects at all.
To work on programs on the PC, the best is to use any UTF-8 text editor, the text can be read like any other file, with SDOPENRD, SDREADTEXT and SDCLOSE, followed by STR->.
As long as the simulator has the same version of the core as the ROM on your calculator, files stored with SDSTO in a virtual SD card with the simulator should read just fine with SDRCL on real hardware.
But I'll put on the bug tracker that perhaps a command like SDTSTO should decompile (unless the object is already a string) and store in a plain text file, no headers of any kind. SDRCL should perhaps read the file as a string if it fails to detect the NRPL header, so we don't need a new command for that.
For the time being, it's easy to write a short routine that reads and compiles a plain text file.

[matthiaspaul]

(05-29-2017 02:55 AM)Claudio L. Wrote:  But I'll put on the bug tracker that perhaps a command like SDTSTO should decompile (unless the object is already a string) and store in a plain text file, no headers of any kind.

Since this would be some kind of "variation" of STSTO I would suggest something like SDSTOTEXT or SDSTOT so that it gets listed alongside SDSTO when sorted alphabetically.

Greetings,

Matthias

[Claudio L.]

(05-29-2017 06:12 PM)matthiaspaul Wrote:  

(05-29-2017 02:55 AM)Claudio L. Wrote:  But I'll put on the bug tracker that perhaps a command like SDTSTO should decompile (unless the object is already a string) and store in a plain text file, no headers of any kind.

Since this would be some kind of "variation" of STSTO I would suggest something like SDSTOTEXT or SDSTOT so that it gets listed alongside SDSTO when sorted alphabetically.

Greetings,

Matthias

Agreed. The only reason I put the T in the middle was so it looks different on the menu, but autocomplete should take priority, I find it more useful in day to day than going through the menus, unless I need help remembering the arguments, then the menu is the only way to get help.

[matthiaspaul]

(05-30-2017 11:50 PM)Claudio L. Wrote:  The only reason I put the T in the middle was so it looks different on the menu, but autocomplete should take priority, I find it more useful in day to day than going through the menus, unless I need help remembering the arguments, then the menu is the only way to get help.

Good point as well.

Is this the only command exhibiting this problem? Then all SD* commands could be aliased as C* (for "card") or X* (for "external") in newRPL and the SD* entries kept only for backwards compatibility with the 50g. After all, it always was a bit odd (by the HP RPL language designers) to name those commands after the brand name of the physical medium instead of chosing a more abstract and futureproof name.

Otherwise, is there a hotkey to (temporarily) list all command assignments in the current menu in an unabbreviated list?

Greetings,

Matthias

[smartin]

(05-29-2017 02:55 AM)Claudio L. Wrote:  

(05-28-2017 02:40 AM)smartin Wrote:  RPL programs can be stored in files on an SD card easily from the 50g using the command SDSTO, and when retrieving via SDRCL the program appears perfectly on the stack. But it doesn't appear as a simple ASCII/text file when examining the SD card from a PC, although there is a 'NRPL' in the header. Is there a preferred way to encode RPL program files on the PC that can be easily loaded on the 50g under newRPL?

Cheers,
Steve

SDSTO/SDRCL work with binary files, adding the NRPL header only. They don't decompile objects at all.
To work on programs on the PC, the best is to use any UTF-8 text editor, the text can be read like any other file, with SDOPENRD, SDREADTEXT and SDCLOSE, followed by STR->.
As long as the simulator has the same version of the core as the ROM on your calculator, files stored with SDSTO in a virtual SD card with the simulator should read just fine with SDRCL on real hardware.
But I'll put on the bug tracker that perhaps a command like SDTSTO should decompile (unless the object is already a string) and store in a plain text file, no headers of any kind. SDRCL should perhaps read the file as a string if it fails to detect the NRPL header, so we don't need a new command for that.
For the time being, it's easy to write a short routine that reads and compiles a plain text file.

Got it. But after playing around a bit (moving programs back and forth between a PC and the 50g), I found that having a command in newRPL to create a new file would be useful (analogous to SDCRDIR). I found the only way I could write a program file (ASCII) to the SD card from the 50g was if I already had an empty file to write to (which I had to create on the PC side). SDTSTO will certainly help address this issue, but still having a command in newRPL to create a new (empty) file may be useful.

-Steve