File: timing.txt

package info (click to toggle)
nvtv 0.4.7-2
  • links: PTS
  • area: main
  • in suites: sarge
  • size: 2,328 kB
  • ctags: 4,303
  • sloc: ansic: 30,302; sh: 6,614; makefile: 159
file content (248 lines) | stat: -rw-r--r-- 9,307 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
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.