I have had a frame buffer controller component that I have been working on and using for a while.

The frame buffer controller component takes care of rendering a frame buffer on a display device. For my system the frame buffer is main memory which is shared with several other devices. The controller may read and write individual pixels to the frame buffer. It handles this as pixels are in bitfields in 128-bit strips of memory. Computing the pixel location, inserting or extracting a pixel would be a time-consuming operation for the cpu. The cpu need only supply the pixel coordinates and color and the frame buffer controller takes care of updating memory.

The frame buffer supports a variety of color depths and display resolutions. From one to twelve bits per color component are supported.

The latest set of modifications include adding a 256-byte PCI config space to the controller and allowing it to accept a 32-bit address. The controller now looks at the PCI config to determine what address to respond to. It has a default address of $FD04xxxx. Also added display virtual to physical address mapping. Up to 128MB may be mapped and used by the frame buffer. Setup the first 2MB of the map so that it points to $200000 thru $3FFFFF. That is enough memory for two pages of an 800x600x16bpp display.

Could you add a font cache to the frame buffer? I am thinking of unicode here, that has very big fonts.

The font cache caches data for font display. I am not sure how the frame buffer controller would use the font cache. The controller has only the capability to plot points, not draw characters. I also have a graphics accelerator component which I usually leave out of builds because it makes the system too large. It can handle drawing raster fonts. Given coordinates and a character code it will draw the character into the frame buffer. The fonts are stored in tables in main memory. Main memory reads are cached in a system cache, so I do not think another cache is necessary.

The CPU or graphics accelerator can draw fonts so I think it may make more sense to have a font cache associated with them. For the CPU the font cache would just be a buffer in regular memory, no dedicated component required.

An issue with caching fonts is that they can be large, and there is not resources in the FPGA for a large cache.

Reduced the number of color depths to four different ones, 8, 16, 24, and 32-bit to simplify the controller.

Developed a test pattern generator, TPG, for the frame buffer. The TPG acts as a replacement for memory. It responds to memory requests output by the frame buffer and passes data back to it. The data is RGB information calculated based on the display address. The TPG is useful when the system’s CPU or the memory system does not work and there is no way to setup an image in the RAM. The TPG varies the timing of the response to simulate memory latency.

I think putting a Finitron logo in a bitmap may be useful as a test too.

More work on the frame buffer. Posted at opencores.org. Made the palette using a RAM macro rather than using a core generator component.

The display is rock-solid display of random data from the DRAM. The display mode is 800x600x16bpp = 80MB/s. There is at least 80 MB/s bandwidth from the DRAM. In theory the available bandwidth should be much higher. Would expect there is considerably less than 800MB/s available.