xbv  andy@warmcat.com  2003-03-25

 - new: RGB AV Cable support (provisional)
 - new: PNG testcard feature
 - new: WSS (Widescreen Signalling) supported
 - new: 1024 x 576 supported!!!!!
 - new: extra support for flatpanel regs
 - new: serveral improvements in register relationship 
    automation
 - CRTC_LINESTRIDE now 11 bits thanks to Petteri Kangaslampi
 - CRTC regs mapped, named and dumped/writable
 - -s draws testcard into framebuffer

BACKGROUND

xbv is a tool to experiment with the video registers in
the Conexant video encoder and the nVidia video chip.  Its
a linux app, and you need to be root to use it.

In addition you can now use it to change video modes, 
although as X is not informed of this its of experimental use
right now.

There are three classes of registers which are involved
with the video generation:

1) Oldstyle CRTC registers
2) Newstyle Memory-mapped nVidia 32-bit registers
3) Conexant TV encoder registers over I2C

xbv can touch all three types, and is aware of some
critical interdependencies between registers.  For example,
some registers in the Conexant must match the value in a
nVidia Memorymapped register, xbv changes both in lockstep.

xbv is different from the hacked nvtv for the Xbox in that
it contains code to init as many registers as possible from
the value in the true variable registers.  For example, PAL
defines a 64uS HSYNC period, when you change the PLL speed
the number of clocks per HYSNC must change too, otherwise
your HYSNCs will no longer match the PAL 64uS.  xbv
automates this and several other derived values greatly
simplifying the interface.  Certain 'automated' registers
are still available for manual manipulation if its necessary.

xbv can be used to change the horizonal size and start offset,
it comes with a couple of scripts to demonstrate this in PAL
640 x 576 mode.


COMPILING AND DEPENDENCIES

Requires libpng3-dev to be installed

Just run make, output is called xbv


USING

Generally

xbv -<video standard> [commands...]

video standard is one of:

NTSC, NTSC60, PALBDGHI, PALN, PALNC, PALM, PAL60

The commands are

-m <mode index>  Change mode (index= 0..3 currently)
-s        Directly draw a full frame testcard into framebuffer
-d             Dump current settings to stdout
-c hx hx       Write CRTC reg hx (first) with value hx (second)
-e hx hx       write encoder reg hx (first) with value hx (second)
<regname> dec  Change setting to decimal value - setting is one of
               any of the uppercase names displayed by the -d dump


NEW VIDEO MODE!!!

This is 1024 x 576 anamorphic - on a normal TV it appears vertically 
compressed....

But on a widescreen TV in 16:9 mode the shape in the middle is a circle (ish)

./xbv -m 2 H_CLKI 1392 H_CLKO 1392 CRTC_HTOTAL 1354 H_ACTIVE 1032 NVHSYNCSTART 1050 H_BLANKI 335 H_BLANKO 570 NVHCRTC 1024 WSS 7 -p 16x9.png -d

This has now been included as video mode 4, you can get it with

xbv -m 4


Note the WSS 7 adds a digital sequence to the video which is
understood by the more expensive TVs to tell it that the video
data is 16:9 anamorphic and the TV should switch to widescreen
automatically.  Use WSS 0 to send out the extra data to
indicate that the TV should show this video in old 4:3 format.
Cheap widescreen TVs ignore WSS and make the user change the
TV mode with the remote.

Note also it has horizontal overscan compensation but not vertical
yet, that is the left and right sides should be fully visible but
the top and bottom are slightly offscreen.


NOTES ON RGB SUPPORT

To my dismay using the RGB cable created subtle timing differences
in the video modes.  I tried to patch these up but it was not
very successful.  The only mode that is fully working in RGB
is the 1024 x 576 widescreen mode.

1024x576 with the RGB AV on a widescreen TV is very comparable to
using a monitor, the difference in quality between composite and
RGB on the same TV is astounding.

For now a composite cable should be used with the other modes.



TODO

Fix RGB AV changes (or at least understand them)

The next move is to try to get the vertical scaling working
too, at the moment this is resulting in FIFO underruns in
the Conexant as things are not synched properly.

After that is resolved, we should be able to make changes in
the CRTC regs to change the whole resolution from scratch,
then we will truly be in control of the whole video.

http://web.inter.nl.net/hcc/S.Weijgers/FreeVGA/vga/crtcreg.htm



