Yes, there are going to be some special formats.  I am still working on them right now, but I can give you a little preview.

First of all, each axiom you add will need a header to indicate the size of the axiom, the type of routine (inline or subroutine), the shells its compatible for, any variation to the structure (like ending in ^r or having the "stored to" format), the number of arguments the routine takes, etc.

After the header, its just regular assembly.  However, there are some convenient differences.  If you use any form of absolute jump or call with an address less than $4000, it will treat the jump as a relative jump instead of an absolute one by replacing the value.  That way, you can preceded any axiom with .org $0 and then all the absolute jumps and calls will work.  Also, numbers between $3FFF and $3F00 are special keywords for "AxeCalls" which will be replaced by the built in routines.  These aren't numbers you have to memorize, the axiom include file will come with all of these predefined for you.

In addition to defining the AxeCalls, the include file will also define the location of all the variables, free-ram locations, files, and other values of interest.

I like it! Question: how would arguments be accessed by the Axiom? EXAMPLE: pretend I have an axiom call: testcall(A,B,C+1). Where are the resulting values stored so that I could axess them from the ASM code (registers,etc)?

Arguments are stored in the stack except the last argument which is in hl.

Qwerty, I'm not sure what you mean.   If you're asking if you can make your own block statements with axioms, that will not be possible with the current axe syntax (using "End"), but I'm sure you could invent your own syntax for it with some hackish code by making a separate ending block routine.  Although debugging would be a little difficult since they would not be detected as block errors if there were one.

  If you're asking if you can make your own block statements with axioms, that will not be possible with the current axe syntax (using "End"), but I'm sure you could invent your own syntax for it with some hackish code by making a separate ending block routine.  Although debugging would be a little difficult since they would not be detected as block errors if there were one.

Excellent. There are plenty of unused TI-OS commands that could be used as "End" statements. What I'm planning won't have any internal code blocks, so all I really need is one "End" statement.

Unfortunately, due to the way the token hook works, it would be virtually impossible to add custom token replacements.  In order for that to work, every token you type in the editor would have to scan the entire program for the Axiom() keyword, look in that file, compare against all the replaceable tokens, and then copy the new value.  This would be way too much of a delay and scrolling would be really sluggish.

My compromise is to provide a bunch of generically sounding token names that are unused by the axe language itself in hopes that they will fit into the axioms.  I will have a poll/thread for suggestions next week when I prepare for the next update, but to give you some examples I have now: Draw1() Draw2() Draw3() Setup() Move() Load() Save() New() Del() and of course in addition to these you have all the unused OS tokens.

That's possible, but it would complicate things a bit becasue there would need to be an "installation" process when adding new axioms.  There could also be conflicts between multiple axioms and the vat would still need to be searched for the information file every token which would still slow it down considerably.

Unfortunately, due to the way the token hook works, it would be virtually impossible to add custom token replacements.  In order for that to work, every token you type in the editor would have to scan the entire program for the Axiom() keyword, look in that file, compare against all the replaceable tokens, and then copy the new value.  This would be way too much of a delay and scrolling would be really sluggish.

That's why my suggestion was to force the user to include all Axiom includes on the line immediately following the header. That way, you would only need to fully reload the custom token set when the user modifies the second line, and otherwise just use the modified token set like usual during normal editing. Although now that I think of it, it may be difficult to target changes in only one line of the program. An easier alternative would be to only scan for Axioms and load token replacements upon opening the program source, and not during any subsequent editing. If the user adds another Axiom into their program's source, it should be simple enough for them to quit and reopen the program to continue editing with the updated token replacements.