A lot of people use the areas pointed to by L1~L6 to store additional data. If even those don't suffice (that's a lot of RAM) you could make a buffer/array stored in your program and store the data there, or for a really complicated method, create a temporary OS variable of whatever size you need  and store the data there.

[...]
That is in most cases not desirable: saving temporary data that you will erase later is wasteful, and you could end up with unpredictable initial state in your program because of that.
[...]

Hmmm couldn't you solve that in theory by clearing your temp. areas upon program start and upon program exit?

And that's extra effort. Though there is probably a performance advantage to accessing that data through statically computed pointers than from an unpredictable memory area. You shouldn't need to do anything at the start of the program either, just reset those arrays before exiting.

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)

Quote from: c4ooo on March 17, 2018, 03:17:01 pm

I always use GetCalc(appvTEMP, size) for dynamic variables. (This creates an appvar called "TEMP" of the given size and returns a pointer to it.) Just remember to delete it later.

I'm pretty sure there's a type of variable that gets deleted automatically by the OS when you exit, it's called tmp and it replaces the w token (2nd+9).

Yea... that's right. I think. Pretty sure. You might have to start its name with a non-alphabetical character like '*' though.