why transfering 128 '00' from SIO give me checksum '01'?

[xt5]

hi,

 

It seems very strange that transfering plenty of '00' with the SIO function at E459h (to a PC as peripheral) give me a checksum of '01', all other values gives me correct checksum except this case.

 

I've read the SIO specification (http://ftp.pigwa.net/stuff/collections/nir_dary_cds/Tech%2520Info/SIOSPECS.PDF) and it don't mention this case, nor I've read of someone having the same problem.

Edited May 23, 2009 by xt5

[Rybags]

Strange. Which machine/OS ?

 

How do you know this to be the case. Being reported that way by APE? (I assume here that APE's Checksum reporting is on the data, not command frames)

[xt5]

Strange. Which machine/OS ?

 

How do you know this to be the case. Being reported that way by APE? (I assume here that APE's Checksum reporting is on the data, not command frames)

 

nopes, it is not APE, is my own software on win32 but I've used it a lot and transfer tons of upstream/downstream data and the only case when the atari generate this bad checksum is with the payload are all zeros. seems I've lot of bug tracking on this, maybe have to hook a logic analyzer to discard any software special condition

[Rybags]

I can't see how such a thing can happen.

 

SIO generates the checksum dynamically, so the "history" of what has already been sent in a block is largely irrelevant.

[xt5]

I can't see how such a thing can happen.

 

me too. that is why I want to know if somebody got similar problems in this forum.

 

my complete setup is the following:

-MS3303H UART -> USB bridge with DSR sensing the SIO Command line.

-Windows XP 32bits with Prolific drive (MS3303H is a Prolific clone or rebranding)

 

the problem is the follow:

when I send a payload using the E459h handler with all the data being zero, int the received data on the PC using the Windows Communication API the last byte (ie: the byte used for checksum) instead of be read as 00 is read has 01.

 

I'm really sure that my code is OK because I already transfer a lot of data up/downstream and always get the last byte ok, except in the situation described above.

 

for example this is the data captured with the analyzer of a payload of 12 zeros

as you can see it looks OK and the actual data are zeros, but look why I get in the data:

****bad checksum***

00 00 00 00 00 00 00 00 00 00 00 01
--------
ACK
ERROR

 

so if someone had experimented similar behavior, please tell me if you know some workaround

 

 

I've tracked down where the problem is, it is in some part of the windows com port management but it seems it will take me long fix to it

[Rybags]

Are you sure it's not something like a delay that runs too long on the last byte (on the PC side).

 

In theory, such a case could cause a situation where the data (00) provides a valid Start bit, and the Stop bit would be misread as part of the data.

 

I guess another thing to try is just send a similar payload and see what APE reports. A quick check of the OS Source (old 800) reveals that the Checksum appears to be cleared at the start of any send/receive operation, even if it's a case where no checksum is expected (ie waiting for Complete), so that makes things a little harder to verify.