This happened again: Axe have a bug with generating appvar O.o
It gives me ERR:MEMORY even though appvar is only 48 bytes big O.o

Data(0,0,0,0,0,0,0,0,0,......)->A
GetCalc("appvMTEMP",48)->B
Copy(A,B,48

Axe has problems when the last of the compiled code in a program is targeted by the peephole optimizer. In this case, Axe is producing erroneous code because Copy(A,B,48 is the last bit of code in the program and it's targeted by the peephole optimizer. This can be avoided easily enough until it is fixed by putting some other code after it or turning off the peephole optimizer altogether by pressing ZOOM to compile instead of ENTER.

I know exactly what is causing that error.  It is as runner said, the peephole optimizer.  There is currently a bug where Axe confuses offsets with constants and is turning your code into exactly this:

Data(0,0,0,0,0,0,0,0,0,......)->A
GetCalc("appvMTEMP",)->B
Copy(A,B,48
The current offset in the code is 48 and you were using 48 at the same time to specify the size.  It also happens to be in a pattern that normally peephole optimizes.  So now its attempting to create an appvar with a size equal to the pointer which is a number around $9E00 which is over 40,000 bytes!  You can fix this temporarily as Runer said by using zoom compile or adding one more zero to your data.  Adding more code to the end wouldn't fix anything because there aren't any known bugs with ending code changing behavior to my knowledge.

I know exactly what is causing that error.  It is as runner said, the peephole optimizer.  There is currently a bug where Axe confuses offsets with constants and is turning your code into exactly this:

Code: [Select]

Data(0,0,0,0,0,0,0,0,0,......)->A
GetCalc("appvMTEMP",)->B
Copy(A,B,48
The current offset in the code is 48 and you were using 48 at the same time to specify the size.  It also happens to be in a pattern that normally peephole optimizes.  So now its attempting to create an appvar with a size equal to the pointer which is a number around $9E00 which is over 40,000 bytes!  You can fix this temporarily as Runer said by using zoom compile or adding one more zero to your data.  Adding more code to the end wouldn't fix anything because there aren't any known bugs with ending code changing behavior to my knowledge.

Uhh... I don't think that explains the code I'm looking at:

ld hl,Data000
ld (axv_A),hl
ld hl,Data001
push hl
ld hl,48 ;I'm still here
call p_NewVar
ld (axv_B),hl
ld hl,(axv_A)
push hl
ld hl,(axv_B)
push hl
ld hl,48
pop de
;Note the abrupt end

p_NewVar:
B_CALL(_EnoughMem)
pop hl
ex (sp),hl
jr c,__NewVarFail
push de
push hl
MOV9TOOP1()
B_CALL(_ChkFindSym)
jr c,__NewVarSkip
B_CALL(_DelVarArc)
__NewVarSkip:
pop hl
ld a,(hl)
MOV9TOOP1()
pop hl
push af
B_CALL(_CreateVar)
pop af
ex de,hl
and %00011111
ret z
cp CplxObj
ret z
inc hl
inc hl
ret
__NewVarFail:
ld hl,0
ret
__NewVarEnd:

Data000:
.block 48

Data001:
.db AppVarObj,"MTEMP",0


Ah, I guess that could do it. A very crazy bug indeed.

For the output command, the column is in the range 0-15 and the row is in the range 0-7.
In your code, I ranges from 1 to 8, so everywhere you have I, you need I-1 (unless you want to use {L₁+0} for something else).
For(I,1,8)
rand^16→{I-1+L₁}
End
For(I,1,8)
Output({I-1+L₁},I-1,"∗")
End
Pause 5000

Edit:
The fact that you have 0→I before For(I,1,8) makes me think that you are trying to make I range from 0 to 7. However, For(I,1,8) starts off by storing 1 to I, causing the 0→I statement to be useless. Instead you may want For(I,0,7).

According to this, Axe uses some SMC.  I think it's probably the programmer's fault, but I figured I'd post this here so it could be looked into.