The next version has already taken care of getting 'illegal' characters into strings using standard tokens.

Let me just explain signed vs unsigned so it doesn't confuse anyone.  All the numbers are unsigned meaning they represent a number between 0 and 65535.  Negative numbers act just like the regular numbers counted backwards instead of forwards, that is -1 is really 65535, -2 is really 65534, etc.  This allows normal subtraction and addition with negative numbers that everyone is used to.

That's all well and good until you have a statement like -1<1.  That would actually be false since 65535 is not less than 1.  You can get around this by doing a 'signed comparison' which is what calc84maniac is talking about.  The limitations with signed comparison is that your numbers can only be half the size, that is -32768 to 32767.  So you would not be able to use the signed comparison (and get the correct answer) if the number is too large or too small.

This is an good idea to implement, but I think I would want it more intuitive than a question mark.  Maybe something like -1<<1 would be better?  Repeating any operation twice will do the signed version of the operation.  So -4<<2 equals 1 and -2**8 would equal -16.

Oh and by the way, bitwise and Boolean or are identical, there is no reason to separate the 2.

But shouldn't << be shift left or something?

Also, bitwise and boolean OR are different.
5 | 2 = 7
5 || 2 = 1 (and the "2" expression isn't evaluated because 5 is non-zero)

I have a suggestion for the parser. You should have a character (I'm thinking "?") that acts as an operation modifier, for things that can possibly have more than one use. For example, "?>" could be used as signed compare, and "? or " would be bit-wise or, while " or " would be boolean or. It could also be used in strings as an escape character, for example ?" would put a quotation mark in the string and ?X41 would put the character 0x41 (or "A")

I just noticed, when Ash is auto-moved up when he tries to leave, he's still facing down. (unless down/up look the same and I'm crazy)

I thought about putting an easter egg in Chip's Challenge but I never got around to it.

I think the only way to speed up anything related to text display is to have a custom font routine, though. I am not sure how easy it would be to implement such thing for Axe parser, especially for home screen stuff, where it might be impossible.

I think the problem here is that the output ASM program has to work on its own, so all the font data and routines would be unnecessary overhead

Sorry to double post, but I've just started to add the "Output()" feature and I'd like to get some feedback on it.

I know that native BASIC uses Output(y,x) but I much prefer the form of Ouput(x,y).  Should I keep it the old way to less confuse people transitioning from BASIC to Axe, or should I change it to (x,y) so that its more consistent with "Text(" "Pt-On(" and the other drawing commands?

I think you should keep the old way, but start counting at 0 instead of 1.

Apparently you can't break at all, so it doesn't matter. But Quigibo, if you save the stack pointer somewhere at the beginning of execution, it should be no problem (this method is used quite a bit in asm programs iirc)