If it maintains the same speed having only a z80 we are extremely lucky.

Even if the display is as fast as possible, the Z80 will be a bottleneck.  Assuming the screen is 8 bits per pixel (a 256-color palette) and assuming a 20 MHz clock rate, the fastest possible drawing algorithms would be on the order of one pixel per microsecond (except, perhaps, to fill the screen with a solid color or pattern.)  If you're redrawing the entire screen for every frame, one pixel per microsecond translates to about 13 FPS (and remember, that's if the CPU is doing nothing else.)

Programmers will need to be very clever in order to get decent performance from this thing.  That said, the programmers in this community are pretty clever.

(Just had a fun thought that contradicts what I said above: executable sprites.  If you're willing to reduce your palette to 3 colors at full resolution, or 10 colors at half resolution, you could encode your sprites as Z80 machine code and draw about 1 pixel for every ~6-8 clock cycles.  So, like I said, clever hacks.)

If there are no wait states, OTIR becomes a possibility. Of course, only if we can scrape together enough RAM for that to be useful.

Hmm, that could be very useful in sprite routines.

FloppusMaximus is quite the optimist.

I'm sure TI had the same thoughts and decided not to use a memory-mapped solution, because who cares if it flickers whenever the screen is updated? Besides, it's a real snub to those awful game coders.

We've counted the pixels in this photo and it appears that the graph size is 265x165 pixels (which goes along with TI tradition of having an odd number of pixels for symmetry reasons).

I feel like the LCD driver probably has its own internal RAM and you output to that somehow (once the borders are initialized you never need to worry about them again)

if this unti has it's own "video ram" for displaying pictures that would be excellent. We wouldn't have to worry about putting them in user ram. It seems that would make the most sense.