Yeah, nobody ever really made use of that feature.

This page seems to have some stuff related to those commands: http://wikiti.brandonw.net/index.php?title=83Plus:Hooks:9B80

Yeah, I'm definitely going to be working on the grayscale commands this version.  What that means, is that every drawing command will eventually be able to draw to either buffer.  So if you want to draw a grayscale sprite, you first draw the black part to the first buffer and then the gray part to the second buffer.  Like this:

:Pt-On(X,Y,Pic1)
:Pt-On(X,Y,Pic2)^r

However, just to save space, I am going to have the grayscale drawing and the regular drawing use the same routine, but just jump into the code with a different buffer.  This will unfortunately make the current drawing routines about 5 bytes larger even when you don't use grayscale, but it makes it much smaller when you do need it.  BUT, I might also share all the different sprite drawing routines with each other so that might actually reduce the size if you use different drawing methods in the same program.  I'm not 100% sure what is going to happen, but I will try to make them take the least amount of space possible.

I am also going to test a very limited and special case of look-ahead parsing for pointers.  I am estimating it will reduce executable size by about 2-5% in programs that use pointers frequently.

I noticed you added conversion from binary to integer with 0.2.2, which is getting closer to bit manipulation, but are you planning to release more direct bit manipulation commands? Such as commands that get or set the nth bit of a byte? If not just say so, so I'll know to just make commands for that myself.

Mhmm I see, I guess it might be best maybe, and more flexible for the programmer, too. It's good to give him freedom, otherwise the command may not be used very much.

Not much of a feature addition request, more of a feature preservation request:

At the moment, Axe Parser compiled programs will run on both 6 and 15 MHz calcs at once. Even if you use the Full command, your program will still run on a 6 MHz calc fine. It will just run at different speed between each calc speeds.

I would like this cross-compatibility to not be removed in future versions of Axe, else it will suck to be forced to update two versions of your programs all the time because one crashes on 15 MHz calcs and the other crashes on 6 MHz calcs.

Same goes for TI-Nspire and the 48KB RAM TI-84+ calcs, altough I think compatibility with those was planned to be kept.

Flags support in Axe Parser could bring advantages in any circumstance? In assembly the use of iy is expensive, so I doubt it is advantageous.

I wish we had a small font TI-BASIC editor on calculator...

Axe Parser syntax takes some time to get used too because of using the TI-BASIC tokens and tokens are not always very descriptive. I imagine it is getting harder to choose the tokens.