Wow!  That's amazing!  I'm surprised you were able to get the 8x8 sprites so close to the original!  It reminds me of that thread with the 8x8 Zelda sprites.  I wouldn't be that surprised is someone was working on that too

Is that on 0.3.x by the way?  Because the grayscale is faster and looks nicer on in the newer versions for sure.  Or is it just your screenshot settings that make the wavy lines?

^ I'll get to that character thing  soon.

I'm thinking of allowing a new alternative syntax to make coding a little easier.  Just like you can do {L1+5} I am thinking of also allowing L1(5) like how BASIC does it.  You would also be allowed to do this with variables.  That is, A(2) becomes {A+2}.  The only downside to this would be that implied multiplication can never be implemented then becasue using parenthesis will ALWAYS imply pointing and never multiplication in order to make this unambiguous.  Not that I was planning to add implied multiplication, but thought I'd mention that.  Similarly, I would also like to be able to do the same with matrices.

What I was thinking is that you can store to a matrix at the beginning at some point.  So L1->[A](5,10) tells the compiler that you would like to start a Matrix at the position L1 and make it 5x10.  This would be completely a compiler command and would not contribute anything to the code.  The next step would be to use [A].  With the new syntax, you could say something like [A](2,4) and it will compile as {L1+2*5+4} since now the compiler knows where to store the matrix and how big it needs to be.

I'm still not sure how possible this will be to do since I still need to have it optimized automatically, but it would certainly be pretty cool.  It might allow me to implement some other commands like row and column swapping as well as well as filling with a single value, copying one matrix to another, etc.  All handled at compile time by the parser to translate into the current way of doing things so that its just as efficient.

I'm not planning to ever replace the old syntax, I'm just giving a new alternative to those who like the BASIC way of doing it.

I'm probably exaggerating when I say that erasing flash pages wears down the flash chip.  Unless your calc is already 10 years old, I wouldn't even worry about it at all.  I only mention it becasue if I don't and then someone's flash chip is no longer able to be written to, that wouldn't be pretty.  Defragmenting has the same effect as garbage collecting.  Both erase flash but in different areas.

I forgot to fix the error messages.  I'll do that now.  I'm glad this is working on an NSpire, that was one of the calculators I was worried about.

Yeah, I know.  I purposely didn't do that in the screenshot.  The OS only decides to redraw the tokens when it thinks they might need changes unfortunately.  I don't want to have the new tokens update the display more often then it should becasue that might cause speed issues especially when scrolling.  Its okay though becasue normally you aren't going to be changing the header since its the first thing you write.

Axe Parser
Gamma 0.3.1

---

No new commands, but you got to admit these new features are pretty cool. Even cooler if had I decided to throw in application compiling

New Features:

• Real error scrolling just like BASIC!  Finally!
• The new token names are now automatic.  They turn on if the program has an Axe Header
• Axe does not re-save the settings unless you make changes.  It will keep it unarchived if you want to unarchive it.
• Commands list shows both new and old token spellings.
• More nested expressions are allowed in a single statement.

Changed:

• Fixed some bugs in the new tokens and documentation.

EDIT: Please Re-Download if you got a copy earlier.  There was a big problem with the error scrolling on programs larger than 10kb that I'm still not able to fix, but at least it won't crash the calc now.

I have enough free ram where I can rely totally on it and I don't have to allocate memory from the user ram.

EDIT: Just to clear confusion, this is just how the compiler works, it has nothing to do with the generated programs.

You can't even type an underscore on the calculator, nor a dollar sign very easily.  I'm curious how you're going to support that.  I saw you were designing a DCS editor for it, but can that support the extra ascii characters?

I doubt you'll need to look at the Axe Parser source becasue the global labels are fairly easy to implement and I don't use local labels.  But if you need something in particular, I can always share some source with you.