I hooked up a TFT display like the one you referenced to my first 6502 computer, it worked quite well. I think it was 320x480 resolution, 16-bit colour, with a fairly easy-to-use parallel interface, even for a complete novice - I'd only just understood how the CPU, ROM, and RAM could work together and share buses.
yep! they're pretty easy to hook up and use. similar to character LCDs.
Although it was a command-based interface, the display I got didn't have much in the way of built-in drawing operations (lines, region copy, etc) - it mostly just let you define a rectangle and stream pixels into it. But it did support hardware scrolling I think.
oops sorry, i misremembered the capabilities. turns out that most of those commands were implemented in software by the arduino library i was using to test them.
but yea rectangular selecting, writing, and scrolling are hardware features.
The main problem I had once it was connected up was the volume of data to send to the display - as each pixel took two bytes, drawing was fairly slow. So as you guys are suggesting, I wanted to add some circuit in the middle to help the CPU out. I came up with a crazy design for allowing the CPU to write an 8-bit RRRGGGBB byte and having the intermediary layer split it into 16 bits RRRRRGGG/GGGBBBBB then send both bytes to the display on consecutive clock cycles while the CPU was busy fetching the next instruction, but it was way beyond my capability at the time, didn't work, and I didn't have the experience to really know how to diagnose it. Looking back, with a better design I think this could be not too complicated to do, and would double the throughput.
hmm, mapping 8-bit colors into the TFT's 16-bit colors seems doable.
using an IDT720x FIFO, and a ROM acting as LUT, all hooked into a CPLD (like an ATF1508) with an SPI Core+Logic, you could have the CPU dump all data into the FIFO, and then go do something else while the SPI core "slowly" chews through it's stockpile.
this not only increases the speed at which the CPU can push data by shrinking the Pixels down to a single byte (or even smaller), but it also makes better use of the bandwidth to the Display.
because the SPI Core feeds itself at maximum speed from the FIFO, instead of having the CPU continuously checking the busy flag, and then waste cycles loading and storing the next byte before going back to checking the flag. (though of course a parallel interface wouldn't have that issue)
though you would need to have 2 write ports to the FIFO, one for pixel data which goes through the LUT first, and one direct connection to the SPI core for everything else (like commands).
plus you would need a second port to the SPI core since you also need to be able to read from it as well, and the FIFO is unidirectional.
or alternatively:
have a write only port (through the FIFO and LUT) for pixel data, and a seperate read/write port for normal SPI operation (and to access some internal status/control register).
godammit now i'm also getting dragged into this idea!
i'm already thinking about the logic design and if i could fit this on an expansion card for my SBC.
i do have some spare ATF1508's, IDT702's, and SPI TFT Displays lying around....
(Though the effect will probably be barely noticeable.)