Frame buffer Rotation for portrait LCD module

[all2coolnick]

I've made some progress with the little TFT module I told you about. I've got the 3-wire, 9-bit SPI configuration command communication working to put it in RGB mode (I can execute basic commands like all pixels on and all pixels off) so now I'm working on the RGB data. I'm not getting anything on the LCD using the standard picomac video out signals (minus the resistors) but I assume this is because the LCD module is 480x640 portrait (with no rotation command). I'm guessing it can't make sense of the data and sync signals.

I've been trying to understand your video code to find the best way to write the frame buffer out as portrait but I'm stuck. I stepped through pio_video.pio but as I understand it, this is essentially just reading the data from the output shift registers so does not control the order the data is read from the frame buffer. I've looked at video.c but what I can't seem to locate is the code loop that continually reads the frame buffer and sends the data to the pio registers. Could you give me a pointer (no pun intended)?
I thought it might be simpler to modify this code to read the framebuffer in a different order (bottom to top, left to right) but as you wrote all this amazing code, is this how you would do it?
The other option I can think of is trying to modify umac to actually write the frame buffer in portrait but then I would still need to modify the read code so it was sending 640 lines of 480 pixels rather than vice-versa.

I'm linking all the 565RGB data inputs to the LCD panel and driving these directly from the picomac video data pin. I can't think of any reason why that would not work since all I need to send is either all 1s or all 0s. Would you foresee any problems with this approach? The TFT module has two RGB modes; DE and HV. That latter is what I'm trying to use as this does not require the Data Enable which I know you have not implemented yet.

Thanks as always,
N

[all2coolnick]

Ok, so following a deep dive into the Pico DMA documentation, I can see that’s what is reading from the frame buffer as a continuous stream so reading every 480th bit for a scan line might not be possible with DMA. Could I use the second DMA to copy the frame buffer to a new FB organised as 480x640 and tweek the existing dma to output 480 pixel lines from the new FB?

[all2coolnick]

Am I right in thinking that the code that writes the video to the frame buffer is part of the Mac ROM, not your umac code?