Transfer files programatically

[gbl08ma Profile Website]

Thanks. I'm a bit confused by your example code in one thing. It seems to first set the baud to 9600, then reset the serial hardware of the remote calculator then tell it to start again at 115200 baud. This makes some sense, because I know older calculators don't support 115200 baud, so the system starts at 9600 (all calculators probably support that).

I think the OS sends command 1 with subtype 9 while it is still running at 9600 baud ("universal" mode) so it can understand the capabilities of the calculator. Then it only accelerates to 115200 (or whatever other setting) if it detects the connected calculator supports it.

But your code only checks for calculator type when it is already running at 115200 baud, which would cause incompatibility with older calculators. Or does App_LINK_SetRemoteBaud automatically check for calculator type and set baud appropriately (not just to 115200, but to whatever the remote supports), and so our code doesn't need to take care of it?
This isn't really relevant to my problem as my add-in only runs on the Prizm, and all the Prizm calcs support 115200 baud. But it may pose an issue for people trying to communicate with old Casio calculators.

Now not entirely related to this, but what other capabilities does the 7.00 communication protocol have? Can we upload a file to a remote calculator and have it run on-the-fly as if it were an add-in, but without the need of installing it to storage (a bit like the OS updater works, but with the OS present and without overwriting its RAM areas)? What other information can we get out of a calculator when it is in file receiving mode (e.g. amount of free storage)?

[SimonLothar]

...because I know older calculators don't support 115200 baud...

With my oldest fx-9860G (manufactured 09.08.2006; bios date 23.06.2005; OS 1.03) 115 kBaud works well. Which older calculators do you mean?

[gbl08ma Profile Website]

Calculators like the CFX9850 (Casio Graph 65) do not support it, according to Wikipedia the maximum transmission rate is of 9600 baud.
I could successfully transfer MCS files from my Prizm to one of these calcs so it definitely has a way to detect if the remote calculator supports higher speeds, and maybe even which baud rates specifically, and only switches to them after the initial handshake and information gathering has been done at 9600 baud.

[SimonLothar]

...Or does App_LINK_SetRemoteBaud automatically check for calculator type and set baud appropriately...

Yes. After App_LINK_SetRemoteBaud tried to change the speed settings of the remote calculator, it checks the reply packet. If it receives an Ack-packet (0x06) with subtype 0x00, it switches its own speed settings to 115 kBaud, too and returns without error code (t. i. the caller proceeds normally). If it receives an Error-packet (0x15) with subtype 0x00 it does not change its own speed settings and instructs its caller to proceed with the current speed settings, which are 9600 baud. In any other case the calling unit will be instructed to quit the transfer process.

[SimonLothar]

...but what other capabilities does the 7.00 communication protocol have?

A lot. Most of these are described in fxReverse.pdf.

Can we upload a file to a remote calculator and have it run on-the-fly as if it were an add-in, but without the need of installing it to storage (a bit like the OS updater works, but with the OS present and without overwriting its RAM areas)?

That would be subtype "56", Upload'n'Run, my favourite (though not described in fxReverse.pdf). I shortly described it in fx_calculators_SuperH_based.chm (look for "Sending a file via the serial..." in the index). The main disadvantage: for every calculator type and OS version you have to find an appropriate RAM area to ensure, the upload does not collide with the OS. As far as I am concerned, this is a feature for research purposes only, but nonetheless very valuable.

[gbl08ma Profile Website]

Makes sense.
I will try to get someone with two Casio Prizm calculators to test software for me, then I'll begin experimenting.

Also, did you know that when a Prizm is overclocked, the baud rate changes proportionally to the CPU speed change, and if two Prizms are overclocked to the same speed, they transfer files faster (but according to my experience, with higher error rate)? USB transfer (and preparation) is also much faster, and without errors.

Just saw your post about protocol 7.00. I have looked in fxReverse but it seems to me that it's a bit incomplete and missing many commands. I understand there's also a way to communicate with protocol 7.00 over USB, even on the Prizm (I believe one can trigger this mode by launching the OS update function on the calc, because usually it just identifies itself as a mass storage device).

Another thing that would be interesting to look into is to how the screen receiver mode works. Using custom software on the computer, the screen receiving mode could be used to quickly (2 bytes per pixel, lots of pixels) dump data out of the Prizm over USB, including the whole flash, by copying it to the VRAM in pieces. The ability to send data back to the Prizm (for example key presses) would be even better.

I own a very old Casio SF diary, it has a 3 pin serial port too, but it's not protocol 7.00, it's an earlier incompatible version I think. I will get to document it one of these days - if only those lithium button cells weren't so expensive...

[SimonLothar]

Also, did you know that when a Prizm is overclocked, the baud rate changes proportionally to the CPU speed change, and if two Prizms are overclocked to the same speed, they transfer files faster (but according to my experience, with higher error rate)?

No, I didn't.

Just saw your post about protocol 7.00. I have looked in fxReverse but it seems to me that it's a bit incomplete and missing many commands.

"a bit incomplete": yes, maybe. "missing many commands": no, I don't think so. Manuel Naranjo and Andreas Bertheussen did an exceptionally good job in these early days.

I understand there's also a way to communicate with protocol 7.00 over USB, even on the Prizm (I believe one can trigger this mode by launching the OS update function on the calc, because usually it just identifies itself as a mass storage device).

Yes, on my fx-9860-calculators I normally use the USB-port as serial device to communicate with a PC. Except for the Comm_Open-parameters, there is no difference to 3pin. On the Prizm I did not manage yet to establish such a serial connection via USB.

Another thing that would be interesting to look into is to how the screen receiver mode works. Using custom software on the computer, the screen receiving mode could be used to quickly (2 bytes per pixel, lots of pixels) dump data out of the Prizm over USB, including the whole flash, by copying it to the VRAM in pieces. The ability to send data back to the Prizm (for example key presses) would be even better.

If one would know, how to establish a serial communication via USB between Prizm and PC (like with the fx-9860-types), you could transfer any data using the Comm_***-functions very fast and convenient.

[gbl08ma Profile Website]

I think Casio just added the mass-storage functionality and made it override the old protocol 7.00 functions in the UI, but the old raw communication syscalls are almost certainly still there and work more or less the same as on the fx9860, because they are needed for initiating the OS update process and maybe for some screen receiver and projector modes.

USB is also much faster than 3 pin uart, even if just at 1.1 speeds.

[TeamFX Profile]

Another thing that would be interesting to look into is to how the screen receiver mode works. Using custom software on the computer, the screen receiving mode could be used to quickly (2 bytes per pixel, lots of pixels) dump data out of the Prizm over USB, including the whole flash, by copying it to the VRAM in pieces. The ability to send data back to the Prizm (for example key presses) would be even better.

If one would know, how to establish a serial communication via USB between Prizm and PC (like with the fx-9860-types), you could transfer any data using the Comm_***-functions very fast and convenient.

You know that I did this some time ago.

[SimonLothar]

You know that I did this some time ago.

Ouch! I think I will request our maintanance staff to have my long term memory checked, possibly increased. 128 KiB are not this much.
Now I promise to have a look.