newRPL - build 1255 released! [updated to 1299]

[Claudio L.]

(05-22-2019 04:42 AM)The Shadow Wrote:  

(05-22-2019 02:00 AM)Claudio L. Wrote:  By the way, there's a couple of new commands in newRPL that I added, inspired by David's library that will help in the implementation of some of his commands.

So what are they? List commands are near and dear to my heart.

In the wiki, Chapter 6, look for "List, Matrix and List commands". The new commands are NPOS, NPOSREV, POSREV, RHEAD, RTAIL. NPOS lets you continue a search from a known location in the list (more efficient than splitting the list, then using POS) and the others are the "reverse" versions of this one and other well known commands. They do the same thing, but starting to look from the end of the list towards the front, in other words: work with the reversed list without physically reversing the object in memory.
If you think you may have other things that need to be incorporated in ROM in order to make David's routines more efficient feel free to suggest it here or add it as a feature request in the bug tracker.

[Gilles]

(05-23-2019 02:25 PM)Claudio L. Wrote:  If you think you may have other things that need to be incorporated in ROM in order to make David's routines more efficient feel free to suggest it here or add it as a feature request in the bug tracker.

I vote for DOPERM and DOCOMB. the other commands can be directly written in newRPL very efficiently in the form of a library. But DOPERM and DOCOMB are more complex and will be much more effective in ROM as "native" commands.

[Claudio L.]

I have updated all unofficial and official builds to 1255. There's still a few things to iron out but it's about time for an update, I hadn't released anything officially since last year I think.

*EDIT* PS: Always make a backup before upgrading. If you notice anything strange restore from backup immediately. Nothing happened on mine but never hurts to have an extra backup.

[Feierabend]

(05-25-2019 01:21 PM)Claudio L. Wrote:  I have updated all unofficial and official builds to 1255.

Claudio, thanks for your fantastic work.

I did not succeed in flashing my 40gs to the new 1225 build. At the end of the flashing process, when I am prompted to press enter, the screen goes blank when I do, and the calculator never comes back. If I disconnect the USB cable at this point, the calculator enters in a sort of loop where a horizontal line appears alternatively at different heights, and the calculator makes clicking noises. Resetting the calc does not change anything, and it cannot be turned off. From this state, it can still successfully flashed back to build 1089 the usual way, or to the original HP firmware.

Maybe something went wrong with the file for the 40gs?

[Claudio L.]

(05-26-2019 11:01 AM)Feierabend Wrote:  

(05-25-2019 01:21 PM)Claudio L. Wrote:  I have updated all unofficial and official builds to 1255.

Claudio, thanks for your fantastic work.

I did not succeed in flashing my 40gs to the new 1225 build. At the end of the flashing process, when I am prompted to press enter, the screen goes blank when I do, and the calculator never comes back. If I disconnect the USB cable at this point, the calculator enters in a sort of loop where a horizontal line appears alternatively at different heights, and the calculator makes clicking noises. Resetting the calc does not change anything, and it cannot be turned off. From this state, it can still successfully flashed back to build 1089 the usual way, or to the original HP firmware.

Maybe something went wrong with the file for the 40gs?

Let me check, did you download from the links in this thread or from sourceforge?

EDIT: I checked, the MD5 from hpgcc3.org and sourceforge matches, so I cleaned up and recompiled from scratch, then check the MD5 and matches exactly the other 2 files built from a different machine and uploaded online. Can somebody else confirm there's a problem with the 40gs ROM?

[Feierabend]

(05-26-2019 12:41 PM)Claudio L. Wrote:  Let me check, did you download from the links in this thread or from sourceforge?

From Sourceforge.

[Claudio L.]

(05-26-2019 07:51 PM)Feierabend Wrote:  

(05-26-2019 12:41 PM)Claudio L. Wrote:  Let me check, did you download from the links in this thread or from sourceforge?

From Sourceforge.

As I mentioned, I checked and all files are the same, and also it's the same after recompiling from source. Try downloading again from the links in this post and from sourceforge and make sure the files are identical. I don't see any reason for the ROM to fail, the binary looks fine when I looked with a hex editor.

[The Shadow]

Haven't RHEAD and RTAIL been around for a while? The rest are amazing, though!

[franco51]

Hello,

Firstly, thank you for the 1255 updates. The Desktop feels much slicker, great on a touch screen PC and no problems loading backups.

Unfortunately I can't get connectivity between the 1255 Desktop and my 39gs. The Desktop can read the serial number okay but is displaying [Device not responding] immediately. On the 39gs it is displaying 'USBAUTORCV Error, Received invalid data' which I've not seen before.

I tried to reflash the 39gs with the new Desktop by placing it in bootloader mode but I did not see any response from the Desktop. Of course if it is intended that the Desktop uses the same connectivity for all purposes then I can't do anything at this stage. I will try the bootloader with the HP connectivity kit in a couple of days.

BR
Frank.

[Gilles]

I've installed the new 1225 build both on the simulator and a hp50g.
All fine... Now USB connection works like a charm!

[franco51]

That is great. What is the procedure you used to bootload your calculator from the new Desktop application?
BR
Frank

[JoJo1973]

I've not been able to operate a USB transfer with my HP50g: that's the procedure I followed (firmware 1255 on the calc, firmware 1255 on the emulator)

1) I start the emulator and plug the calc: the transfer indicator lights up and USBSTATUS returns #3h, without need to type USBON
2) "Hardware/USB Connections" on the emulator: the calc is recognized, appears in the list and the "RX" indicator on the emulator's screen flashes.
3) Selecting the calc and pressing OK estabilishes the connection: USBSTATUS returns #0h
4) I type USBON on the emulator, the indicator lights up and USBSTATUS returns #3h
5) I type 30 USBRECV on the emulator and try to USBSEND an object: nothing happens and sometimes the emulator locks and I need to kill it. Other times the transfer silently fails.
6) Sending an object from the emulator to the calc using the reverse procedure fails either.
7) "Hardware/Remote USBARCHIVE to file" brings a dialog box to choose where to save the backup, but then fails: an "USB communications error" pops up, "USBAUTORCV error: Received invalid data" on the emulator and (not all the times) "~INVALID~" object on the calc.

[Claudio L.]

(05-27-2019 08:08 PM)JoJo1973 Wrote:  I've not been able to operate a USB transfer with my HP50g: that's the procedure I followed (firmware 1255 on the calc, firmware 1255 on the emulator)

1) I start the emulator and plug the calc: the transfer indicator lights up and USBSTATUS returns #3h, without need to type USBON
2) "Hardware/USB Connections" on the emulator: the calc is recognized, appears in the list and the "RX" indicator on the emulator's screen flashes.
3) Selecting the calc and pressing OK estabilishes the connection: USBSTATUS returns #0h
4) I type USBON on the emulator, the indicator lights up and USBSTATUS returns #3h
5) I type 30 USBRECV on the emulator and try to USBSEND an object: nothing happens and sometimes the emulator locks and I need to kill it. Other times the transfer silently fails.
6) Sending an object from the emulator to the calc using the reverse procedure fails either.
7) "Hardware/Remote USBARCHIVE to file" brings a dialog box to choose where to save the backup, but then fails: an "USB communications error" pops up, "USBAUTORCV error: Received invalid data" on the emulator and (not all the times) "~INVALID~" object on the calc.

Forget about USBSTATUS and USBON/OFF, none of that is needed.
The procedure should be:
Run the emulator and plug the calc in any order. Go to the USB connections dialog, the device should show the version in the list, if it does it's communicating well, just hit OK.
At this point connection is established and you can use all the menus and commands to send/receive. Type 1 USBSEND and it should instantly go to the other end.

Now, you seem to be having real issues: The received invalid data means the CRC checks are failing. Try a different port, different cable, etc. If you have a hub, try connecting it directly to the PC to make sure it's not a hardware issue. The strange thing is that it is doing the initial handshake well if it's showing the version in the list. To get the version, it's actually sending a program to the calculator that does VERSION and sends one of the strings with USBSEND, so if that works you do have a proper connection.

What version of Windows are you using? I used a library that's supposed to work from Windows 7 and up, but I only tested on Windows 10.

[Claudio L.]

(05-27-2019 08:08 PM)JoJo1973 Wrote:  3) Selecting the calc and pressing OK estabilishes the connection: USBSTATUS returns #0h

USBSTATUS should return #7h for a proper connection, the bits are:

1 = cable connected
2 = Host OS initialized as HID device correctly.
4 = Connection to newRPL Desktop is established.

You get a zero if you pull the cable, when you plug it, if you see the symbol in the calc come up, it means the OS registered, so now you are at #3h, if the OS doesn't recognize it, you are stuck at #1h.
When you hit OK in the dialog, you'll get a #7h.

[Claudio L.]

(05-27-2019 07:49 PM)franco51 Wrote:  That is great. What is the procedure you used to bootload your calculator from the new Desktop application?
BR
Frank

You need to flash the calc using traditional methods. The firmware update on newRPL Desktop will only work if you already have newRPL 1255 or newer on the calc. It won't communicate with the bootloader or with the stock ROM or even with older versions of newRPL.

[JoJo1973]

(05-27-2019 09:18 PM)Claudio L. Wrote:  

(05-27-2019 08:08 PM)JoJo1973 Wrote:  3) Selecting the calc and pressing OK estabilishes the connection: USBSTATUS returns #0h

USBSTATUS should return #7h for a proper connection, the bits are:

1 = cable connected
2 = Host OS initialized as HID device correctly.
4 = Connection to newRPL Desktop is established.

You get a zero if you pull the cable, when you plug it, if you see the symbol in the calc come up, it means the OS registered, so now you are at #3h, if the OS doesn't recognize it, you are stuck at #1h.
When you hit OK in the dialog, you'll get a #7h.

Mixed progress:

First of all, I'm using Windows 10 and I never get a #7h when I press OK, neither on the calc nor the emulator.

Stuck with #3h, I get to transfer back and forth the emulator and the calc doing USBSEND on the sender and leaving unattended the receiver. Sometimes the transfer fails.

If I do USBSEND and 30 USBRECV on the receiver, the transfer never succeeds. Usually the receiver hangs and has to be reset/killed.

30 USBRESTORE/USBARCHIVE works perfectly, but using the Hardware menu fails always.

I tried various cables and ports on my laptop and always get the same results.

[Claudio L.]

(05-27-2019 10:03 PM)JoJo1973 Wrote:  Mixed progress:

First of all, I'm using Windows 10 and I never get a #7h when I press OK, neither on the calc nor the emulator.

Stuck with #3h, I get to transfer back and forth the emulator and the calc doing USBSEND on the sender and leaving unattended the receiver. Sometimes the transfer fails.

My apologies, looking at the source it seems at some point I replaced the bit from "connection with newRPL Desktop established" to "data is available for read". At the time it made sense that you are connected the moment you hit OK, so it becomes more or less useless to know that, #3h is good once connection is established. #7h is for programs to detect if there's data available when they disable auto-receive (via flag) and periodically check if there's some data ready to be picked up.

(05-27-2019 10:03 PM)JoJo1973 Wrote:  If I do USBSEND and 30 USBRECV on the receiver, the transfer never succeeds. Usually the receiver hangs and has to be reset/killed.

Arghhh... it seems in the rush to publish I forgot to backport the latest changes from USBAUTORCV to USBRECV. Good catch.

(05-27-2019 10:03 PM)JoJo1973 Wrote:  30 USBRESTORE/USBARCHIVE works perfectly, but using the Hardware menu fails always.

I tried various cables and ports on my laptop and always get the same results.

I confirmed your observations, USBRESTORE/ARCHIVE from the menu has some kind of race condition, depending on load my PC fails or not (works fine for the most part, but I was able to make it fail consistently under load). It seems the transfer takes place but the final confirmation fails to arrive (and without confirmation it reports it like an error). The calculator restarted every time and my directories were there (during RESTORE, after totally clearing the memory). I'll have to investigate further. The simulator doesn't seem to have that problem, as you noted.

As a workaround for the time being, backing up to the simulator and then using Save As... from the menu works the same. The file format is identical, the same file saved by the simulator can be sent via USBRESTORE to the calc directly (it mostly worked despite the error message). It can also be copied to an SD card to use SDRESTORE, or first open the file in the simulator and then send it to the calc. It's actually quite flexible.

[JoJo1973]

(05-28-2019 10:41 PM)Claudio L. Wrote:  

(05-27-2019 10:03 PM)JoJo1973 Wrote:  Mixed progress:

First of all, I'm using Windows 10 and I never get a #7h when I press OK, neither on the calc nor the emulator.

Stuck with #3h, I get to transfer back and forth the emulator and the calc doing USBSEND on the sender and leaving unattended the receiver. Sometimes the transfer fails.

My apologies, looking at the source it seems at some point I replaced the bit from "connection with newRPL Desktop established" to "data is available for read". At the time it made sense that you are connected the moment you hit OK, so it becomes more or less useless to know that, #3h is good once connection is established. #7h is for programs to detect if there's data available when they disable auto-receive (via flag) and periodically check if there's some data ready to be picked up.

(05-27-2019 10:03 PM)JoJo1973 Wrote:  If I do USBSEND and 30 USBRECV on the receiver, the transfer never succeeds. Usually the receiver hangs and has to be reset/killed.

Arghhh... it seems in the rush to publish I forgot to backport the latest changes from USBAUTORCV to USBRECV. Good catch.

(05-27-2019 10:03 PM)JoJo1973 Wrote:  30 USBRESTORE/USBARCHIVE works perfectly, but using the Hardware menu fails always.

I tried various cables and ports on my laptop and always get the same results.

I confirmed your observations, USBRESTORE/ARCHIVE from the menu has some kind of race condition, depending on load my PC fails or not (works fine for the most part, but I was able to make it fail consistently under load). It seems the transfer takes place but the final confirmation fails to arrive (and without confirmation it reports it like an error). The calculator restarted every time and my directories were there (during RESTORE, after totally clearing the memory). I'll have to investigate further. The simulator doesn't seem to have that problem, as you noted.

As a workaround for the time being, backing up to the simulator and then using Save As... from the menu works the same. The file format is identical, the same file saved by the simulator can be sent via USBRESTORE to the calc directly (it mostly worked despite the error message). It can also be copied to an SD card to use SDRESTORE, or first open the file in the simulator and then send it to the calc. It's actually quite flexible.

That's great to know! In the meanwhile I can happily live with manual USBRESTORE/USBARCHIVE, which is really useful.

[Feierabend]

(05-26-2019 10:50 PM)Claudio L. Wrote:  

(05-26-2019 07:51 PM)Feierabend Wrote:  From Sourceforge.

As I mentioned, I checked and all files are the same, and also it's the same after recompiling from source. Try downloading again from the links in this post and from sourceforge and make sure the files are identical. I don't see any reason for the ROM to fail, the binary looks fine when I looked with a hex editor.

I finally found some time to come back to this topic. I am obviously misunderstanding something. To me, it seems that the file from sourceforge, named newRPL-1255-firmware-40gs.bin, and the file from this thread, found at https://hpgcc3.org/downloads/newrpl40.bin are not the same. They are not even the same size. The former is 1044420 bytes long and the latter, 1044356 bytes.

This said, after changing the USB cable and starting anew with fresh batteries, I was able to flash the calculator successfully. I tried to reproduce the issue I observed, but could not. I would recommend making sure that the batteries are fully charged before updating, but I am not sure this was the problem.

I know it has been mentioned before, but on some machines, and at least on my HP 40gs, newRPL is initially setup with the LCD so light that text is almost completely invisible. I remembered that, so after the update, facing a blank screen, I pressed ON + to make the screen darker. This did not succeed, because newRPL was asking for a confirmation, and contrast control was not yet available: I had to press F1 first (but did not see it at first because the screen was so light). So I would suggest making the initial LCD contrast setting much darker, so that anybody can see that there is something on the screen.

[Han]

Mac OS 10.14.5 (Mojave) build errors for firmware (but oddly, the simulator had no issues compiling):

Code:

../newrpl-sources/newrpl/decimal.c:1432:5: error: conflicting types for 'sig_digits'
 int sig_digits(BINT word)
     ^~~~~~~~~~
In file included from ../newrpl-sources/newrpl/newrpl.h:84,
                 from ../newrpl-sources/newrpl/decimal.c:9:
../newrpl-sources/newrpl/decimal.h:165:6: note: previous declaration of 'sig_digits' was here
 BINT sig_digits(BINT word);

Using latest XCode and ARM eabi (bare-metal) toolchain; latest Qt Creator seems to be quirky (to me anyway) regarding make parameters. I seem to be unable to set up a proper working "kit" in order to compile using Qt Creator. Perhaps someone can enlighten me on how to properly create a "kit". In particular, qmake seems to always add architecture-specific options that makes arm-none-eabi-gcc barf. I had to manually edit the Makefile to remove $(EXPORT_ARCH_ARGS) and -mmacosx-version-min= compiler flags. Even so, my strict compiler does not like the mismatched declarations (isn't BINT just a define for int anyway?).

EDIT: changing "int" to "BINT" in decimal.c fixes this issue to compile