Depends on the model! On the models with crystal timers yes, On the models with out sadly no.

My knowledge is somewhat... lacking... in crystal timers. Can it be accomplished in > ~20 clock cycles?
In generalized pseudocode is to:
Interrupt:
exx
64 loop for y
ld i,(breakSave) // change the interrupt location (I know you can't just set I)
12 loop for x
set interrupt to trigger in ~25 clock ticks (15 for next 2 instructions and 10 for after)
exx
ret
//go and execute 1 or 2 instructions while we wait for the lcd to be ready
breakSave: //when the interrupt triggers it will jump to right here
exx
out ($10),a // write to the lcd
endXLoop:
endyLoop:
ld i,(Interrupt) // restore the interrupt location
exx
ret
I'm not sure if all the code is correctly formatted. Ignore any incorrect syntax. I'm sure you get the idea of what my goal is. I want to spend time executing useful code while I wait for the lcd to be ready for another write. It only works if the function is in an interrupt of course. I don't think that it will help with greyscale display since they have less waisted time waiting for the lcd to be ready. I can't create the method since I don't know how to use crystal timers. Some code showing me how to use them would be nice.

That's a good explanation of it, thanks for doing my job.

Are there positions open there? 

How much data are you using? Even 80 sprites can fit inside L1. If you have massive amounts, you can store the sprites in an appv and copy it to ram when the program runs. I have never run into trouble with the amount of sprites. I usually run out of ram.

There is a lot of free ram hanging around. Try using static locations if you can. (like L1-6 or special spots you can type in with the scientific E key) A large portion of 0x8000 - 0x9D93 is free to use. L1-6 are there but they only cover a small portion. If you need a lot of variables, use 0x966E. It is 128 bytes long. You will need to fill it with the space character when you are done or your homescreen will look wierd when you quit.
Also L5 is the only L1-6 variable that can't be used as 756 byte buffer.
L1 can be used whenever you want.
L2 is listed as 512 bytes long but it is closer to 800. Make sure to ClrDraw(L2) when you are done. I know that it says you can't use it with interrupts but that isn't true. I've written many programs with interrupts and used L2 in each one without any problems.
L3 is basically the same as L1. The only time you can't use it is when you are using greyscale.
L4 is listed as 256 bytes long but all L4-512 to L4+256 is free to use. Some values might change if you are are use Copy() with the Y0-9 archive variables.
L6 is the graph screen buffer. You probably know what that is used for.

If you really need more try:
https://www.omnimaga.org/index.php?page=ram

If you can't use any of that:

I would avoid using getCalc unless you need a very large amount of uninterrupted space. If you are trying to store a bunch of 2 byte variables there, it will be 2-4 times as slow as if you put those variables in L1-6. I'm not saying don't use getCalc for memory! I'm only saying that it will be a bit slower. (There are actually hacky advanced ways to get all the memory space of using getCalc and the speed of static locations...)

As for using Buff() for memory, that is up to you. Make a program that uses Buff(8000) and run it. If it takes a second to quit, don't use Buff. If not then feel free to use it as much as you want since your shell isn't writing it to archive.

If you know what you are doing, you can have a huge amount of memory at once. One of my programs had 25k of executable code and 28k of ram that I could write to at any time. (I didn't swap anything to archive)

That sounds neat! I'd use it if I had a phone... heh

If you want to draw text to a custom buffer, I made an axiom that lets you do just that! It also is twice as fast as standard Text( command. The tokens are under the matrix menu.

Wow! Thats a lot of questions. Ill try to answer them all.

1. Making a map that moves with the character and extends beyond the screen:
You dont say how the map is formatted. I assume you mean a tile map. Creating a tilemaping engine is not terribly hard, but creating a good one is. Runer112 has made a really good one called YAAM. There is really no reason not to use it. It is a bit confusing to learn but straightforward enough when you figure it out.

2. Rotate sprites:
Axe has sprite rotation commands built in. I don’t remember what they are exactly but you can find them in the ‘s’ section of the catalog. Remember that they use the same memory so copy or display the sprite before you use another rotation command. They are also sort of slow. Not a big deal if you are rotating one or 2 sprites a tick but can be a big problem if you rotate many each tick.

3.  GDB’s:
I don’t think you understand what a GDB is. Its nothing more than a pointer. All it does is tell the program to look in a specific spot for the data. Since all it does is point to the start of the data, the data can be of any size. If you wrote:
:Data(0,0,0,0,0) -> GDB1Then GDB1 would be 5 bytes long.
:Buff(NUMBER) -> GDB1Then GDB1 would be NUMBER bytes long. There is no limit to how big NUMBER can be as long as there is space in memory. It can point anywhere. If you did: L1 -> GDB1 then you could use GDB1 instead of L1.

I find that it is very helpful to program with a copy of the Axe Parser command list nearby. You might want to spend more time to become very familiar with pointers before you continue. Much of Axe requires you to have a solid grasp of them. (Plus you can do some really cool things with them when you become a better programmer)