One thing to mention is that the Asset Builder has a feature where it can re-calculate the addresses of the fonts in the bin file. When generating the flash in the 'Generate Flash' tab, if you have the .xfont file with the same name in the same folder as the glyph file, it will adjust the data address of the font accordingly. This means you don't need to re-convert the fonts a second time and will save a lot of time.

Now this is really interesting, thank you Graham! 

I tested it and it changes a 16 bit word at offset 0x20 of the .xfont file, both in the original file and
in the flash image.
This puzzled me at first, this is the start of graphics data.
But instead of the absolute address it is the number of a block the size of 32 bytes, just like what BITMAP_SOURCE
is used with to display a picture from FLASH.
So 0x0080011e at offset 0x20 means that is in FLASH at address 0x11e * 0x20 = 0x23c0.
And the following glyph adresses are all relative to this start address.

Nice, so most of what I tried to get a number of fonts into FLASH was pointless since the adress
we use the "Generate Font" tool pratically becomes meaningless when we use "Generate Flash".
I like that.

Unfortunately, with this working as intended, I have no idea left why my fonts are not working.

And since I also used the "User Guide" while playing with the EVE Asset Builder, I noticed that it does not
match version 0.4.2.
It appears to be written for 0.4.1. and there have been some changes to the Asset Builder that did not make
it into the "User Guide".

I have a problem with the EVE Image Converter.
I needed an image for a project and in order to comply with corporate identity I asked a colleague
who does graphics design for a couple of departments, mostly to create apps.

He had a fitting image in his library and sent me a couple of .png files with a variety of resolutions derived from a vector drawing.

Now the problem is, the images he sent me are 32 bit .png, the 8-bit alpha-channel is used for anti-aliasing.
And he made a very convincing argument that this is quite normal in graphics design.

The problem I have is that img_cvt.exe completely ignores the 8-bit alpha channel.
Everything that is in the alpha-channel gets to be transparent and so any anti-aliasing is lost.
And the dither option makes it even worse, at least it can be disabled now.

https://www.fontsquirrel.com/tools/webfont-generator
The resulting notosans-regular-webfont.ttf only has 222 glyphs.

Then I converted the font using the EVE Asset Builder.
ASTC block footprints: Auto
Compression Speed: thorough
Addr of Font Data: FLASH

I did this for font-sizes of 12, 14, 16, 18 and 20.

At first I converted all fonts to FLASH address 4096.
Then I put together a flash file, putting .glyph and .xfont files in pairs in it:

notosans-regular-webfont_12_4096.glyph               : 4096   : 119936
notosans-regular-webfont_12_4906.xfont               : 124032 : 5056
notosans-regular-webfont_14_129088.glyph             : 129088 : 120064
notosans-regular-webfont_14_129088.xfont             : 249152 : 5056
notosans-regular-webfont_16_254208.glyph             : 254208 : 269760
notosans-regular-webfont_16_254208.xfont             : 523968 : 5056
notosans-regular-webfont_18_529024.glyph             : 529024 : 270016
notosans-regular-webfont_18_529024.xfont             : 799040 : 5120
notosans-regular-webfont_20_4096.glyph               : 804160 : 180032
notosans-regular-webfont_20_804160.xfont             : 984192 : 5120
chipsie_40x56_40x56_COMPRESSED_RGBA_ASTC_8x8_KHR.raw : 989312 : 576

Then I redid the .xfont files by re-compressing the fonts in "veryfast" for the addresses.

I wrote a litte test code, put in the numbers and got five lines of cmd_text() output.
Ah yes, I copied all the .xfont data to graphics memory and I used bitmap-handles 10...14.

Now, the problem was, only the first and the last line were okay, the other three had broken chars.

So I re-compressed the 14/16/18 fonts again in "thorough" for these addresses and replaced all files.

Now the third and the fourth line still have broken chars. And in different places.

So I started to hack this into a spreadsheet.
All the addresses are 64 byte aligned.

Then I tried to read notosans-regular-webfont_16_254208.xfont with a hex-editor.
0x0100aaff - signature
0x00001395 - size of 5013, gen-flash rounds that up to 5056 which is a multiple of 64
0x000093b5 - format
0x0000024a - swizzle
0x00000030 - width
0x00000006 - height
0x00000018 - pixel width
0x0000001e - pixel height
0x00801f08 - start -> 0x1f08 = 254208
0x00010000 - num of glyphs -> 65536 - this is wrong and the one other font (184 glyphs) I checked also had this number
gptr/wptr/widh data - not sure how to really interpret these

Now, what else could I try to put a bunch of fonts into the FLASH?

And on a side-note, the amount of bitmap-handles really is a tad bit low, having annother 32 at least would be nice.

You could either scale down the .jpg in order to fit two into GRAM and scale them up to 800x480.
Or, with the BT815, it should be possible to use ASTC instead.

I have not tried if this works but chapter 6 in the programming guide states:
"With enough ASTC images in flash memory or RAM_G, it is
possible for user to construct an image-rich GUI application."

COMPRESSED_RGBA_ASTC_4x4_KHR has 8 bits per Pixel, the other formats use less bits per pixel.

At least with the EVE Asset Builder it takes quite some time to convert images to ASTC though.

At least https://29a.ch/photo-forensics/ shows a difference then between the original file and the one I saved with IrfanView.

Original structure:
    SOI
    APP0
    DQT
    SOF0 (Baseline DCT)
    DHT
    DRI
    SOS
    EOI

New structure:
    SOI
    APP0
    DQT
    DQT
    SOF0 (Baseline DCT)
    DHT
    DHT
    DHT
    DHT
    SOS
    EOI

So the new file does not only have two DQT entries but also four DHT entries.
Oh yes, and no DRI entry, whatever a "Define Restart Interval" is good for.

I have a board that is populated with a BT816 and a Winbond 25Q128JVSI.
There also is a FT232H on the board I can connect to from the EVE Asset Builder as "MPSSE".

I generated an "output.bin" with only this "unified.blob" and a single small image in ASTC 8x8 format.
But I can not write it to the FLASH, not even after I resorted to use progflash.exe directly.

D:\FLASH>progflash
Welcome to BT81X Flash Programming Utility V0.0.5
Copyright(c) Bridgetek Pte Ltd All Rights Reserved

Usage: ProgFlash [command] [argument]

module       Select Program Module [ FT4222 (default) | MPSSE ]
erase        Erase all of flash
newblob      Install blob <file_name> in flash
write        Write <file_name> to flash (assumes flash is already erased)
update       Write <file_name> to flash, erasing if necessary
read         Read all of flash into <filename>

D:\FLASH>progflash module MPSSE erase
 Information on channel number 0:
 Flags=0x2
 Type=0x8
 ID=0x1b3d0200
 LocId=0x433
 SerialNumber=0k2LWMY6
 Description=USB 2 SPI
 ftHandle=0x0

handle=0x6d4330 status=0x0
VC1 register ID after wake up 7c

 reg_touch_rz =0x7fff
 reg_touch_rzthresh =0xffff
 reg_touch_tag_xy=0x80008000
 reg_touch_tag=0x0

Progress ERASE 1
Erasing Flash...
Progress ERASE 90
Progress ERASE 100
Erase Flash successfully

DONE!

I was about to additionally ask why erasing takes this long but then I just found that the datasheet for this chip
specifies 40...200 seconds for a chip erase.

Now when I try to write this is what happens:

D:\FLASH>progflash module MPSSE write output.bin
[exactly the same lines repeated as above]
Progress BLOB 1
Writing Blob file ".\unified.blob" to BT81X Flash Storage
Progress PROG 0
Write Blob file ".\unified.blob" to BT81X Flash Storage successfully
Progress WRITE 1
Writing Flash file "output.bin" to BT81X Flash Storage (assumes flash is already erased)
Progress PROG 0
Progress PROG 83
Verify Flash failed!
Write Flash file "output.bin" to BT81X Flash Storage unsuccessfully
Exsiting ...

The first thing that is strange is that progflash.exe insists of writing "unified.blob", it is even required to have a file of that name in the same directory as progflash.exe.
However, genflash.exe always adds this mysterious blob to the first 4096 bytes - and I see no way around this, neither from the Eve Asset builder or from using genflash.exe directly.
So it really looks like progflash.exe is shooting itself in the foot there.

Okay, annother erase then, followed by an update command:

D:\FLASH>progflash module MPSSE update output.bin
...
Progress BLOB 1
Writing Blob file ".\unified.blob" to BT81X Flash Storage
Progress PROG 0
Write Blob file ".\unified.blob" to BT81X Flash Storage successfully
Progress UPDATE 1
Writing Flash file "output.bin" to BT81X Flash Storage, erasing if necessary
Progress PROG 0
Verify Flash failed!
Write Flash file "output.bin" to BT81X Flash Storage unsuccessfully
Exsiting ...

Still does not look like it is working.

A "progflash module MPSSE read empty.bin" after an erase results in a 16MB sized file filled with 0xff.
That is fine, although it would be somewhat nicer if it would not save all the empty pages from the end of the data to the end of the flash and even would not save a file at all for an empty flash.
Why? Well, because that would allow copying the content of a flash from one board to annother even when the second board has a smaller flash than the first one, given of course that the first flash is not full but one would be able tell by the size of the file if it will fit or not.
Also writing only the necessary data should be faster.

Okay, "progflash module MPSSE write output.bin" again and it fails again, or at least it says so.
Followed by "progflash module MPSSE read notempty.bin".

Now I compared this "notempty.bin" to "unified.blod" and "output.bin" and it turned out that I wasted a couple of hours to look into a problem that is not even there.
The "notempty.bin" and "output.bin" are exactly the same for the length of "output.bin".

Please update the EVE Asset Builder, it is still on the first release and out for over six months now, thank you.
And please add a "verify" option to progflash.exe in case you do not already have.