(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.

(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?

(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)

(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.

(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.

(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)

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

(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.

(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

(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.

(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

(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.

(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.