Hmm... the problem with the new constants runs deeper than I thought.  The normal static pointers optimize with the assumption they will eventually be replaced by a value within the normal pointer range during the second pass since their actual value is unknown during the first pass.  Constants on the other hand ARE known on the first pass and this replacement model doesn't work in that case since the value is never updated during the next pass.  Therefore, this requires me to modify some very core routines.

So because I'll be rewriting this part anyway, I might finally add a request from a while ago which was to allow static variables to be used before they're defined.  So you can put data at the end of your program instead of only the beginning.  This has some drawbacks however:  First, it will be harder to debug errors.  Since the compiler won't know if a symbol is defined until the end of the source, it would not be able to scroll to the specific place it was used and would instead have to just display "Missing: Str1A" for example, just like labels.  Secondly, it uses up an extra symbol in the symbol table for each use until its finally defined.  As an example of this, here is the symbol count for this program:

:.TEST
:Str1       ;1 Symbol
:Str1       ;2 Symbols
:Str1       ;3 Symbols
:"H"->Str1  ;Now defined, so 1 symbol from now on
:Str1       ;1 Symbol
:Str1       ;1 Symbol
:Str1       ;1 Symbol
I'm guessing this will result in a lot of "MAX SYMBOLS" errors if people start using this too much since you only get 153 symbols to use.  What are everyone's thoughts about this?  Is it worth the extra effort?  I feel like most people who would use this would want to use it on large programs in which case they would probably run out of symbols anyway and be forced to move them back on top, which is a very annoying process.

Not Axe's "B" the assembly "b".  The way pause works is it runs a loop which executes b number of times, which is then repeated pause number of times.  The thing is, after each loop, b is reset to 256.  But since b is not set to anything the first time, it could be any number.  So each cycle of "Pause 5" could look something like this:

loop 100
loop 256
loop 256
loop 256
loop 256

So the first iteration could be any random number of cycles.  But you generally never need to worry about that because you don't normally call pause with such low numbers.

I think I'll release a new version soon just to fix bugs again.

Yes, I'm using spasm, I'll keep the must be in ram thing in mind, and what token should I use then?

Any unused token is fine, I definitely recommend tokens on the [vars] "Zoom..." menu when possible since those are guaranteed no to used by Axe in any future update.  Also, only the initial program has to be in ram.  Once its converted to an appvar, it can be in ram or archive.  You could bypass the conversion yourself actually if you change one of the bytes in the 8xp file, but that's more complicated.

Hmmm, I did forget to mention that very big interrupt routines (such as those with Dispgraph) can be problems, so a huge routine should start with FnOff and end with FnOn.

Axe automatically adds this for you.  When you're in an interrupt routine, the interrupts are turned off until it returns to the rest of the main program.  All DispGraph commands are interrupt safe I believe.

Compiled axe programs are already asm. 

Hot_Dog, why do you need the AxesOff?  Couldn't you do something similar to what I do with the app header where you call the main program as a subroutine.  Something like this:

AxesOn:
  #asm code here
  call mainprog
AxesOff:
  #asm code here
  ret
MainProg:

That way you only need one command at the beginning and the users could use ret just like they're used to.  I don't know how the source looks though, so maybe there is something preventing this I don't know about?  Anyway, nice job!

Am I the only one who pronounces jr as "jur"?  I think ldir as "elder" is normal.  But a lot of these I instinctively pronounce as what they stand for.  Like I generally say "compare" for cp and "rotate right" for rr, etc. instead of reading the actual letters.

I found the bug to the big endian reading/writing.  It just happened this version so it wasn't around before.  Its because I added the No-Op command which uses the illegal command size 0.  A zero normally signifies an immediate replacement when found right after a command and the no-op was right after the swap command so it was trying to replace pars of the swap command with the last thing in "ans" which would be the constant.  So I've moved the no-op operation to the top of the file instead so that its never trailing another command.  I realize I could just slap on the label to any zero byte in the file, but I'm trying to keep it readable.