Here are some details about the host interface of the encoder chips and their timings. There are several ways the encoder chip and the host CRTC can interact. * In clock master mode, the encoder synthesizes the pixel clock, which is fed into the host. The host then returns this clock together with the pixel data to the encoder, possibly after some internal delay. * In clock slave mode, the host synthesizes the pixel clock. Unless this clock is very accurate, this may cause worse color quality, because the encoder has to adapt its color subcarrier frequency to the external clock. * In sync master mode, the encoder chip produces HSYNC* and VSYNC* signals, which force these syncs upon the host. * In sync slave mode, the host chip is responsible for these signals. Here is an illustration of the resulting three interface modes (clock slave/sync master is usually not used). The encoder chip is on the left, the host on the right: clock master/ clock master/ clock slave/ sync master sync slave sync slave CLKO E ] -->-- [.. E ] -->-- [ .. E ] -* [ N ] [ V N ] [ V N ] [ CLKI C ] --<-- [.. H C ] --<-- [ .. H C ] --<-- [ H O ] [ O O ] [ O O ] [ O HSYNC* D ] -->-- [ S D ] --<-- [ S D ] --<-- [ S E ] [ T E ] [ T E ] [ T VSYNC* R ] -->-- [ R ] --<-- [ R ] --<-- [ Often the encoder chips have extra blank, frame, or data request signals. These seem to be unused. In the clock master modes, the host CRTC has to genlock onto the pixel clock. This is controlled by bit 7 of CRTC Register 0x28. The HSYNC* and VSYNC* signals are active high for the NV host, but it might be possible to change this in register 680700 (TV_SETUP). In sync master mode, the relationship between the CRTC sync signals and the interface sync signals is a bit tricky. It is explained below for the Brooktree encoder. For the sync slave mode on card with two heads it looks like both heads must be in sync slave mode; otherwise the image is not stable. BROOKTREE ========= HORIZONTAL TIMING ~~~~~~~~~~~~~~~~~ Analog Signal (tv chip out) DDDDDDDDDDDD ___ ____BBBB____| |_____ __ |____| |____| a b c d e f g (Example Timings for PAL 800x600) a) 0 us Start of hsync pulse (always at 0 clocks) b) 4.70 us End of hsync pulse (at HSYNC_WIDTH clocks) c) 5.60 us Start of burst (at HBURST_BEGIN clocks) d) 7.58 us End of burst (at HBURST_END + 128 clocks) e) 10.5 us Start of analog data (at HBLANK_O clocks) f) ?? us End of analog data (at HBLANK_O + 2 * HACTIVE clocks) g) 64 us End of line (at H_CLKO clocks) Digital Signal (tv chip in) _ _ HSYNC* ____| |___________________________| |______ ______________ _______________ BLANK* |____________| DATA ______________XXXXXXXXXXXXXX_______________ HSYNC ____ __________________________ _____ |__| |__| _ _______________________ _____ HSYNC' |__X__| |__X__| BT a b c d e CRTC r' r s t u r' r (Example timings for 800x600 PAL "Normal") a) 0 clocks b) 2 clocks (at HSYNWIDTH) c) 140 clocks (at H_BLANKI) d) 940 clocks (at H_BLANKI + H_ACTIVE) e) 960 clocks (at H_CLKI) Note that HSYNC stands for the monitor horizontal sync signal. The CRTC seems to set its internal counters at the HSYNC* signal to the HSyncStart value. This is necessary because unlike the BT chip, the CRTC normally starts at 0 when the digital data is output. r) 824 clocks (at HSyncStart) s) 880 clocks (at HSyncEnd) t) 960 clocks (at HTotal = HCLK_I) t) 0 clocks (counter reset) u) 800 clocks (at HDisplay = H_ACTIVE) That means that increasing HTotal will move the image to the right (both in the monitor and the TV), while increasing HSyncStart will move it to the left. However, if HTotal is less then HCLK_I, the monitor sync signal will be generated before the HSYNC* signal (r' in HSYNC' in the diagram above). When the HSYNC* signal arrives, the internal counter is set to HSyncStart again, effectively lengthening the monitor sync pulse. But the distance between r and s remains the same. That means the image on the monitor will not move, while the image on the TV may be adjusted, because s occurs now earlier relative to the HSYNC* signal. But if the width of the monitor sync pulse is too small, two sync pulses may be generated (as shown by the X in the HSYNC' diagram above). This should be avoided. As the TV image can be adjusted with HSYNOFFSET, it is not necessary to have HTotal < HCLK_I. Note that the lowest bit of HSYNOFFSET has strange effects (see below). BLANK INPUT ~~~~~~~~~~~ If BLANK* is enabled as input (EN_BLANKO=0, EN_DOT=0), then H_BLANKI seems to denote extra blank cycles after the falling flank before the data is accepted. (Increasing H_BLANKI moves the image to the left, decreasing moves it to the right). VERTICAL SCALING ~~~~~~~~~~~~~~~~ The BT chip is able to subsample 1 to 3 input lines into one (interlaced) output line. Therefore the input lines can arrive faster than than output lines are produced, and horizontal timing for TV and monitor are (nearly) independent of each other. There is a FIFO between the vertical scaling engine of the chip and the digital/analog converter to decouple these parts. If, however, the horizontal timings are too different, this FIFO may overrun or underrun. To be precise, one output line corresponds to 1 + (V_SCALE / 4096) input lines. The first and last line are always output, so roughly V_ACTIVEO = VACTIVE_I / (1 + V_SCALE / 4096) + 2. VERTICAL TIMING ~~~~~~~~~~~~~~~ Digital Signal (in) HSYNC* ___|__|__|__|__|__|__ ... __|__|__|__|__|__|__ _ _ VSYNC* ___| |_______________________________| |______ LINES _____________XX_XX_XX ... XX_XX_XX____________ _____ ______________________________ __ VSYNC |__| |__| BT a b c d (Example timings for 800x600 PAL) a) 0 lines b) 95 lines (at V_BLANKI) c) 695 lines (at V_BLANKI + V_ACTIVEI) d) 750 lines (at V_LINESI) The vertical timing for the CRTC seems to be similar to the horizontal timing (same effects if VTotal < V_LINESI). However, as vertical sync pulses are short (a few lines), and VTotal < V_LINESI is true in nearly all modes in data_bt, one would expect a "double sync pulse" effect. But I have not seen this with my Multisync monitor. Effects of changing CRTC/BT Registers ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Register Increase Decrease VSync mon/tv up mon/tv down VTotal tv down tv up HSync mon/tv left mon/tv right HTotal tv right tv left hblanki tv left tv right hblanko tv right tv left vblanki tv cut top vblanko tv cut top hsynoffset tv right tv left vactivei tv cut bottom If HTotal > h_clki, then the monitor image also moves right when changing HTotal. Similar for VTotal and v_linesi. Sometimes hoffset has different effects if it is even/odd, so the image seems to jump. CHRONTEL ======== Timing is much less flexible with the Chrontel encoder chip. The M and N values modify the phased locked loop (PLL) to produce the pixel clock. Each data pixel requires two clocks. The lower bit of the VOS register switches between NTSC and PAL. For each of those, the value of the SR registers determines the number of total lines (which roughly correspond to the scale factor). The scale factor also stretches the pixels horizontally. In this way, the number of total pixels/line can be calculated from the fixed horizontal frequency for PAL/NTSC, the pixel clock and the scaling factor. I have seen no register to provide this number directly. This is a bit strange, since the chip must produce a hsync signal after one complete line. Maybe that frequency is just determined by VOS and otherwise fixed. Changing the dot clock frequency causes the image on the TV to become unstable outside a small range, while the image on the monitor just widens or shortens, as expected. I am not sure what conclusions to draw from this. An additional feature of the Chrontel chip is that it can calculate the color frequency value (FSCI) by itself, upto the lowest 6 bits. This value is called CIV, and may be inspected on the status page. The chip can automatically transfer this value to the FSCI register if ACIV is enabled. On some systems, this seens ti produce bad values, so ACIV is disabled by default.