Lots of bullets

1. At least on OS 2.53 they are stored out in the extra ram page. Page 3 977Eh–9A7Dh, I have no idea what format. They are somewhere else on previous OS's but I don't remember.
2. ! and # are normal for what they do. If you change them cleverly you can mess with them.
3. Instead of changing !, use the recall queue. With this, you can send whatever you want to the command line when the app returns.

LOTS OF BULLETS

1. AT LEAST ON OS 2.53 THEY ARE STORED OUT IN THE EXTRA RAM PAGE. PAGE 3 977EH–9A7DH, I HAVE NO IDEA WHAT FORMAT. THEY ARE SOMEWHERE ELSE ON PREVIOUS OS'S BUT I DON'T REMEMBER.
2. ! AND # ARE NORMAL FOR WHAT THEY DO. IF YOU CHANGE THEM CLEVERLY YOU CAN MESS WITH THEM.
3. INSTEAD OF CHANGING !, USE THE RECALL QUEUE. WITH THIS, YOU CAN SEND WHATEVER YOU WANT TO THE COMMAND LINE WHEN THE APP RETURNS.

Oh, okay, thanks.

I got my calc to recall a string of tokens by messing with #, but I couldn't make the rclQueue thing work, even when I copied the example program directly. Does it work with normal programs?

Also this might be off-topic but make sure to not accidentally lock/hide them because it can mess up your calc badly when you recall an entry or press ENTER on the home screen. It's even worse when trying to archive them. When adding ":" at the start of a home screen line, those files showed in MirageOS 1.1 and out of curiosity I decided to mess around with them.

Got it Can Axe create protected programs?

Another question:

• I noticed a real var ? in Calcsys. What is it?

EDIT:

I got my calc to recall a string of tokens by messing with #, but I couldn't make the rclQueue thing work, even when I copied the example program directly. Does it work with normal programs?

The recall queue should work with standard programs, you just have to be sure to store the info to be recalled somewhere where it won't get destroyed. Like appBackUpScreen. Also, I'm not positive, but you might need to force a jForceCMDNoChar. One way would be to manually deallocate the memory for your program and then bcall(_jForceCmdNoChar)

The example in the link you gave me said to close with a jForceCmdNoChar, but I read the info page on it and it said that normal ASM prgms should never use it, so I replaced it with a RET What does it do?

And real vars are real number variables. So like A, B, C are all real number vars. Unless of course they are complex

I meant I found one called "?"

Ok, bcall(_jForceCMDNoChar) tells the OS, "Go." But when you do this, the OS does not know that there is a program currently sitting in ram that needs to be deallocated, which results in a memory leak the size of your program. So here's how to get around that:

First, put a label "theStart" at the very beginning of your program (but after .db $BB $6D). Then put a label "theEnd" at the very end of your program. Now, instead of quitting with RET, quit with this.
quit:
ld hl, runner
ld de, $8000
ld bc, runnerEnd-runner
ldir

jp $8000
runner:
ld hl, $9D95
ld de, theEnd-theStart
bcall(_delMem)
bcall(_jForceCMDNoChar)
runnerEnd:

This manually deallocates your program (which obviously must be done from outside of it) and then does a jForceCMDNoChar. This might cause a one byte memory leak or something, so if it does, just increase DE by one there at the end.

Oh, and using RET instead of jForceCMDNoChar won't make the OS look at the recall queue. But then pressing [2nd] [mode] might make it happen.

$8000 has at least until $8100 of nothing. And then the area from $8100 to about $8180 is also rarely used.

It's basically just used as a temporary do something area. That's what the OS uses it for.

Oh, okay, thanks! By the way, what's after $C000? Why can't programs run after it?

It's a hardware limitation. TI apparently added it so you couldn't run FlashApps from RAM or something, iirc