newRPL - build 1255 released! [updated to 1299]

[bzoom]

My 39gs update from 1180 to 1255 went bad, it seems that paperclip menu is not accessible anymore, zero action on the screen, only clear screen without any pixels.

Update froze after "Erase Finished" line and Conn3x program was not responding anymore.
Another fine moment with Win10.

I guess I have to pop the 39gs case open and use debugger to program bootloader again.
I think I have a ST-link clone laying somewhere...

[Claudio L.]

(06-01-2019 04:47 PM)bzoom Wrote:  My 39gs update from 1180 to 1255 went bad, it seems that paperclip menu is not accessible anymore, zero action on the screen, only clear screen without any pixels.

Update froze after "Erase Finished" line and Conn3x program was not responding anymore.
Another fine moment with Win10.

I guess I have to pop the 39gs case open and use debugger to program bootloader again.
I think I have a ST-link clone laying somewhere...

Just wanted to clarify for other people that might get scared of flashing the new ROM: your issue is not related to newRPL, if it crashed after Erase Finished, the ROM never made it to your calculator. Your comms got stuck who knows why and the transmission got interrupted before anything was programmed.
If this was the case, the bootloader was never erased, so you should be able to reset and use + and - to access the boot loader menu. The timing is not so easy, make sure you try plenty of times before giving up. I never heard of boot loader getting erased on this type of hardware (39,40,50 series), except when I did it myself.

[bzoom]

Yes, I agree it is not newrpl problem but some update program / cable / connector / win10 failure. Previous updates went all fine, except some access violation error dialogs at Conn3x start.

I can access boot menu near 100% of time with my HP50g so I think I have right timing with reset. HP39gs display stays completely clear, there isn't any display flicker with reset pin.

It really looks like the bootloader is wiped with conn3x malfunction.

[Gilles]

Hi all,

How to use a "SD Card Image" with the simulator ? The simulator ask me for a .img file but what is this ?

[Claudio L.]

(06-02-2019 06:50 AM)bzoom Wrote:  Yes, I agree it is not newrpl problem but some update program / cable / connector / win10 failure. Previous updates went all fine, except some access violation error dialogs at Conn3x start.

I can access boot menu near 100% of time with my HP50g so I think I have right timing with reset. HP39gs display stays completely clear, there isn't any display flicker with reset pin.

It really looks like the bootloader is wiped with conn3x malfunction.

If/when you fix it, please let me know which debugger/dongle you used so I can get it and do the same on my 50g. I bought a Flashcat that supposedly supported this flash chip, but doesn't through the old JTAG from the ARM9 cores so I wasted my money. I want to find something that's proven to work before I spend any more money on it.

[Claudio L.]

(06-02-2019 11:31 AM)Gilles Wrote:  Hi all,

How to use a "SD Card Image" with the simulator ? The simulator ask me for a .img file but what is this ?

Just a raw image of a disk, you can get it by dumping the SD card with 'dd' on Linux or any other means. Make sure you include all sectors, not just the used ones, and no compressions, no headers of any kind, etc. just sectors one after another.
Same image you would use with x49gp, I think it includes some scripts to create one and format it with FAT. I find it easier to get a real SD card and dump it, that way you can dump the image back to the card and put it on the real calc if needed.

[3298]

(06-02-2019 06:07 PM)Claudio L. Wrote:  Same image you would use with x49gp, I think it includes some scripts to create one and format it with FAT.

It's actually part of the Makefile, but close enough. For Gilles' convenience, this is the relevant snippet (the first half is for OSX, the second half for Linux):

Code:

ifeq ($(shell uname),Darwin)
    rm -f sdcard.dmg
    hdiutil create sdcard -megabytes 64 -fs MS-DOS -volname x49gp
else
    /sbin/mkdosfs -v -C -S 512 -f 2 -F 16 -r 512 -R 2 -n "x49gp" $@ 65536
endif

The part about how to get files onto this SD card used to be in the readme up to the patch series last year, but I removed it because there's a more convenient way now (based on a QEMU part constructing a FAT filesystem on the fly from a regular directory). It wasn't really obscure though, just the standard mount and umount commands. Their manual pages and/or a mounting tutorial should be more than enough to shunt files between the SD image and the computer around it.

Gilles, if you're stuck on Windows, try WSL (Windows Subsystem for Linux), that ought to support these commands. Anything graphical is supposedly very tricky, so perhaps stay away from trying to run x49gp on it, but these SD-related commands are just simple command-line tools, i.e. exactly what WSL was built for.

[Nigel (UK)]

Two points:

• Entering '(0,1)' onto the stack and then pressing EVAL returns the list { '0' '1' } rather than the complex number (0,1). This may or may not be by design, but it surprised me.
• Entering 'sqrt(-2)' onto the stack and then pressing EVAL crashes both the physical calculator and the PC emulator.
  

Both of these operations are carried out with the complex results flag checked.

I haven't used newRPL for a while and it is wonderful to see how much progress has been made. George R R Martin could learn a thing or two from Claudio!

Nigel (UK)

[Claudio L.]

(06-03-2019 09:32 AM)Nigel (UK) Wrote:  Two points:

• Entering '(0,1)' onto the stack and then pressing EVAL returns the list { '0' '1' } rather than the complex number (0,1). This may or may not be by design, but it surprised me.
• Entering 'sqrt(-2)' onto the stack and then pressing EVAL crashes both the physical calculator and the PC emulator.
  

Both of these operations are carried out with the complex results flag checked.

I haven't used newRPL for a while and it is wonderful to see how much progress has been made. George R R Martin could learn a thing or two from Claudio!

Nigel (UK)

I updated the unofficial ROMs with a few bugfixes, I believe the crash you mentioned above should be resolved.
Also, complex numbers can't be expressed with parenthesis in a symbolic. You basically called a function without any name or command, therefore the list of arguments was returned as it was on the stack. This is part of the not-so-new support for multivalued functions in a symbolic. You can return multiple results and will be packed into a list.

Edit: Just for completeness, to express a symbolic you need to use a+b*i where the complex i is not the letter 'i' but the one on Alpha-LS-7.

[JoJo1973]

(06-03-2019 12:13 PM)Claudio L. Wrote:  

(06-03-2019 09:32 AM)Nigel (UK) Wrote:  Two points:

• Entering '(0,1)' onto the stack and then pressing EVAL returns the list { '0' '1' } rather than the complex number (0,1). This may or may not be by design, but it surprised me.
• Entering 'sqrt(-2)' onto the stack and then pressing EVAL crashes both the physical calculator and the PC emulator.
  

Both of these operations are carried out with the complex results flag checked.

I haven't used newRPL for a while and it is wonderful to see how much progress has been made. George R R Martin could learn a thing or two from Claudio!

Nigel (UK)

I updated the unofficial ROMs with a few bugfixes, I believe the crash you mentioned above should be resolved.
Also, complex numbers can't be expressed with parenthesis in a symbolic. You basically called a function without any name or command, therefore the list of arguments was returned as it was on the stack. This is part of the not-so-new support for multivalued functions in a symbolic. You can return multiple results and will be packed into a list.

Edit: Just for completeness, to express a symbolic you need to use a+b*i where the complex i is not the letter 'i' but the one on Alpha-LS-7.

This prompted me to test if it's possible to express complex numbers in polar form into symbolics: I found two issues.

1) (-1+i) = (sqrt(2),∡135º) so at first I tried to build 'sqrt(2)*e^(i*∡135º)' by steps: I failed because symbolic i units can't be multiplied by an angle using the '*' key. Nevertheless, typing the whole expression on the command line was accepted by the parser.

2) Evaluation gave a wrong result because I was in DEG mode and ∡135º was converted to 135 rather than 3*pi/4. Repeating the test in RAD mode returned the correct result.

IMHO multiplication of complex by angle should be allowed and considered a special case whereas the angle is always converted to a real in radians regardless current angular mode: it's the only case where there should be a deviation from the standard treatment which, in other situations, it's useful and straightforward.

[franco51]

(06-02-2019 06:01 PM)Claudio L. Wrote:  

(06-02-2019 06:50 AM)bzoom Wrote:  Yes, I agree it is not newrpl problem but some update program / cable / connector / win10 failure. Previous updates went all fine, except some access violation error dialogs at Conn3x start.

I can access boot menu near 100% of time with my HP50g so I think I have right timing with reset. HP39gs display stays completely clear, there isn't any display flicker with reset pin.

It really looks like the bootloader is wiped with conn3x malfunction.

If/when you fix it, please let me know which debugger/dongle you used so I can get it and do the same on my 50g. I bought a Flashcat that supposedly supported this flash chip, but doesn't through the old JTAG from the ARM9 cores so I wasted my money. I want to find something that's proven to work before I spend any more money on it.

Hello, my 39gs is also dead after a recent ROM update attempt. I was using Conn3x on a Win7 PC and cable that had previously reflashed the calculator a number of times with no issues. As described elsewhere the processes froze without completing. When I now connect the calculator, the PC reports USB device is not recognised, failed to respond. Just before the attempt I checked and it was recognised as a newRPL HID class device. I'll also look into the availability of suitable j-tag dongles.
BR
Frank

[3298]

I have a theory regarding the recent flashing failures on the 39gs ... if:
- the firmware image is longer than the flash space (1MiB) minus the length of the bootloader (probably 16KiB, because that's the length on 49g+ and 50g),
- the firmware update code doesn't check if the firmware fits into 1MiB (either because it doesn't check at all, or because Kinpo goofed and left it at the 2MiB appropriate for 49g+ and 50g), and
- the flash memory repeats in the adress space, e.g. by leaving the extra address pin unconnected,
then a catastrophic buffer overflow happens during the update process. The write process would fill the flash, then wrap around and overwrite the bootloader by writing into the start of the mirror image. That would not only crash as the update code deletes itself during the sector clear part of the write operation, but also brick the machine preventing any further use as the rest of the bootcode goes poof along with the updater. The firmware was displayed to me as 1020 KiB long, so the first condition seems to be fulfilled.

If this theory is correct, the machines affected so far will definitely need a new bootcode. NewRPL would also need some adjustment as it cannot fit into the flash memory anyway.

By the way, if someone manages to un-brick one of the victims, could you fork over a copy of the bootcode as well? x49gp has the 49g+ and 50g bootcodes (or at least one version each, if there were multiple versions over the models' lifetimes), but no others. I was looking into adding support for 39/40 emulation, and even though the 49/50 bootcode might just do the trick, it'd be nicer to have the matching one.

[Nigel (UK)]

(06-03-2019 12:13 PM)Claudio L. Wrote:  

(06-03-2019 09:32 AM)Nigel (UK) Wrote:  Two points:

• Entering '(0,1)' onto the stack and then pressing EVAL returns the list { '0' '1' } rather than the complex number (0,1). This may or may not be by design, but it surprised me.
• Entering 'sqrt(-2)' onto the stack and then pressing EVAL crashes both the physical calculator and the PC emulator.
  

Both of these operations are carried out with the complex results flag checked.

I haven't used newRPL for a while and it is wonderful to see how much progress has been made. George R R Martin could learn a thing or two from Claudio!

Nigel (UK)

I updated the unofficial ROMs with a few bugfixes, I believe the crash you mentioned above should be resolved.
Also, complex numbers can't be expressed with parenthesis in a symbolic. You basically called a function without any name or command, therefore the list of arguments was returned as it was on the stack. This is part of the not-so-new support for multivalued functions in a symbolic. You can return multiple results and will be packed into a list.

Edit: Just for completeness, to express a symbolic you need to use a+b*i where the complex i is not the letter 'i' but the one on Alpha-LS-7.

Thanks for the quick reply. I now understand how to represent complex numbers in symbolics.

Are the "unofficial" ROMs the "development" ROMs linked to on the first page? If so, the 'sqrt(-2)' EVAL crash persists in the ROM I have just downloaded and installed.

Nigel (UK)

[Gilles]

(06-02-2019 09:03 PM)3298 Wrote:  Gilles, if you're stuck on Windows, try WSL (Windows Subsystem for Linux), that ought to support these commands. Anything graphical is supposedly very tricky, so perhaps stay away from trying to run x49gp on it, but these SD-related commands are just simple command-line tools, i.e. exactly what WSL was built for.

Thank you ! I will try… For now i used a free w10 soft to create SD image. I tested the commands for the SDCARD and file manipulation both on simulator and HP50. Efficiant and powerfull. SD card can be used easily like a mass storage ;D

[Gilles]

Not a priority at all and I know that DOSUBS or MAP do the job. But it could be nice to have a kind of FOR IN syntax :

{ 1 2 3 4 7 9 } FORIN 'MyDigit' ... NEXT
or
{"Red" "Yellow" "Blue" } FORIN 'MyColor' ... NEXT
or why not :
"abcdefxyz" FORIN 'MyChar' .... NEXT

Perhaps FOR instead of FORIN would be sufficiant, as it depends of the type of the object before FOR

[Claudio L.]

(06-03-2019 09:04 PM)Nigel (UK) Wrote:  Are the "unofficial" ROMs the "development" ROMs linked to on the first page? If so, the 'sqrt(-2)' EVAL crash persists in the ROM I have just downloaded and installed.

Nigel (UK)

Noted, will add it to the bug tracker. I tested the Android build and doesn't crash but there's some garbage after the result, showing some malformed symbolic, I'll investigate this regression. Thanks!

[Claudio L.]

(06-04-2019 11:11 AM)Gilles Wrote:  Not a priority at all and I know that DOSUBS or MAP do the job. But it could be nice to have a kind of FOR IN syntax :

{ 1 2 3 4 7 9 } FORIN 'MyDigit' ... NEXT
or
{"Red" "Yellow" "Blue" } FORIN 'MyColor' ... NEXT
or why not :
"abcdefxyz" FORIN 'MyChar' .... NEXT

Perhaps FOR instead of FORIN would be sufficiant, as it depends of the type of the object before FOR

I like it as an alternative format for FOR. NEXT would simply advance in the list. Is there any use for STEP? Perhaps add the number to the index within the list, so you can skip backwards or more than one item forward. The loop ends whenever the index is out of bounds.

[Gilles]

(06-04-2019 08:46 PM)Claudio L. Wrote:  I like it as an alternative format for FOR. NEXT would simply advance in the list. Is there any use for STEP? Perhaps add the number to the index within the list, so you can skip backwards or more than one item forward. The loop ends whenever the index is out of bounds.

STEP with positive or negative argument would be coherent.
FOREACH could also be a good keyword for this.

Another point… I Always like the way Pascal does with ordered set, and allows things like :

If MyVar in [ 1 .. 4, 7, 10, 15 .. 20 ] Then ….
If MyVar in [ 'a' .. 'z' ]
More : https://www.tutorialspoint.com/pascal/pascal_sets.htm
But Pascal is a strongly typed langage.

[The Shadow]

(06-04-2019 08:46 PM)Claudio L. Wrote:  

(06-04-2019 11:11 AM)Gilles Wrote:  Not a priority at all and I know that DOSUBS or MAP do the job. But it could be nice to have a kind of FOR IN syntax :

{ 1 2 3 4 7 9 } FORIN 'MyDigit' ... NEXT
or
{"Red" "Yellow" "Blue" } FORIN 'MyColor' ... NEXT
or why not :
"abcdefxyz" FORIN 'MyChar' .... NEXT

Perhaps FOR instead of FORIN would be sufficiant, as it depends of the type of the object before FOR

I like it as an alternative format for FOR. NEXT would simply advance in the list. Is there any use for STEP? Perhaps add the number to the index within the list, so you can skip backwards or more than one item forward. The loop ends whenever the index is out of bounds.

I am totally down for this! It would simplify a lot of things.

Also, could I put a request in for FXND? I use it constantly, and my version is slow.

[Martin Hepperle]

Out of curiosity I bought a Hp 39gs and flashed newRPL into the device (I did not want to destroy my HP 50g).

The first visual thing I noticed was that the display contrast for the menu key letters was weak and seemed to flicker a bit (grayscale). I adjusted with ON +/- but it is not perfect - a true black and white design might look better (but this is maybe a matter of taste).

Concerning the keyboard layout: I assume that the HP50g layout is the father of the keyboard and the HP 39gs has a rather different layout.
I am thinking of creating an overlay template, laminating it and cutting the key holes with a knife to make a usable overlay.

Has someone already done this (created a keyboard overlay?)

Otherwise, after reading through the Wiki documentation I am very much impressed by the number of the functions and the speed of execution - a great project and great work!


Thank you, Claudio,

Martin