LCD Controller?

Can I ask what model is the LCD and LCD controller? :slight_smile:

The LCD is custom made for us by ****** in China

Reason for this is to ensure availability and price

Controller is ST7775R

@uXe and welcome to the community!

Thanks! :grinning:

Which interface are you using? SPI? or parallel / RGB?

Its parallel. The glass is standard, but we have our own connector.

Cool! So, parallel RGB (with HSYNC & VSYNC pins)? or parallel MCU?

1 Like

Parallel MCU (16-bit)

Exploring the datasheet for the LCD controller, looking at this table for the display RAM addressing:

So… if a 220x176 bitmap was stored as an array of 16-bit RGB values, then the 177th value in that array would represent the 2nd pixel across in the top row of the image (illustrated below) if I am understanding correctly? :confused:

Correct. And that is one of the ways I optimize for speed. I don’t do addressing if it can be avoided. Switching data/command mode takes time and is one of the places where I need to slow down to get the LCD to respond correctly.

Shouldn’t it be possible to use these DRAM direction settings (below), so that the 2nd pixel across as illustrated above would more logically be the 2nd value in an array (not the 177th)?

1 Like

Yes it is possible. I however dont do that in the Pokitto, because there was some problem (i think it was a missing pixel at far end) on some of the displays i was testing with this driver. It could have been my code but in the end i decided to not use it.

The order in which the dram is drawn doesn’t make a difference. The routines take care of that.

I know people will find lots of places to improve the pokitto code. And i think that process will be awesome to follow.

i dont see why, you got to end up sending the hole screen buffer anyway

But its really cool to play around on a hardware level. You can “dig” for all sorts of hidden gems!

Well, say for example you created a 220x176 title screen in some pixel art program and export that as an array of 16-bit RGB values… the tools you are using would need to support this format (having the 2nd pixel across be the 177th value in the array) otherwise there’d be a whole lot of on-the-fly conversion needed to draw that image to the screen buffer?

i can write you one right now if you want? i have not looked at the sprite specifications idk if there was one in the documentation yet

here is some unoptimized example code
its super slow, any large image basically make the browser freeze.
can rewrite this in c but i am very tired right now :sleeping:
its setup for pico8 pallet if its not using the exact same rgb data it wont work

Also, thinking ahead - would be much simpler to implement a VGA shield for example if the pixels in the screen buffer were already in the more ‘logical’ / ‘conventional’ order… Anyway, just thinking out loud, definitely not meant as some kind of a criticism!

1 Like

I have never made a VGA shield so I don’t know how they work. But the only problem is incrementing the memory pointer by += screen height instead of 1 to access next pixel and restting to zero at end of scanline. Some performance damage but nothing catastrophic. Also, Pokitto already has 1, 2, and 4 bit drawing modes. If an additional mode with different memory mapping is needed, its not as big deal as you might imagine.

1 Like