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

[Bruno]

(11-10-2016 02:30 AM)Helix Wrote:  - At the beginning, the calculator displayed an "alarm event" message each time it was turned on. I think that the ACK command solved the problem.

The alarm feature is under development, so in the tests phases I re-use the 'Connection' annunciator as a flag for 'Past Due Alarms'.
I think this annunciator was enabled after the upgrade for any reasons, then on wake-up this message was displayed.
The ACK command only turn off this annunciator.
Sorry for the inconvenience !

(11-10-2016 02:30 AM)Helix Wrote:  - In the TIME menu, there are strange commands like MEMCHEK, MEMFIX, READCFI, PEEK, POKE, and also the MEM command that seems misplaced.

Those commands are used for testing purposes, I will remove them from the menu.
Also you are right, the MEM command need to be in another menu.

Thanks for your report !

[Claudio L.]

(11-10-2016 02:30 AM)Helix Wrote:  Here are some initial comments:

- At the beginning, the calculator displayed an "alarm event" message each time it was turned on. I think that the ACK command solved the problem.

Already answered by Bruno.

(11-10-2016 02:30 AM)Helix Wrote:  - In the TIME menu, there are strange commands like MEMCHEK, MEMFIX, READCFI, PEEK, POKE, and also the MEM command that seems misplaced.

Will have to reorganize that menu, thanks.

(11-10-2016 02:30 AM)Helix Wrote:  - The PRG / TEXT menu is identical to the PRG / LOCAL menu

Oops, will fix.

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

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

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

(11-10-2016 02:30 AM)Helix Wrote:  - the Right Shift CHARS shortcut is useless, since SYMB / VARS do the same thing, with two key presses as well.

True, that's why I said temporarily, I'll probably put something else there. It's easy enough to do SYMB / Vars.

[Claudio L.]

(11-09-2016 11:40 PM)Vtile Wrote:  Not actually that copy, paste, split and round functionality were more of thinking out loud. My primary improvement idea were cursors position counter that counts starting from radix. Just like you have cursor poition countr in most programming editors.


Written with anchor that believes to be smart phone.

I understand now. I'll put it as a feature request.

[Han]

Can anyone post and MD5 sum of the newrpl.bin file? I flashed my calc and the first thing I got was the Exception: Data abort screen.

EDIT: I updated from the original ROM, with my RAM left as-is. Am I getting this screen because of my RAM not being initialized?

[Claudio L.]

(11-10-2016 04:27 PM)Han Wrote:  Can anyone post and MD5 sum of the newrpl.bin file? I flashed my calc and the first thing I got was the Exception: Data abort screen.

EDIT: I updated from the original ROM, with my RAM left as-is. Am I getting this screen because of my RAM not being initialized?

Even with the ram not initialized, you should not get a data abort, ever. There must be some bug introduced, can you share a picture of the data abort? I want to see the registers, in particular R15.

[Han]

Some more bad news... Now I cannot flash back to the original 2.15 ROM. After a successful flash, it just boots right back into the flash update menu (choosing between usb and card).

[Han]

Here is the screenshot

   

[Han]

Well, I may now have just bricked my HP 49G+ as well. Exact same issues (data abort screen) followed by not being able to re-flash back the the original HP ROM 2.15!!

I don't want to cause an alarm, but please be aware of the issues one of us is having.

Further testing:

Tried to reflash the ROM using 2.15 and USB this time; still no success. The calc continues to reboot into the flash update menu. So I don't think it is an SD card issue.

[Bruno]

(11-10-2016 08:35 PM)Han Wrote:  Further testing:

Tried to reflash the ROM using 2.15 and USB this time; still no success. The calc continues to reboot into the flash update menu. So I don't think it is an SD card issue.

Have you tried to reflash using the previous newRPL firmware ?

[Han]

Unfortunately I do not have any older versions. If anyone else has an older version lying around, could they upload it for testing?

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.

[Claudio L.]

(11-10-2016 08:35 PM)Han Wrote:  Well, I may now have just bricked my HP 49G+ as well. Exact same issues (data abort screen) followed by not being able to re-flash back the the original HP ROM 2.15!!

I don't want to cause an alarm, but please be aware of the issues one of us is having.

Further testing:

Tried to reflash the ROM using 2.15 and USB this time; still no success. The calc continues to reboot into the flash update menu. So I don't think it is an SD card issue.

You did not brick anything.
Pull out the batteries, including the backup batteries. Leave it be for a few minutes to make sure RAM was cleared and try flashing again.
The data abort message indicates there was an old newRPL version installed, which was properly detected (did you have newRPL or 2.15 before?), but somehow RAM memory was corrupted and the routine that verifies if your variable directories are consistent is having trouble to interpret the contents of your RAM (shouldn't, that's a bug I intend to correct, it should verify that pointer is valid before attempting to read from it).
The fact you cannot flash back 2.15 indicates the RAM is indeed corrupted, as even the bootloader relies on a few bytes of RAM to tell it what to do on boot. This is used by the calc OS (Hp one) to enter the diagnostic mode, etc.

All you have to do is clear your RAM.

I'll work on a new firmware version that will do a full memory wipe if you hold a certain key combination when you power on, to prevent this endless loop from happening.

[Claudio L.]

(11-10-2016 09:09 PM)Han Wrote:  Unfortunately I do not have any older versions. If anyone else has an older version lying around, could they upload it for testing?

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.

[Han]

(11-10-2016 09:32 PM)Claudio L. Wrote:  You did not brick anything.

Thank goodness, too! But yes, I managed to revive it by re-writing the entire ROM region.

Quote:Pull out the batteries, including the backup batteries. Leave it be for a few minutes to make sure RAM was cleared and try flashing again.
The data abort message indicates there was an old newRPL version installed, which was properly detected (did you have newRPL or 2.15 before?), but somehow RAM memory was corrupted and the routine that verifies if your variable directories are consistent is having trouble to interpret the contents of your RAM (shouldn't, that's a bug I intend to correct, it should verify that pointer is valid before attempting to read from it).
The fact you cannot flash back 2.15 indicates the RAM is indeed corrupted, as even the bootloader relies on a few bytes of RAM to tell it what to do on boot. This is used by the calc OS (Hp one) to enter the diagnostic mode, etc.

I did have an older version, but had since restored to 2.15 for some time. I'll try to re-flash again.

Quote:I'll work on a new firmware version that will do a full memory wipe if you hold a certain key combination when you power on, to prevent this endless loop from happening.

Awesome! Many thanks for such an awesome project!

[Claudio L.]

(11-10-2016 09:37 PM)Han Wrote:  I did have an older version, but had since restored to 2.15 for some time. I'll try to re-flash again.

OK, that explains why it detected newRPL was installed, but then RAM was corrupted. I'll have to solve that problem somehow.
Turns out newRPL uses ALL RAM, while the stock ROM leaves pretty much untouched the first 128 kb (uses only the first 32 kbytes in this block).
newRPL basic variables were still present in this untouched area even after you used 2.15 for a while.
newRPL started and detected it as if it was always there, but by installing 2.15 the rest of the memory had been rewritten, so your directories were garbled. Still, I have to fix that bug and offer the user an option to break out of the infinite loop.

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.

[Guenter Schink]

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

(11-08-2016 10:56 PM)Guenter Schink Wrote:  Are you sure the link at post#1 loads the new ROM? I don't see any difference to the previous one. No menu at all except "units"

Günter

Oops, my apologies. I uploaded the file with a typo in the name, so it didn't overwrite the old one. Please download again now.

Thanks, nice improvement. Another question, is there a way to set the number of digits other than the shortcuts (ON+Digit)?

Günter

[Guenter Schink]

About missing white space!

I think the command line editor should be more tolerant with omitted <blanks>

Given «1 2 +» gives a command line error when the <blank> after the opening or before the closing program delimiter is missing. It happens to me quite frequently when I edit something later.

Günter

[Han]

(11-10-2016 11:33 PM)Guenter Schink Wrote:  About missing white space!

I think the command line editor should be more tolerant with omitted <blanks>

Given «1 2 +» gives a command line error when the <blank> after the opening or before the closing program delimiter is missing. It happens to me quite frequently when I edit something later.

Günter

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.

[Claudio L.]

(11-10-2016 11:33 PM)Guenter Schink Wrote:  About missing white space!

I think the command line editor should be more tolerant with omitted <blanks>

Given «1 2 +» gives a command line error when the <blank> after the opening or before the closing program delimiter is missing. It happens to me quite frequently when I edit something later.

Günter

Sure, I've already done it with matrices and lists to some extent, but not with programs. I''ll put it in the list of features.

[Claudio L.]

(11-10-2016 11:10 PM)Guenter Schink Wrote:  Thanks, nice improvement. Another question, is there a way to set the number of digits other than the shortcuts (ON+Digit)?

Günter

Not yet, as SETNUMFORMAT is not implemented.

[Claudio L.]

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