1. This is more of a feature request, and I agree I would like it.
2. This is because DCS installs a parser hook, and if you delete the appvar, it thinks you reset the calc, and it feels obligated to fix this. Just don't delete it (Though I agree this should be fixed)
3. gui7 is the GUI stack, and should not exist except when a program is running. If it's there, it's because a BASIC program that used the GUI didn't close the GUI stack or it was interrupted w/ON. Make sure to delete this appvar before running other programs and especially before running DCS. CHAIN7 has something to do with DCS's ability to run programs, and it really should not appear outside of when a program is running. Under what circumstances do you see it?

Also, it would help to post this on cemetech, since that's where Kerm is most often. (He doesn't normally frequent here except to make announcements.)

So, at $4000 on the first page will be the header, which goes to $407F.
The calculator starts execution of the app at $4080. If you want a multipage app, (or rather if you want to run routines on other pages), you'll need a branch table (what was mentioned above). However, you'll need to skip over the table because executing it would not be good, so you'll want to use jp to skip over it. After that you'll need one byte of padding to get to a multiple of three (anything will do, so just use nop). After that, you'll need to add your off-page calls.
Starting at $4084, after the header, jp, and nop, will be the branch table. As Hot_Dog said, first you'll put the address of the routine, then the page, indexed from 0. (So the main page is page 0, the next page is page 1, and so on) As for a "nickname," it would be easiest to adapt a convention for naming them. The one I'll use in the example I'm about to give will be to prefix an underscore ('_') to the label name. For getting what it is divided by three, you'll want to use ($-$4000)/3. Now for an example.
;Branch table example
.org $4000
;Header goes here
.org $4080
    jp Start
    nop
;We're now at $4084, and here will be the branch table
;Let's suppose you have a routine called PutSprite on the third page
_PutSprite .equ ($-$4000)/3
    .dw PutSprite
    .db 2
;And a routine FetchData on the second page
_FetchData .equ ($-$4000)/3
    .dw FetchData
    .db 2
Start:
;At the end of the branch table, your code can start
;When you need to run PutSprite, use b_call(_PutSprite)
;Same for FetchData, for which you use b_call(_FetchData)If you're still confused, feel free to continue asking.

You'll have to do it by hand. Assuming you don't need T, then the following code will display 2 hex digits corresponding to the data at P.
Disp {P}/16->T>=10*7+T+48>Char,{P}^16->T>=10*7+T+48>CharThe condition is to add the right amount to make $30+$10 $41 (which is A)

By the include file it's the start of ram and some field called "appdata"
I'm not really sure, though.

So water acts like antigravity?
Nice to see a release, I hope you can get more work done on it.

Yeah. Obviously you'd use saferam before you used an appvar
And, now that I think about it, I'm not sure there is a workaround for apps. For text, I'm convinced it does something to the effect of displaying one char at a time, but there's no simple equivalent for a bitmap...
You might have to stick with copying it to RAM, as above.

This is probably related to why text w/in an app can't be used w/o care (in regular ASM, not Axe)
Like he does for text, Quigibo will have to add support for bitmaps.
Until then, you need to copy the bitmap to RAM before using it.

Nice to know.
How hard (and how large in the generated program) would it be to support more characters? (Right now I'm thinking of the language's own []<>+-,. so I can run a self-interpreter )