Well, its not really a contest, but I need to design a nice splash screen which will be displayed at the intro and when loading and saving large chunks of archive occurs.  I have a little battle axe I made kind of similar to my avatar, but it seems kind of dull.  I'm not a very good artist.  There are no restrictions, just make sure its monochrome and smaller than 96x64.  The winner will be used in the program if I like it.  It doesn't need the name "Axe Parser" as part of the picture, but I prefer if it does or at least has some room to add text.

Some ideas I had:

• A swinging axe in motion blur
• A knight holding an axe
• An axe chopping the TI logo
• An axe separating basic snippets and binary

These are just some ideas, anything you come up with is fine, just don't make it too violent though

Wow I just noticed this thread.  This is amazing!  I'm definitely going to have to try this when it comes out!

To answer some questions, no, Axe programs do not need a separate category on TiCalc since they're assembly.  However, it might be reasonable to have a section for Axe source code and routines the same way they have assembly routines, but I don't know if that's necessary.  When you upload an assembly program, there is a check box for "Source code included?" in which you can add the source if you choose to.  One advantage of this is that when newer versions of Axe Parser come out, you can always recompile with the new optimizations to make smaller executable.

I don't care too much about credits.  I prefer you mention it was made with Axe Parser, especially if you include the source, but its not absolutely necessary.  The main reason is that if any assembly programmer actually looked at the hex code, its VERY obvious if a program was made with Axe Parser by the nature of program flow and the routines I use.

I don't want to release it yet on TiCalc because it really isn't that safe yet without the archive features and also there is going to be a lot that will change once I finish the user interface.  By change, I mean in a compatible way.  Old code will still work and all that, but arrays are going to be automated and things like interrupts are going to really change the way you program.

FINALLY!  I fixed it!  I've learned that there are 3 types of lies: Lies, Damn Lies, and the TI Developer's Guide.  It clearly stated that I was not supposed to update the program size because its done for you with CloseProg but this was exactly the opposite of the case.

And I also noticed that 95% of the time spent parsing was actually going into displaying the progress.  So now, it only displays the progress 1/256th of the time so it can parse about 5000 bytes of source per second on SE/84+.  The example programs can almost instantly be compiled now.

Another XKCD fan!     I read it regularly as well.

I'm currently working on that bug.  I'm getting very close.  I'll let you know when I fix it.

The language itself is pretty stable in my opinion.  New commands are going to be added so some larger routines can be replaced by a single instruction later on.  But I don't have any concerns at the moment for reverse compatibility.  If it works on 0.1.0 then it should almost surely work on the final release.  If I do make any major changes, I always list them on the updates.  I've only had to do this once so far and I don't see myself needing to in the near future.

Axe Parser
Alpha 0.1.0

---

Sorry, I've been really busy this week.  I haven't had a lot of time to add all the things I wanted to.

New Features:

• Faster Parsing
• Program List Is Improved
• 15MHz Commands

Changed:

• Fixed the >Frac bug.

I added the new speed command to my Game Of Life example program so you can see the speed difference.

Yeah, the majority of programs and games have to use pauses to keep good timing.  There is almost no need for greater speed unless it is actually demanded.  We'll see how far the hardware can be pushed in the next version since it can take advantage of 15MHz calculators.  I'm getting about 125 sprites per frame at 30 fps.  That's without any game mechanics, but that usually only makes up a small fraction of the cpu time anyway.