Bug Reports

[Runer112]

I knew there was a bug in this somewhere...

[kindermoumoute]

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...

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52

:.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-1

Look on wabbitemu all bytes pass easily, but on real calc it doesn't :

[Quigibo]

What were the 2 models of calculator?  I know in particular, Nspire calculators are not as precise in their emulation timing.

[kindermoumoute]

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 ?

[Freyaday]

I found a weird one.
I compiled Nymless into its app with 1.0.5 on an 83(+)
Nymless works fine. The weirdness occurs when you exit:
After you exit Nymless, any text written with the small font is written to the graph screen instead of the current screen, making the Plot123 invisible on the Y= screen invisible, among other things (the table, the plot screen itself). It isn't fixed by turning it off and on. Rather, it is fixed by activating Trace. Also, the app doesn't clear the graph screen when exiting and it isn't marked dirty. None of the misplaced small font-writing marks it dirty either.

[Darl181]

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

[Freyaday]

Uhhhhhhh....
Bad Frey, Bad!

* Freyaday smacks himself

[Runer112]

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.

[Quigibo]

Hmm, you bring up a good point, I was only testing it on the homescreen before.  I will try to make this look cleaner at a low byte cost.

[jacobly]

I forgot to mention that for the new sprite routines, p_DrawSteal has to be changed to:

Code: Select All | Copy To Clipboard

1 2 3 4

p_DrawSteal: .db 2 pop ix

otherwise drawing sprites to arbitrary buffers doesn't work

[Darl181]

Also, I've had a few problems with the instant goto.  I'd get err:parenthesis and goto.  Editing is fine, but once I quit some program or another will sometimes have an edited name (ie one time the archived program "SDOTRUN2" became SDOTRU►2").  thepenguin's archive cleaner fixes it, btw, but it's still kind of concerning..

This just happened again in Axe 1.1.1.  I can't get wabbitemu to replicate it, but it changed prgmSPRITES to prgmSPRITE► .  Evidently it's not just Err:Parenthesis, this time it happened on an Err:missing program.
The program whose name was corrupted was in the archive, btw.  I think it was the previous time, too.

Edit:  Just noticed this corruption is six letters into the program name as well.

Just happened again in 1.1.2
It switched around the last letter this time, so ATST1SRC turned into ATST1SR► .  It might be worth saying this is/was the first program on the program list, not sure about in the VAT.
I got a bit inquisitive and tried it again, so it would corrupt the same program twice: it didn't change the name the second time (or maybe re-wrote the first change?) but changed the contents of the program to a bunch of junk which gave Err:Bad Address when viewed in the program editor.  The archive fixer fixed the second part, but like previously the name wasn't fixed.

[Runer112]

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.

[Runer112]

o_PushPop9 and o_PushPop11 are not working correctly. The ld bc,($0000) in both of them isn't being replaced, resulting in code such as this not functioning properly.

Also, why is o_PushPop5 commented out?

[Quigibo]

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

[thepenguin77]

During an API call, if an error during compiling occurs and you decide to scroll to the error, the editor is not opened properly. At first, all looks fine, but when you try to move, you are actually in the kPrgm menu.

Edit:
   Also, runer says you should make an option on what to do in the case of an error. A = 0 would scroll to the error and A = 1 would return the error offset in HL. (Or something similar)

Edit2:
   This would be useful for programs that need to deallocate themselves in the event of a scroll or for programs that have their own implementation of the program editor.