Video Interface: Difference between revisions
→0x0440 0000 - VI_CTRL
(→0x0440 0020 - VI_H_SYNC_LEAP: by the evidence, this must be how LEAP is implemented) |
|||
(14 intermediate revisions by 4 users not shown) | |||
Line 131:
{{#invoke:Register table|definitions
| 31-17 | Undefined | Initialized to <code>0</code>
| 16 |
| 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.
| 6 | SERRATE |
| 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:'''
: '''
:: 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 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] |
| 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 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 314 ⟶ 315:
{{#invoke:Register table|definitions
| 31-10 | Undefined | Initialized to <code>0</code>
| 9-0 | V_SYNC[9:0] |
}}
==== <span style="display:none;">0x0440 001C - VI_H_SYNC ====
----
Line 340 ⟶ 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] |
}}
'''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 368 ⟶ 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>
| 15-12 | Undefined | Initialized to <code>0</code>
| 11-0 | LEAP_B[11:0] | NTSC: Identical to H_SYNC width. PAL: <code>
}}
'''Extra Details:'''
Line 376 ⟶ 383:
: 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
==== <span style="display:none;">0x0440 0024 - VI_H_VIDEO ====
Line 400 ⟶ 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>
| 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>
}}
'''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 483 ⟶ 494:
}}
===== Errata =====
* If [[#0x0440_0000_-_VI_CTRL|AA_MODE]] = 11 (resampling disabled), [[#0x0440_0000_-_VI_CTRL|TYPE]] = 10 (16-bit),
* 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.
Line 537 ⟶ 548:
{{#invoke:Register table|definitions
| 31-7 | Undefined | Initialized to <code>0</code>
| 6-0 | TEST_ADDR[6:0] |
}}
==== <span style="display:none;">0x0440 003C - VI_STAGED_DATA ====
Line 560 ⟶ 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.
}}
|