Topic : The ATARI Compendium
Author : Scott Sanders / JAY Software
Version : 1.25 (20/6/2003)
Subject : Documentation
Nodes : 1117
Index Size : 32614
HCP-Version : 6
Compiled on : Atari
@charset : UTF-8
@lang : en
@default :
@help : %About
@options : +g -i -t4 +y +z
@width : 100
View Ref-FileVideo ControlThe video capabilities of Atari computer systems have varied greatly
since their introduction. Applications which use the VDI for their video
displays will require little if any modifications to run on new systems.
The XBIOS is mostly required for device drivers and other applicationswhich require more direct control over the video hardware. When present,
the '_VDO' entry in the system cookie jar will reveal information about
the video hardware present.
The Physical/Logical ScreenTwo separate video display pointers are maintained by the XBIOS at any
time. The physical screen address points to the memory location that the
video shifter uses to update the display. This memory must not be in fast
RAM and must be WORD-aligned (original ST computers expect screen memory
to be aligned to a 256-byte boundary).
A second video memory pointer points to the 'logical' screen. This memory
area is used by the VDI to output graphics. Normally, the physical screen
address is equal to the logical screen address meaning that VDI output is
shown immediately on screen. Software (most commonly games) can allocate
an additional memory block and use these two pointers to page-flip for
smooth animations.
Physbase() and Logbase() return these ngtwo addresses. Setscreen() can be
used to reset these addresses and change screen modes. As of TOS 4.0,
Setscreen() reinitializes the VDI screen driver (you must still call
vq_extnd() to update your workstations) but will not reinitialize the AES.
This means that if you change resolution using Setscreen(), do not use the
AES until the screen is restored to its original resolution. On TOSversions prior to 4.0, you should not use any GEM calls while the screen
mode is altered.
The Falcon030 function VgetSize() is a utility function that will return
the number of bytes that must be allocated for the specified video mode.
When not running on a Falcon030, you will have to calculate this
yourself.
Setting/Determining Screen ResolutionGetrez() was originally a safe method for determining the current video
hardware configuration. As new video modes became available, though,
Getrez() became less and less useful. Currently, Getrez() should be used
for only one purpose. The formula Getrez() + 2 should be used to select
the VDI physical device ID for the screen so that the proper screen fonts
can be selected. See the description of v_opnvwk() for more details.
In order to provide true screen independence, you should use the values
returned by the VDI call v_opnvwk() to determining the screen resolution
your application is using. The XBIOS provides calls that will determine
the current video mode but they are hardware dependent and will probably
stop working as expected as new video hardware is released.
The Getrez() call can reliably determine the video mode of an ST, STe or
Mega ST/e. Three calls have since been added to determine the video mode
of the TT030 and Falcon030 computers.
EgetShift() and EsetShift() can be used to interrogate and set the TT030video mode. VsetMode() can similarly be used to interrogate and set the
Falcon030 video mode. The Falcon030 call VgetMonitor() can be used to
determine the type of attached monitor and, therefore, the available video
modes.
TT030TOS also provides the calls EsetGray() and EsetSmear(). Together,
these calls duplicate some of the functionally contained in EsetShift()but can be used individually as desired to configure the special
gray-scale and smear modes present in the TT030.
EsetShift() and VsetMode() are designed to change the video modes of the
TT030 and Falcon030 respectively, however, they do not reinitialize the
AES or VDI. It is also possible to change TT030 and Falcon030 video modes
using Setscreen(). TT030 modes are set by supplying the appropriate
resolution code (see Getrez() for a list of resolution codes). Falcon030modes are set by adding an extra parameter to the call with a special
resolution code of 3. See the explanation for Setscreen() later in this
chapter for details.
Manipulating the PalettePrior to the introduction of the TT, Setcolor() and Setpalette() were used
to set the 16 available palette entries. Setpalette() sets the entire palette
at once whereas Setcolor() sets colors at an individual level and can also
be used to interrogate palette entries.
The ST has 16 palette entries, each supporting any of 512 available colors.
The ST specifies color in components of red, green, and blue. Intensity
settings of 0-7 are valid for each color component. The following list
contains the red, green, and blue values for the ST's default 16 color
palette.
Index Color Red Green Blue
0 White 7 7 7
1 Red 7 0 0
2 Green 0 7 0
3 Yellow 7 7 0
4 Blue 0 0 7
5 Magenta 7 0 7
6 Cyan 0 7 7
7 Light Gray 5 5 5
8 Dark Gray 3 3 3
9 Light Red 7 3 3
10 Light Green 3 7 3
11 Light Yellow 7 7 3
12 Light Blue 3 3 7
13 Light Magenta 7 3 7
14 Light Cyan 3 7 7
15 Black 0 0 0
You might have noticed that these registers are not mapped the same as
VDI color indexes. The VDI re-maps color requests to its own needs. For
a list of these re-mappings, see the entry for vr_trnfm(). It is also
possible to build a remapping table on the fly by plotting one pixel for
each VDI pen on the screen and using the VDIv_get_pixel() call on each to
return the VDI and hardware register index.
Each of the sixteen color registers is bitmapped into a WORD as follows
(The first row indicates color, the second is bit significance):
xxxx xRRR xGGG xBBB
xxxx x321 x321 x321
The STe series expanded the color depth to four bits instead of three
which expanded the number of available colors from 512 to 4096. This
changed the layout of these color WORDs as follows:
xxxx RRRR GGGG BBBB
xxxx 1432 1432 1432
This odd bit layout allowed for backward compatibility to the ST series.
The TT030 supports an expanded palette of 256 entries in 16 banks
containing any of 4096 colors. The first bank of colors is still supported
by Setcolor() and Setpalette(), however to access the additional 240
colors, 4 additional palette support calls were added.
Esetpalette(), Egetpalette(), and Esetcolor() provide access to these
colors in a similar manner to Setpalette() and Setcolor(). Esetbank()
switches between the 16 available banks of colors in color modes that
support less than 16 colors. You should note that the TT030 color calls
returned the color WORDs to normal bit ordering as follows:
xxxx RRRR GGGG BBBB
xxxx 4321 4321 4321
When using the TT's special gray mode, the lower eight bits of each
hardware register is used as a gray value from 0-255.
The Falcon030 computer gives up the TT030 calls in favor of a more
portable method of setting the hardware palette (ST calls will remain as
compatible as possible). VsetRGB() and VgetRGB() set color palette entries
based on 24-bit true color values. The XBIOS will scale these values as
appropriate for the screen mode.
Advanced VideoVsync() halts all further processing by the application until a vertical
blank interrupt occurs. This interrupt signals that the video display gun
has reached the bottom of the display and is returning to the top. At this
time, a brief period occurs where updates to the screen will not be
immediately apparent to the user. This time is usually used to present
flicker-free animation and redraws.
VsetSync() is used to enable external hardware video synchronization for
devices such as GENLOCK's. Both the vertical and horizontal
syncronizations may be set independent of each other with this call.
VsetMask() provides easy access to the Falcon030's overlay mode. This
call allows you to specify bits which will be added or removed to future
color definitions created with the VDI call vs_color(). When a GENLOCK
hardware device is connected, pixels with their overlay bit cleared will
be replaceable by the device with external video.