So if we want to include these commands in our games, should we turn off interups before these commands and then turn them back on? 

Ah, thats true good to know

I believe that it was mentioned before, but just in case, Using a timer as an interrupt and utilizing the counter to update the screen in steady intervals.

This is just a general warning because I didn't realize how badly I screwed up the text command in the past.

I completely rewrote all of the Text( commands.  They now have the exact same syntax as Output( meaning you can display more than one thing per use like Text(2,3,"Hello"," World:",A>Dec) for instance.  It also means you can define just the coordinates Text(2,3) or a compressed coordinate Text(3*256+2).  The only problem is that I had to redefine the existing "draw text here" command because that was formatted the same way, but it was a relatively new command so hopefully no one has gotten too comfortable with it.  To replace it, I will add a new command called "Text " with a space and it will act exactly like "Disp " but for small text.  So to reiterate;

Disp     <=> Text
Output() <=> Text()

They can be used interchangeably and have exactly the same syntax.

The thing I was talking about when I said the old text routines were screwed up is that they were very inefficient and I had 2 sets of routines, one for text anywhere and one for text at the current pen location.  Also, the actual coding of the text parsing was quite messy.  I combined everything to a single, smaller routine and organized the code and commands to make it more readable.  I was using ztrumpet's spider game as an example and it shrunk by almost 100 bytes and text wasn't even a part of that game.

Hopefully I will get one more major optimization before the next release because I had a revelation yesterday.  I got to thinking, what's the difference between data and subroutines?  There isn't any!  So I can mix in all the subroutines with the data as if it was data without having to make a 3rd pass which can save a lot of bytes in the executable.  The only side effect to this is that if you are defining 2 blocks of data that are split by a command that uses a subroutine, then the 2 pieces of data are no longer consecutive in memory.  I doubt anyone will have a problem with this though because its always good practice to define consecutive data together without interruptions and I've never seen anyone do it wrong in their code.

Anyway, this will be the first Axe release since the 0.2.x versions that features major optimizations that will reduce the size of just about ALL programs.

Hopefully I will get one more major optimization before the next release because I had a revelation yesterday.  I got to thinking, what's the difference between data and subroutines?  There isn't any!  So I can mix in all the subroutines with the data as if it was data without having to make a 3rd pass which can save a lot of bytes in the executable.  The only side effect to this is that if you are defining 2 blocks of data that are split by a command that uses a subroutine, then the 2 pieces of data are no longer consecutive in memory.  I doubt anyone will have a problem with this though because its always good practice to define consecutive data together without interruptions and I've never seen anyone do it wrong in their code.

Great work Quigibo.

It affects somewhat disassembly but will be rare someone hand optimize Axe Parser. Maybe some curious will like to learn a bit of assembly from Axe Parser like some guys do with C and assembly.

That's cool!  Thanks for everything Quigibo, and I can't wait for the next update of Axe!

Does 0.4.0 contain any syntax changes that would render old programs useless?

Here. I think he uses this exact picture in the zip as well. It's the same as the xlib and Celtic keycodes.