newRPL - can't restore to 39gs

[Claudio L.]

(03-13-2019 02:19 PM)franco51 Wrote:  I use newRPL on a 39gs regularly (it’s great!) but following a crash I want to restore the data.

I’m using a .nrpb file, with 30 USBRESTORE on the 39gs and USBARCHIVE on the virtual calc. When I try to send the file to the physical 39gs I get an “Error Received invalid data” message and the USB link disconnects.

I’ve tried Warmstarts, Resets (physical and software), purging all vars and also going back to the 1089 firmware release and trying again but with no luck.

I can Open this file on the virtual calc and everything runs from there with no problems.

I’m using Win 7 Pro by the way.

What am I missing, please?

BR
Frank.

Try the following:
Save As... the virtual calculator (which has your data) to a file on the PC and then use the option from the menu to remote RESTORE from a file. This will bypass the simulator completely and send the data file directly to the calc.

Looking at the source code, the USBRESTORE command will only show "Received invalid data" under ONE condition: The received file does not have the letters "NRPB" on the first 4 bytes. This means the data received was likely completely garbled (hasn't happened to me before, comms have been very reliable to me).

Try a different USB port, different cable, different PC. Blow your calculator USB connector with a dust blower, etc. to eliminate the possibility of a bad connection.
Open the file on the PC with a hex editor and double check that the first 4 bytes actually are NRPB (this is for the Save As... method above, where you actually have a file you can check).

Other than that... I don't know. The strange part is that your Desktop version can work with the file without any issues, (so the data itself is good) but the calc isn't even receiving the header correctly.
For the record, the .nrpb file is not just a dump of the objects in memory. Before saving, a there's a pass that converts any object in ROM into special ROMIDs, then objects are saved. Recovery is even more involved: there's one pass reversing the process I just mentioned where all ROMIDs are changed with objects in the new ROM (new because it is potentially completely different, since the file can be restored on a different platform). Then each individual object is checked for validity (same as using the MEMFIX command).