Table des matières
Bitmap VGA output (Old version / Deprecated)
WARNING This page is kept only to keep continuity with the previous modules. For new designs, prefer the new version.
Before the implementation of any of these modules, please, check if your design leaves enough memory resources for the required memory. Logic requirements are negligible and working frequency is above 395MHz in most cases.
( figure source )
- n : number of address bits (resolution dependant)
- bpp : number of bits/pixel (configurable)
- reset is active high
addressing a pixel
Pixels are addressed by lines from the top left to the bottom right. For example, using a 160×100 resolution, the top left pixel has address 0, its right neighbor has address 1, and the top right pixel has address 159 (0x009F). The Left pixel of the top second line has address 160 (0x00A0), and so on. The bottom left pixel has address 15840 (0x3DE0) and the bottom right has address 15999 (0x3E7F).
Different resolutions are available :
- 160×100
- 160×120
- 320×200
- 320×240
- 640×480
Pixel coding
All resolutions are available from 1 bit/pixel to 12 bit/pixel. It is possible to chose between colored or greyscale for color depth of 2, 3 and 4 bits / pixel.
1 bit/pixel
The graphic memory only contains 1 bit/address to match the pixel coding. The output is then black for '0' and white for '1'. As the VGA interface is coded using 4 bits / color (or 12 bits / pixel). It is possible to modify the white value by any other with simple logic gating.
2 bits/pixel
The pixel value is encoded with 2 bits. The generic parameter grayscale makes it possible to code the screen as monochrome if set to true, if omitted, it is considered as false and display will be colored. The corresponding values are as follow :
Value (MSB:LSB) | Color | Grayscale |
---|---|---|
0:0 | Black | Black |
0:1 | Blue | Dark Grey |
1:0 | Green | Light Grey |
1:1 | Red | White |
In each case, the color is set at its maximal intensity.
3 bits/pixel
Here again, the generic parameter grayscale makes it possible to code the screen as monochrome if set to true, if omitted, it is considered as false and display will be colored. With this coding scheme, each bit represent a primary color. Each individual color is always set at its maximum. The next table lists the expected colors.
Value | r | g | b | Color |
---|---|---|---|---|
000 | 0 | 0 | 0 | Black |
001 | 0 | 0 | 1 | Blue |
010 | 0 | 1 | 0 | Green |
011 | 0 | 1 | 1 | Cyan |
100 | 1 | 0 | 0 | Red |
101 | 1 | 0 | 1 | Magenta |
110 | 1 | 1 | 0 | Yellow |
111 | 1 | 1 | 1 | White |
4 bits/pixel
The 4-bit representation is very similar to 3-bit. There is the possibility to use it to code grayscale or colored pixels. For colors, it uses the same scheme as 3-bit for the chrominance, and uses the MSB (4th) bit to code luminance. When the MSB is 0, colors are dark, when the MSB is '1', colors are bright. It is worth mentioning that dark white is a gray which is lighter than bright black.
5 bits/pixel (3 level coding)
Using this color scheme, colors are coded in RGB format where R, G and B may take three values (dark or 0, medium or 1, bright or 2). The corresponding values are then coded as an integer given by : (R*9 + G*3 + B). This representation only provides 27 different colors where 32 are actually possible, but it is a good compromise to provide RGB coding with low memory resources.
6 bits/pixel and above
Beyond this point, pixel values are coded using RGB representation. The table below shows how bits are split to provide the expected coding :
bpp | Red | Green | Blue |
---|---|---|---|
6 | 2 | 2 | 2 |
7 | 2 | 3 | 2 |
8 | 3 | 3 | 2 |
9 | 3 | 3 | 3 |
10 | 3 | 4 | 3 |
11 | 4 | 4 | 3 |
12 | 4 | 4 | 4 |
memory usage (Artix 7)
All combinations could not be tested, so the information below may be incomplete. Please not that the following values are given for the Artix 7 family synthetized with ISE 14.7 .
- For 160×100, half RAM block use the ability to split a 36kb block into two 18kb blocks. So using the 3bpp color representation requires one 36kb block and one 18kb block (the second half of the 36kb block used is still available)
- For 320×240, the synthetizer is not able to split blocks because of address counting, so using a 3bpp representation will actually require 8 blocks (7.5 rounded to 8).
- For 640×480, memory requirements may be very high, resulting in very high implementation times.
- Being only a machine, the synthetizer is not able to perform high optimizations. For example, it is possible to use only 5 36k-block RAMs to perform a 160×120 resolution with 8bpp, instead of 8 required by the synthetizer. Implementing this optimization could be a nice project :)
resolution | ISE synthesis | greedy Vivado (v1.1 and previous) |
---|---|---|
160×100 | 0.5 BRAM / bpp | 0.5 BRAM / bpp |
160×120 | 1 BRAM / bpp | 1 BRAM / bpp |
320×200 | 2 BRAM / bpp | 2 BRAM / bpp |
320×240 | 2.5 BRAM / bpp | 4 BRAM / bpp |
640×480 | 10 BRAM / bpp | 16 BRAM / bpp |
Files
Known bugs
Modules use excessively high memory resources when synthetising with Vivado. Versions 1.2 and above should soon fix this issue soon. Til then, 640×480 resolution can only be achieved at 8 bits/Pixel. (9 bits/pixel might work but was not tested, please give feedback concerning this limitation).