If you don't know binary there is no reason why you can't learn now.
Lets start by reviewing the number system you're probaly used to, the decimal system. It is called the decimal system because there are ten digits. 0 1 2 3 4 5 6 7 8 9. Now you probaly write zero as 0 but for the time being lets call it 0000. ( this will help you with binary later) If you increment 0000 by 1 you get 0001. Now if you do this eight more times you will have 0009. Now we are going to call the digit on the far right the zero's place, the second to right the one's place and so on. The dilema you now face is that there is no digit above 9. (No 10 is not a digit!) So what you can do now is increment the digit to the left of nine to one and you reset the 9 back to zero. 0010. Hey look you got the number 10  . Okay so you're probaly thinking I already know this, but to learn binary you need to go back to the basics and learn the fundamentals of all number systems.

Now lets start learning binary. It is called binary because there are two digits 0 and 1. So lets start at zero. You write zero in binary as 0000. Look it is the same thing in decimal. Binary is easy. And if you increment that. Yep you guessed right 0001 is the number one. Now we face an issue. We are all out of digits. So what do we do? We reset the furthest right digit and increment the one to its left. So you get 0010. Now this looks like the number ten but it is really two. Now if we keep on following thsi we get 0011 0100 0101 0110 0111 1000 ans so on. In binary we call each digit a bit. and 8 bits make a byte. In one unsigned (not negative) byte you can write numbers from 0 to 255. Hope you now know binary 

Pop quiz:
1001 =
0011 + 0100 =
1100 - 0101 =

Even if the image format is limited to 8 bit color, it still has to be written in 16 bit in the LCD ram. So this probaly means that the screen image is located in ram and not rom. For the LCD drawing test I'm starting at $B4000000 because that was where the lcd ram for the fx-9860g was located.

If you've used the picture plot app and maually flip through through one of the animation pictures, the screen updates quite quickly.

Okay for some reason in the color menu you can not select white. (It's greyed out  ) I need this feature to erase some lines in programs though. Also I tried Erase color, but that just causes a syntax error.

With the collision detection that was an experiment I was trying with adding life to the game. The number in the top left shows how many walls you can hit before gameover. I don't think I'm going to keep that in the final version. I'm also going to try a slightly different version of the engine where coodinates are stored in a matrix instead of doing the slow pixel test. This would allow the back end of the snake to disapear over time.

I have an idea, but I'm not sure if it is going to work. Unlike the TI 83+ the Prizm has its lcd directly mapped to memory. One screen image on the Prizm takes up 166 kilobytes. What I don't know though is where all this data is. I'm assuming that the Prizm doesn't have more than 1 megabyte of ram. What this means that if I do a few writes to memory I might be able to find where the plotscreen is. This could also really screw up my Prizm too. What I will do is up to one megabyte every 160 kilobytes I will send 32 bytes of one color. Every segment seperated 160 kilobytes will also be a different color. Hopefully when (if)  I get a small line on my screen, I will be able to determine the general memory location. Then later I can narrow that down. to an exact location 

I'm hoping though that later versions include an SD card slot as that would be faster and have more memory.

I'm guessing that booting Wabbit from the Prizm is quite slow. I'm not sure if the Prizm has enough memory for this, but imagine coding a very simple PC OS and placing that on the Prizm and then set your computer to boot from the Prizm. That would be awesome.