LOL!  I don't think anyone is going to make any axiom where all you have to do is type a single command to run a complete game for a simple reason: It would require them to actually make that entire game in pure assembly first!  If someone did make am entire game that complicated within the contest deadline, I would be very shocked!  If you are still trying to avoid that though, its very easy to check the source for things like that since Axioms would be part of their submitted "source" so I think this could be enforced with the rule that at least say... 70% of the size of their code must be native axe.  For example:  If the Axiom is 5kb and their executable is 6kb, then you know something is definitely suspicious about that.  But if the axiom is 1kb and their executable is 7kb, this seems like a fair usage of an Axiom.

Wow, this is a really dead-close poll!  Not sure what I'm going to do yet, I usually only make a change this large if there is overwhelming support for it.  And no, it doesn't affect compile time because axe has to figure out where to close the parenthesis (pop the stack) on its own already without them so it would take just as long.  This would only be a programmer convenience and wouldn't change anything at all about the compiling process or generated programs.  If you are extremely for it or against it, please state your lengthy opinions why this is either a terrible idea or an absolute necessity.

Another new feature I am adding is a new style of pointer referencing.  For any variable or static pointer you can now write {__+A} as A(__).  and {__*2+A}^r as A(__)^r.  Here, the variable A can also be a ram location like L1, a static pointer like Str1, and possibly a file object like Y1 if I can get that to work.  That means things like L1(7) means the same thing as in basic as it does in Axe; the 7th item in L1's memory.  I think this form will make pointers easier for beginners to understand and reduce pointer related errors.

randInt(min,max) for a range of numbers is definitely useful and I'll probably get to that in this release.  I have been working this whole week with little sleep to finish my python compiler project for class so I'm a little "compiled out" right now, but hopefully I'll get this all done soon.  My goal is to finish adding core features so that the next release after that will be 1.0.0 but we'll see what happens...

Haha!  Interesting bug, unintentional self-modifying code... And Runer, isn't that 2nd piece of code only 17 bytes?  That's only a 2 byte total increase in size.

That code looks like it should work.  But since its not, there is some problem and you need to do a little debugging to figure out what it is.  Some possibilities: r6 got modified somewhere else, maybe as a 6th argument?  P at some point incremented or decremented by a number that was not a multiple of 383?  P got set somewhere else unintentionally?  You could figure these out by textual runtime debugging like I suggested, that's my primary way of fixing bugs in Axe at least.

I'm with Builderboy on this one.  I can't replicate the error.  Just to be clear, what you're describing is that the amount of RAM displayed in the memory management menu before compiling is larger than after compiling when you have an error and scroll to it correct?  To help me debug this, I need more information about how you got there:

* What shell were you compiling for?
* By how much did the memory shrink?
* How large is the source code?
* Approximately how far down the program was the error located?

Axe doesn't chain hooks, it uses the Token hook exclusively.  I'm not sure how omnicalc uses the Token hook (which is Axe's only hook) so I can't say for sure what the problem might be.

Runer, how do you suggest I do the token replacement?  The first problem I had was that you have to know ahead of time what Axioms are being used in the program so it knows what to replace.  That can easily be solved with your first suggestion of always requiring the Axioms to come first, but this does remove a possible convenience, however its probably worth it.  The next problem is that for each token the Axioms have to be searched for in the symbol table to find their pointers, which could be costly with a large number of programs.  Then, when finally found, each Axiom would have to be scanned completely to find if the token matches by transversing the offset list (again, for each token).  So if you had 2 Axioms with 25 new commands each, and about 20 tokens on the screen, that's 40 symbol table searches + 1000 checks + the built in checks.  I could definitely see this causing lag in the scrolling.  There might be another way of caching the data in ram somewhere, and maybe setup a binary search, but this would greatly complicate things.  The token hook is only called when tokens are being printed and I don't want to use other hooks so its difficult to have some sort of "pre-parsing".  I am however still open to suggestions of what to name the rest of the custom override tokens.

Your other suggestion, If I'm reading this correctly, is a static offset to optimize doing ld hl,dynamic_ptr; ld de,offset; add hl,de; correct?  This might be an option in the future.  There are other useful features I can think of too, like adding the ability to create Axioms that take a label as their first argument, like how the current interrupt setup command works.

"Get" checks if a byte is trying to be sent first so it doesn't do the routine if there isn't.  Your test isn't actually reading anything so nothing is transferring which is why it appears so fast.  The last time I tested the speed, I was able to transfer the entire graph buffer in about 1.5 seconds I think, so that's somewhere near 500 bytes per second.