Video Interface: Difference between revisions

m (Fixed broken section link)
 
(25 intermediate revisions by 5 users not shown)
Line 131:
{{#invoke:Register table|definitions
| 31-17 | Undefined | Initialized to <code>0</code>
| 16 | DEDITHER_FILTER_ENABLEDEDITHER_ENABLE | Dedither Enable bit <br>1 {{=}} DeditherDedithering (aka "dither filter") is enabled; (normally used for 16-bit framebuffers; thisto maytry causeto verticalreconstruct bandinga if anti32-aliasingbit isimage. disabledNotice [https://github.com/DragonMindedthat this filter only works correctly when <code>AA_MODE</libdragon/issues/159code> asis seenset here])to <code>00</code>. <br>0 {{=}} Dedither filterDedithering is disabled (normally used for 32-bit color)
| 15-12 | PIXEL_ADVANCE[3:0] | Use <code>0b0011</code> for most effective behavior on N64. On the iQue Player a pixel advance of <code>0b0011</code> creates video glitches, applications typically use <code>0b0001</code> instead.
| 11 | KILL_WE | Diagnostics only, possibly kills VI DMA writes to line buffers making them safe to access via the test registers.
| 10 | Undefined | Initialized to <code>0</code>
| 9-8 | AA_MODE[1:0] | Anti-Alias Mode <br>11 {{=}} AA and resampling disabled, replicate pixels without interpolation <br>10 {{=}} AA disabled, resampling enabled, and operate as if everything is covered <br>01 {{=}} AA enabled, resampling enabled, and only fetches extra lines as needed <br>00 {{=}} AA enabled, resampling enabled, and will always fetch extra lines (required if <code>DEDITHER_ENABLE</code> is 1).
| 7 | TEST_MODE | Diagnostics only, enables usage of the line buffer test registers VI_TEST_ADDR/VI_STAGED_DATA. KILL_WE should also be set to avoid access races between the VI and CPU.
| 7 | TEST_MODE | Diagnostics only
| 6 | SERRATE | Normally enabledRequired if interlacing, otherwisepermitted when progressive, often disabled <br>1 {{=}} Enabled <br>0 {{=}} Disabled
| 5 | VBUS_CLOCK_ENABLE | Vbus Clock Enable <br>1 {{=}} Enabled <br>0 {{=}} Disabled <br>{{spaces|4}}'''''Warning: Always leave disabled!''' Setting this bit enables a second driver, which will output on the same pin as another driver, possibly causing physical console damage.''
| 4 | DIVOT_ENABLE | Fixes minor artifacts left over from anti-aliasing (more details below) <br>1 {{=}} Enabled (usually used if AA is enabled) <br>0 {{=}} Disabled
Line 145:
}}
'''Extra Details:'''
: '''DEDITHER_FILTER_ENABLEDEDITHER_ENABLE'''
:: When enabled, the VI will run a de-dithering algorithm, trying to reverse the effects of dithering on each pixel to produce an higher resolution color information on the analog output. This is useful when the framebuffer is 16-bit and has been dithered while drawing. To do so, VI looks at the 8 neighbors around each pixel and perform an error correction; the algorithm used works best with images that have been dithered using the "Magic Square" dithering algorithm (that the RDP can be configured to do). The VI does de-dedithering only on pixels where coverage is full; on pixels with partial coverage, the standard AA algorithm is performed. '''NOTE''': this filter requires <code>AA_MODE</code> to be set to <code>00</code>, otherwise the image is corrupted by vertical streaks ([https://github.com/DragonMinded/libdragon/issues/159 as seen here]).
: '''DIVOT_ENABLE'''
:: When enabled, this feature fixes artifacts that the anti-aliasing algorithm leaves behind. The median color of three neighboring pixels, from any pixels on or next to silhouette edges, is selected to be displayed in place of the center pixel. Effectively removing any one pixel divots that can be seen in some fractal-based terrains. The anti-aliasing function encounters issues when multiple fragments occur on a single pixel. Since this filter is only used on edges, and not the surface of an object, texture details will not be affected. Be aware that bad quality effects can occur when the ''decal line'' rendering mode is used in conjunction with this filter, as the rendering mode generates edges that the filter can detect.
Line 176:
| 23-0 | ORIGIN[23:0] | RDRAM base address of the video output Frame Buffer. This can be changed as needed to implement double or triple buffering.
}}
'''Extra Details:'''
: ORIGIN must be a multiple of 8 (i.e. ORIGIN[2:0] must be 0). Otherwise the VI output may be noisy, shifted, or weirdly interleaved.
 
==== <span style="display:none;">0x0440 0008 - VI_WIDTH ====
----
Line 200 ⟶ 203:
| 11-0 | WIDTH[11:0] | This is the width in pixels of the frame buffer if you draw to the frame buffer based on a different width than what is given here the image will drift with each line to the left or right. The common values are 320 and 640, the maximum value is 4095. The same value would also be used on drawing commands for clipping or scissors. This can also be used with High Res interlacing modes to change the odd and even lines of the frame buffer to be drawn to screen by doubling the width of this value and changing the VI_ORIGIN register to the odd or even field being displayed.
}}
'''Extra Details:'''
: WIDTH must be a multiple of 2 (if 32bpp) or 4 (if 16bpp) such that the number of bytes from one scanline to the next is a multiple of 8. The same caveats about VI_ORIGIN apply here, but incorrect display will only happen on some scanlines.
 
==== <span style="display:none;">0x0440 000C - VI_V_INTR ====
----
Line 271 ⟶ 277:
| 31-30 | Undefined | Initialized to <code>0</code>
| 29-20 | BURST_START[9:0] | Start of color burst in pixels from hsync
| 19-16 | VSYNC_WIDTH[3:0] | VerticalOne less than the vertical sync widthduration in half lines
| 15-8 | BURST_WIDTH[7:0] | Color burst width in pixels
| 7-0 | HSYNC_WIDTH[7:0] | Horizontal sync width in pixels<br>Default value of <code>0x01</code>
Line 279 ⟶ 285:
:* horizontal sync width in pixels: 57 (decimal)
:* color burst width in pixels: 34 (decimal)
:* vertical sync width in half lines: 5 (decimal) (and thus 6 half-lines)
:* start of color burst in pixels from h-sync: 62 (decimal)
: PAL @ any resolution is <code>0x0404233A</code>
:* horizontal sync width in pixels: 58 (decimal)
:* color burst width in pixels: 35 (decimal)
:* vertical sync width in half lines: 4 (decimal) (and thus 5 half-lines)
:* start of color burst in pixels from h-sync: 64 (decimal)
 
==== <span style="display:none;">0x0440 0018 - VI_V_SYNC ====
----
Line 308 ⟶ 315:
{{#invoke:Register table|definitions
| 31-10 | Undefined | Initialized to <code>0</code>
| 9-0 | V_SYNC[9:0] | TotalOne less than the total number of visible and non-visible half-lines. This should match either NTSC/MPAL (non-interlaced: <code>0x20D525</code>, interlaced: <code>0x20C524</code>) or PAL (non-interlaced: <code>0x271625</code>, interlaced: <code>0x270624</code>)
}}
 
==== <span style="display:none;">0x0440 001C - VI_H_SYNC ====
----
Line 334 ⟶ 342:
| 20-16 | LEAP[4:0] | 5-bit leap pattern used only for PAL. Should always use standard value of <code>0x15</code>
| 15-12 | Undefined | Initialized to <code>0</code>
| 11-0 | H_SYNC[11:0] | TotalOne widthless than the total length of a line,scanline in 1/4 pixel units. Should always use standard values: NTSC (<code>0xC153093</code>), PAL (<code>3177</code>), or PALMPAL (<code>0xC693090</code>)<br>Default value of <code>2047</code> (</code>0x7FF</code>)
}}
 
'''Extra Details:'''
: LEAP chooses whether to use LEAP_A or LEAP_B on each vsync repeating every five vsyncs. The NTSC default (0) means "always use LEAP_A". The PAL default (0x15) means "alternate using LEAP_B, LEAP_A, LEAP_B, LEAP_A, LEAP_B" and repeat
: Derivation of numbers:
:: NTSC has 227.5 chroma periods per scanline. NTSC N64 has 13.6 VI clocks per chroma period. 227.5 × 13.6 = 3094
:: MPAL has 227.25 chroma periods per scanline. MPAL N64 has 13.6 VI clocks per chroma period. 227.25 x 13.6 = 3090.6
:: PAL (European) has 283.7516 chroma periods per scanline. PAL N64 has 11.2 clocks per chroma period. 283.75 x 11.2 = 3178
: H_SYNC is also used by the RDRAM Interface for refresh timings. As the default is notably shorter than regular video modes, there will be a noticeable impact to memory bandwidth until H_SYNC is configured to a valid video mode.
 
==== <span style="display:none;">0x0440 0020 - VI_H_SYNC_LEAP ====
----
Line 358 ⟶ 375:
{{#invoke:Register table|definitions
| 31-28 | Undefined | Initialized to <code>0</code>
| 27-16 | LEAP_A[11:0] | NTSC: Identical to H_SYNC width. PAL: <code>0xC6E3182</code>
| 15-12 | Undefined | Initialized to <code>0</code>
| 11-0 | LEAP_B[11:0] | NTSC: Identical to H_SYNC width. PAL: <code>0xC6F3183</code>
}}
'''Extra Details:'''
: LEAP_n specifies an alternate scanline length for one scanline during vsync. Values larger than H_SYNC specify the length of the second scanline of vsync. Values smaller than H_SYNC specify the length of the first scanline of vsync and have a variety of undesired side effects, such as skipping one hsync entirely or leaving csync erroneously high for one whole scanline. Serration changes these effects subtly.
: Specifically, a counter is started at the start of vsync. When that counter is equal to LEAP_n, the VI starts or restarts the second scanline of vsync without changing the status of the csync bit.
 
: The default PAL values of LEAP, LEAP_A, and LEAP_B appear to be chosen to add PAL's nominal "one extra chroma period per 625 whole scanlines emitted". Average of 5,6,5,6,5 = 5.4; divide 5.4 by 11.2 VI clocks per chroma period = 1/2 chroma period per field.
 
==== <span style="display:none;">0x0440 0024 - VI_H_VIDEO ====
Line 385 ⟶ 407:
{{#invoke:Register table|definitions
| 31-26 | Undefined | Initialized to <code>0</code>
| 25-16 | H_START[9:0] | Start of the active video image, in screen pixels. Typical values: NTSC (<code>0x06C108</code>) or PAL (<code>0x080128</code>)
| 15-10 | Undefined | Initialized to <code>0</code>
| 9-0 | H_END[9:0] | End of the active video image, in screen pixels from hsync. Typical values: NTSC (<code>0x2EC748</code>) or PAL (<code>0x300768</code>)
}}
'''Extra Details:'''
: H_START specifies when VI evaluation starts. The screen remains blanked for several pixels afterwards, while the VI loads values from RAM for filtering, even if AA_MODE is set to "no filtering".
: H_END specifies the first black pixel on the right end of each scanline.
 
==== <span style="display:none;">0x0440 0028 - VI_V_VIDEO ====
----
Line 467 ⟶ 493:
| 11-0 | X_SCALE[11:0] | 1/horizontal scale up factor (2.10 format)
}}
===== Errata =====
* If [[#0x0440_0000_-_VI_CTRL|AA_MODE]] = 11 (resampling disabled), [[#0x0440_0000_-_VI_CTRL|TYPE]] = 10 (16-bit), X_SCALE is 0x200 or lower, and H_START is less than 128, the VI generates invalid output, consisting of the first 64 pixels from the framebuffer from the current line, then 64 pixels of garbage, and these two repeat for the rest of each scanline
* If X_SCALE is higher than 0x800 (32bpp) or 0xE00 (16bpp), the scaler renders incorrect pixels, with specifics depending on depth. This appears to be due to exceeding the number of VI fetches allocated per scanline.
 
==== <span style="display:none;">0x0440 0034 - VI_Y_SCALE ====
----
Line 493 ⟶ 523:
| 11-0 | Y_SCALE[11:0] | 1/vertical scale up factor (2.10 format)
}}
===== Erratum =====
* If Y_SCALE exceeds 0xC00, it instead behaves like a glitchy variation of 3*(0x1000-Y_SCALE)
 
==== <span style="display:none;">0x0440 0038 - VI_TEST_ADDR ====
----
Line 515 ⟶ 548:
{{#invoke:Register table|definitions
| 31-7 | Undefined | Initialized to <code>0</code>
| 6-0 | TEST_ADDR[6:0] | DiagnosticsSets only,the usageline unknownbuffer word address at which VI_STAGED_DATA will read/write data.
}}
==== <span style="display:none;">0x0440 003C - VI_STAGED_DATA ====
Line 538 ⟶ 571:
{{#invoke:Register table|foot}}
{{#invoke:Register table|definitions
| 31-0 | STAGED_DATA[31:0] | Reads from this register returns 32 bits of line buffer data at the address specified in VI_TEST_ADDR. Writes to this register emplace 32 bits of data into the line buffer at the address specified in VI_TEST_ADDR. Usage requires TEST_MODE to be set in VI_CTRL.
| 31-0 | STAGED_DATA[31:0] | Diagnostics only, usage unknown
}}
 
=== Fixed-Point Format ===
 
[https://en.m.[wikipedia.org/wiki/:Fixed-point_arithmetic |Fixed-point]] is a method of representing decimal numbers.
Unlike floating-point numbers, fixed-point numbers allocate a specific number of bits for the integer (X) and
fractional (Y) parts of the number, denoted as "X.Y format" (similar to [https://en.m.[wikipedia.org/wiki/:Q_(number_format) |Q-notation]]).
In this format, a certain number of bits are dedicated to the integer part, while the
remaining bits represent the fractional part. For instance, some VI registers employ
the 2.10 format, where two bits are used for the integer part and ten bits are
allocated for the fractional part, resulting in a total of twelve bits.
Line 583 ⟶ 616:
</math>
 
= How to use this information =
=== Interlace Mode ===
The NTSC (and PAL) standard support interlace mode which is commonly associated with high resolution, but it can be used for more than that.