I was just curious if there was a way to reuse letter variables.

Reallocating the letter variables does give you a full new set of variables backed by different memory (provided you used a location that doesn't overlap with the default). But if you want extra variables, I would suggest instead making use of named constants/variables. You can define a constant like L₁→°MyVar, and then for the rest of the program, MyVar will be a variable stored at L₁. You can do anything with it that you can do with a letter variable.

Hrm... Relloc(A) gives an error.

You're redefining the base pointer for the letter variables, which should be a constant, and A is not a constant.

Is there a way to access the OS's unused spaces?
When I downgraded from 2.55 the new os took up 200k less space.
Is there a way to access this unused space (my available archive didn't go up when I downgraded)

I'm not sure where you got the 200KB number from; if you're referring to the fact that the 8xu file is larger, those files are roughly twice as large as they would be on an actual calcluator and they contain varying amounts of filler blank data, so don't trust their file size differences to tell you much. Regardless, you didn't see your available archive space change because there's a fixed size allocated for the OS for simplicity and compatibility reasons. A "larger" OS will simply take up more of this space. It won't eat into archived variable and application storage.

Theoretically, you could store data in the unused space allocated for the OS, but not in any way that the OS would be able to recognize variables or applications. You'd essentially be patching the OS. And unless you've got a really good reason to be doing so, you probably shouldn't be patching the OS.

While debugging my program editor I opened a weird file (it uses the VAT to select a file) and it contained my last entry.
After experimenting with it I found that I could access it with a Getcalc([0523]) -> var and that modifying it did indeed modify the OS's last entry. (It seems to use tokens to store data.)
Is there a way to execute this modified entry so I can use the OS's math or run a program? (or just reset my ram)
I love poking into places that I shouldn't! 

As it seems you have discovered, the home screen entry is implemented as a specially named program that you edit directly on the home screen, and it is executed when you press enter. But outside of this program's special connection to the home screen, there's really nothing special about it. You can do anything with it that you can do with any other program.

However, I'm not aware of any way to execute BASIC programs (which is more or less what the home screen entry is) from Axe.

Is there any useful uses of it?
I am assuming that the OS has a flag for whether the enter key is pressed on the home screen.
It there a way I can "activate the flag" and execute anything it has.
I am looking for a way to implement floating point math (It doesn't have to be fast) into my editor as a feature.
Basically I am tired of quitting my program to do a math operation on the home screen. (and I don't want to do long math in my head)
Thanks!
(the whole home screen is a program thing BLEW MY MIND)

However you'd end up doing such a thing, you'd need some things beyond the capabilities of pure Axe. My inclination would be to let the user select a line, or some more specific selection, and then press a button to request that it be replaced with its evaluation. I've never done anything like this before, but it might work something like this (DISCLAIMER: COMPLETELY UNTESTED):

• (Optional) Save the value of Ans. This gets rather tricky for lists and matrices.
• Create a temporary equation with the same size as the selection. The clean way to do this in assembly would be to use B_CALL(_CreateTempEqu). But a pure Axe solution would be to use a fixed temporary equation name, like [03FFFF00], and create it with GetCalc(<name>,size).
• Copy the selection into the temporary equation.
• Install an error handler around the next step in case an error occurs while parsing the equation. DrDnar's axiom meant for running assembly programs seems to provide this functionality.
• Execute the temporary equation by putting its name in OP1 and using B_CALL(_ParseInp) (in Axe: <name>Asm(E7EF9B4A)).
• If an error occurred, handle it as you wish. Perhaps append "=ERROR" to the selection.
• If no error occurred, convert the result to a string representation. Thankfully, Mateo recently demonstrated how this could be done. In Axe (returns a pointer to the variable's size word): Asm(210000EF2443D5EF6949EF524BEFAB49EF6C49E1).
• If no error occurred, delete the selection and insert the result's string representation into the program at that location.
• (Not sure if necessary) Clean up temporary variables with B_CALL(_CleanAll) (in Axe: Asm(EF5041)).
• (Optional) Restore the original value of Ans.

I may wind up using memkit...

Thanks!
Maybe you can add it in 1.3 if there is enough space.

Does anyone know an good aiming routines?
The project I am working on requires that a good amount of aiming.
All attempts at creating a particle that will move at the same speed (reasonably accurately) between two points have failed.
I feel like the solution lies in the sin( cos( tan-1( command but I can't get them to work.
the world uses 256 to 1 pixel up (for good jump animation) but 1 to 1 for the side (for bigger maps)

To answer my question from earlier
:Goto (GetCalc("prgmNAME"))
Seems to work and jumps to the beginning of another program without the lag of other commands.
I know this is probably pretty dangerous and bad things will happen if the program isn't there or crashes.
It appears to be able to jump from an app to a program in ram and then return back to the app.
If it really does what I think it can that lets programs have 36000+ ram to work with (about 16000 for the app and 20000 for ram)

Any thoughts on either subject?

Do I need to make space for it, or can I just copy a program directly to it?
Copying it directly doesn't work.

Never mind, I messed up the copy statement.

Edit: the program runs fine but crashes when exited (the program in e9D93 not the one who ran it)