That's interesting it happened when the picture was in RAM because I first thought it might be a page boundary issue.  I'll double check the code for tilemap importing.

EDIT: Found it!  Funny bug... the picture tokens are 2 bytes each so it has to call an extra "read byte" routine after the first byte has already been added to the file name buffer.  That's fine, but there's a 1/256 chance that the parser needs to display the current progress (which it checks for during every "read byte").  It just so happens that TI's routine uses the same buffer to display numbers so the filename being built up will get corrupted and you get a "pic missing".  This will be fixed next version, in the mean time, adding/removing a comment before the [Pic] command should get rid of it.

You can always use a single Pt-Mask() to write a white square to both buffers.  Not sure if yours is faster than that or not, but its possible due to the lack of clipping and argument checking.

Don't forget order of operations is strictly left to right.  Change O=X+A-2 to X+A-2=O.

eh.... as much as I like the dot, I would really like to avoid it so it doesn't look weird next to another new feature I'm adding.

Cool, thanks!  I was also able to do that same sign flag optimization to the 8.8 multiplication routine.  Any idea what might be a good token for fixed point division?  That's the main thing holding me back from adding it.  /* is the first thing that comes to mind but I think its confusing.  /// could also work but that's a lot to type...

High order functions will be possible in Axe 1.0.0, and will be an interesting paradigm change.  That will probably be THE biggest change from the betas.  However, I'm still not sure if they will be recursively nestable yet, where the parameters can be backed up to the stack, but its still pretty damn useful.

So far, its the same speed.  However, after the first pass, there is a short but noticeable pause as it writes all the used subroutines to the current end of the program so that data is always after any code during the 2nd pass.  I don't think the peephole ops would cause a significant slowdown either, probably unnoticeable.

Yay!  I can finally parse STARSHIP and have it work.  I still need to fix a bunch of miscellaneous things though.

Since I'm rewriting the engine anyway, I figured I might also want to add another feature to the auto-optimizer, something called "Peephole Optimization".  The way it works is basically every time the parser writes an inline instruction, it will scan upwards several bytes and see if the code matches a list of patterns.  If it does, it will replace the code with the more optimized version and then continue writing.  If this works, then its possible Axe programs can get EXTREME optimizations approaching that of a moderate z80 coder. It could result in up to a 5-10% decrease in code size plus a small speed boost!

I am going to try to make these open source like I have been doing with the commands so that others can help me with them, hopefully I can find a good system for it.  This is all speculation though, I'm not sure if I'll have time or add it at all if it gets too complex, but I'm hoping it can work.  This could also render a lot of those weird Axe tricks obsolete since they would happen automatically, like 0->A:0->B could automatically optimize to 0->A->B.