That would be pretty cool!  But Axe syntax is really designed around the limitations of the tokens available to Basic programmers as well as z80 itself.  If the Nspire is not token based and uses ARM assembly, it would be easier just to create a C language or something well defined since its more universal and there would be more support for it.  You would have to start from scratch either way since this isn't something that would be "portable" since it is so heavily dependent on z80 and token parsing.

I might get an Nspire myself after its finally cracked, but until then, I'm just going to stick with z80.

Unfortunately no, I haven't been able to spot a pattern in the errors yet, but I haven't done a rigorous debugging either.  I'll do that tomorrow probably.

I'm going to post most of the assembly routines I use in Axe Parser here to see if any of you asm programmers can help me with their optimizations.

• I am always trying to optimize for size, not speed, unless it is significantly faster and close to the same size.
• I would greatly prefer that it does not use any extra RAM to store temporary variables, but  that's not that big of a deal.
• No self modifying code or undocumented commands because I need to make this compatible for Apps and with the Nspire TI-84 emulator.

The most important thing right now is the clipped sprite routine since its really big.  Here's what I got so far:

p_DrawOr8x8:
   push   hl
   pop   ix      ;Input hl = Sprite
   ld   b,7      ;Input c = Sprite X Position
   ld   d,0      ;Input e = Sprite Y Position
   ld   h,d
   ld   a,c
   add   a,b
   jr   c,__ClipLeft
   sub   96+7
   ret   nc
   cpl
   cp   b
   jr   nc,__NoClipH
__ClipRight:
   inc   d
   jr   __ClipHDone
__ClipLeft:
   add   a,89
   ld   c,a
__ClipHDone:
   inc   d      ;d,c,e are updated
__NoClipH:
   ld   a,e
   add   a,b
   jr   c,__ClipTop
   sub   64+7
   ret   nc
   cpl
   cp   b
   jr   nc,__NoClipV
   jr   __ClipBottom
__ClipTop:
   inc   ix
   inc   e
   jr   nz,__ClipTop
__ClipBottom:
   ld   b,a
__NoClipV:         ;b,ix,e are updated.
   dec   d
   jr   z,__NoFix
   inc   e
__NoFix:
   push   de
   ld   l,e
   ld   d,h
   add   hl,hl
   add   hl,de
   add   hl,hl
   add   hl,hl
   ld   e,c
   ld   a,e
   srl   e
   srl   e
   srl   e
    add   hl,de
   ld   de,plotSScreen-11
   add   hl,de
   pop   de
   inc   b
    and   %00000111
   jr   z,__DrawOr8x8Aligned
   ld   c,a
__DrawOr8x8Loop:
   push   bc
   ld   b,c
   ld   c,(ix+0)
   xor   a
__DrawOr8x8Shift:
   srl   c
   rra
   djnz   __DrawOr8x8Shift
   dec   d
   jr   z,__SkipRight
   or   (hl)
   ld   (hl),a
__SkipRight:
   dec   hl
   inc   d
   jr   z,__SkipLeft
   ld   a,c
   or   (hl)
   ld   (hl),a
__SkipLeft:
   ld   c,13
   add   hl,bc
   inc   ix
   pop   bc
   djnz   __DrawOr8x8Loop
   ret
__DrawOr8x8Aligned:
   dec   hl
   ld   de,12
__DrawOr8x8AlignedLoop:
   ld   a,(ix+0)
   or   (hl)
   ld   (hl),a
   inc   ix
   add   hl,de
   djnz   __DrawOr8x8AlignedLoop
   ret
__DrawOr8x8End:


If you spot anything that can be optimized, bold it so I can see what you changed, thanks!

You'll have direct access to the screen ram in the next version so it will probably be a lot easier to do many of those effects.

By the way, I don't think I mentioned how to do masking.  If Pic1 is the inverse of the sprite and the mask of the sprite is immediately after it, then to mask the sprite, you do:

:Pt-On(X,Y,Pic1+8)
:Pt-Change(X,Y,Pic1)

What I mean by double buffering is that you can draw a background, like a tile map for instance, and then copy it to the extra back-buffer using "StorePic".  When you want to draw over the buffer, then instead of using "ClrDraw", you use "RecallPic" to copy the extra buffer to the main buffer and then you only need to draw the foreground over that instead of having to render the entire foreground and background each time and then clearing it each time a sprite moves.  I don't think it would be fast enough for flickerless gray scale like Pyoro, but flickerless gray scale support is planned in the future.  By flickerless I literally mean solid gray, no faint crosshatches.  Quality depends on how long it takes between renders, but its a reasonable amount of time you'll have to do basic rendering and computation.  I'm sure you can get some quality of grayscale without the native support in the mean time though.

Yeah, I could, but it would be so inefficient.  That would be like a BASIC programmer trying to make a compiler for assembly language programs, which I have seen done before, but its very slow.  However, I could just cheat and the whole program would just be asm([hex code of entire program]) That would work

Safety features will come in due time.  I'm kind of in that awkward phase where the next version about to come out has enough features to compile nearly any type of game you can think of, yet I still don't have a GUI (even the list of programs is awful because of the scrolling and such), no safety features like archiving the ram before testing the program, or a compiler options menu for things like 15MHz mode options.  And there are still hundreds of commands I still have to add!

I promise.  After the next release, Axe Parser will become 0.1.x and make more of those changes instead of new commands and such.

Nice!  Although you don't need all those parenthesis since order of operations is still just left to right:
:B+D->B<D+A+C->A
:A-C-(B-D->B>=-D)->A
Won't make a difference in the compiled code, but saves some memory in the source.

Right, I haven't clipped the sprites yet, so that means it actually draws the sprite into the memory immediately after the buffer which contains a lot of important information the calc needs...  so it will corrupt that data and do a RAM clear most likely.  Might be fixed in the next version.