Can I ask what model is the LCD and LCD controller? 
The LCD is custom made for us by ****** in China
Reason for this is to ensure availability and price
Controller is ST7775R
Thanks! 
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? 
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 
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