Just making sure you weren't going through the whole load like "ld hl,address \ ld a,(hl) \ inc hl \ ld h,(hl) \ ld l,a" like you have to do for non-constant loads.

What are the planned new features (or optimizations/improvements) for the next version, by the way?

Ok, I forgot what it was though I know you were planning to try implementing something to check for possible optimizations by scanning through the code in advance when compiling, but I was not sure for which version it was planned.

EDIT Btw, I noticed that the 3 level grayscale command still works fine even if you forget to set the program to 6 MHz before running the command. I heard before that garbage would be displayed instead starting on Axe 0.2.3. Did you change your mind about the way the commands would work finally?

I am asking since I just compiled my Tunnel clone with Axe Parser 0.2.5 and the game still run without any glitches on my Nspire

It won't glitch on the Nspire or an emulator because they don't need the LCD delays.  But all the hardware is different and some LCD drives are slower than others and vary widely with different models.  Even my own calculator seems to have slightly different timing each time I use it based on the grayscale patterns I receive on what is usually perfect gray (possibly a temperature dependence?), so I would highly recommend switching into 6MHz mode during any grayscale displaying even if it works for your model.

EDIT: You should be able to read backwards into the header with a program or appvar header.  But if you're familiar with assembly, you'll know that the header data depends on the size of the program name and is in a weird backwards order I think (or is that the symbol table entry I'm thinking of).

Question: Was SortA() and SortD() implemented yet?

SortA(PTR,SIZE).

It just makes things uniform.

Okay, I checked the doc again, and you're right, there is NO header at the variable's data.  There is only the size field.  All the header data is in the symbol table (and each header there is not a fixed size by the way).

Maybe there should be a GetCalc()r command that returns the VAT pointer instead of the data pointer.