Runner, the one I made is much smaller than the one from WikiTI:

p_DispHex:
ld b,4
__DispHexLoop:
xor a
add hl,hl
rla
add hl,hl
rla
add hl,hl
rla
add hl,hl
rla
add a,$90
daa
adc a,$40
daa
B_CALL(_PutC)
djnz __DispHexLoop
ret
It would be about 8 bytes larger to save it to a buffer.  The syntax wouldn't really work well though because axe would throw a fit if you tried to do Disp A►Hex->B for instance since the display routine looks for commas.  You would have to do some hackish code by putting the store on the line after it or using the address of the buffer directly.  But I guess if this is a conversion command rather than a display command this could be allowed... and then I would only need one routine for both display and text.  That might actually work.   I will have to see if I can make that more consistent with the other display format commands because that does sound convenient.

Builderboy.  I really want to but I'm afraid it will break too much compatibility with current Axe programs.  For instance:

:A+1->A
:If A=10
:->A
:End

This code increments A and if it goes above 10 rests it back to 1.  Here you are using the fact that the result of the if expression is a one if it ends up going inside the block.  It would be impossible for me to tell if the next expression is going to use the result of the if expression or not.

NINJA'D!

Not really, I'm already using 6*2 = 12 for the r1-r6 variables, 10*3 = 30 for the Y0-Y9 files, 2 for the random seed, and 8 for the sprite buffer. That totals 52 bytes so I really only have 12 bytes left

Edit: Also, I added >Hex finally

As much as I would like to do OOP, there just simply aren't enough resources on the calculator to handle all the overhead that would take in the parser.

I finally moved the default location of the variables to the end of L1 instead of the beginning and I'm in the process of writing the #Realloc() routine to move them anywhere else.  I decided to make all the compiler instructions have the '#' prefix so they don't get confused with actual commands.  So far, the only other token that has changed is "#Axiom()" but "#Icon()" will be coming soon and I'm pretty sure you can guess what that does

Another thing I noticed that I can't believe I didn't see before was to move the random seed away from the variables and into the hidden buffer (the one I'm using for r1-r6, files and other smaller things).  This expands the usable memory in L1 by 2 extra bytes!  It was actually kind of a necessity rather than a choice though because the Rand routine uses a fixed location to get the seed.  If the variables included the seed and then got reallocated, the Rand routine would no longer be looking at the correct location so you could get glitches if you tried to use all of L1 for something.  So it was a win-win to move it.

Yeah, that's supposed to happen.  Its TI's routine not mine, they don't do clipping like mine do.

The statistics would be different if you assume that A and B are non-Boolean.  In that case you have extra clock cycles for the not equals zero operations which might actually make it always faster to do the 2 separate statements regardless of probability.  But then again, realistically in programs, there is likely to be a mix of operations so I would include in that calculation.

If A__op__
  If B__op__
    Do stuff
  End
End
If A__op__ and (B__op__)
  Do stuff
End
In this case, assuming the previous numbers were correct, there is a difference of
    * A is false: 34 t-states + ops
    * A is true: 68 t-states + ops

Against:
    * Always: 87 t-states + ops

So you should always short circuit if you're looking for a speed optimization (assuming non-Boolean), but the second is smaller I think.

Recursive subroutines are great and often reduce the size of the program a lot.  The drawback is that they are generally a little slower and there is a limit to how many nested subroutines and pushed variables you can have before you get a stack overflow which crashes the calc.

I'm rewriting the line drawing routine.  So far, its about the same size as the original, except its at least twice as fast and can be drawn to ANY buffer.