The data packet we discuss actually, is the machine count process (with eventually a sync process) I call this frame type 1
As soon as all the machines have responded correctly, there is a reconfiguration of the recv-send address and recv-send size. This allows to receive-send the real datas packet game. I call this frame type 2
ie:
for frame type1 dirtdvls (2cabs)
send off=0xf000 send size=0x10 recv off=0xf010 recv size=0x18
for frame type2 dirtdvls (2cabs) and raw data before treatment (see code)
send off=0x0001 send size=0x801c recv off=0x000f recv size=0x001c
for frame type1 harley (2cabs)
send off=0x0080 send size=0x07 recv off=0x0090 recv size=0x0b
for frame type2 harley (2cabs) and raw data before treatment (see code)
send off=0x0001 send size=0x003a recv off=0x0009 recv size=0xff37
for frame type1 lemans (2cabs)
send off=0xf000 (M) send size=0x04 recv off=0xf010 recv size=0x08
send off=0xf010 (S)
for frame type2 lemans (2cabs)
unknown for now but certainly this
send off=0x0001 send size=0x8??? recv off=0xc00d recv size=0x????
Maybe each client doesn't need to send the whole buffer? Just sends data from its slot.
this is entirely possible, but this also means each game work differently...
I do not put my hand to the fire saying packet will be terminated by 0xff and we don't care, because all is based on packet/slot size
I think it's only predetermined data with only 2-3 bytes of real datas in the case of type1 frame
this is an example of type1 frame exchange between 2 cabs(scud, skichamp and some others) aka machine count frame exchange
the values of 0x90 and 0x68 are fixed
M : 90 00 00 68 00 00 00
S : 90 00 00 68 01 00 01
M : 90 00 09 68 00 00 00
S : 90 00 09 68 01 00 01
M : 90 00 ec 68 00 01 00
S : 90 00 ec 68 01 01 01
the 0xff for lemans would certainly acts as 0x90 and 0x68 for the other games