I am trying to reproduce your output but I am not getting up to your number.
I am not using an UTF-8 code to not extra complicate things.

With this:

{
    static uint32_t alive = 0;
   
    if(tft_active != 0U)
    {
        EVE_cmd_dl(CMD_DLSTART);
        EVE_cmd_dl(DL_CLEAR_COLOR_RGB | WHITE);
        EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);

        EVE_color_rgb(BLACK);
        for(uint8_t lines = 0; lines < 15; lines++)
        {
            EVE_cmd_text(10, 10 + lines * 30, 28, 0, "123456789!123456789!123456789!");
            EVE_cmd_text(400, 10 + lines * 30, 28, 0, "123456789!123456789!123456789!");
        }

        EVE_cmd_number(150, 570, 28, 0, alive++);

        EVE_color_rgb(BLACK);
        EVE_cmd_number(100, EVE_VSIZE - 30, 26, EVE_OPT_RIGHTX, display_list_size); /* number of bytes written to the display-list by the command co-pro */

        EVE_cmd_dl(DL_DISPLAY);
        EVE_cmd_dl(CMD_SWAP);
       
        EVE_execute_cmd();
    }
}

I do get 15 lines of text just fine, no problem.
But I "only" get 5284 printed for the size of the display list.
Increasing the lines to 19 this passes 7000 depending on the value of the alive counter.
And yes, still no issue.

Modifying the loop to this:
    for(uint8_t lines = 0; lines < 16; lines++)
    {
        EVE_cmd_text(10, 10 + lines * 30, 28, 0, "123456789!123456789!123456789!123456789!");
        EVE_cmd_text(490, 10 + lines * 30, 28, 0, "123456789!123456789!123456789!123456789!");
    }

It gets up to 8052 - no issue.

Modifying the alive counter to run from 1000 to 9999 to avoid extra digits and adding one extra line:
EVE_cmd_text(10, 540, 28, 0, "123456789!123");
Results in a display list of 8184 bytes.

So well yes, I need more text to get there, but like this I can really use the full display list.
No flickering, just works this way.

Hello,

Thank you for your question, I have queried the development team on the relationship between the .astc and .raw outputs when performing an ASTC image conversion.

You can find the astcec.exe utility and eab_tools.exe utility within the installation folder for EAB, generally this is in the following location:

C:\Users\Public\Documents\EVE Asset Builder\tools

Best Regards,
BRT Community

Hi Rudolph,
We checked with a 7" 1024x600 and also with a 10.1" 1280x800 screen.
Here is an example on the 10.1" screen

Best Regards, BRT Community

 

As I just got a new company style guide to comply with I went thru a number of different fonts and font-sizes today using EAB 2.10.2.
I am using the fourth flash image now with only Roboto font in sizes 12/14/16/18/20/22/24/26/28.
I also tried Ubunto-Light, a couple of other fonts and using odd sizes 19/21/23/25/27.

And well, it just works in all sizes.
My input character file is this:
" !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~©«°±²³´µ¹»¼½¾ÄÖ×Üßäëö÷øü"
So only "Basic Latin" and a selection from "Latin-1 Supplement".


I encountered three "issues".
First one was that EAB 2.10.2 is using the correct size for the .xfont files now and adds a meta-file .pad in between the entries.
And at first I just copied the size for the .xfont file from the .map and used it with CMD_FLASHREAD - but the number of bytes read must be a multiple of 4.
In earlier versions of EAB there was no .pad and the .xfont ended up beeing shown with a size of 320 bytes.

My second issue was that I tried to use bitmap handle 15 for one of the fonts, just counting up from 12, which does not work by default as this is the scratch bitmap handle.

And my third issue was that the bandwith of the external flash is of course limited, even more so with random access, so I can not use the six fonts I set up for display from the external flash at the same time.
Well, I could use the font-cache for at least the largest font and copy all 9 fonts to RAM_G as the flash image is only 275kiB (copying the .glyph to RAM-G also requires to adapt the .xfont file to use the new memory location).
But this is not a real project anyways.

Edit: I tried a couple of things including over-clocking (looked stable at 96MHz but I went back to 72MHz)
I set REG_AH_HCYCLE_MAX to 4000 and now I have the line "Quick fox at 120°C" printed out in six different sizes: 18/20/22/24/26/28 and reading REG_FRAMES once per second and calculating the delta to the previous value shows rather stable 58 to 59.
So that really makes the last point a non-issue as well, even without copying any of the .glyph files to RAM_G.



In regards of EAB 2.10.2 I found a couple of things a bit odd.
- why is "Reserve Space" not set as default?
- why is "L8" selected by default for "Extended Format"?
- why is the ASTC set to 4x4 by default instead of a more reasonable 8x8?
- why is this SampleApp generated every single time? can we please have a switch for that which defaults to off?

Just to update, We were able to fill RAM_DL to 7964 by using text commands with this string (on BT817)

What resolution does the panel have you tested this with?

Hi,

Just to update, We were able to fill RAM_DL to 7964 by using text commands with this string (on BT817)

"123456789\u00B0123456789\u00B0123456789\u00B0"

We will try the NOPs and your other string too to see if we can see the issue, and will update you,

Best Regards, BRT Community

Really nobody can give me a hint?

Oh god, thanks for the tip. I copied it out from an example without thinking.   

cmd_text( 10,  10, 1, 0, "\u00D6sterreicher \u00E4rgern sich \u00FCber \u00E4gypter");

Besides the issue, that is an odd way to work with strings.
I just use UTF-8 encoding for my source files, so in this case I would have "Österreicher ärgern sich über Ägypter" in the text.

EAB 2.10.2