Hmm, what do you mean by that? I am assuming it wrote an incorrect command to the LCD port to change it to 6-bit mode, but I see nowhere in my code that that could happen...

What where you doing when it compressed it? Like, what program or commands were you using?

Hmm, what is your calculator (83+/84+/SE)?

Hmm, I am not sure what is wrong There are no writes to the LCD port that would cause this, so my only other idea is that it is writing to a RAM address that it isn't supposed to, but I did add in checks to make sure it wouldn't write outside of the screen  I've no clue what is wrong Has it done this using the current version? maybe I added the code to prevent writing outside of the screen after releasing the previous version?

Okay, I will change that, then Thanks!

Also, I am working on adding a feature for particle effects that will let you use other pieces of RAM. However, if I do this, then the current setup won't work (which means my examples won't work and any work done with the particle features won't work with the new version).

Is this okay for people?

EDIT: Actually, never mind, I will just add code to make it all still work I will just change the default buffer to appBackUpScreen

Okay, now I see binary has something to do with it. Still kinda confused though.

Heya and welcome to the forums awalden0808. Just so you know consecutive posts by the same author in one thread are not allowed within less than a few hours so you have to use the edit button within that time (unless somebody else replied already). I unfortunately cannot help on Grammer, though, as I have never used it. Hopefully Xeda112358 shows up soon and can answer your question(s).

Hi and thanks! I was actually gone for about a day and a half and just got back! So let's see, you are having trouble with the sprites? Well as Yeong mentioned, 0=32, but in binary that is 00100000, so 8 zeros would draw an 8x8 sprite of just a column of pixels.

I still need to add a command to use hex data for sprite data, but for now, you can try this:
-Draw the sprite in the upper left corner of the graph screen
-Copy this code to a program and execute it:
.0:Asm(prgmGRAMMER
Lbl "SPRITE→A
Pt-On(4,A,0,0,1,8       ;This swaps the data on screen
ClrDraw
Pt-Off(0,A,0,0,1,8       ;Draws the sprite back
DispGraph
Stop
Return                   ;Executed by TI-BASIC
.SPRITE
00000000            ;8 bytes for the sprite data
-When you open up the program, the 00000000 line should be replaced with the sprite data

The way this works is that with the Pt-On( command, using option 4 will replace the sprite on the screen with the sprite data (it swaps everything). I hope this helps and it is awesome knowing more people are interested!

Also, in the program you just gave me, the "SPRITE->A line stores the line after .SPRITE into A, correct? And if I want to show my sprite in your example program in the PDF (where you can move the sprite around) I just replace the 01234567 with the code?

Okay, here is a breakdown of what it does:
the Lbl "SPRITE→A kind of does what you think. Technically, it stores the memory location of the line after .SPRITE. So a neat biproduct of this is this: Say you have two sprites stored after .SPRITE. If you wanted to access the second sprite, just do A+8 (assuming the sprites are 8 bytes).

So to answer your question about the sprite data, you do simply replace the 01234567. If you wanted to, though, you could do some other crazy things (like make a program to store all your sprites in), but that is a little more advanced If you want an example of doing this, feel free to ask!

And the code I'm getting back is really messed up (e.g. + and randM(({->??). It's supposed to be like that, right?

Yes, it is supposed to be like that, which is kind of unfortunate (especially if you wanted to copy the data by hand). I will see what  I can do about adding support for hex data to make your lives a bit easier.