VI Settings

  The N64's has a rather fancy video encoder that runs counter of the modern world.

  This is a bit of a rewrite of a very old doc pulled from Dextrose lost to time.  It only addressed NTSC and likewise, not going to discuss PAL-specific things that can't be verified this side of the pond (like how they're modulating chroma into luma).  Would like to blame any other inaccuracies on somebody else but haha, that probably won't fly.
  Keep in mind this is entirely *analog* behavior.  How digital devices interpret that vary with the device.
  You provide a box of pixels, it converts them to video.

  First, the raw registers:
VI Status	A4400000
	00000003	type: 0:blank, 2:16bit color, 3:32bit color
	00000004	gamma divot enabled
	00000008	gamma enabled
	00000010	divot enabled
	00000020	vbus clock enable (always off)
	00000040	serrate (on if interlaced)
	00000080	test mode (always off)
	00000300	antialiasing mode
		0: antialias and resample, always fetching extra lines
		1: antialias and resample, fetching lines as needed
		2: resample
		3: replicate pixels without interpolation
	00000400	[undefined]
	00000800	kill we (always off; test mode only)
	0000F000	pixel advance (3 apparently is optimal)
			iQue may use this value differently; 2000 cannot be set and is treated as a flag
	00010000	dither filter enabled

VI RDRAM Address	A4400004	frame buffer offset; this will update
VI Horizontal Width	A4400008	width of frame buffer line, in pixels (not bytes!)
VI Vertical Interrupt	A440000C	triggers interrupt when cur. half-line equals this value
VI V. Current Line	A4400010
	Read: current half-line, sampled once per line; constant for progressive output, otherwise interlaced field number
	Write: clears the interrupt line.
VI Timing Register	A4400014
	3FF00000	start of color burst in pixels f/ hsync
	000F0000	width of vsync in half-lines
	0000FF00	width of color burst in pixels
	000000FF	width of hsync in pixels
VI Vertical Sync	A4400018
	Half-lines per field; same or -1 of total scanlines for format (525 NTSC, 625 PAL)
VI Horizontal Sync	A440001C	how long IRE is held at -40
	001F0000	???; 5bit pattern used by PAL
	00000FFF	hsync period (line duration in quarter-pixels)
VI Horz. Sync Leap	A4400020
	0FFF0000	hsync period
	00000FFF	hsync period
VI Horizontal Video	A4400024	start & end of active video (difference is normally 640); before this is horz. blanking (EAV to SAV)
	01FF0000	start of active video, in pixels
	000001FF	end of active video, in pixels, f/ hsync
VI Vertical Video	A4400028	start & end of active video (difference is normally 474); before this is vert. blanking
	01FF0000	start of active video, in screen half-lines
	000001FF	end of active video, in half-lines, f/ vsync
VI Video Burst Register	A440002C	color burst period after hsync, +-20 IRE
	01FF0000	start of color burst, in half-lines
	000001FF	end of color burst, in half-lines
VI X Scale Register	A4400030
	0FFF0000	horz. subpixel offset (2.10 format)
	00000FFF	1/scale factor (2.10 format)
	Basically output signal width.
	0x200 = 2: 320px * 2 = 640px; 0x2C0 = 1.45: 440px * 1.45 = 640
VI Y Scale Register	A4400034
	0FFF0000	vert. subpixel offset (2.10 format); offset used with interlaced fields esp. in deflicker mode.
	00000FFF	1/scale factor (2.10 format)
	Scale *must* be set to 1.0 before blackout or preNMI or the RCP may hang on a reset!
	Y scale of 50% is used in deflicker modes to blend two scanlines into one (overlapping subpixel offsets of 1/4 and 3/4).
VI Test Address (diag.)	A4400038
VI Test Data (diag.)	A440003C	two color values? iQue defaults to 00010001 and overwrites changes


  Most of these registers will never need to be touched by a programmer.  They're tied to signal generation, so unless you want to support some alternate video format like PAL-N or try embedding data in the blanking period you don't need to know how they work.  It is highly recommended to read this section with a reference to analog signal encoding.
  That said, let's discuss those first.

  NTSC and PAL have a fixed number of lines per frame.  Being analog, multiple signals are layered at related frequencies and all have some degree of tolerance, most famously the -0.06 frequency drop for backward-compatible support color video.
  Vertical Sync is the lines per frame: 525 NTSC, 625 PAL.  In interlaced mode this will usually be -1 the value.
  The Timing Register contains four of the primary timings.  To prevent encoding actual frequencies, these are all relative to the pixel clock or half-lines.  First is the delay between horizontal sync and the color burst subsignal, width of the vertical sync pulse interval, width of the color burst, and horizontal sync pulse interval.

  Video has both a vertical blanking and horizontal blanking period.
  Vertical blanking is an undrawn series of lines before the video.  These were also used to embed data like captions and wide-screen signalling, though these "standards" were rarely standardized outside the target market.
  The Vertical Video register consists of two halfwords: the number of halflines to start drawing active video, and the duration counting from vsync.  These have practical applications because they allow shifting the drawn field, especially when lazily scaling hi-res NTSC to PAL.  Under normal circumstances, the difference should match the expected vertical resolution (474 in NTSC).

  The reference sync amplitude is -40 IRE NTSC, -300 mV PAL.  The horizontal blanking period is defined by the Horizontal Sync value using quarter-pixels as reference.
  The sync leap registers were omitted from the original document.  It probably has to do with the H. blanking rise time to reference white period for each field.  In NTSC these are identical to horizontal sync.  PAL fields seem to require an offset, maybe because the 25Hz signal does not always appear in phase with other timing signals?  Please consult an expert if you actually need this information.
  Horizontal Video registers work like the vertical regs.  The first halfword defines when hsync stops and video starts, the second value the duration.

  The Video Burst Register (probably, because again this was omitted from the original documents) defines the burst locked sinewave color field.  That (should) be everything from the end of vblank to the end of active video.  Pushing the first value back would (presumably) send data during vblank and pushing the end forward would shorten the displayed image.  Probably.


  Onto more practical registers, starting with the obvious ones.
  The RDRAM Address is initially set to the start of a framebuffer or other image source.  This will shift forward each halfline read.  Note it can point to a window in a larger source image.
  Horizontal Width defines how wide each *halfline* is in bytes.  (Pretty certain this was wrong in the original document.)
  Setting the Vertical Interrupt indicates which halfline triggers a CPU interrupt.  Usually used for refill, though nothing saying you couldn't chase the beam in some arcane way.

  The X & Y Scale registers are halfword pairs, both (presumably) in 2.10 format.  These are used to rectify the fact N64 can handle completely arbitrary input video sizes.
  The first halfword provides a sub-pixel offset, primarily for interlaced output.  Drawn on its own, a second interlaced field would appear on top of the original.  The subpixel offset shifts video output, overlapping the previous field.
  The second is a scale factor used to fill the video field with the data from the image source.  Some games, like Midway Arcade Classics, will also use small adjustments for magnification.
  Note that scale applies to the field drawn, not full intended image!
  Its value is inverted, stored as a 2.10 number.  Using NTSC as an example, 0x400 would be a x1 magnification used for 640/480, 0x200 a x2 scale (1/0.5) for 320/240.  Some examples of middling values include GE's intro (0x2C0 = 1.45: 440px), Turok 2's intro (0x34C = ~1.33: 480px), Turok 3 & Rage War's (0x1E3 = 2.25: 284px), or Donald Duck's several oddballs (0x1F3 = ~2.13: 300px; 0x2A6 = 1.6: 400px)

  Y Scale factors are often used for lazy NTSC -> PAL conversion, using a factor of x1.2.  Interlacing doubles y resolution, so y scale can be adjusted to compensate.  Hi-res deflickered modes use 480 source, so a scale factor of 0.5 (0x800) is used to blend two scanlines together, combined with subpixel offsets to overlay interlaced fields at a 25% / 75% rate.

  Lastly, if the displayed field needs to be adjusted (shifted up/down on screen, or letterboxed) that is done with the Vertical Video registers.  These adjust what half-line video starts displaying at and which it ends on.  "480" is a myth.  Normal output (difference in these values) is 474.  Some games, like the aforementioned Donald Duck, letterbox to some degree.  In 3D areas it clips 8 off the top, 12 off the bottom (002D 01F3), for a displayed area resolution of 454.


  A couple notes from a collection of multiple sources gathered over the years.
*) Serrate introduces an extra half-line into video output so the TV can produce offset field for interlacing to prevent it drawing fields on top of the previous one.  Recommended on when interlacing used.
*) Z-buffer reduces pixel fill rate 2-3 times.
*) RDP drawing span limitations can cause interlaced artifacting along the right edge in 640x480.  632 width can be used to compensate.  (Curse you Densha de Go)
*) Due to restrictions on the memory bandwidth when deflickered interlaced mode is used, there are cases in which noise will appear in the screen when there is frequent memory access to the same memory bank (1MB units) as that of the frame buffer during display. The various frame buffers and the Z-buffer need to be situated in separate memory banks. Also make sure not to situate the buffers used for DMA transfer (audio heap, etc.) in the same memory bank as the frame buffers.  (Note: Fairly certain this came from the manual, and it does raise the question about bandwidth concerns when a single 4MB module is in use.  Might not apply equally to all console revisions.)
*) Irregardless the mode, the actual displayed color depth is 21bit.  8-bit channels are cropped to 5-bit.  Noise dither and gamma correction are set in the two least significant bits, with the color data in the most significant bits.  A consequence is that gamma boost and noise dither are free operations.  The sole advantage of 32bit color framebuffers is retention of data while drawing, much like how 10bit video encoding is used.
*) VI AA roughly halves framerate and RDP AA additionally halves it.  The bottleneck is rdram access during read/modify/write cycles.  If one is in use, don't use the other!

-Zoinkity