Oberon/ETH Oberon/Writing a display driver

#F0FFF0 This document was originally hosted at ETHZ. It remains under the ETH license and is in the WayBack archive. Writing a display driver Here are some guidelines when writing a new display driver (for release 2.3.6). The driver is contained in a module called Display. The source code of existing Display modules in the Source1.Arc archive can be used as a starting point, e.g. SVGA.Display.Mod (generic) or S3Trio.Display.Mod (accelerated). Extending the generic SVGA driver (SVGA.Display.Mod) is a relatively simple programming exercise if bank switching and BIOS mode setting information is available for a card. This information for most cards is available in vgadoc (see Recommendations). Empty.Display.Mod contains a skeleton of a display driver. It includes the canonical comments about the display module definition. Also see Trace.Display.Mod, an null display module that displays trace code of all display operations. It is available in the standard release. To try it out, enter the config strings "Init=90", "Display=Trace." and "TraceBPS=-1". The new display driver must have exactly the same interface as the existing module. Never use the \s switch when compiling a new Display module! Leaving this switch out will prevent the compiler from ever overwriting the definition file, thus avoiding problems. If you compile your Display module, it will overwrite Display.Obj. This is ok, because the loader will normally load the Display module from a file called xxxDisplay.Obj, where the xxx prefix is what has been configured with the Display="xxx" configuration string during installation. To test your module, the Display configuration string has to be set to the empty string (see Configuration Strings below). You can boot the system and temporarily change the string by entering "Display=" at the OBL> prompt. Another testing strategy when developing an accelerated driver is to install one of the framebuffer-based drivers (e.g. SVGA.Display) on your development system. Because this driver performs all rastering directly in the frame buffer, and does almost no other communication with the display card, it will be possible to develop and test your accelerated driver as a normal Oberon module, without interfering with the framebuffer-based driver. When your driver is completely tested, you can rename it to Display and do final testing. The display mode setting can be done in the boot loader before Oberon has booted. It is therefore not always necessary to write Oberon code to set the display mode. You can use the real-mode video BIOS to do this, via the Init configuration string (see below). However, the video BIOS on most cards conservatively set the refresh rate very low. If you want a more ergonomic rate, you might have to resort to some register programming. In this case a technical reference for the card is required. From version 2.3.4 onwards the Display module definition supports optional fast framebuffer access via the TransferBlock procedure. The minimum support is to simply program a HALT statement in TransferBlock, and make TransferFormat return "unknown". However, your driver will then not support newer tools like the new Magnifier or Gfx library based on TransferBlock. Writing a TransferBlock procedure is very similar to writing a DisplayBlock procedure, except that the former also has to be able to read from the display. From version 2.3.4 onwards the Display module definition also supports optional Truecolor support. The minimum support is to write a TrueColor function that always returns FALSE, indicating that the driver does not support truecolor. However, your driver will then not completely support newer truecolor-capable tools like the Gfx library. Note that although the module definition uses 24-bit truecolor values and 8-bit indexed color values, the actual display mode can be 15-bit, 16-bit, 32-bit or anything. Your driver just has to translate the truecolor values on-the-fly to the display format. It is even possible to write a truecolor driver that maps the colors to a fixed 8-bit palette. In addition, you can select the TransferFormat (for TransferBlock) that is most convenient to you. This table summarizes the capabilities of the current display drivers: Driver Truecolor TransferBlock GD54xx no no Permedia2 (new beta) yes yes S3C805 no no S3C924 no no S3Trio yes yes SVGA no no VGA no no W32 no no 26 Aug 2001 - Copyright © 2001 ETH Zürich. All rights reserved. E-Mail: oberon-web at inf.ethz.ch [expired] Homepage: blue http://www.ethoberon.ethz.ch/native/ [expired]