For embedded PC solutions there is support for standard VGA cards. For more cost and space sensitive devices it makes sense to build your own hardware. For simulation purposes there is a X-Windows framebuffer emulation making testing of your application (and the toolkit !) much easier. The following discusses these three options in more detail.
The generic (old) VGA compatible cards can be used with the 1bpp and 8bpp modes. In these modes the host CPU has transparent access to the framebuffer, i.e. each byte from the framebuffer is directly accessible by the host CPU. Traditionally the VGA card occupies 64KB address range from 0xa0000 to 0xaffff. This limits the possible resolution to 800x600 for 1bpp modes and 320x200, for 8bpp mode. The legacy VGA modes which are present in all VGA cards practically limits the number of available modes further to the following two:
LILO-SVGA | legacy | |
Mode Code | VGA-Mode # | Resolution | Color depth
| (Int10,AH=0) | |
-----------+--------------+------------+-------------
0x111 | 0x11 | 640 x 480 | 1 bpp
0x113 | 0x13 | 320 x 200 | 8 bpp
Fortunately modern PCI VGA cards can map a larger amount of the framebuffer into the host address space. Current VESA compatible cards, supporting VBE2.0 or above (VBE stands for VESA BIOS Extensions) typically have additional flat linear frame buffer modes available which can be used together with picoTK. The following table shows these VESA modes.
LILO-SVGA | VESA | |
Mode Code | VGA-Mode # | Resolution | Color depth
|(Int10,AX=4f02)| |
-----------+---------------+------------+-------------
0x300 | 0x100 | 640 x 400 | 8 bpp
0x301 | 0x101 | 640 x 480 | 8 bpp
0x302 | 0x102 | 800 x 600 | 4 bpp
0x303 | 0x103 | 800 x 600 | 8 bpp
0x304 | 0x104 | 1024 x 768 | 4 bpp
0x305 | 0x105 | 1024 x 768 | 8 bpp
0x306 | 0x106 | 1280 x1024 | 4 bpp
0x307 | 0x107 | 1280 x1024 | 8 bpp
picoTK relies on foreign software to switch into the required VGA video
mode. Together with RTEMS this is easily done using the pc386_lilo
package found on the RTEMS homepage. LILO can set the legacy VGA-BIOS mode
as well as the VESA modes before launching RTEMS. Note that not all modes
are necessarily supported by each card - the LILO bootloader will stop if
a specified video mode is not supported. The VESA modes have no fixed
frame buffer address - as the Legacy modes have; but LILO can tell the
frame buffer start to RTEMS and picoTK, which picks it up (the base
address is stored in the boot segment INITSEG at 9000:0018 equalling
linear 0x90018 as physical 32 bit address). For a general discussion on
VGA hardware/software and the many different operating modes used here see
[1] and [3]; and take a look into pc386_lilo/video.S.
Non VGA hardware requires custom logic to readout the framebuffer and feed the pixel data to the display. Today this can easily be done using programmable CPLD chips. As framebuffer a static RAM can be used. The RAM is quasi simultanously addressed by the host CPU and address counters within the CPLD. Since the CPLD logic can be tailored to the applications needs, it need not to be register configurable at run-time. This has two distinct advantages: It makes the implementation of the logic easier. It removes the need for the software to initialize the framebuffer logic after power on.
picoTK contains a framebuffer emulator (fbe) which emulates the
framebuffer hardware under X-Windows. The emulator uses Unix shared
memory inter process communication [2]. With real framebuffer hardware the
framebuffer is located at a fixed and well known address (e.g. 0xa0000 for
VGA hardware). When using the framebuffer emulator the emulated frame
buffer base address is returned by the mmap()-call when initializing the
shared memory. From the application point of view, obtaining and setting
the framebuffer address is the only difference between real hardware and
emulation. The framebuffer emulator constantly looks at the shared
memory, interprets its contents and updates its graphic window accordingly.
The application and the framebuffer emulation asynchronously access the
framebuffer shared memory. The application reads and writes the
framebuffer, while the emulator reads only.
The fbe can emulate all supported picoTK color depths. The color depths
is set by starting fbe with appropriate parameters. The resolution and
zooming can be set as well. Execute fbe -help to get a list of available
options.