Ok. I can't post more, and I don't think it will help that much. The executable is now about 4k large and compiled to axe fusion atm. I will change that to an App because I will never be able to be under the 8k limit. It uses a lot of Filling/Copying for fast drawing on parts of the screen and the whole data is stored in L1 and L2 if that helps.The rest is just very standard axe stuff.

The only reason inData( would return the index of the 0, is if you were searching for 0.

Edit: If you wanted 0 if byte is 0, you could do BYTE?inData(,PTR).
Also, I can't help but mention that inData(BYTE,PTR)-29??0,+29 optimizes to inData(BYTE,PTR)-29?+29.

Edit 2: Alternatively, if BYTE can not be 255, you can do inData(BYTE+1,PTR), where every byte in PTR has been incremented by 1.

Here's a bug that seems to have plagued Stefan Bauwens in the recent contest. It boils down to these three lines of code:

Buff(54)→°CA
#Realloc(°CA)
°A-2→°CE

The issue appears to be that, during the first pass, the A-theta variables haven't been assigned their proper addresses because °CA is not yet known. This then results in °CE being defined with a false value. I would say the bug isn't that °CE is defined with the incorrect value, but that an error isn't thrown. Pointers to variables should not be allowed to be used in constant definitions.

This has been plaguing me for a while.
Nymless crashes when you win, but only if compiled in 1.1.2
I caught it in Wabbit though.
Everything is in the .zip file.

Spot the problem!

p_TextStrApp:
.db __TextStrAppEnd-$-1
__TextStrAppLoop:
ld a,(hl)
or a
ret z
inc hl
B_CALL(_VPutMap)
jr nc,__TextStrAppLoop
__TextStrAppEnd:


A minor interface bug/optimization: the numbers for size continue to update after the first pass.

This is the effect of neither the OS nor Axe properly handling lists and matrices when creating arbitrary variables. Lists and matrices don't have the normal 2-byte size header that programs and appvars do; lists have a 2-byte header with the number of 9-byte elements, and matrices have two 1-byte entries for number of elements in each dimension. However, the arbitrary variable creation B_CALL doesn't handle lists or matrices in any special way, so the OS only allocates as many bytes as the size argument you pass to it and writes that value to the variable header. So GetCalc("L₁",10) would cause the OS to allocate 10 bytes in RAM (+2 bytes for the header) and write $000A to the header. However, after it's created, if the OS subsequently looks at it, it will think it's a list with 10 elements, and thus much larger. Deleting this will result in deleting more memory than was allocated, causing your crash.

A special case for lists and matrices could be added to Axe, but I think that would add too much size for such rarely-created variable types. You can correct it manually yourself fairly easily though, like this:

!If GetCalc("L₂",N*9)→L
.Error
End
N→{L-2}ʳ

Or, optimized:
EDIT: calc84maniac says this may be unsafe, so for the costs of 2 bytes, perhaps just skip it.

!If N→{GetCalc("L₂",N*9)→L-2}ʳ+1
.Error
End