Wow, I am surprised I haven't posted these in this topic as I have been very proud of them for a long while now. They make a legitimate use of RRD and RLD, so for those questioning the use, check it out:
ShiftScreenRight4:
;Shifts the graph screen right 4 pixels
     ld hl,plotSScreen
     ld c,64
       xor a
       ld b,12
         rrd
         inc hl
         djnz $-3
       dec c
       jr nz,$-9
     ret
ShiftScreenLeft4:
;Shifts the graph screen left 4 pixels
     ld hl,plotSScreen+767
     ld c,64
       xor a
       ld b,12
         rld
         dec hl
         djnz $-3
       dec c
       jr nz,$-9
     ret
It is the same size as shifting 1 pixel, though 7680 cycles slower. That is still about 1 bazillion times faster than shifting left or right 1 pixel, 4 times. I've been using these for years in my graphics related programs I hope they prove useful!

EDIT: In this case, 1 bazillion == 88664, apparently. To run the shifting right code once, it is 22166 cycles. The above codes use 29846 cycles.

Cool! I cannot wait to see what the topic is!

I think I am about to complicate matters .__.

But I'm still kind of new to this data editing stuff with appvars and hexcode and stuff like that. So are appvars solely hexadecimal? And when I create a new one is it just a series of zeros until I write other data to it?

Appvars are whatever you want it to be. However, in Grammer, you have a few ways of editing them, including writing bytes to it through hexadecimal and numbers. For example, if Z points to the appvar:
int(Z,37 will write to the first byte of data the value 37.  The number is 0 to 255 and can be a variable.
Z[(111213 will write 3 bytes to Z in hexadecimal. They are 11h, 12h, and 13h. in decimal, that is 17,18, and 19.
Z[77,23,47 will write three bytes to Z, also

And there are a few more ways to do this. Basically, if you write a byte at Z+13, when you read it, it should be the same.

As for creating new vars, the data is filled with all zeros until you write to it It used to contain data that was not necessarily all zeros, but  changed that, so that is a good question.

And are tokens one byte each?

Not all tokens are 1 byte each. Some are 2 bytes
I am curious about what you are going for here

You say the tilemap data is series of numbers, so is it 0000 for four tiles or 00000000 for four tiles? And is zero the first tile or no tile at all? And do I need to convert the hex to token? I plan to store everything in appvars.

Hmm, tilemap data is a series of bytes. So however you want to think of bytes is how tiles are stored. If you think of them as two hexadecimal digits smushed together, then 00000000. If you think of them as just solitary bytes, they can be 0000.

0 is the first tile, indeed. And there is no need to write hex or tokens as you can just do something like int(Z,0. However, if you have the data sitting somewhere you can copy it using the solve(1 command. It might be a bit tricky, though.

To save space, how can I have no tiles at a position, without having a blank sprite in the tileset? Or do I need to do that, have the blank sprite as the first sprite?

You will need a blank tile in the set it does not need to be the first sprite, technically, but I normally do that. If you make it the second sprite, for example, then to write a blank tile, you would use tile 1 instead of tile 0.

I've never seen that one, but his Uncle Worm is probably one of the best-known TI-83 Plus games of all time. And from the links on his TI|BD page, I found out that he's ported it to Android.

I've heard of it but never played it

That's funny—a famous calculator game getting ported to a phone

Imagine that being said back in 1990 First, a game being made for a graphing calculator. Second, the same game being made for a phone.

And yeah, there is so much stuff that isn't known by us newer folks. That is why I am glad this has been started. I learned that this had been made for the calc a long while ago before I made Grammer:
http://tift.tuxfamily.org/projects/fastrpl
I mean, look at these screenies:



I think that is fairly awesome.
EDIT: The first is called gravity pong, the second is minesweeper, and the the third is a snake game. I am pretty sure that is all at 6MHz, too, as it was designed for the TI-83+.

EDIT2: I learned about this from deeph-- a member of the TIFT team and one of the organizers of last years zContest. The team is a french team, I believe.

I am now officially back from vacation, so here goes (be prepared). First off, though, I like your game!
I completely forgot to add in a description of how maps are stores, so I will try to do it properly here First, each tile is stored as a single byte. The byte tells which tile to draw using the tile set you define. You can use the program I gave to make the tile set, too (it will be in the proper format for tilemaps). Tilemaps can be variable sized as long as it is big enough to fit the screen (8 down, 12 across). To edit the tilemap, I used this code in my map editor:
If getKey(9
int(G+C+X+W*Y+B/8,F

err, sorry, I accidentally clicked to submit the post. Continuing:

G points to the map data
C is the x-offset into the current region displayed
X is the x-offset into the map data
W is the width in tiles of the map
Y is the y-offset into the map
B is the y-offset (in pixels!!) into the current region displayed
F is the tile number to write

So if you want to use a 128x128 tilemap, you would need 16384 bytes of RAM free. I hope this helps a bit more?
EDIT: Also, I have been playing with GramCrft and I like it! You should post a new topic about it sometime!

Burr has done some great work so far with documenting since February: http://tibasicdev.wikidot.com/ti:home

I have already learned of some amazing things I never knew. For example, I wonder how many of the new folks are familiar with this TI-83+/84+ game? Check out the page on the programmer Badja

You could also write a sub routine to generate pseudo-random numbers that can be seeded >.>

Also, great post, DJ_O