What do you mean setting it up with a different page of ram? As in copying it into another ram page, or running it from a ram page?

The only way, that I can think of, is to use port 6 and 7, and copy 0x4000 to 0x8000.  But messing with port 7 is hard. Also, you could just allocate enough space for an appvar, copy it, then copy it to a ram page.  Not sure if it is runnable, though.

Well, first off, how much RAM do you really need?  Could you stick to using the main RAM, and keep compatibility with the 83+ BE?

Hardware-wise, the Z80 address space is divided into 4 "banks", which each hold one 16k memory page.  The first bank is always used for Flash page zero; the second two ("A" and "B") can be mapped to any page you like, and the fourth ("C") is always used for RAM page zero on the 83+ BE, but can be mapped to any RAM page on the 83+ SE and 84+.

Now, all of that said, you should realize that you can't usually change the pages mapped in banks B and C, unless you're very careful about it; bank C contains your program's stack, and bank B contains your program's code and variables.  Bank B - RAM page 1 - also contains lots of variables that are used by system routines, including the system interrupt service routine.

So that leaves bank A.  In a RAM assembly program, you can change bank A whenever you like (unless it's a shell program and you're using shell library routines), but you also have to be sure to restore the original page to bank A when your program finishes.  This might be a plausible strategy for Axe programs (correct me if I'm wrong, but I don't think Axe programs use any shell library routines), but it wouldn't work for Flash applications.  And of course it does break compatibility with the 83+ BE.

As far as what pages you can use: newer 84+es have only 1 extra page of RAM, whereas older 84+es, 83+ SEs, and (I believe) Nspire-84+es have 6 extra pages.  Of RAM page 3 (or, on newer calculators, the single extra page), a small amount of memory is used by the OS for storing application base pages (so if you overwrite that area, you have to call FillBasePageTable to restore it), and a further area (about a kilobyte, as I recall) is used as scratch space for USB operations.

Perhaps it would be useful for Axe to provide an "allocate temporary buffer" function, which could be implemented in various ways depending on the calculator model and the type of program (RAM versus application) you're compiling.

Right, sorry.  In that case, I'm not sure what exactly you're asking.  Could you post an example of code you've tried that doesn't work the way you expect?

I guess you would do something like "in a,(6) / push af / ld a, 83h / out (6),a" (Asm(DB06F53E83D306)) to set the mapping, and "pop af / out (6),a" (Asm(F1D306)) to restore it.  (Is it OK to use pushes and pops in inline assembly like that?)

There shouldn't be a problem with that, I use that all the time for when I switch out pages. It won't pose a problem at all unless his code uses a "pop" without another "push."

EDIT: Ninja!

No, all it does is swap out 4000h to 7FFFh to the RAM page leaving the rest intact. Are you trying to make use of all of the RAM at once?

Yes, it's okay, and thank you
That gives me C000 and up as free RAM, correct?

No, that's port 6, which controls the 4000-7FFF area.  And if you want to use the area from 4000h to 4080h, you should also add a B_CALL FillBasePageTable (that's EF1150) to clean up when you're done.

So this only works from a program?  And I get 4000-7FFF, assuming I use FillBasePageTable?