Protocol 7.00 - Error 0x04 and tests

[cakeisalie5 Profile Website]

Yup, the complete list is model.txt, but it hasn't got the last characters sent by Protocol 7.00 (and I can't deduce them as "it seems to be inconsistent among all models..."). So thanks, I'll use these! Can I have the OS ones too please ?

(here's the current list of environments)
(and I've got the same with my SH4 calculator. they are shameless xD)

[TeamFX Profile]

Hardware ID (8-chars identifier, like "Gy363007")

My Graph 35+ E returns "Gy36200F" via LINK/receive...
I have no clue what that last character means.

[cakeisalie5 Profile Website]

Well in fact, some sort of pattern comes out with the codes I've got. It's not a complete list, but here's what I found for now :

https://bible.planet-casio.com/cakeisal ... odels.html

(topic on planète casio)

[critor Profile]

Hardware ID (8-chars identifier, like "Gy363007")

My Graph 35+ E returns "Gy36200F" via LINK/receive...
I have no clue what that last character means.

To make things simple, in receive mode :
Gyxxx006 = SH3
Gyxxx007 = SH4 without exam LED / SH4 with exam LED and OS 2.02-2.04
Gyxxx00F = SH4 with exam LED and OS 2.05-2.09
Gy362xxx = OS Graph 35+/fx-9750GII
Gy363xxx = OS Graph 75/95//fx-9860GII

Tested on Graph 35+SH3, Graph 35+SH4, Graph 35+E, Graph 95 SH3 and Graph 75+E with all compatible OS images available.

[cakeisalie5 Profile Website]

By the way, what is the maximum (normal) command argument size the OS accepts? The encoding means it can go to 256, but as the typical maximum is something around 16, does LINK accept command arguments above this? (or, worse, does this cause a buffer overflow?)

[SimonLothar]

By the way, what is the maximum (normal) command argument size the OS accepts? The encoding means it can go to 256, but as the typical maximum is something around 16, does LINK accept command arguments above this? (or, worse, does this cause a buffer overflow?)

If you mean the command parameters D1..D6 (fxReverse, chapter 4.3.1), the maximum size for every single parameter is 0xFF indeed. Theoretically.
But the responsibility for interpreting the various parameter sets lies at the specific protocol 7.00 command.
Concering the basic transfer buffers the max. transmit buffer size is 256 bytes and the max. receive buffer size is 1024 bytes.
There is no OS-defined command, which needs arguments, which could possibly violate these limits.

If you want to implement your own commands, you have to heed for the size of the basic transfer buffers.
There is a risk to overrun the receive buffer, if you send more than 1024 bytes without a software handshake (F. i. ACK-packet) between.

[cakeisalie5 Profile Website]

Sorry for not being very active here, I'm struggling to finish writing libcasio as fast as I can, while I can. I'm still trying to make libcasio (libp7 and libg1m, protocols and file formats management, are being merged into this library), and I'm struggling a little.

I am currently making a stream abstraction implementation above Protocol 7.00 data flow, and was wondering: how do calculators react to unordered data packets? Is there a way to interrupt the current flow without interrupting the hole communication, in "basic" Protocol 7.00 (I've seen the "modified" Protocol 7.00 fxRemote's update.exe uses)? In case of unordered data packets, should a server accept it and store it, or interrupt the data flow/communication? Thanks in advance!

[SimonLothar]

..In case of unordered data packets, should a server accept it and store it, or interrupt the data flow/communication?

I do not think, that you have to support non-consecutive data packets.