video_modes.txt

- Phil Gossett
  6/27/95

Overview
-----------

The video interface performs the second pass of the antialiased z-buffer
algorithm used in the rdp. It also generates the video sync pulses for
NTSC or PAL in both interlaced and non-interlaced modes, for both 16 and
32 bit color pixels, at either high or low resolution, with or without
video filtering for deflickering interlaced video. It can optionally also
rescale the image in order to sacrifice resolution for rendering speed,
making it possible to load balance the per-pixel rendering time.

This document first describes in some detail the functionality of the
antialiasing parts of the video interface.  It then describes the
video interface control registers, and their use for the 28 supported
video display modes.

Note that this document only describes the "normal" modes, supported in
the gbi.h macros. For NTSC and PAL, these should suffice for almost any
imaginable circumstance. However, the sync generation circuitry is more
general than it needs to be, and could be programmed for other video
formats (provided the hardware has sufficient bandwidth).


Antialiasing
---------------

The bulk of the video interface is devoted to the second pass of
the antialiased z-buffer algorithm. In the point sampling modes,
this circuitry is effectively bypassed.

The main goal of this algorithm is to produce an antialiased rendering
of polygonal surfaces without the need for sorting. The key to
achieving this goal is to split the antialiasing problem up into
several pieces, each of which is readily implemented.

There are basically three different kinds of antialiasing. The first
is the antialiasing of textures within polygons. This is accomplished
by the texture hardware, using the industry standard mipmapping
technique.  This uses tri-linear interpolation to produce a correctly
sampled texture lookup. (The details of this are beyond the scope of
this document.)

The second kind of antialiasing is the blending of poly fragments
within the pixels they share. The classic example of this is the
pinwheel, where alternating black and white triangles meet at a center
vertex. The pixel within which this vertex lies should be the average
of the colors of all the triangles which share this vertex, weighted
by the area of the pixel at the vertex covered by each of the
triangles. (The details of this are also beyond the scope of this
document.)

The third kind of antialiasing is the blending of the silhouette of a
foreground object against the background. This is traditionally done
at rendering time in the blend unit. Unfortunately, doing it at this
time has bad consequences for z-buffering.

Consider an internal edge of a surface (i.e., an edge shared by two
visible polys not at the silhouette). A priori, when the first of the
two polys is rendered, the blender does not yet know whether it is a
silhouette edge (and hence needs to be blended with the background),
or an internal edge (and hance should not be blended with the
background). Note that if an internal edge does blend with the
background, there will be a line along the edge left when the second
poly blends with the first. Once the blending is done, there is no way
to undo it. Also, note that the background may not even have been
rendered yet, unless the rendering of polys is done in depth-sorted
order, which defeats the purpose of z-buffering.

The only way to deal with this is to postpone the blending of
silhouette edges until after the whole scene is rendered. In fact, the
final blending of the silhouette edges is done at display time by the
video interface.  To do this blend on video output, there needs to be
a coverage value left behind in the frame buffer, with which to
interpolate between the foreground (the color in the frame buffer) and
the background (which is assumed to be in one or more of the
neighboring pixels in the frame buffer).  This interpolation is as
follows:

	output color = cvg*foreground + (1-cvg)*background.

The foreground is always the color stored in the frame buffer for that
pixel.  The problem is to find a representive of the background (which
was overwritten for this pixel during the rendering process by the
foreground pixel) amoung the neighbors of the pixel. (For now, let's
ignore the precise definition of which pixels are the neighbors. We'll
get back to this later.) If we looked at the z-buffer (assuming the
image was rendered with z-buffering turned on), we might be able to
use this to distinguish between foreground and background pixels,
perhaps using the neighboring pixel with the largest z (most distant)
as the representative of the background. However, if we did this, the
video interface would have to read the z-buffer, which would add to
the memory bandwidth required. Even worse, this would require double
buffering of z, since if it's being used it display time, it can't be
allowed to be stepped by the rendering of the next frame. Since we
have so little frame buffer memory, this would be prohibitive. So
again, the problem is to find a representive for the background
without using depth information, using only the color and coverage
values for each pixel and its neighbors.

Surprisingly enough, this can be done to a reasonable approximation,
assuming relative constancy of color within neighboring pixels of the
foreground and relative constancy of color within neighboring pixels
of the background. Note that this must be assumed for the background,
since the true background for a foreground pixel has already been
overwritten. Errors in this assumption tend to not be noticable, since
they are consistent with "edge effects" (diffraction, etc.).  For a
well-known example of the human visual system's tolerance for this
kind of artifact, note that in the movie "2001: A Space Odyssey", due
to the difficulties of the matting process (mostly done by hand), the
stars in the background of a spaceship would disappear somewhat before
they should actually have been occluded. (It would have been much
worse for them to have disappeared after they should have been
occluded). Despite many very picky people (myself, the son of a
professional cinematographer, included) looking for errors in the
special effects (and there were a few that were noticable), no one
noticed this error. (It was written up by some of the people involved
several years after the release of the film, which is why I know about
it.) Note also that this assumption of color constancy tends to be
true for foreground objects, even for textured objects, since by
mipmapping, the pixels near the silhouette of an object (which are the
only pixels altered by the display time antialiasing in the video
interface) tend to be free of high spatial frequencies tangentially as
well as radially (since mipmapping gives no directionality to the
level of detail). But I digress...

What we are trying to find is some estimate for the color of the lost
(overwritten) background pixel. First, we look at the neighbors of the
central pixel currently being displayed. Once again, we'll defer
discussion of the details of the neighborhood (including how many
neighbors there are) until later. In any case, however many there are,
we sort them (independently by RGB color component), reject the
maximum and minimum values in each component, and take the remaining
(penultimate) maximum and minimum values for each component.
(Actually, before the sort of the neighbors we reject any partially
covered pixels, since they are bound to be part of the foreground, for
which we already have a good representative.) We then take the maximum
of the central pixel (known to be the foreground) and the penultimate
maximum of the neighbors, as well as the minimum of the central pixel
and the penultimate minimum of neighbors. Note that at this point, one
of the maximum and minimum will be representative of the foreground,
and the other will be representative of the background (independently,
color component by color component).  But we do not yet know which is
which.

We then average these component maxima and minima. This gives us a
color half way between the foreground and background. We then take the
difference of this color with the central pixel's (foreground)
color. This is half the magnitude of the difference between the
foreground and background colors. So we double this difference and add
it to the central (foreground) pixel. This is our estimate of the
background pixel color, which was overwritten by the foreground pixel
color. We then interpolate between the foreground and background
colors by the coverage value stored in the frame buffer along with the
(foreground) color. This interpolated result is our antialiased pixel.

The careful observer may have noticed that in the 16 bit case, there
aren't enough bits for RGB and coverage. In this pixel size, there are
5 bits each of red, green and blue. We also need at least 3 bits of
coverage. This adds up to 18 bits, not 16. (32 bit mode, of course, is
not a problem, having 8 bits free for coverage.) Since the DRAMs we
are using are really 9 bits, and we have no use for parity (where do
you dump core?) we can use the ninth bit to get 18 bits in 2 bytes.
(We also use these "hidden" bits to pack 18 bits into the z buffer.)

Note that all the operations done here (maximum, minimum, averaging,
etc.) are continuous and monotonic (although nonlinear). These
properties insure that there isn't excessive "popping" of whatever
artifacts there may be as objects move across the pixel grid. Note
that the maximum function can be viewed as one member of a family of
two variable functions, of which the sum and the Pythagorean distance
are the first two members. If such functions are written as:

	z^n = x^n + y^n,

then in the limit as n approaches infinity:

	z = max(x, y).

Let's return to the issue of neighborhoods. This algorithm proved to
be remarkably sensitive to the choice of a neighborhood. In it's
development, I tried many different neighborhoods, from 2 by 2 with 1
to 3 neighbors, to 3 by 3 with 4 or 8 neighbors, to some pretty
obscure ones. None of the obvious choices worked out very well. There
were two reasons for this. In the small neighborhoods (4 neighbors or
less), there are not enough samples to be able to insure that there
will always be a background pixel represented within the neighborhood.
On the other hand, in the more highly connected neighborhoods (such as
3 by 3 with 8 neighbors), the fact that some (orthogonal) neighbors
are significantly closer than the other (diagonal) neighbors
introduces a bias, creating unacceptable artifacts.

The ideal case would have been a triangular grid, with each pixel
having 6 neighbors (a nice, healthy number), all equidistant (so no
bias). But we are rendering on a square (or at least rectangular)
grid. (I don't want to think about rendering to a triangular grid...)
So what can we do?

A triangular grid can be approximated by "checkerboarding" the pixels.
If you only consider the neighboring squares on a checkerboard that
are of the same color, you can get a slightly deformed triangular
grid. (This deformation turns out to not be problematic, since
anything that correctly antialiases something on one rectangular grid
should also work on another rectangular grid with a different aspect
ratio.) So the neighborhood we use is as follows:

	0 X 0 X 0
	X 0 * 0 X
	0 X 0 X 0,

where * is the central pixel, the X's are the neighbors, and the 0's
are unused. Note that in the case of interlace, since we are only
rendering one field at a time, the rows of neighbors above and below
are actually from 2 lines away. Note that this simply deforms the
triangular grid the other way, and so is not really any different.

Before final processing, one more operation is done (optionally) to
the antialiased pixels, to fix up some slight artifacts of the
algorithm. For any pixels on or adjacent to a silhouette edge, the
divot cicuit takes the median of three adjacent pixels as the color to
be displayed in place of the center pixel. For any single silhouette,
this will always leave the pixels essentially undisturbed, while
filtering out the "divots" (one pixel notches) due to multiple
overlapping silhouetts.  While not perfect, this simple circuit
effectively eliminates most of the divot artifacts. Note that this
median filter is not used in regions of full coverage, so high spatial
frequency textures within a surface will not be disturbed by the divot
circuit.

The processed pixels are then rescaled (optionally), gamma corrected
(optionally), and dithered (optionally) to 7 bits per RGB component,
which together with the sync pulses are output to the video DACs.


Display Modes
----------------

The 28 modes supported in the gbi.h macros could have been represented
by 5 binary switches (hi/lo res, 16/32 bit, antialiased/point-sampled,
filtered/not, NTSC/PAL), but 4 of the 32 switch combinations are illegal
due to lack of memory bandwidth. The disallowed modes are all the hi res,
32 bit, antialiased modes. Note that the hi res, 32 bit, point-sampled
modes are allowed.

The gbi.h macros have override flags to inactivate the following features:

gamma_dither_enable - for intentional Mach banding ("special effects")
gamma_enable	   - for MPEG (which is already gamma corrected)
divot_enable	   - for decal lines (which interract poorly with divot)

In addition, in all modes, there is an x scale factor to scale the image
up horizontally to the required display format from a reduced number of
rendered pixels per line. In the low-res, non-interlaced modes, there can
also be a y scale factor to scale the image up vertically to the required
display format from a reduced number of rendered lines per frame. The
intended use for this is load balancing in cases where reducing the frame
rate would be unaccetable. The most likely case is running into an object
(eg., a wall) where the time of impact is important to the "feel" more
than maintaining the full resolution. Note that this rescaling is linear,
so there will be some artifacts from the interpolation, such as alternating
bands of blurring where the interpolation factor is near 50% versus bands of
sharpness where the interpolation factor is near 0% or 100%. In particular,
this feature should probably not be used to rescale between NTSC and PAL
pixel aspect ratios. (There are approximately the same numbers of pixels
across in both NTSC and PAL, but PAL has more lines per frame. However, the
frame aspect ratios between NTSC and PAL are the same. So PAL pixels are
"shorter" than NTSC pixels. Usually, as in the SNES, this difference is
ignored, since the ratio is 480 to 525, which is off by about 9%, well
within the adjustment range of most TV monitors.)


Video Interface Control Registers
------------------------------------

There are 16 control registers for the video interface which control all
its functions including sync generation, video rescaling, and antialiasing.
These video interface registers are as follows:

0  : ctrl[16:0]			- see below

1  : origin[23:0]		- frame buffer origin in bytes

2  : width[11:0]		- frame buffer line width in pixels

3  : v_int[9:0]			- interrupt when current half-line = v_int

4  : v_current[9:0]		- current half line, sampled once per line
				  (the lsb of v_current is constant within
				  a field, and in interlaced modes gives the
				  field number - this is constant for non-
				  interlaced modes)

5  : burst_start[29:20]		- beginning of color burst in pixels from hsync
     vsync_width[19:16]		- width if vsync in half-lines
     burst_width[15:8]		- width of color burst in pixels
     hsync_width[7:0]		- width of hsync in pixels

6  : v_sync_period[9:0]		- number of half-lines per field

7  : leap_pattern[20:16]	- a 5 bit pattern used for PAL only
     h_sync_period[11:0]	- the total duration of a line in 1/4 pixels

8  : hsync_leap_a[27:16]	- identical to h_sync_period (except for PAL)
     hsync_leap_b[11:0]		- identical to h_sync_period (except for PAL)

9  : h_video_start[25:16]	- start of active video in screen pixels
     h_video_end[9:0]		- end of active video in pixels from hsync

10 : v_video_start[25:16]	- start of active video in screen half-lines
     v_video_end[9:0]		- end of active video in half-lines from vsync

11 : v_burst_start[25:16]	- start of color burst enable in half-lines
     v_burst_end[9:0]		- end of color burst enable in half-lines

12 : x_offset[27:16]		- horizontal subpixel offset (2.10 format)
     x_scale[11:0]		- 1/horizontal scale up factor (2.10 format)

13 : y_offset[27:16]		- vertical subpixel offset (2.10 format)
     y_scale[11:0]		- 1/vertical scale up factor (2.10 format)

14 : test_addr[6:0]		- for diagnostics, not used in normal operation

15 : staged_data[31:0]		- for diagnostics, not used in normal operation

Note that all the numerical parameters count from zero. So a count of zero
means one unit is to be counted. In general, the actual count is one plus
the count for any of the control register parameters.

Most of the video registers should not be changed at any time except during 
vertical blanking. The registers which are exceptions to this are h_video_start,
h_video_end, v_int and v_current


The power on default settings for the video registers are:

ctrl          = 0;               // blank video (incl syncs)
origin        = 0;
width         = 0;
v_int         = 0x3FF;
burst_start   = 0;
vsync_width   = 0;
burst_width   = 0;
hsync_width   =  0xd1;           // for refresh
v_sync_period = 0;
leap_pattern  = 0;
h_sync_period = 0xd2047;         // for refresh
hsync_leap_b  = 0;
hsync_leap_a  = 0;
h_video_end   = 0;
h_video_start = 0;
v_video_end   = 0;
v_video_start = 0;
v_burst_end   = 0;
v_burst_start = 0;
x_scale       = 0;
y_scale       = 0;
x_offset      = 0;
y_offset      = 0;
test_addr     = 0;
staged_data   = 0;

The following are the definitions (positive true) of the mode bits in the
video interface control register:

ctrl[1:0]   = type[1:0] (pixel size) == 0: blank (no data, no sync)
					1: reserved
					2: 5/5/5/3 ("16" bit - really 18 bit)
					3: 8/8/8/8 (32 bit)
ctrl[2]     = gamma_dither_enable (normally on, unless "special effect")
ctrl[3]     = gamma_enable (normally on, unless MPEG/JPEG)
ctrl[4]     = divot_enable (normally on if antialiased, unless decal lines)
ctrl[5]     = vbus_clock_enable (never on - hardware damage may result)
ctrl[6]     = serrate (always on if interlaced, off if not)
ctrl[7]     = test_mode (for diagnostics, not used in normal operation)
ctrl[9:8]   = aa_mode[1:0] == 0: aa & resamp (always fetch extra lines)
			      1: aa & resamp (fetch extra lines if needed)
			      2: resamp only (treat as all fully covered)
			      3: neither (replicate pixels, no interpolate)
ctrl[11]    = kill_we (for diagnostics, not used in normal operation)
ctrl[15:12] = pixel_advance (always 3 for optimal operation)
ctrl[16]    = dither_filter_enable (normally on for 16 bit, off for 32 bit)

Type is just the pixel size used by the video interface, with a code
for shutting off the video altogether (including the syncs. TV
mointors will display snow or a blank frame.) Gamma_dither_enable adds
in some random noise to the lsbs of the video out before the final
quantization to 7 bits. This is to eliminate Mach banding artifacts.
In general, this should always be on, unless deliberate artifacts are
desired as a "special effect".  Gamma_enable turns on the correction
for the gamma non-linearity of TV monitors. This amounts to taking a
square root of the linear color space used within the rendering
pipeline. The TV monitor (according to spec) effectively raises these
color values to the 2.2 to 2.4 power, leaving a residual gamma of 1.1
to 1.2. This error is actually desirable, since a slightly higher than
unity effective gamma produces a more color accurate image in the
typical somewhat darkened TV viewing environment. Note that for MPEG
and JPEG images, this gamma correction is already in the image data,
so the hardware gamma correction should be turned off.

Divot_enable is a part of the antialiasing alogrithm which fixes up
some slight artifacts of the algorithm. For any pixels on or adjacent
to a silhouette edge, the divot cicuit takes the median of three
adjacent pixels as the color to be displayed in place of the center
pixel. This eliminates the "divots" (one pixel notches) seen in the
horizon of some fractal terrains, due to the antialiasing algorithm's
problems with multiple fragments (silhouette edges) per pixel. Note
that this median filter is not used in regions of full coverage (the
surfaces of objects), so any texture detail will not be disturbed by
the divot circuit. Note also that this feature interacts poorly with
one of the more obscure rendering modes (decal line), since this
rendering mode can produce details (lines at the silhouette edge)
which the divot circuit could affect. So this feature can be turned
off (or the effect can simply be tolerated in cases where the divot
defects are more visually annoying than the decal line defects).

Dither_filter_enable turns on a filter which largely undoes the effect
of dithering, restoring a smooth image. This would normally be used
with 16 bit pixels (with their 5 bits per component) with the assumption
that these would be dithered in the rdp. For 32 bit mode, this would
normally be turned off

Vbus_clock_enable must never be turned on. This is a hardware feature
for cases where the clock distribution is other than it is in the
actual Ultra 64. Turning this mode bit on in the current hardware will
result in two output drivers both being enabled on the same wire at
the same time, which can result in permanent damage to the device.

Note that SetImage rdp command must be consistent with the video
display modes for correct operation. In particular, the pixel size
must be the same and the image origin must be consistent (although
with an offset in some modes). The SetScissor rdp command should also
be consistent with the video display mode for optimal rendering
efficiency. In particular, in the hi-res, normal interlace modes,
scissoring the even or odd field out can be used to double buffer
without the need for additional frame buffer memory. One field can be
rendered while the other field is being displayed. The rendering
hardware can skip over the unneeded lines of the scissored out field
to prevent the currently displaying field from being stepped on by the
currently rendering field.

The 28 Supported Video Modes
-------------------------------

		video format
		|	resolution
		|	|	pixel size
		|	|	|	antialiasing(aa)/point-sampling(ps)
		|	|	|	|	interlace
mode		|	|	|	|	|
---------	-	-	-	-	-
vi_ntsc_lpn1	ntsc	lo	16	ps	non-interlace
vi_ntsc_lpf1	ntsc	lo	16	ps	interlace
vi_ntsc_lan1	ntsc	lo	16	aa	non-interlace
vi_ntsc_laf1	ntsc	lo	16	aa	interlace
vi_ntsc_lpn2	ntsc	lo	32	ps	non-interlace
vi_ntsc_lpf2	ntsc	lo	32	ps	interlace
vi_ntsc_lan2	ntsc	lo	32	aa	non-interlace
vi_ntsc_laf2	ntsc	lo	32	aa	interlace
vi_ntsc_hpn1	ntsc	hi	16	ps	normal interlace
vi_ntsc_hpf1	ntsc	hi	16	ps	deflickered interlace
vi_ntsc_han1	ntsc	hi	16	aa	normal interlace
vi_ntsc_haf1	ntsc	hi	16	aa	deflickered interlace
vi_ntsc_hpn2	ntsc	hi	32	ps	normal interlace
vi_ntsc_hpf2	ntsc	hi	32	ps	deflickered interlace

vi_pal_lpn1	pal	lo	16	ps	non-interlace
vi_pal_lpf1	pal	lo	16	ps	interlace
vi_pal_lan1	pal	lo	16	aa	non-interlace
vi_pal_laf1	pal	lo	16	aa	interlace
vi_pal_lpn2	pal	lo	32	ps	non-interlace
vi_pal_lpf2	pal	lo	32	ps	interlace
vi_pal_lan2	pal	lo	32	aa	non-interlace
vi_pal_laf2	pal	lo	32	aa	interlace
vi_pal_hpn1	pal	hi	16	ps	normal interlace
vi_pal_hpf1	pal	hi	16	ps	deflickered interlace
vi_pal_han1	pal	hi	16	aa	normal interlace
vi_pal_haf1	pal	hi	16	aa	deflickered interlace
vi_pal_hpn2	pal	hi	32	ps	normal interlace
vi_pal_hpf2	pal	hi	32	ps	deflickered interlace

In low-res (320 pixels by 240 lines), there is a choice between
non-interlace and interlace. Non-interlace repeats the same frame each
field. Interlace interpolates between adjacent lines, weighted 75% of
the line above plus 25% of the line below in the first field, then
weighted 25% of the line above plus 75% of the line below in the
second field. Note that there will be no flicker, since there are no
high spatial frequencies. Interlace requires slightly more memory
bandwidth due to the interpolation (but no additional frame buffer
memory). However, it will look better.

In hi-res (640 pixels by 480 lines), there is a choice between normal
interlace and deflickerd interlace. Normal interlace uses just the
data rendered in one field to display that field. This mode can use
one hi-res frame buffer without additional double buffering, since one
field can be displayed while the next is being rendered without
stepping on each other. However, any single pixel high detail will
flicker, since it will only be displayed in one field. Deflickered
interlace averages adjacent lines to filter out the high frequency
vertical detail, but at the cost of requiring double buffering of the
entire hi-res frame, since both rendered fields are used to display
each field.

There are, in general, two sets of settings for each of the two fields
in a frame, which must be switched each vertical blanking interval. In
non-interlace modes, the two settings are the same in each field.

vi_ntsc_lpn1
---------------

register	address		field 1 value	field 2 value
---------	--------	--------	--------
VI_ORIGIN	04400004	00000280	00000280
VI_WIDTH 	04400008	00000140	00000140
VI_V_INT 	0440000c	00000208	00000208
VI_BURST 	04400014	03e52239	03e52239
VI_V_SYNC 	04400018	0000020d	0000020d
VI_H_SNYC 	0440001c	00000c15	00000c15
VI_LEAP 	04400020	0c150c15	0c150c15
VI_H_START	04400024	006c02ec	006c02ec
VI_V_START	04400028	002501ff	002501ff
VI_V_BURST	0440002c	000e0204	000e0204
VI_X_SCALE	04400030	00000200	00000200
VI_Y_SCALE	04400034	00000400	00000400
VI_CTRL   	04400000	0001320e	0001320e


vi_ntsc_lpf1
---------------

register	address		field 1 value	field 2 value
---------	--------	--------	--------
VI_ORIGIN	04400004	00000280	00000280
VI_WIDTH 	04400008	00000140	00000140
VI_V_INT 	0440000c	00000208	00000208
VI_BURST 	04400014	03e52239	03e52239
VI_V_SYNC 	04400018	0000020c	0000020c
VI_H_SYNC 	0440001c	00000c15	00000c15
VI_LEAP 	04400020	0c150c15	0c150c15
VI_H_START	04400024	006c02ec	006c02ec
VI_V_START	04400028	002301fd	002501ff
VI_V_BURST	0440002c	000e0204	000e0204
VI_X_SCALE	04400030	00000200	00000200
VI_Y_SCALE	04400034	01000400	03000400
VI_CTRL   	04400000	0001324e	0001324e


vi_ntsc_lan1
---------------

register	address		field 1 value	field 2 value
---------	--------	--------	--------
VI_ORIGIN	04400004	00000280	00000280
VI_WIDTH 	04400008	00000140	00000140
VI_V_INT 	0440000c	00000208	00000208
VI_BURST 	04400014	03e52239	03e52239
VI_V_SYNC 	04400018	0000020d	0000020d
VI_H_SYNC 	0440001c	00000c15	00000c15
VI_LEAP 	04400020	0c150c15	0c150c15
VI_H_START	04400024	006c02ec	006c02ec
VI_V_START	04400028	002501ff	002501ff
VI_V_BURST	0440002c	000e0204	000e0204
VI_X_SCALE	04400030	00000200	00000200
VI_Y_SCALE	04400034	00000400	00000400
VI_CTRL   	04400000	0001311e	0001311e


vi_ntsc_laf1
---------------

register	address		field 1 value	field 2 value
---------	--------	--------	--------
VI_ORIGIN	04400004	00000280	00000280
VI_WIDTH 	04400008	00000140	00000140
VI_V_INT 	0440000c	00000208	00000208
VI_BURST 	04400014	03e52239	03e52239
VI_V_SYNC 	04400018	0000020c	0000020c
VI_H_SYNC 	0440001c	00000c15	00000c15
VI_LEAP 	04400020	0c150c15	0c150c15
VI_H_START	04400024	006c02ec	006c02ec
VI_V_START	04400028	002301fd	002501ff
VI_V_BURST	0440002c	000e0204	000e0204
VI_X_SCALE	04400030	00000200	00000200
VI_Y_SCALE	04400034	01000400	03000400
VI_CTRL   	04400000	0001305e	0001305e


vi_ntsc_lpn2
---------------

register	address		field 1 value	field 2 value
---------	--------	--------	--------
VI_ORIGIN	04400004	00000500	00000500
VI_WIDTH 	04400008	00000140	00000140
VI_V_INT 	0440000c	00000208	00000208
VI_BURST 	04400014	03e52239	03e52239
VI_V_SYNC 	04400018	0000020d	0000020d
VI_H_SYNC 	0440001c	00000c15	00000c15
VI_LEAP 	04400020	0c150c15	0c150c15
VI_H_START	04400024	006c02ec	006c02ec
VI_V_START	04400028	002501ff	002501ff
VI_V_BURST	0440002c	000e0204	000e0204
VI_X_SCALE	04400030	00000200	00000200
VI_Y_SCALE	04400034	00000400	00000400
VI_CTRL   	04400000	0000330f	0000330f


vi_ntsc_lpf2
---------------

register	address		field 1 value	field 2 value
---------	--------	--------	--------
VI_ORIGIN	04400004	00000500	00000500
VI_WIDTH 	04400008	00000140	00000140
VI_V_INT 	0440000c	00000208	00000208
VI_BURST 	04400014	03e52239	03e52239
VI_V_SYNC 	04400018	0000020c	0000020c
VI_H_SYNC 	0440001c	00000c15	00000c15
VI_LEAP 	04400020	0c150c15	0c150c15
VI_H_START	04400024	006c02ec	006c02ec
VI_V_START	04400028	002301fd	002501ff
VI_V_BURST	0440002c	000e0204	000e0204
VI_X_SCALE	04400030	00000200	00000200
VI_Y_SCALE	04400034	01000400	03000400
VI_CTRL   	04400000	0000324f	0000324f


vi_ntsc_lan2
---------------

register	address		field 1 value	field 2 value
---------	--------	--------	--------
VI_ORIGIN	04400004	00000500	00000500
VI_WIDTH 	04400008	00000140	00000140
VI_V_INT 	0440000c	00000208	00000208
VI_BURST 	04400014	03e52239	03e52239
VI_V_SYNC 	04400018	0000020d	0000020d
VI_H_SYNC 	0440001c	00000c15	00000c15
VI_LEAP 	04400020	0c150c15	0c150c15
VI_H_START	04400024	006c02ec	006c02ec
VI_V_START	04400028	002501ff	002501ff
VI_V_BURST	0440002c	000e0204	000e0204
VI_X_SCALE	04400030	00000200	00000200
VI_Y_SCALE	04400034	00000400	00000400
VI_CTRL   	04400000	0000301f	0000301f


vi_ntsc_laf2
---------------

register	address		field 1 value	field 2 value
---------	--------	--------	--------
VI_ORIGIN	04400004	00000500	00000500
VI_WIDTH 	04400008	00000140	00000140
VI_V_INT 	0440000c	00000208	00000208
VI_BURST 	04400014	03e52239	03e52239
VI_V_SYNC 	04400018	0000020c	0000020c
VI_H_SYNC 	0440001c	00000c15	00000c15
VI_LEAP 	04400020	0c150c15	0c150c15
VI_H_START	04400024	006c02ec	006c02ec
VI_V_START	04400028	002301fd	002501ff
VI_V_BURST	0440002c	000e0204	000e0204
VI_X_SCALE	04400030	00000200	00000200
VI_Y_SCALE	04400034	01000400	03000400
VI_CTRL   	04400000	0000305f	0000305f


vi_ntsc_hpn1
---------------

register	address		field 1 value	field 2 value
---------	--------	--------	--------
VI_ORIGIN	04400004	00000500	00000a00
VI_WIDTH 	04400008	00000500	00000500
VI_V_INT 	0440000c	00000208	00000208
VI_BURST 	04400014	03e52239	03e52239
VI_V_SYNC 	04400018	0000020c	0000020c
VI_H_SYNC 	0440001c	00000c15	00000c15
VI_LEAP 	04400020	0c150c15	0c150c15
VI_H_START	04400024	006c02ec	006c02ec
VI_V_START	04400028	002301fd	002501ff
VI_V_BURST	0440002c	000e0204	000e0204
VI_X_SCALE	04400030	00000400	00000400
VI_Y_SCALE	04400034	00000400	00000400
VI_CTRL   	04400000	0001334e	0001334e


vi_ntsc_hpf1
---------------

register	address		field 1 value	field 2 value
---------	--------	--------	--------
VI_ORIGIN	04400004	00000500	00000a00
VI_WIDTH 	04400008	00000280	00000280
VI_V_INT 	0440000c	00000208	00000208
VI_BURST 	04400014	03e52239	03e52239
VI_V_SYNC 	04400018	0000020c	0000020c
VI_H_SYNC 	0440001c	00000c15	00000c15
VI_LEAP 	04400020	0c150c15	0c150c15
VI_H_START	04400024	006c02ec	006c02ec
VI_V_START	04400028	002301fd	002501ff
VI_V_BURST	0440002c	000e0204	000e0204
VI_X_SCALE	04400030	00000400	00000400
VI_Y_SCALE	04400034	02000800	02000800
VI_CTRL   	04400000	0001324e	0001324e


vi_ntsc_han1
---------------

register	address		field 1 value	field 2 value
---------	--------	--------	--------
VI_ORIGIN	04400004	00000500	00000a00
VI_WIDTH 	04400008	00000500	00000500
VI_V_INT 	0440000c	00000208	00000208
VI_BURST 	04400014	03e52239	03e52239
VI_V_SYNC 	04400018	0000020c	0000020c
VI_H_SYNC 	0440001c	00000c15	00000c15
VI_LEAP 	04400020	0c150c15	0c150c15
VI_H_START	04400024	006c02ec	006c02ec
VI_V_START	04400028	002301fd	002501ff
VI_V_BURST	0440002c	000e0204	000e0204
VI_X_SCALE	04400030	00000400	00000400
VI_Y_SCALE	04400034	00000400	00000400
VI_CTRL   	04400000	0001305e	0001305e


vi_ntsc_haf1
---------------

register	address		field 1 value	field 2 value
---------	--------	--------	--------
VI_ORIGIN	04400004	00000500	00000a00
VI_WIDTH 	04400008	00000280	00000280
VI_V_INT 	0440000c	00000208	00000208
VI_BURST 	04400014	03e52239	03e52239
VI_V_SYNC 	04400018	0000020c	0000020c
VI_H_SYNC 	0440001c	00000c15	00000c15
VI_LEAP 	04400020	0c150c15	0c150c15
VI_H_START	04400024	006c02ec	006c02ec
VI_V_START	04400028	002301fd	002501ff
VI_V_BURST	0440002c	000e0204	000e0204
VI_X_SCALE	04400030	00000400	00000400
VI_Y_SCALE	04400034	02000800	02000800
VI_CTRL   	04400000	0001305e	0001305e


vi_ntsc_hpn2
---------------

register	address		field 1 value	field 2 value
---------	--------	--------	--------
VI_ORIGIN	04400004	00000a00	00001400
VI_WIDTH 	04400008	00000500	00000500
VI_V_INT 	0440000c	00000208	00000208
VI_BURST 	04400014	03e52239	03e52239
VI_V_SYNC 	04400018	0000020c	0000020c
VI_H_SYNC 	0440001c	00000c15	00000c15
VI_LEAP 	04400020	0c150c15	0c150c15
VI_H_START	04400024	006c02ec	006c02ec
VI_V_START	04400028	002301fd	002501ff
VI_V_BURST	0440002c	000e0204	000e0204
VI_X_SCALE	04400030	00000400	00000400
VI_Y_SCALE	04400034	00000400	00000400
VI_CTRL   	04400000	0000334f	0000334f


vi_ntsc_hpf2
---------------

register	address		field 1 value	field 2 value
---------	--------	--------	--------
VI_ORIGIN	04400004	00000a00	00001400
VI_WIDTH 	04400008	00000280	00000280
VI_V_INT 	0440000c	00000208	00000208
VI_BURST 	04400014	03e52239	03e52239
VI_V_SYNC 	04400018	0000020c	0000020c
VI_H_SYNC 	0440001c	00000c15	00000c15
VI_LEAP 	04400020	0c150c15	0c150c15
VI_H_START	04400024	006c02ec	006c02ec
VI_V_START	04400028	002301fd	002501ff
VI_V_BURST	0440002c	000e0204	000e0204
VI_X_SCALE	04400030	00000400	00000400
VI_Y_SCALE	04400034	02000800	02000800
VI_CTRL   	04400000	0000324f	0000324f


vi_pal_lpn1
---------------

register	address		field 1 value	field 2 value
---------	--------	--------	--------
VI_ORIGIN	04400004	00000280	00000280
VI_WIDTH 	04400008	00000140	00000140
VI_V_INT 	0440000c	0000023a	0000023a
VI_BURST 	04400014	0404233a	0404233a
VI_V_SYNC 	04400018	00000271	00000271
VI_H_SYNC 	0440001c	00150c69	00150c69
VI_LEAP 	04400020	0c6f0c6e	0c6f0c6e
VI_H_START	04400024	00800300	00800300
VI_V_START	04400028	005f0239	005f0239
VI_V_BURST	0440002c	00110267	00110267
VI_X_SCALE	04400030	00000200	00000200
VI_Y_SCALE	04400034	00000400	00000400
VI_CTRL   	04400000	0001320e	0001320e


vi_pal_lpf1
---------------

register	address		field 1 value	field 2 value
---------	--------	--------	--------
VI_ORIGIN	04400004	00000280	00000280
VI_WIDTH 	04400008	00000140	00000140
VI_V_INT 	0440000c	0000023a	0000023a
VI_BURST 	04400014	0404233a	0404233a
VI_V_SYNC 	04400018	00000270	00000270
VI_H_SYNC 	0440001c	00150c69	00150c69
VI_LEAP 	04400020	0c6f0c6e	0c6f0c6e
VI_H_START	04400024	00800300	00800300
VI_V_START	04400028	005f0239	005d0237
VI_V_BURST	0440002c	00110267	00110267
VI_X_SCALE	04400030	00000200	00000200
VI_Y_SCALE	04400034	01000400	03000400
VI_CTRL   	04400000	0001324e	0001324e


vi_pal_lan1
---------------

register	address		field 1 value	field 2 value
---------	--------	--------	--------
VI_ORIGIN	04400004	00000280	00000280
VI_WIDTH 	04400008	00000140	00000140
VI_V_INT 	0440000c	0000023a	0000023a
VI_BURST 	04400014	0404233a	0404233a
VI_V_SYNC 	04400018	00000271	00000271
VI_H_SYNC 	0440001c	00150c69	00150c69
VI_LEAP 	04400020	0c6f0c6e	0c6f0c6e
VI_H_START	04400024	00800300	00800300
VI_V_START	04400028	005f0239	005f0239
VI_V_BURST	0440002c	00110267	00110267
VI_X_SCALE	04400030	00000200	00000200
VI_Y_SCALE	04400034	00000400	00000400
VI_CTRL   	04400000	0001311e	0001311e


vi_pal_laf1
---------------

register	address		field 1 value	field 2 value
---------	--------	--------	--------
VI_ORIGIN	04400004	00000280	00000280
VI_WIDTH 	04400008	00000140	00000140
VI_V_INT 	0440000c	0000023a	0000023a
VI_BURST 	04400014	0404233a	0404233a
VI_V_SYNC 	04400018	00000270	00000270
VI_H_SYNC 	0440001c	00150c69	00150c69
VI_LEAP 	04400020	0c6f0c6e	0c6f0c6e
VI_H_START	04400024	00800300	00800300
VI_V_START	04400028	005f0239	005d0237
VI_V_BURST	0440002c	00110267	00110267
VI_X_SCALE	04400030	00000200	00000200
VI_Y_SCALE	04400034	01000400	03000400
VI_CTRL   	04400000	0001305e	0001305e


vi_pal_lpn2
---------------

register	address		field 1 value	field 2 value
---------	--------	--------	--------
VI_ORIGIN	04400004	00000500	00000500
VI_WIDTH 	04400008	00000140	00000140
VI_V_INT 	0440000c	0000023a	0000023a
VI_BURST 	04400014	0404233a	0404233a
VI_V_SYNC 	04400018	00000271	00000271
VI_H_SYNC 	0440001c	00150c69	00150c69
VI_LEAP 	04400020	0c6f0c6e	0c6f0c6e
VI_H_START	04400024	00800300	00800300
VI_V_START	04400028	005f0239	005f0239
VI_V_BURST	0440002c	00110267	00110267
VI_X_SCALE	04400030	00000200	00000200
VI_Y_SCALE	04400034	00000400	00000400
VI_CTRL   	04400000	0000330f	0000330f


vi_pal_lpf2
---------------

register	address		field 1 value	field 2 value
---------	--------	--------	--------
VI_ORIGIN	04400004	00000500	00000500
VI_WIDTH 	04400008	00000140	00000140
VI_V_INT 	0440000c	0000023a	0000023a
VI_BURST 	04400014	0404233a	0404233a
VI_V_SYNC 	04400018	00000270	00000270
VI_H_SYNC 	0440001c	00150c69	00150c69
VI_LEAP 	04400020	0c6f0c6e	0c6f0c6e
VI_H_START	04400024	00800300	00800300
VI_V_START	04400028	005f0239	005d0237
VI_V_BURST	0440002c	00110267	00110267
VI_X_SCALE	04400030	00000200	00000200
VI_Y_SCALE	04400034	01000400	03000400
VI_CTRL   	04400000	0000324f	0000324f


vi_pal_lan2
---------------

register	address		field 1 value	field 2 value
---------	--------	--------	--------
VI_ORIGIN	04400004	00000500	00000500
VI_WIDTH 	04400008	00000140	00000140
VI_V_INT 	0440000c	0000023a	0000023a
VI_BURST 	04400014	0404233a	0404233a
VI_V_SYNC 	04400018	00000271	00000271
VI_H_SYNC 	0440001c	00150c69	00150c69
VI_LEAP 	04400020	0c6f0c6e	0c6f0c6e
VI_H_START	04400024	00800300	00800300
VI_V_START	04400028	005f0239	005f0239
VI_V_BURST	0440002c	00110267	00110267
VI_X_SCALE	04400030	00000200	00000200
VI_Y_SCALE	04400034	00000400	00000400
VI_CTRL   	04400000	0000301f	0000301f


vi_pal_laf2
---------------

register	address		field 1 value	field 2 value
---------	--------	--------	--------
VI_ORIGIN	04400004	00000500	00000500
VI_WIDTH 	04400008	00000140	00000140
VI_V_INT 	0440000c	0000023a	0000023a
VI_BURST 	04400014	0404233a	0404233a
VI_V_SYNC 	04400018	00000270	00000270
VI_H_SYNC 	0440001c	00150c69	00150c69
VI_LEAP 	04400020	0c6f0c6e	0c6f0c6e
VI_H_START	04400024	00800300	00800300
VI_V_START	04400028	005f0239	005d0237
VI_V_BURST	0440002c	00110267	00110267
VI_X_SCALE	04400030	00000200	00000200
VI_Y_SCALE	04400034	01000400	03000400
VI_CTRL   	04400000	0000305f	0000305f


vi_pal_hpn1
---------------

register	address		field 1 value	field 2 value
---------	--------	--------	--------
VI_ORIGIN	04400004	00000500	00000a00
VI_WIDTH 	04400008	00000500	00000500
VI_V_INT 	0440000c	0000023a	0000023a
VI_BURST 	04400014	0404233a	0404233a
VI_V_SYNC 	04400018	00000270	00000270
VI_H_SYNC 	0440001c	00150c69	00150c69
VI_LEAP 	04400020	0c6f0c6e	0c6f0c6e
VI_H_START	04400024	00800300	00800300
VI_V_START	04400028	005f0239	005d0237
VI_V_BURST	0440002c	00110267	00110267
VI_X_SCALE	04400030	00000400	00000400
VI_Y_SCALE	04400034	00000400	00000400
VI_CTRL   	04400000	0001334e	0001334e


vi_pal_hpf1
---------------

register	address		field 1 value	field 2 value
---------	--------	--------	--------
VI_ORIGIN	04400004	00000500	00000a00
VI_WIDTH 	04400008	00000280	00000280
VI_V_INT 	0440000c	0000023a	0000023a
VI_BURST 	04400014	0404233a	0404233a
VI_V_SYNC 	04400018	00000270	00000270
VI_H_SYNC 	0440001c	00150c69	00150c69
VI_LEAP 	04400020	0c6f0c6e	0c6f0c6e
VI_H_START	04400024	00800300	00800300
VI_V_START	04400028	005f0239	005d0237
VI_V_BURST	0440002c	00110267	00110267
VI_X_SCALE	04400030	00000400	00000400
VI_Y_SCALE	04400034	02000800	02000800
VI_CTRL   	04400000	0001324e	0001324e


vi_pal_han1
---------------

register	address		field 1 value	field 2 value
---------	--------	--------	--------
VI_ORIGIN	04400004	00000500	00000a00
VI_WIDTH 	04400008	00000500	00000500
VI_V_INT 	0440000c	0000023a	0000023a
VI_BURST 	04400014	0404233a	0404233a
VI_V_SYNC 	04400018	00000270	00000270
VI_H_SYNC 	0440001c	00150c69	00150c69
VI_LEAP 	04400020	0c6f0c6e	0c6f0c6e
VI_H_START	04400024	00800300	00800300
VI_V_START	04400028	005f0239	005d0237
VI_V_BURST	0440002c	00110267	00110267
VI_X_SCALE	04400030	00000400	00000400
VI_Y_SCALE	04400034	00000400	00000400
VI_CTRL   	04400000	0001305e	0001305e


vi_pal_haf1
---------------

register	address		field 1 value	field 2 value
---------	--------	--------	--------
VI_ORIGIN	04400004	00000500	00000a00
VI_WIDTH 	04400008	00000280	00000280
VI_V_INT 	0440000c	0000023a	0000023a
VI_BURST 	04400014	0404233a	0404233a
VI_V_SYNC 	04400018	00000270	00000270
VI_H_SYNC 	0440001c	00150c69	00150c69
VI_LEAP 	04400020	0c6f0c6e	0c6f0c6e
VI_H_START	04400024	00800300	00800300
VI_V_START	04400028	005f0239	005d0237
VI_V_BURST	0440002c	00110267	00110267
VI_X_SCALE	04400030	00000400	00000400
VI_Y_SCALE	04400034	02000800	02000800
VI_CTRL   	04400000	0001305e	0001305e


vi_pal_hpn2
---------------

register	address		field 1 value	field 2 value
---------	--------	--------	--------
VI_ORIGIN	04400004	00000a00	00001400
VI_WIDTH 	04400008	00000500	00000500
VI_V_INT 	0440000c	0000023a	0000023a
VI_BURST 	04400014	0404233a	0404233a
VI_V_SYNC 	04400018	00000270	00000270
VI_H_SYNC 	0440001c	00150c69	00150c69
VI_LEAP 	04400020	0c6f0c6e	0c6f0c6e
VI_H_START	04400024	00800300	00800300
VI_V_START	04400028	005f0239	005d0237
VI_V_BURST	0440002c	00110267	00110267
VI_X_SCALE	04400030	00000400	00000400
VI_Y_SCALE	04400034	00000400	00000400
VI_CTRL   	04400000	0000334f	0000334f


vi_pal_hpf2
---------------

register	address		field 1 value	field 2 value
---------	--------	--------	--------
VI_ORIGIN	04400004	00000a00	00001400
VI_WIDTH 	04400008	00000280	00000280
VI_V_INT 	0440000c	0000023a	0000023a
VI_BURST 	04400014	0404233a	0404233a
VI_V_SYNC 	04400018	00000270	00000270
VI_H_SYNC 	0440001c	00150c69	00150c69
VI_LEAP 	04400020	0c6f0c6e	0c6f0c6e
VI_H_START	04400024	00800300	00800300
VI_V_START	04400028	005f0239	005d0237
VI_V_BURST	0440002c	00110267	00110267
VI_X_SCALE	04400030	00000400	00000400
VI_Y_SCALE	04400034	02000800	02000800
VI_CTRL   	04400000	0000324f	0000324f