Video Interface: Difference between revisions
→0x0440 0000 - VI_CTRL
(Add a note about the dither filter causing vertical bars in analog video.) |
|||
(41 intermediate revisions by 8 users not shown) | |||
Line 2:
= Video DAC =
The Video DAC
[[File:N64videosys.png|thumb|Video DAC Bus and waveform. Image from: http://members.optusnet.com.au/eviltim/n64rgb/n64rgb.html]]
The Video DAC clock runs at 4 times the speed of the internal pixel clock so the multiplexing can happen on the VI bus. This 4 clock process outputs the RGB colors and the VSync, Hsync, Clamp and Csync and is reset using a dsync reset signal.
{| class="wikitable"
|+
Line 63:
|Low
|}
There are 3 different
File:MX8330 video maths.png|Mx8330 video clock maths and fselect
</gallery>
Line 69:
|+
!TV Signal Type
!MX8330 Nominal input clock (by definition)
!MX8330 FSEL input
!Measured Video Clock
!Clock Maths using datasheet
|-
|NTSC
|14.32MHz (18 × 227.5 ÷ 286)
|HIGH
|48.62Mhz
|(14.3 * 17) / 5
|-
|PAL
|17734475 Hz
|LOW
|49.56Mhz
|(17.7 * 14) / 5
|-
|MPAL
|14.30MHz (18 × 227.25 ÷ 286)
|HIGH
|Not yet measured
|(14.3 * 17) / 5
|}
Line 109:
-n = Default value n at power on
<x:y> = Specifies bits x to y, inclusively</pre>
==== <span style="display:none;">0x0440 0000 - VI_CTRL
----
{{#invoke:Register table|head|1200px|VI_CTRL <code>0x0440 0000</code>}}
Line 119:
| U-0 || U-0 || U-0 || U-0 || U-0 || U-0 || U-0 || RW-0
|-
| — || — || — || — || — || — || — || style="font-size:
{{#invoke:Register table|row|15:8}}
| RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || U-0 || RW-0 || RW-0
|-
| colspan="4" | PIXEL_ADVANCE
{{#invoke:Register table|row|7:0}}
| RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0
|-
| TEST_MODE || SERRATE || style="font-size: 70%;" | VBUS_CLOCK_ENABLE || DIVOT_ENABLE || GAMMA_ENABLE || style="font-size: 70%;" | GAMMA_DITHER_ENABLE || colspan="2" | TYPE
{{#invoke:Register table|foot}}
{{#invoke:Register table|definitions
| 31-17 | Undefined | Initialized to <code>0</code>
| 16 |
| 15-12 | PIXEL_ADVANCE
| 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
| 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
| 3 | GAMMA_ENABLE | Fixes non-linear gamma in TV screens (more details below) <br>1 {{=}} Enabled <br>0 {{=}} Disabled
| 2 | GAMMA_DITHER_ENABLE | Adds randomized noise to the video output, in the least significant bits to remove mach banding artifacts <br>1 {{=}} Enabled (usually set unless banding artifacts are desired for extra effect) <br>0 {{=}} Disabled
| 1-0 | TYPE
}}
'''Extra Details:'''
: '''DEDITHER_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.
: '''GAMMA_ENABLE'''
:: This feature is used to correct non-linear gamma found in TV screens (although this may have changed in modern TV's). To do this, the feature square roots the linear color space that the rendering pipeline uses. TV screens will raise these color values to the power of 2.2 to 2.4, which leaves a residual gamma behind of around 1.1 to 1.2. This residual value is actually preferred as a gamma slightly above 1.0 will generate more color accurate images when the TV is in darker than normal rooms. When using MPEG or JPG images, the gamma correction is included in the image data, so this feature should be turned off accordingly.
==== <span style="display:none;">0x0440 0004 - VI_ORIGIN ====
----
{{#invoke:Register table|head|550px|VI_ORIGIN <code>0x0440 0004</code>}}
Line 159 ⟶ 162:
| RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0
|-
| colspan="8" | ORIGIN
{{#invoke:Register table|row|15:8}}
| RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0
|-
| colspan="8" | ORIGIN
{{#invoke:Register table|row|7:0}}
| RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0
|-
| colspan="8" | ORIGIN
{{#invoke:Register table|foot}}
{{#invoke:Register table|definitions
| 31-24 | Undefined | Initialized to <code>0</code>
| 23-0 | ORIGIN
}}
'''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 ====
----
{{#invoke:Register table|head|550px|VI_WIDTH <code>0x0440 0008</code>}}
Line 187 ⟶ 193:
| U-0 || U-0 || U-0 || U-0 || RW-0 || RW-0 || RW-0 || RW-0
|-
| — || — || — || — || colspan="4" | WIDTH
{{#invoke:Register table|row|7:0}}
| RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0
|-
| colspan="8" | WIDTH
{{#invoke:Register table|foot}}
{{#invoke:Register table|definitions
| 31-12 | Undefined | Initialized to <code>0</code>
| 11-0 | WIDTH
}}
'''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 ====
----
{{#invoke:Register table|head|550px|VI_V_INTR <code>0x0440 000C</code>}}
Line 211 ⟶ 220:
| U-0 || U-0 || U-0 || U-0 || U-0 || U-0 || RW-1 || RW-1
|-
| — || — || — || — || — || — || colspan="2" | V_INTR
{{#invoke:Register table|row|7:0}}
| RW-1 || RW-1 || RW-1 || RW-1 || RW-1 || RW-1 || RW-1 || RW-1
|-
| colspan="8" | V_INTR
{{#invoke:Register table|foot}}
{{#invoke:Register table|definitions
| 31-10 | Undefined | Initialized to <code>0</code>
| 9-0 | V_INTR
}}
==== <span style="display:none;">0x0440 0010 - VI_V_CURRENT
----
{{#invoke:Register table|head|550px|VI_V_CURRENT <code>0x0440 0010</code>}}
Line 235 ⟶ 244:
| U-0 || U-0 || U-0 || U-0 || U-0 || U-0 || RW-0 || RW-0
|-
| — || — || — || — || — || — || style="font-size: 88%;" colspan="2" | V_CURRENT
{{#invoke:Register table|row|7:0}}
| RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0
|-
| colspan="8" | V_CURRENT
{{#invoke:Register table|foot}}
{{#invoke:Register table|definitions
| 31-10 | Undefined | Initialized to <code>0</code>
| 9-0 | V_CURRENT
}}
==== <span style="display:none;">0x0440 0014 - VI_BURST
----
{{#invoke:Register table|head|550px|VI_BURST <code>0x0440 0014</code>}}
Line 251 ⟶ 260:
| U-0 || U-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0
|-
| — || — || colspan="6" | BURST_START
{{#invoke:Register table|row|23:16}}
| RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0
|-
| colspan="4" | BURST_START
{{#invoke:Register table|row|15:8}}
| RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0
|-
| colspan="8" | BURST_WIDTH
{{#invoke:Register table|row|7:0}}
| RW-1 || RW-1 || RW-0 || RW-1 || RW-0 || RW-0 || RW-0 || RW-1
|-
| colspan="8" | HSYNC_WIDTH
{{#invoke:Register table|foot}}
{{#invoke:Register table|definitions
| 31-30 | Undefined | Initialized to <code>0</code>
| 29-20 | BURST_START
| 19-16 | VSYNC_WIDTH
| 15-8 | BURST_WIDTH
| 7-0 | HSYNC_WIDTH
}}
'''Examples:'''
Line 276 ⟶ 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 ====
----
{{#invoke:Register table|head|550px|VI_V_SYNC <code>0x0440 0018</code>}}
Line 297 ⟶ 307:
| U-0 || U-0 || U-0 || U-0 || U-0 || U-0 || RW-0 || RW-0
|-
| — || — || — || — || — || — || colspan="2" | V_SYNC
{{#invoke:Register table|row|7:0}}
| RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0
|-
| colspan="8" | V_SYNC
{{#invoke:Register table|foot}}
{{#invoke:Register table|definitions
| 31-10 | Undefined | Initialized to <code>0</code>
| 9-0 | V_SYNC
}}
==== <span style="display:none;">0x0440 001C - VI_H_SYNC ====
----
{{#invoke:Register table|head|550px|VI_H_SYNC <code>0x0440 001C</code>}}
Line 317 ⟶ 328:
| U-0 || U-0 || U-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0
|-
| — || — || — || colspan="5" | LEAP
{{#invoke:Register table|row|15:8}}
| U-0 || U-0 || U-0 || U-0 || RW-1 || RW-1 || RW-1 || RW-1
|-
| — || — || — || — || colspan="4" | H_SYNC
{{#invoke:Register table|row|7:0}}
| RW-1 || RW-1 || RW-1 || RW-1 || RW-1 || RW-1 || RW-1 || RW-1
|-
| colspan="8" | H_SYNC
{{#invoke:Register table|foot}}
{{#invoke:Register table|definitions
| 31-21 | Undefined | Initialized to <code>0</code>
| 20-16 | LEAP
| 15-12 | Undefined | Initialized to <code>0</code>
| 11-0 | H_SYNC
}}
'''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 ====
----
{{#invoke:Register table|head|550px|VI_H_SYNC_LEAP <code>0x0440 0020</code>}}
{{#invoke:Register table|row|31:24}}
| U-0 || U-0 || U-0 || U-0 ||
|-
{{#invoke:Register table|row|23:16}}
| RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0
|-
| colspan="8" | LEAP_A
{{#invoke:Register table|row|15:8}}
| U-0 || U-0 || U-0 || U-0 ||
|-
{{#invoke:Register table|row|7:0}}
| RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0
|-
| colspan="8" | LEAP_B
{{#invoke:Register table|foot}}
{{#invoke:Register table|definitions
| 31-
|
| 15-
|
}}
'''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 ====
----
{{#invoke:Register table|head|550px|VI_H_VIDEO <code>0x0440 0024</code>}}
Line 365 ⟶ 391:
| U-0 || U-0 || U-0 || U-0 || U-0 || U-0 || RW-0 || RW-0
|-
| — || — || — || — || — || — || colspan="2" | H_START
{{#invoke:Register table|row|23:16}}
| RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0
|-
| colspan="8" | H_START
{{#invoke:Register table|row|15:8}}
| U-0 || U-0 || U-0 || U-0 || U-0 || U-0 || RW-0 || RW-0
|-
| — || — || — || — || — || — || colspan="2" | H_END
{{#invoke:Register table|row|7:0}}
| RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0
|-
| colspan="8" | H_END
{{#invoke:Register table|foot}}
{{#invoke:Register table|definitions
| 31-26 | Undefined | Initialized to <code>0</code>
| 25-16 | H_START
| 15-10 | Undefined | Initialized to <code>0</code>
| 9-0 | H_END
}}
'''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 ====
----
{{#invoke:Register table|head|550px|VI_V_VIDEO <code>0x0440 0028</code>}}
Line 391 ⟶ 421:
| U-0 || U-0 || U-0 || U-0 || U-0 || U-0 || RW-0 || RW-0
|-
| — || — || — || — || — || — || colspan="2" | V_START
{{#invoke:Register table|row|23:16}}
| RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0
|-
| colspan="8" | V_START
{{#invoke:Register table|row|15:8}}
| U-0 || U-0 || U-0 || U-0 || U-0 || U-0 || RW-0 || RW-0
|-
| — || — || — || — || — || — || colspan="2" | V_END
{{#invoke:Register table|row|7:0}}
| RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0
|-
| colspan="8" | V_END
{{#invoke:Register table|foot}}
{{#invoke:Register table|definitions
| 31-26 | Undefined | Initialized to <code>0</code>
| 25-16 | V_START
| 15-10 | Undefined | Initialized to <code>0</code>
| 9-0 | V_END
}}
==== <span style="display:none;">0x0440 002C - VI_V_BURST
----
{{#invoke:Register table|head|700px|VI_V_BURST <code>0x0440 002C</code>}}
Line 417 ⟶ 447:
| U-0 || U-0 || U-0 || U-0 || U-0 || U-0 || RW-0 || RW-0
|-
| — || — || — || — || — || — || style="font-size: 90%;" colspan="2" | V_BURST_START
{{#invoke:Register table|row|23:16}}
| RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0
|-
| colspan="8" | V_BURST_START
{{#invoke:Register table|row|15:8}}
| U-0 || U-0 || U-0 || U-0 || U-0 || U-0 || RW-0 || RW-0
|-
| — || — || — || — || — || — || style="font-size: 90%;" colspan="2" | V_BURST_END
{{#invoke:Register table|row|7:0}}
| RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0
|-
| colspan="8" | V_BURST_END
{{#invoke:Register table|foot}}
{{#invoke:Register table|definitions
| 31-26 | Undefined | Initialized to <code>0</code>
| 25-16 | V_BURST_START
| 15-10 | Undefined | Initialized to <code>0</code>
| 9-0 | V_BURST_END
}}
==== <span style="display:none;">0x0440 0030 - VI_X_SCALE
----
{{#invoke:Register table|head|550px|VI_X_SCALE <code>0x0440 0030</code>}}
Line 443 ⟶ 473:
| U-0 || U-0 || U-0 || U-0 || RW-0 || RW-0 || RW-0 || RW-0
|-
| — || — || — || — || colspan="4" | X_OFFSET
{{#invoke:Register table|row|23:16}}
| RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0
|-
| colspan="8" | X_OFFSET
{{#invoke:Register table|row|15:8}}
| U-0 || U-0 || U-0 || U-0 || RW-0 || RW-0 || RW-0 || RW-0
|-
| — || — || — || — || colspan="4" | X_SCALE
{{#invoke:Register table|row|7:0}}
| RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0
|-
| colspan="8" | X_SCALE
{{#invoke:Register table|foot}}
{{#invoke:Register table|definitions
| 31-28 | Undefined | Initialized to <code>0</code>
| 27-16 | X_OFFSET
| 15-12 | Undefined | Initialized to <code>0</code>
| 11-0 | X_SCALE
}}
===== 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 ====
----
{{#invoke:Register table|head|550px|VI_Y_SCALE <code>0x0440 0034</code>}}
Line 469 ⟶ 503:
| U-0 || U-0 || U-0 || U-0 || RW-0 || RW-0 || RW-0 || RW-0
|-
| — || — || — || — || colspan="4" | Y_OFFSET
{{#invoke:Register table|row|23:16}}
| RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0
|-
| colspan="8" | Y_OFFSET
{{#invoke:Register table|row|15:8}}
| U-0 || U-0 || U-0 || U-0 || RW-0 || RW-0 || RW-0 || RW-0
|-
| — || — || — || — || colspan="4" | Y_SCALE
{{#invoke:Register table|row|7:0}}
| RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0
|-
| colspan="8" | Y_SCALE
{{#invoke:Register table|foot}}
{{#invoke:Register table|definitions
| 31-28 | Undefined | Initialized to <code>0</code>
| 27-16 | Y_OFFSET
| 15-12 | Undefined | Initialized to <code>0</code>
| 11-0 | Y_SCALE
}}
===== 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 ====
----
{{#invoke:Register table|head|550px|VI_TEST_ADDR <code>0x0440 0038</code>}}
Line 507 ⟶ 544:
| U-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0
|-
| — || colspan="7" | TEST_ADDR
{{#invoke:Register table|foot}}
{{#invoke:Register table|definitions
| 31-7 | Undefined | Initialized to <code>0</code>
| 6-0 | TEST_ADDR
}}
==== <span style="display:none;">0x0440 003C - VI_STAGED_DATA
----
{{#invoke:Register table|head|550px|VI_STAGED_DATA <code>0x0440 003C</code>}}
Line 519 ⟶ 556:
| RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0
|-
| colspan="8" | STAGED_DATA
{{#invoke:Register table|row|23:16}}
| RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0
|-
| colspan="8" | STAGED_DATA
{{#invoke:Register table|row|15:8}}
| RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0
|-
| colspan="8" | STAGED_DATA
{{#invoke:Register table|row|7:0}}
| RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0
|-
| colspan="8" | STAGED_DATA
{{#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.
}}
= Fixed-Point Format =
[[wikipedia: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 [[wikipedia: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.
Here are examples of decimals represented in 2.10 format:
<math>
\begin{align*}
1\ == &\quad 01\ 0000000000\ \text{(0x400)} \\
0.25\ == &\quad 00\ 0100000000\ \text{(0x100)} \\
0.125\ == &\quad 00\ 0010000000\ \text{(0x80)} \\
\end{align*}
</math>
Note that not all decimals can be represented and must be approximated.
For example, in 2.10 format the decimal 3.14 is approximated as 3.1416015625,
or `11 0010010001`. Here's an example of how to convert from the binary to decimal:
The integer part is given by adding powers of two, starting at zero and going right to left:
<math>
\begin{align*}
\text{Binary:} &\quad 11 \\
\text{Value:} &\quad 1 \times 2^1 + 1 \times 2^0 = 3 \\
\end{align*}
</math>
The fractional part is given by adding the inverse of powers of two, staring at one and going left to right:
<math>
\begin{align*}
\text{Binary:} &\quad 0010010001 \\
\text{Value:} &\quad \frac{0}{2^1} + \frac{0}{2^2} + \frac{1}{2^3} + \frac{0}{2^4} + \frac{0}{2^5} + \frac{1}{2^6} + \frac{0}{2^7} + \frac{0}{2^8} + \frac{0}{2^9} + \frac{1}{2^{10}} = 0.1416015625 \\
\end{align*}
</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.
Line 590 ⟶ 669:
Advanced version of this is to reduce either the height or width and to increase the scaling so it still fits the screen but stretches the image out to fill the screen.
__FORCETOC__
|