Next Previous Contents

3. Display hardware

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.

3.1 The VGA card as framebuffer

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.

3.2 Non VGA hardware

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.

3.3 The frame buffer emulation

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.

Next Previous Contents