newRPL - can't restore to 39gs

[Claudio L.]

(03-18-2019 11:01 PM)franco51 Wrote:  It would be great if someone else could check this out please.

On my Win 10 system some behaviour is slightly different from my Win 7 system –
n USBRECEIVE on the real calc for { « 1 1 + 2 2 + 3 3 + 4 4 + » } causes an Invalid data notice from the real calc, and the link does not disconnect.

Other results are the same -
{ « 1 1 + 2 2 + 3 3 + » } is received okay on the real calc. Also, it seems that any length is handled correctly when sent to the virtual calc.

This list is less than 60 bytes so it should fit in a single-packet of information. Data sent by the physical calc is prepared by newRPL's USB drivers, so it doesn't have any extra bytes and is properly formatted, I'm not surprised it arrives correctly even for multi-packet files.

(03-18-2019 11:01 PM)franco51 Wrote:  The difference in behaviours may suggest timing issues, at least in part.

The other error message I was getting: "Failed to send remote commands to newRPL Calc - serial number - version"

If for some reason libusb fails to recognize that extra byte and doesn't read it off the stream, all data sent afterwards will be shifted by one byte and all communications will fail. That makes me even more suspect of that extra byte being the issue.

(03-18-2019 11:01 PM)franco51 Wrote:  Finally, just to elaborate on the .nrpb file, opening it in Notepad++ I can see NRPB in plain text at the start of the content, followed by NULs, EOTs and so forth. (Notepad++ does see this file as a Normal text file).

BR
Frank

That's correct and expected. The file is binary and contains compiled RPL objects, but the first 4 bytes are used to identify the file type: NRPB is a full system backup as created by ARCHIVE/RESTORE while NRPL are individual objects (as saved by SDSTO for example).