Today I received two SST26VF064BA-101I/SM from Microchip which I bought from Mouser.
Instead of the industrie-standard 50...180 seconds for a chip-erase these do a chip-erase in 50ms max.
I soldered one onto my RVT43ULBNWC00 and tested it with the EVE Asset Builder.
The whole "Erase" action takes less than five seconds now which really is great for testing things.

Edit: after some tries and no help with this here I gave up on the SST26VF064BA-101I/SM now.
Yes, the chip-erase is very fast.
But as it turns out, EVE refuses to write to these.
The SST26VF064BA-101I/SM are detected correctly with the right size, but cmd_flashwrite does not write
anything to the chip.
And there is no output from the EVE Asset builder to indicate what could be wrong.

I removed the SST26VF064BA-101I/SM again and put back the 64Mbit flash that the RVT43ULBNWC00 was deliverded with.
And after a (painfully long) erasing of the chip with the EVE Asset Builder my test aplication used cmd_flashwrite just fine
for a small file containing the unified.blob and two images.

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.

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.

I am a bit disapointed now that the BT81x still has the handbrakes VERTEX2F und VERTEX2II in place with no alternative.
The need to shift the coordindates into the bit-positions only wastes time.
Especially since by default pixel precision for VERTEX2F is 1/16 - and for whatever reason that is.

Looking thru the user-manual I recognize though that it is just not possible to add a VERTEX3F command.
VERTEX2F is 0x01nnnnnn and VERTEX2II is 0x10nnnnnn, neither a 0x00nnnnnn or a 0x11nnnnnn would work because that would make it indistinguishable from the other commands.
This might be the reason why this has not been touched.

However, there would be a way out.
There are 21 reserved bits in VERTEX_FORMAT.
Bit 3 could have been used to change the format of VERTEX2F:
Bit 0...13 = Y
Bit 16...29 = X

With 1 bit less in resolution as a trade-off the frac-value of 0 would be -8192 to 8191, same as 1 and so the maximum pixel precision would be 1/8 pixel.

Can we have this as a patch please for both the FT81x and the BT81x?