i replaced STRIPLINE through POINTS and also LINES.
Well, both require less computations in EVEs graphics backend,
i can totally see that making a difference.
I merely changed the precision to remove the multiplications on the controller side.
My value for EVE_HCYCLE is also 1344.
This made it much better:
Code: EVE_memWrite32(REG_AH_HCYCLE_MAX, EVE_HCYCLE + 500);
Also i don't understand what it does?
This allows EVE to extend lines by additional clock cycles and there gives it more time to compute the display-list.
Here is something weird though.
I calculated the time per line in µs based on HCYCLE and the pixel clock.
EVE3_43G: 53.278 µs
EVE3_50G: 25.778 µs
RVT50H: 34 µs
RVT70H: 26.353 µs
RVT101H: 20.282 µs
So actually the BT817 on the RVT70H with 1024x600 has more time per line than the EVE3_50G.
I am using the EVE3_50G with 36 MHz pixel-clock due to limited options to setup the pixel-clock with the FT81x and BT815/BT816, the value for HCYCLE is 928.
On the RVT70H the line is much longer with 1344 and I am using a pxiel clock of 51 MHz.
The time per visible pixel is lower for the RVT70H though - if that even is a valid concern.
I ordered a RVT50HQBNWC00-B as I do not have a BT817 with 800x480 so far.
And I will test what happens when I lower the frame-rate by reducing the pixel-clock.
Edit: I played with it some more.
Now I am using two DMA transfers to reduce the time for the actual transfer, just to make sure
everything is within my intended timing of 50 changes per second.
And I was wrong before, 190+190+190+190+150 is not the limit.
I have it currently running with 6 x 255 Segments, the size of the display-list is 7400 bytes.
The frames per second actually dropped from 60 to 57/58 - which is to be expected when EVE is allowed to lengthen the lines to compensate for more complex lines.
The complexity per line is key.
When I change the last block to overlapped with these before -> tilt.