BRT Community

I know that the REG_SWIZZLE function is to ease board layout reordering the RGB signals so that traces can be routed in a better way…

But what about the BITMAP_SWIZZLE display list function? does it have a *practical* use? I really can't see any, maybe there some useful way for it.

The only thing I could relate it to is to handle priority to the ASTC encoder (usually alpha is less prioritized, for example) but astcenc has options to tune it.

I know that from a display list perspective a font is a cell from a bitmap (i.e. an handle). How does the coprocessor handle
fonts with more characters (i.e. with extended metrics)? Does it use multiple handles or reconfigures on the fly the handle to another address?
I also suppose that the ASTC font cache works copying from flash to ram and configuring the handle to work from ram, am I wrong?

Thanks in advance

Oooh that's interesting. I've pondered about many ways to do it but not a bitmap. Thanks for the info

As shown in https://www.ftdichip.com/Images/CleO/CleO50-TutorialPics.png it seems the MCU on the CleO somehow coerces the FT810 into drawing tapered lines… how is that done?

- Multiple overlapping lines?
- Somehow changing line width between points?
- Magic?

We are thinking to evaluate the BT816 for use with an 800x480 TFT panel. However calculations show issues with the required memory bandwidth for ATSC compressed images. Please correct me if some of the assumptions are wrong.

The FTDI is clocked at 72 MHz. Nominal dot clock for the panel is 40 MHz, maximum 50 MHz, so using the PCLK divider we run at 36MHz. From timing specs the horizontal raster time is 862-1200 dots (1056 nominal), giving 2112…2400 master clocks to build a scanline using the display list.

Now, from the datasheet and the ATSC 2×2 tile organization it is strongly inferred that the texture line cache size is 64 bytes: 2×2 ATSC blocks are 64 bytes, every address in flash must be multiple of 64 bytes and so on.

The fastest way to access the SPI flash is in quad SPI XIP mode, which is what the firmware blob I assume does… in this mode from the chip select the memory needs: 6 cycles for the address, 2 for the mode/address extension, 4 dummy cycles for access latency and then it outputs the data. So for a 64 byte transfer you need 44 master clocks.

Since a scanline runs for 2112…2400 clock you can only have 48-50 tile transfers in a line (for a 2×2 ATSC block tile). At the minimum compression level (4×4 texels for block) a tile represents 8×8 texels, so to hypotetically fill a full size background image (800 pixels) you would need 100 tiles and that doesn't fit the timings.

This is of course a bit extreme (since it's kind of a worse case, we could use bigger blocks and so on) but if there are many bitmaps (i.e. many characters) on the scanline, the texture unit/rasterize can definitely starve. What happen in this case? The condition is not described in neither the datasheet nor in the programming manual.

- The bitmap is not drawn? (like the old game console with something like max 5 sprites for scanline)
- The display list stalls? like when the display list is too long and there is no time to render all the pixels
- Something else?

On a smaller 480×272 panels there is a lot more time (because there are a) less pixels and b) dot clock is usually about 8MHz) so probably it isn't a concern, and I will try to lower the dot clock to see if it's feasible; this panel is currently running on the FT810 without issues however it seems to be quite sensible to the clock (for example it hangs if I try to do a snapshot) so I'd like to know what would actually happen if the scanline timing are exceeded due to memory accesses.

Thanks in advance
Regards