I just noticed a really stupid mistake on my part.  I accidentally was checking for a right bracket "]" instead of a brace "}" for the pointers.  I just updated with the fixed file, so if you downloaded 0.2.2 before this post, you'll want to re-download it.

It Axe, you can do this:

:"prgmMYPROG"->Str1
:getcalc(Str1)->C
:{C-2}^r->S

Puts the size of the program in S.  Basically, the size bytes come right before the data.

EDIT: by the way, you cannot change the size of the program without some pretty advanced assembly.  You either have to append data to the end ,which might cause the program to shift around in ram and you'll need to get a new pointer right after, OR you can put the entire calculator in edit mode and add as much data as you want, but you have to keep track of a bunch of pointers.  Either way you need to make sure you update the new size manually after changing it.

The "Fix CODE" commands are Asm flags.  I only have 3 controllable flags right now, but I can always add more.  bcalls are way too low level since they often require registers for input, so you will have to do those with Asm(EFxxxx) where xxxx is the hex code (little endian).

EDIT:
MAJOR MINOR REVISION COMING SOON

I'm announcing this before the next version becasue there is going to be a very big change to how a lot of the commands work and I want to let everyone know if they need to modify their code to accommodate the change.  Let me first explain my reasoning:

Lets say you wrote "If A=5" (assume that A is 5 at this point).  What happens, is first, A is compared to 5.  If they are equal, it returns 1.  Then, it checks to see if the expressions is true, that is to say, that it is not zero.  So it checks if 1 = 0 which it is not, so it will execute the If block.  Now you might see a redundancy here.  A has to be compared to 5 and then the result has to be compared to 0.

EDIT:
I found out that I can not do this, its already pretty efficient here.  However, I do realize that 99% of the time, the logical "and" "or" and "xor" commands are used as Boolean "xor" "or" and "and".  Therefore, I will change them to this (3 bytes less).

Commands this will affect:
If
ReturnIf
While
Repeat
or
and
xor

What you have to change:

EDIT:
Nothing.  The only time you would ever have to modify your code is if you were using the "and" "or" or "xor" commands as low level byte operations instead of logical operations.  If you still need to do bit logic, I will be adding new commands for that.

Axe Parser
Beta 0.2.2

---

New Features:

• Min and Max operations
• Display numbers and ASCII characters anywhere
• Binary Numbers
• Import Pics as tile maps
• Huge update to auto-opts list

Changed:

• Fixed A LOT of bugs.
• Programs should be smaller due to auto-opts.

Edit: Fixed some more bugs

I've used 12*12 before, even though it was really a 16*16 with transparent edges.  8*16 and 16*8 are common as well.

Jerros, I don't think you have a clear understanding of how that assembly routine works.  First of all, drawing an 8x8 sprite fully clipped onto the buffer literally takes less than a millisecond.  You don't actually have to refresh the screen until you have finished drawing all the sprites.  Your layout should be something like this:

Loop:
<Draw Sprites>
<Refresh Screen>
<Pause For Timing>
<Handle Key Presses>
<Sprite Movement>
jp Loop

It sounds like you're pretty new to assembly.  You might want to start a little slower becasue you're trying to do some complicated things that are going to be very confusing without a lot of experience.

I use this one.  Its really basic, but its great for monochrome images and supports any size you want.

http://www.ticalc.org/archives/files/fileinfo/134/13415.html

I finally finished rewriting the entire math engine.  The code was getting way too messy and especially with the addition of signed and unsigned versions of math operations.  It was making it way too complicated to optimize the code.  The parser code is now a lot more organized, smaller, faster, and uses fewer variables.  In addition, nearly all of my example programs became a few bytes smaller from my increased auto-opt list.  In my game of life example, it actually shrunk by 9 bytes (1.3% reduction) without changing any code, simply by compiling with the newer version!  Everyone will most likely see small drops in the executable sizes.  These aren't the big optimizations though.  Those will eventually come when I get to look-ahead parsing.

I'm going to focus on some new commands now.  I might have it ready by late tonight, but I'm not sure.  Don't expect too many new things, I spent most of my time swatting bugs and cleaning the code so that future versions will be easier to write.