Redrawing it (or backing up the entire buffer-pair (you'll need a 768*2-byte appvar)) is probably the easiest option
But yes, screen data is at L6. The backbuffer is at L3, and is also used for displaying greyscale images.

Are there a couple of memory blocks easily available in Axe that can store the front and back screens? How would you transfer the contents of the screen to this memory and recall it?

Well, the buffer (L6) is pretty much just a chunk of memory that the OS uses to keep a temporary copy of what's on the screen. What's actually on the screen is controlled by the RAM of the display, which is separate from the calculator's RAM. When you use DispGraph, you're basically sending the data in the buffer to the display's RAM, so that it can display it.

The back-buffer (L3) was originally meant by TI to be another chunk of memory for backing up the buffer (so you can display a menu "over" what's already on the screen. Axe uses this for grayscale instead, so if you're using monochrome, you can still use this as a backup for the buffer.

Then there's L1, which is a chunk of SaveSScreen. SaveSScreen was originally meant by TI to save a copy of the screen when the calculator APD's (auto-power down). You could also use it for buffer storage, but Axe uses the first 56 bytes of it for the A-Z and theta vars, so you only have 712 bytes left, which isn't enough for the whole screen (768 bytes).

There are a few commands to save copies to other locations. StoreGDB  saves what's actually on the screen (what's in the display's RAM, which could be different from what's in the buffer) to the buffer L6. StorePic  saves the buffer to the back-buffer L3, so you can use that as a backup if you only have monochrome. If you're using grayscale, though, you'll have to make your own 1536-byte chunk of memory to save stuff in. You could do that with a chunk of your program set apart for this (with Zeros(1536)) or with an appvar. Just Copy( the buffers there.

I'm currently using StorePic, but the program needs greyscale and I have plenty of speed to spare. But what I'm asking is if there's a way that I can do something like

Code: [Select]

:StoreGDB->"appvTEST"
:StoreGDB^r->"appvTEST2"
:[Move sprite]
:Recall "appvTEST"
:Recall "appvTEST2"
If there were some way to access specific bytes in the screen, I wouldn't even need to recall the whole thing.

Nope, you'll have to use Copy(

You can store specific bytes, since it's basically just an array of 12 bytes per row, 64 rows total. You'd have to find the byte(s) to copy for that, though. And eight pixels are stored in a single byte, so it's pretty hard to find the right bytes when the sprite overlaps an edge.

The easiest way to do it would probably be to use Pt-Change( (so you can just use it again to take the sprite off) or redraw the entire screen every frame. Or store the entire screen, as you said.

L1 can be used completely if you plan to use no variables and use other storage areas for data. You can also use it and still use variables if for example your game screen is 12x7 tiles large, for example if there's an HUD at the bottom/top of the screen

L1 can be used completely if you plan to use no variables and use other storage areas for data. You can also use it and still use variables if for example your game screen is 12x7 tiles large, for example if there's an HUD at the bottom/top of the screen

I've already broken the variables rule by using pointers. Plus, this is for a GUI, meaning that the whole screen is fair game. It's pretty efficient so far (>700 bytes).