I tested thousands of times.. and I conclude there is mistakes with the link command Send() or Get or both. Normally, the value of received byte is only between 0 and 255, or it failed and the value is 65535. Now, sometimes I feel a bit is missing...
:.AXE
:.Initialisation of L1 values (lets try with 20 bytes)
:For(I,0,19)
:I→{L1+I}
:End
:.L2 is empty, we will put received bytes on the 20 first bytes of L2
:Fill(L2,20)
:
:.Lets try if we have 2 calcs
:Output(0,,"Synchronisation ...
:SYN()
:ClrHome
:
:.20 bytes are exchanged
:ECH(19
:.Normally the sum is 190...
:Output(0,,cumSum(L2,20)►Dec
:Pause 4000
:Return
:
:.Synchronisation routine
:Lbl SYN
:Repeat Get(+1
:Send(0,65535)
:ReturnIf getKey(15)
:End
:-1→B
:!If B
:Send(1,65535)
:End
:Return
:
:.Data exchange
:Lbl ECH
:.Check if there is again 2 calcs
:SYN()
:For(I,0,r1)
:!If B
:Send({L1+I},65535)
:GET()→{L2+I}
:Else
:GET()→{L2+I}
:Send({L1+I},65535)
:End
:End
:Return
:
:Lbl GET
:Repeat Get(+1→r2
:ReturnIf getKey(15)
:End
:Returnr2-1Look on wabbitemu all bytes pass easily, but on real calc it doesn't :

I tested with a 83+ and a 83+.fr, here my 83+ was everytimes under 190 while the 83+.fr reached 190 several times. After that I tested two 83+.fr (more recent) and it was several times around 190 to both. But each time it's random.


(sorry to my bad english.. :x )

EDIT : I've no problem on ti-connect with my calc (83+), so why it can't work perfectly ?

I'm guessing here, but did you use Fix 5?  Did you change it back?

Sorry Quigibo, I have a semi-bug report with Axe Fusion already. You may have already considered both of these and purposely left these out, but I'll throw these out there just in case.

If the Axe application is not found, you may want to consider doing a bit more than just displaying the "Axe required" string. First, I think it may be a good idea to perform a B_CALL(_HomeUp) and a B_CALL(_ClrScrnFull) before the display, or the message may pop up in very strange parts of the screen and possibly not even fully display. Second, it may be a good idea to have a B_CALL(_GetKeyRetOff) after the message appears, as when run by a shell, the message only appears for a split second before control is returned to the shell and the message is overwritten with the shell's UI. The user would probably be able to see the message with neither of these "bugs" fixed, but the question is whether 9 bytes is worth the cleaner appearance. I personally think it is worth it, because the lack of these calls may make Axe Fusion programs appear somewhat unprofessional, an issue which may bother some coders who like their programs to look clean.

I forgot to mention that for the new sprite routines, p_DrawSteal has to be changed to:
p_DrawSteal:
.db 2
pop ix
otherwise drawing sprites to arbitrary buffers doesn't work

Here's a bug that's my fault. The tokenhook.inc file that I suggested you include in the Axe download must've been some strange unfinished version that I accidentally uploaded, because it doesn't even assemble correctly without errors. I have re-uploaded a correct version: http://www.ticalc.org/archives/files/fileinfo/445/44517.html.

o_PushPop5 is commented out because I currently don't have enough support in the optimizer to allow this optimization.  It needs to be able to tell the difference between declared-static and unknown-static values to work.  It should only optimize if they are both declared, or both unknown, but not a mix of the 2.  Technically, this affects more than one of the optimizations, but this one in particular is easily found in practice while the other ones would not be (except in maybe extremely rare circumstances).  This needs to fixed eventually, but I will need to rewrite the optimizer.  For now, I leave it there to remind me.

As for the o_PushPop9 and o_PushPop11 I had a mistake in the optimizer code that I forgot to update after I added value replacement peepholes.  I fixed that error now.  Runer, in case you're interested, it was adding the "P" to JRZ(4,WriteToAsmR2P) in WriteToAsmED.  Thanks for the report