I had this idea that I plan to apply to Grammer once I totally free up saveSScreen of other uses. During the wait loops of updating the LCD, I can compare the current byte wanting to be updated with the corresponding one in saveSScreen (or some other buffer). If they are the same, don't update and go to the next byte. If they are different, copy the new byte to the saveSScreen location and update that spot on the LCD. At the worst, it will use the same amount of time to update the screen. I know this isn't the best for situations where consistent timing is important, but where you want purely speed (like 3D rendering and whatnot), this could be very useful. I figured this might save a few frames per second for folks

I'll try to write up some code when I have time .___.

EDIT: Also, what are some other ways that I can use to update the LCD as fast as possible (that will work in all cases).

Ah, cool And I am glad that uses safe mode. Also, why would it take more time if it is updating a lot? I'll look at the code to figure it out...

I made an attempt at this and that was the problem that I ran into. The overhead was about 20 cycle longer than the delay in 6MHz. Of course, that still made it faster than my current routine (because I didn't use the method of drawing columns first).

Wow, I just checked it out on youtube and I am going to check it out on MaxCoderz. That looks really neat Also, that seems like a great example of where this kind of update would speed things up. Often there is a lot of black space that does not change. For the curious,