Further to our earlier convesation.
You implied that a monochrome frame buffer might be possible. The thing is, even assuming 4-bit, 16-greyscale (or greenscale!) operation, that works out to (2404004)/8/1024 = 46.875kB of RAM, which isn’t available.
Am I overlooking something? Because this would make it possible.
About the alternative approach of summing up 10 scanlines then writing frame buffer info for each:
Assuming we grabbed every fourth scanline, which would probably be acceptable, that means 240 scanlines per frame, ten scanlines per buffering period, and thus 240/10=24 retrievals of all columns from the TFT per frame. Assuming 25fps that means 2425=600 getcolumn() calls per second. At 240 pixels per column, assuming your estimate of 4 ARM cycles per pixel, that’s 600240*4 = 576,000 cycles per frame just spent retrieving data from the TFT, which is not feasible.
So, this is not going to work either, again unless I’m overlooking something.
Is getpixel() slow? Does it just call getcolumn() behind the scenes? Because if it’s reasonably fast, that would work too.
Edit: a 200x120 (half-resolution) 4-bit greyscale image is just about acceptable and would require 11k of RAM; am I likely to have 11k of RAM available after the Pawn interpreter is running? Would there be enough CPU time to blow this image up to the display, nearest-neighbour style?