I think I’m starting to understand instead of having variables I have data spaces that space out and hold data in binary just hypothetical  when should sombody want to use more dangerous storage like l3

Ok how many bits can I fit in l1

Than you so much I think I got it figured out (kinda)

Does Axe not allow you to manipulate more than one appvar at a time? I'm getting some really strange bugs when I do. I have 2 appvars that I create in RAM. One is the appvar for the current generated floor in my game. The second appvar is supposed to be another map that I am going to use in my AI calculation that I call DistMap. I running across several strange bugs with Axe when I do this. If I create both appvars at the same time, I am no longer able to manipulate the DistMap appvar if I do anything with the Floor appvar. In this case all I am trying to do is fill it with some value for now. If I instead create the DistMap appvar whenever I press a button (down in this case), the tilemap gets corrupted somehow. Or rather, it seems as if the 2 pointers are getting mixed up somehow. Because when I try to move down a bunch of corrupted tiles are scrolled in instead. Any ideas?

Some code to see exactly what is going on would be helpful. Here is a summary of what GetCalc( does which may be helpful.

Everything in ram is stored between 0x9D95 and the VAT which is at the top couple hundred bytes of memory. The VAT (Variable Allocation Table I believe) holds information about everything in RAM that isn't locked down to a fixed address. It also holds information on where archived stuff is in flash is but that doesn't matter for your problem. When you use GetCalc() to open an existing program/appvar/other that is in ram, what it is actually doing is going to the VAT to look up where in memory the file is and returning that pointer. Since the file is in memory, ti-os may move the file whenever needed. Any time you create or destroy a file, you should assume any pointers you got from GetCalc() are outdated and that you need to get them again. There are rules as to what moves when, but unless you are really, really hurting for speed, just do it anyway. I don't think that existing files move when you make a new one but it doesn't hurt to make sure. Resizing almost always moves stuff around.
Since each file is nothing but a reserved space in memory, simply reading/writing to it is no different than manipulating a normal area in memory. From your description of the problem my guess would be that you are resizing or creating and deleting appvars which causes them to move in memory and throws off your pointers. If you are, remember that creation/deletion/resizing can be slow because it likely has to copy kilobytes of memory around. That shouldn't cause slowdowns if you do it once or twice a second, but I would avoid it in a loop. I would suggest using existing memory areas before resorting to appvars. There is a lot of built in memory if you look. Take a look at this if you want to to beyond what Axe's L1-L6 give you. It is pretty outdated in where it says Axe's variables are located so ignore those. For example 0x8000 gives you 256 bytes of memory and as long as you don't turn your calc off, it is perfectly free to use. (although it overlaps somewhat with the 756 byte buffer L4-512)

Here are some other fun facts that probably won't help you but may be interesting:
Appvars and programs are the same thing (as far as I know) and they only differ by one byte which tells what they are.
Pretty much any name is legal for a program/appvar as long as you don't intend on interacting with it through ti-os. You can make and edit programs with lower case names. Axe will even allow you to include and compile programs with lowercase names just like normal ones. Ti-os won't let you run a program with a lowercase name but as long as you compile to an uppercase program you will be fine. When transferring these programs to and from a computer, the ti-connect will irritatingly capitalize all the names.
"prgm#" and "prgm!" are special programs that hold recently entered stuff on the home screen. I don't remember exactly what each one does, but they exist. I'm not 100% sure on their names but I'm pretty sure those are it.
When you run a program, it gets moved to 0x9D95 (0x9D93 is the 2-byte size of the program) and then executed. So if you want to run a program from within an app, you can copy it there and just :Goto E9D95. Since there could be appvars there already, you should use some calls that aren't part of standard Axe to move anything that is there out of the way.

This -8→{°MobOX+Mob}Is storing -8 as an 8-bit number.

At first, -8 is a 16-bit number stored as 65536-8 = 65528. That's works when your arithmetic is 16-bit. But when you store it as an 8-bit number, you lose the top 8 bits and it is stored as 256-8 = 248 instead.

Now when you read it, Axe has no idea that it used to be a signed 16-bit number, it's reading an 8-bit value that is 248 and in 16-bit, that's a positive number.

So what you need is to sign-extend the number where you copy the sign bit [top bit] of the 8-bit number into the top 8 bits of the 16-bit number. Luckily, Axe has a command for that: signed{<ptr>}

So whenever you are reading an 8-bit number and you want to tell Axe to interpret it as a signed number, you need to explicitly tell it.

This is probably the last question for a while. How can I make and used Latin named variables? Also why does it seem like everyone knows all about this stuff but I’m just behind?

I didnt mean Latin but custom, like EMNX for enemy x rather than j, I see people share code with long named variables and degrees symbols and was wondering what that was.