Also (although unfortunately on the calculator you don't see much of it) the music is a factor that really immerses me into a game as well.  It really sets the mood, often times even more than the backgrounds.  That's one of the reasons I loved Chrono Trigger and Secret of Mana becasue those games had awesome music along with an excellent story line and great graphics.

If you run out of room, you just use some free ram location.  You have to save the current stack pointer somewhere anyway before you can use it, otherwise the calc will crash becasue it can never return back to the operating system.  If you're not taking advantage of the automated push/pop features that are inherent to the stack pointer, then just use a ram location becasue its smaller and faster in ever way.  Trust me, you'll NEVER use the sp register until you get into the really advanced tricks, and even then you're not using it to store numbers, you're using it as a fast way to read or write to ram.

That's not something you would ever want to use unless you're seriously abusing the consequences of its normal use, which I only did once when I tried grayscale double buffering.  The sp register is the location of the stack.  If you change it, you will no longer be able to call or return from subroutines, push or pop variables, and some other nasty things.  Not to mention there's a lot of roundabout code you would have to use to even load stuff to or from it.

Just thought I'd mention I wrote a 4 level grayscale routine today for the next version and it seems to work very nicely.  The only problem is that it needs to be initialized before you can start using it, so you need to add one extra command to the top of your code, but the code itself is tiny.

No, a subroutine is negligible unless its called over 9000 times per second.  Typically, the screen updates around 20-60 times a second.

You can do this:

While getkey(0):End

That works even when you're using direct keys.  It will wait until you've let go of all the keys.

Also, you can use it for general optimizing.

If you check the source of Starship, I was using a bunch of things like this: conj(A-3,B-3,4)
Which I changed to this: conj(A,B,4)^r  Since it doesn't have to do extra subtractions.

I prefer to keep my 15 MHz games cross-compatible, even if it means they run twice slower on older models.

What you can do is this:

prgm15MHZ
:Full
<some code>
:Normal
:DispGraph^r
:Full
<more code>

That way it will do all the game calculations in 15MHz mode but still update the graph in 6MHz mode.  The 6MHz and 15MHz DispGraph routines take the same amount of time since they are limited by the same LCD delay in both cases.

One thing about the new update:

Can someone please tell me how the new commands would be used?
More specifically, conj()^r and the bitwise "and", "or", and "xor".

This is a good explanation for the bitwise features:
http://en.wikipedia.org/wiki/Bitwise_operation

As for conjr, these are the same:
conj(L1,L6,100)
conj(L1+99,L6+99,100)^r
It copies the 99th byte first then the 98th, the 97th, ... to the 0th byte instead of the other way around.