All FT8xx so far have 8k of memory for the display-list, that is 2048 32-bit words.
Expanding this to 64k would be nice on first glance but then everything still would need to be executed for every single frame.
So at the same time the chip would need to be much faster.

This reminds me of a different "issue".
The divider for the clock only works well for small displays.
800x480 is configured to 928 h-cycles und 525 v-cycles, that are 487200 clock-cycles.
A typical value for the divider would be REG_PCLK = 2 which means that a FT81x uses 30 MHz.
In return these settings result in about 61 frames per second, nice.

Now I have this 1024x600 TFT from Glyn.
For some reason (I suspect a flaw in the design on Glyns side) these can not be used with the full clock of 60MHz.
As these are configured to 1100x720 this would result in 75 frames per second anyways.
The recommended value is 20MHz and therefore 25 fps and they work well with 30MHz which results in 37 FPS.

The issue I have there is that the divider does not allow for fractional values, so I could not configure it to
use 45MHz for example which would result in 56 fps.

Now the upcoming BT81x uses 72MHz.
That is nice, so the 1024x600 panel could be used with 45 fps.
The 800x480 panel at REG_PCLK = 2 would run with 73 fps so we need to make that REG_PCLK = 3.
But then it would be clocked with 24MHz and "only" 49 fps.

If for whatever reason you would need to fine-tune the frame-rate you simply could not do that.
One could come up with the idea to manipulate the base-clock but the datasheet does not give a frequency range, the only allowable frequency is 12MHz.
The PLL could be changed to multiply by 2...5 (6 with BT81x).

At higher resolutions this would even become more of an issue.

Do I want higher resolutions or do I need them?
No, not really, I would be fine with 4 pixels per mm for HMI. Or make that 8 pixels per mm.
The typical 800x480 7" has 11 pixels per mm.
But what I need are bigger displays and there close to none 800x480 or 800x600 panels bigger than 7" out there.
And the bigger panels do not only have higher resolutions, they also typically do not have a RGB interface anymore but LVDS instead.

Among a few other things I just added timings for all the Riverdi modules I had no timings for so far.

The VM810C, ME812A and ME813A all use the WVGA settings.

Thanks, I will add that.

Note that the ME810A-HV35R requires configuration of the ILI9488 inside the LCD panel via the dedicated serial interface on the LCD ribbon cable. You can find an example of this in the file ILI9488.h in our sample apps such as FT_App_Gradient.

Well, after a look in the datasheet and after checking out ILI9488.c of that example I better give this one a pass.
With no way to test this this is just to weird unique to support. Maybe if someone asks for it.

With the discussions here around the ME813A-WH50C module I just thought it would be a nice touch to add timing parameters for a few of the newer modules to my library.
ME813A-WH50C
ME812A-WH50R
ME810A-HV35R
VM810C50A-D

But there are no timing parameters to be found, not even the ones from the panel datasheets.

BRT_AN_018_FT90x_Camera_to_EVE\eve\EVE_config.h has these:

#if FT8XX_DISPLAY == WVGA
#define EVE_DISP_WIDTH 800 // Active width of LCD display
#define EVE_DISP_HEIGHT 480 // Active height of LCD display
#define EVE_DISP_HCYCLE 928 // Total number of clocks per line
#define EVE_DISP_HOFFSET 88 // Start of active line
#define EVE_DISP_HSYNC0 0 // Start of horizontal sync pulse
#define EVE_DISP_HSYNC1 48 // End of horizontal sync pulse
#define EVE_DISP_VCYCLE 525 // Total number of lines per screen
#define EVE_DISP_VOFFSET 32 // Start of active screen
#define EVE_DISP_VSYNC0 0 // Start of vertical sync pulse
#define EVE_DISP_VSYNC1 3 // End of vertical sync pulse
#define EVE_DISP_PCLK 2 // Pixel Clock
#define EVE_DISP_SWIZZLE 0 // Define RGB output pins
#define EVE_DISP_PCLKPOL 1 // Define active edge of PCLK
#endif // FT81X_WQVGA

But with no reference whatsoever for what module these parameters are supposed to be used.
Are these good for the three 5" modules with 800x480?

What parameters should be used with the ME810A-HV35R then?


Well, if FTDI/BRT would send me a sample ME813A-WH50C and ME810A-HV35R I would gladly tests these for use with my library and put these into my extensive collection of EVE modules. :-)

This is how I control the backlight

Why? What purpose serves that calculation?

I just use a 8-bit memory write:
FT8_memWrite8(REG_PWM_DUTY, 0x10);

And the valid range is 0...128.

As I wrote, there is no function to draw arcs or circles directly.
The follwing is untested, just a bunch of code put together adhoc from existing code and modified.

Drawing a circle:
   FT8_cmd_dl(DL_BEGIN | FT8_POINTS);
   FT8_cmd_dl(DL_COLOR_RGB | mycolor);
   FT8_cmd_dl(POINT_SIZE((diameter + (2*width))* 16));
   FT8_cmd_dl(VERTEX2F(some_x * 16,some_y * 16));
   FT8_cmd_dl(DL_COLOR_RGB | background);
   FT8_cmd_dl(POINT_SIZE(diameter * 16));
   FT8_cmd_dl(VERTEX2F(some_x * 16, some_y * 16));
   FT8_cmd_dl(DL_END);

Drawing an arc:

       fill_arc_array();

   FT8_cmd_dl(DL_COLOR_RGB | color);
   FT8_cmd_dl(LINE_WIDTH(width * 16));
   FT8_cmd_dl(DL_BEGIN | FT8_LINE_STRIP);

   for(counter=0;counter<31;counter++)
   {
                FT8_cmd_dl(vertex2f_arc_xy[counter]);
   }
   FT8_cmd_dl(DL_END);

So the second assumes that you have a vertex2f_arc_xy[] array with 32 bit values filled like this:
vertex2f_arc_xy[n] = VERTEX2F(some_x * 16,some_y * 16);

This can be pre-calculated data, maybe with the help of a spreadsheet or calculated on the fly between to points
in the plane and probably a radius to go with that.

The result of this can be seen somewhat in this picture:
https://github.com/RudolphRiedel/FT800-FT813/blob/master/example_pics/FT811_HY50HD.jpg
That graph on the right consists of a line-strip with 64 points with fixed values for the sample code.
That sine curve on the far right only has a fraction of that points and still looks decent.

But as I wrote above, this eats the display-list, you have to find a a trade-off between just enough points for the arc and a really smooth one.

For static display elements however using pictures of arcs would be far superior in terms of resources used.

You can use the VERTEX2F or VERTEX2II commands to draw graphics primitives including lines/arcs.

Actually, no, there is no command for drawing arcs or full circles, that is something I am missing in the FT8xx as well.
You can draw a circle by drawing a POINT and then a smaller one with the background color on top of it.
Plus you could draw a RECT to mask out a portion of that circle for an arc.

And you could in theory use a LINESTRIP to draw an arc but that would not only require quite a lot VERTEX2F commands for a decent arc and therefore eating up the available space in the display-list fast, it also is a pain for the controller to calculate since the Y coordinate has to be shifted into that odd bit-position for every VERTEX2F.

The third option would be to use bitmaps, if you can't draw it on the fly, fake it. :-)

However, I have a home icon saved as a png image and I converted it to a hex file which I used in an array, and I followed same sequence in displaying the start Icon, but it not display when I run the code. Could anyone say what I need to change in the code below so that that png icon is displayed. I tried changing format from L4 to ARGB4, but no success.

Did you convert the .png to a hex file or did you convert it with the image-convert utility?
If you are trying to load a plain .png there is a chance that there is nothing wrong with your code since EVE is a bit picky about PNGs in generell.

Also this might help: https://github.com/RudolphRiedel/FT800-FT813
https://github.com/RudolphRiedel/FT800-FT813/tree/master/example_projects/FT8xx_Test_90CAN_FT813_EVE2-35G

This is a bit specific as it is for AVR and a EVE2-35G module from Matrix Orbital, however this example is a bit smaller than my others
and it includes loading and displaying of a .png image.

Although, while PNG has adantages over JPG for icons - it should compress a little better and is lossless - loading PNGs is really slow compared to JPG.

Best Regards, Rudolph