Try this:

Copy(A,L6,768)
Copy(B,L3,768)
Repeat getkey(15)
DispGraphr
End

Replace "A" with a pointer to the picture in the front layer, and "B" with a pointer to the picture in the back layer.  They can either be in the program code itself (pic absorption or hex code) or they can be pointing to an OS pic in ram or even archive if you use a file variable instead of the pointer.

@FinaleTI
Oh I see.  Yes, you can read and write to hacked Pictures as well, but you have to use the hex codes since you can't type it in.

GetCalc([0760]Data(#,0))->A

To return a pointer to the hacked pic # (in decimal)

@DJ
I'm not talking about a static pointer either, that's the actual OS picture.

I'm not quite sure what you mean, you've been able to read/write/create/delete/modify pictures of any size for a long time now...

If you want to create a picture Pic1 that is 64 rows long, you can do this:
If GetCalc("Pic1",768)->A
  .Modify the picture here
End

You can even make the pictures ridiculous sizes and it should still work.

Yes, "and" "or" and "xor" all operate exclusively on the low byte (8 bits).  You have to use the plot style tokens to do bit logic on 16 bit numbers.  I am thinking it could eventually be possible to have C style Boolean logic in Axe++ which would be the 2.0 version but I don't know if that would ever get completed, I have to worry about 1.0 for now and still have a long way to go.

I think it's just the tricky double standard that was introduced when I added that optimization.

The routine to store a number to a constant address is different than the routine to store to a variable address.  Different enough in fact to have a different return value.  So doing 6->{8*4+L1} returns 6 and can be used in series with other storing since the address inside the brackets is a constant, definite number.  6->{A*4+L1} on the other hand returns the address (what's inside the brackets) instead of 6 since it has a variable address.

The technical reason is that if the expression inside has to be evaluated during run-time, then that expression will be the last thing evaluated and hence the thing returned after the store.  Constant addresses on the other hand are evaluated during compile-time and so the last real evaluation was the expression being stored so it can be chained with other stores.  Don't forget though, you can still do some optimizations with return addresses:

A->{P}
B->{P+1}
C->{P+2}

.Can be optimized to:

C->{B->{A->{P}+1}+1}

.This optimization only works with variable addresses
.Constant addresses are automatically optimized anyway

The only other weird thing is that when storing to a  variable address with a full 2 byte number (using the r modifier) then it actually returns the address plus 1.  That actually makes it compatible with the code example above since you would otherwise have to increment by 2 every time.

But there might be a bug treating some constants as variables instead, so I'll have to look into that.

Also, you are increasing health by 6 each time but checking that it's equal to the max health.  If the current health is 999 and you add 6, that's 1005 which is not equal to 1000 and the health would continue to increase.

Axe makes interrupts very simple, there really isn't much to them.  You just give it the name of the routine that you want to use for the interrupt and the frequency (how often the interrupt is executed every second).  The fnInt() command also enables the interrupts for you so they start working right away.  Generally though, interrupt code makes the program much larger and slightly slower so I would only use them for applications where you're actually using it for it's timing feature.  For example; a stopwatch or music player.

Once its set up, it will execute the interrupt code at a regular frequency "in the background" except that it has to halt normal code execution while the interrupt code is used which might make your game appear to pause if the interrupt code is too long.  Interrupt code should normally be short like increasing a timer variable.  There are several commands that go with interrupts explained in the commands list.  fnOff will temporarily turn off the interrupts.  fnOn will turn them back on.  Stop will wait until the next interrupt before continuing.  And lastly but most importantly is LnReg which kills the custom interrupt completely and returns back to the normal OS interrupt.  You NEED this before you exit the program or else the calculator will freeze.

The user manual has been updated since I added the file commands, if you haven't looked at it recently, try the newest version.

Here is a little more technical insight.  Normally you use pointers to access something in ram, but only 65536 bytes of memory can actually be read because that's all the combinations you can make with only 2 bytes.  That's fine because there's only 2 ram pages anyway corresponding to 32768 bytes total.  But when it comes to reading from the archive, there is MUCH more data, 2 million bytes on the TI-84+SE.  So in order to compensate for this, you have to use files which you can think of as "extended" pointers.  Each file is 3 bytes corresponding to a page number and pointer within that page.  Because the files obviously have to be handled differently, they can only be used in a few commands: Copy(), {}, and GetCalc() are used most often.  If you need to use the data for other things like sprite drawing, you can use the Copy command to copy it to ram and then refer to it using a normal 2 byte pointer.