 DISPLAY DRIVERS
 ===============

   Introduction: Computer graphics on the Amiga and graphic cards
   -------------------------------------------------------------
   Here are just a few words on the differences between planar and
   chunky graphic organisation which have already been discussed
   within the chapter on graphic formats.

   "Planar"

   On the Amiga, with its original graphic chipset, the graphic data
   is principally organised in the form of single planes.
   With ECS these are max. 6 Bitplanes (0..16/32 Colours or HAM6),
   with AGA then max. 8 Bitplanes (0..256 Colours or HAM6/HAM8).
   These planes have to be understood as the single levels of the bytes,
   which contain the number of the colour registers to be used.
   So bitplane 0 contains "one after the other" the lowest and
   bitplane 6/8 the highest bits of these bytes.
   The reason for this is how the custom chips of the Amiga
   work. Also certain advantages in speed which will appear when
   using less than 256 colours (for example only 63 or 128).
   With chunky modes this does not matter since 8 Bits per pixel (1 Byte)
   will always be used in contrary to the planar mode where only
   as many bytes as actually needed (1-8) will be used.

   Additionally, at least two ways exist to represent data
   as bitplanes. The first one is just called "planar" (from "plane").
   The second one is "interleaved", since the lines of the
   single planes do not follow each other but instead
   are interleaved together.
   This has just been mentioned for reasons of completeness - and because
   it is a special feature of the AGA chipset:
   for more information you should read specialised literature.


   "ChunkyPixel"

   The ChunkyPixel representation of graphics is the most simple of all
   and in most cases where 256 colours are to be displayed perhaps
   also the fastest one.
   There's not much to say about this one, the colour register numbers
   will simply be stored line by line - as much as needed.
   Depending on the width and height of the graphics, these are
   written from left to right and top to bottom into a rectangle
   memory area which in the best case would be identical with the
   graphic memory of an optionally used graphic card.

   There are also derivatives which usually only appear when
   saving graphics and which take 4 Bit pixel pairs which then will be
   represented by a single byte. This is only possible, when only up to
   16 Colours (4 Bit) are represented by a single chunky byte so that the
   free space may be used for simple compression.



   "TrueColour"

   Quite often 16 and 24 Bit TrueColour graphics may be wrongly
   called "ChunkyPixel" which is not actually correct.
   Although "chunky" is not wrong, "chunky pixel" is reserved
   for palette based data.


   Using the standard graphic mode with PMPro
   ===========================================

   Displaying graphics from outside and within PMPro is managed by
   SuperView-Library. When speaking of SuperView from now on,
   this will mean the Library in conjunction with PMPro.
   In general, SuperView knows planar (BITPLANE) as Chunky- and 
   TrueColour (both ONEPLANE) graphics.
   It has to be mentioned that only the most common derivatives are
   supported to not overload the applications with a whole bunch
   of variations.
   So without confusing the user other formats will automatically be
   converted internally to the required format just before the graphic
   is ready to be used after the loading has finished.

   The following table shows the system behind this:


      up to      256 Colours (planar)      BITPLANE
      up to      256 Colours (chunky)      ONEPLANE  8 Bit (Palette)
      more than 256 Colours (TrueColour)   ONEPLANE 24 Bit (RGB-Values)

   Which format that is used internally for representation mainly
   depends on how the data has been stored within the source graphic
   file format so that the least amount of conversion overhead
   will be needed.

   Why this is so will become clear when coming to the displaying of 
   graphics. Depending on the output medium, either chunky or planar data
   will be faster. It really does not matter whether this conversion
   will be or has been done before or during the display operation.
   When using chunky in general, this might mean multiple conversion
   (planar ILBM file -> ONEPLANE -> displaying on AGA as bitplane),
   as well as using bitplanes in general (e.g. converting 24 bitplanes to
   RGB TrueColour values).

   So it makes more sense to use the format which comes nearest
   to the original data (minimal conversion amount) and which only
   converts when the data actually has to be processed
   for displaying in another format.

   With SuperView-Library and many other graphic programs this "dualism"
   of bitmap and chunky graphics is the reason for long display times
   of planar graphics on chunky displays and vice versa.

   Therefore, this means for example that IFF-ILBM is 
   displayed faster on AGA than e.g. BMP but that a graphic card
   perhaps will display BMP quicker on the screen than IFF-ILBM.

   When using the SuperView-Library system the user in general does not
   have to concern themselves since this work will automatically
   be managed by the specific application of superview-internal display-
   drivers (SVDrivers). However, it may be useful to know which format
   would be the fastest one for their own system configuration.
   In the end it makes sense to save newly created graphics for your own
   usage only in either Bitplane OR Chunky formats.

   This does mainly concern 8 Bit graphics (256 colours with palette),
   since 24 Bit does not allow such assumptions: 24 Bit RGB data
   in chunky representation will always be used no matter how these
   have been stored within the source file.
   There are really strange ways to save 24 Bit graphics but only this
   one has actually become a standard even if the single vendors of
   display engines and graphic cards seem to have different opinions
   about representing these internally as either BGR or RGB values...



   SVDrivers - display drivers of PMPro
   ====================================

   The following display drivers are currently available for the PMPro:


   Display/card   SVDriver         Requirements              Shows:

   ECS            ECS              ECS*, OS V2.04+ (V38)     8/24 Bit
   AGA            AGA              AGA*, OS V3.00+ (V39)     8/24 Bit
   CyberGraphX    CyberGraphX      CyberGraphX RTG System    8/24 Bit
   EGS-System     EGS7             EGS-Graphic-Libraries V7  8/24 Bit
   Picasso II     Picasso II       Picasso II-Card           8/24 Bit
   OpalVision     OPAL             OpalVision Card           8/24 Bit
   RetinaZ2/Z3    Retina           Retina ZII/ZIII Card      8/24 Bit
   Merlin         Merlin           Merlin Graphics Card      8/24 Bit



   ECS / AGA
   ---------
   Special ECS/AGA optimised SVDrivers which nevertheless will also work
   - when driven in RTG mode - in up to 256 Colours with graphic cards
  (* no AGA chipset needed).

   The following settings are possible/necessary for configuration:

                          ECS/AGA

                        - 24BITOPERATOR=<OperatorName>
                          ; (case-sensitive, ".svoperator" may be added)
                          ; e.g. "24BITOPERATOR=24BitToHAM.svoperator"
                          ; or   "24BITOPERATOR=ExtractGrayScales"
                          ; specifies which operation should be performed
                          ; on 24 Bit graphics _before_ displaying them
                          ; (if not specified, "best guess" colours will
                          ;  be used, which is really slow)
                        - BITMAPCOPY=<DIRECT|RTG>
                          ; "BITMAPCOPY=RTG" prevents AGA.svdriver from
                          ; directly copying into Bitmaps which will
                          ; result in a usage of more memory but keeps it
                          ; working.
                          ; Default is "BITMAPCOPY=DIRECT".
                        - SCREENINFRONT
                          ; Put Screen to front _before_ the graphic
                          ; has been displayed (useful with GfxCards)

                          ECS only

                        - 8BITOPERATOR=<OperatorName>
                          ; (case-sensitive, ".svoperator" may be added)
                          ; e.g. "8BITOPERATOR=ExtractGrayScales"
                          ; specifies which operation should be performed
                          ; on non-ECS graphics (more than 16 Colours in
                          ; HighRes, more than 32 Colours in LowRes, HAM8)
                          ; (if not specified, will be used to display)


   CyberGraphX
   -------------
   This driver displays any 1-8 or 24 Bit graphics on the
   CyberGraphX RTG-System.
   More than 256 colours will either be displayed in 16 or 24 Bit,
   depending on preferences and/or free memory.
   HAM6/8-data will be converted to 24 Bit.
   Only CyberGraphX screen modes will be used.

   The following settings are possible/necessary for configuration:

                        - EMUSCREENDEPTH=<16|24>
                         ; beginning depth for opening CyberGraphX Screens
                         ; Default is 16 Bit (which will also be tried
                         ; if opening a 24 Bit Screen fails)
                         ; This does not concern colour depths < 16 Bit,
                         ; except HAM6/8.
                        - SMALLSCREENS
                         ; unless this KeyWord is specified it is not
                         ; possible to open screens smaller than 320x240

   EGS7
   ----
   This driver displays any 1-8 or 24 Bit graphic on the
   EGS Workbench emulation system. Any data will be displayed in 24 Bit.
   HAM6/8 data will be converted to 24 Bit.

   There are no further settings possible/necessary.


   Picasso II
   ---------
   This driver displays any 1-8 or 24 Bit graphic on the
   Picasso Workbench emulation system (not tested with
   the cloned vilintuisup.library of CyberGraphX - so the
   CyberGraphX driver should be used).
   More than 256 colours will either be displayed in 16 or 24 Bit
   - depending on preferences and/or free memory. HAM6/8-data will
   be converted to 24 Bit. Only Picasso screen modes will be used.

   The following settings are possible/necessary for configuration:

                        - SMALLSCREENS
                          ; unless this KeyWord is specified, it is not
                          ; possible to open screens smaller than 320x240
                        - EMUSCREENDEPTH=<16|24>
                          ; beginning depth for opening Picasso Screens
                          ; Default is 24 Bit (if opening fails, it will
                          ; try to open a 16 Bit Screen)
                        - AUTOSCROLLADJUST
                          ; this keyword will force Autoscroll whenever
                          ; it would make sense, but the Picasso Software
                          ; would not manage it by itself (when either
                          ; only width or height need to be autoscrolled)


   OPAL
   ----
   This driver allows the display of graphics on the Framebuffer-/video card
   OpalVision, which allows a max. 768x512 at 15KHz.

   The driver is included with kind permission of Steve Quartly.
   We cannot therefore guarantee full functionality.


   Retina
   ------
   This driver displays any 1-8 or 24 Bit graphic on the
   Retina Workbench emulation system.
   More than 256 colours will either be displayed in 16 or 24 Bit,
   depending on preferences and/or free memory.
   HAM6/8-data will be converted to 24 Bit.

   The following settings are possible/necessary for configuration:

                        - EMUSCREENDEPTH=<16|24>
                          ; beginning depth for opening Retina Screens
                          ; Default is 24 Bit (if opening fails, it will
                          ; try to open a 16 Bit Screen)

   Merlin
   ------
   This driver displays any 1-8 or 24 Bit graphic on the
   Merlin Workbench emulation system.
   More than 256 colours will either be displayed in 16 or 24 Bit,
   depending on preferences and/or free memory.
   HAM6/8-data will be converted to 24 Bit.

   The driver is included with kind permission of Thomas Eigentler.
   We cannot therefore guarantee full functionality.

   There are no further settings possible/necessary.

