I’ve been flicking through the datasheet for the screen and apparently its possible to read pixel data back from the screen using command 0x22.
Does anyone know anything about this? Is the hardware even setup to make it possible?
Read Data from DRAM (R22h)
RD [17:0]: 18-bit data read from the DRAM. RAM read data RD [17:0] is transferred via different
data bus in different interface operation. When the ST7775R reads data from the DRAM to the
microcomputer, the first word read immediately after RAM address set is executed is taken in the
internal read-data latch and invalid data is sent to the data bus. Valid data is sent to the data bus
when the ST7775R reads out the second and subsequen t words. When either 8-bit or 16-bit
interface is selected, the LSBs of R and B dot data are not read out.
i cant think of any application for reading data from the screen
Its possible. The read/write select line is connected
If we can read, copy and paste memory from and back to the screen, then we can make some cool glitch effects (examples from my pico8 game):
The above “glitches” take a part of the screen and procedurally paste it elsewhere on the screen.
most of the games are buffered its faster using the screen buffer for these effects
since your not reading from external device
you dont need to read the screen to have full color sprites
hmm i guess you could do that, also a paint program or just creating screen shots for the none buffered games
I think that the LCD has more ram than just the physical screen area, so we could use the outside area to store things maybe…
you sure thats not used by anything else like states or settings
That’s is a great idea if there is non-visible screen memory
is this for real?
we only using like 1/4th the display ram?
i guess this is basically intended for screen scrolling
It does look that way. I assume the expect people to use hardware scrolling and reduce data writes.
If that is for real it is a huge amount of memory! The native screen resolution buffer is: 220 x 176 x 2 = 77.5 KB.
So we can store extra info for each visible pixel also? That’s cool!
no so you send 16bits per pixel from the cpu to the display in RGB565 format and the display chip converts that to 18bit RGB666 i guess
Here’s an idea! use it for double buffering when using direct pixel modes. Simple draw the gfx to an off screen region then jump to it with hardware scroll then repeat… I wonder if hardware scroll or screen offset or whatever lets you do that.
oh man having double buffering would basically solve the direct draw overlap issues