April 27, 2002: Update on compatibility between CX and BT chips: After you program a mode in the CX chips, you absolutely need to issue a 'timing reset' command. If you do not, the CX chips will be in an 'indetermined' state: sometimes things will be OK, and sometimes TVout flickers *a lot*. The BT chips don't need the timing reset (though they do support it): they handle setting new modes very gracefully.
Another issue is the detection of connected output devices. While the BT only needs a few microseconds to determine what's connected, the CX chips need 60.000uS!
Jan 25, 2002: Conexant has two chips, the CX25870 (non-macrovision) and the CX25871 (macrovision protection feature included) that are pin-compatible with the BT chips. Also these chips have a BT compatible mode, so BT software works with these chips almost without modification. One modification that is nessesary though, is that you place these chips in this compatibility mode. The VGA BIOS or for instance Windows just might place these chips in their enhanced mode after all..
Although the chips have this compatibility mode, they are not entirely compatible. You have to enable the active video output (EACTIVE) via register $6C for instance even if compatibility mode is ON. This active video bit is located in this register at a bit that is not used in BT chips. Another issue that has to be observed is the fact that CX chips will not release SDA during a READ command if the last received byte to be is acknowledged. The BT chips don't mind if you acknowledge this byte or not, they always release SDA.
Dec 21, 2001: Thanks to Dirk Thierbach, who pointed me to the RIVA128(ZX) datasheets, it is now known that cards with these chips will not work with BeTVOut. While TNT and newer chips use dedicated TVout chips to encode a Y/C or CVBS signal using a digital interface (IIC and a pixeldata port), RIVA128 chips use a entirely different method to create TVout signals.
The RIVA128(ZX) chips do TVout specific stuff themselves already as much as possible (interlacing, flickerfiltering). This way they only need a RGB to CVBS converter chip to generate a TVout signal from the (already analog) RGB RIVA128 output. This method of generating a TVout signal also implies that on RIVA128(ZX) cards, it's impossible to create different contents on VGA and TV simultaneously. On TNT and newer chips this *can* be done however, using hardware overlay: it's a shame almost nobody knows how to do that...
Dirk Thierbach recently began setting up Nvidia TVout for Linux. His project is called nv-tv-out, you can find it on SourceForge also. He also has TVout working on some cards already. Way to go, Dirk!
BTW: Note please that his project is dedicated to TVout support, unlike riva-tv (also on SourceForge) which also plans to enable video-in support.
Dec 13, 2001: The first PCI drivers (V0.20 and V0.21) are shutting down power to the TVout chips on (some) GeForce cards. This function does not exist on TNT1 and TNT2 cards however. As it turns out power to these (add-on) chips is controlled by the NV_PMC_ENABLE register: bit 0 ('1' is power-on). This function can come in handy for preserving power on laptops when TVout is not in use.
Converting the driver from ISA to PCI space turned out to be something of a challenge. For instance the 'vertical retrace' registers lock behaves different if you access these retrace registers via the PCI bus instead of via the ISA bus. The ISA variation is described in the standard VGA programmers manual, and of course nowadays this still works that way. Nvidia decided however to do it different for PCI access. You now need a different 'key', and also you need to unlock at the exact right moment, otherwise the 'door' locks again... For details, have a look at the driver sourcecode. ;-)
Nov 9, 2001: All VCD modes are operational also now. For the BT these modes were calculated by hand again. The VCD modes are implemented in exactly the same way for the Chrontel and Brooktree chips. This means that for PAL768x576 the PAL800x600 overscanning mode is used, while for NTSC640x480 the NTSC640x480 overscanning mode is used.
The VCD modes complete the modelist BeTVOut was planned to support. Now on to the GDW and GUI implementations...
Oct 25, 2001: All DVD modes are operational now. For the BT chip all registersettings had to be calculated 'by hand' for the NTSC720x480 mode, as this mode isn't documented anywhere apparantly. The datasheets used for the BT chip contain several errors, and also you have to 'scrape' all info together from different places. The scope came in very handy again also, because not every register description is detailed enough to calculate it 'blindly'.
Oct 20, 2001: For the best TVout experience in non-standard Desktop modes you would best use a videocard with Brooktree BT868 (non-macrovision) or BT869 TVout chip. With a BT chip the aspect ratio is exactly right, while with CH chips this is 'slightly' off. If you don't mind this then you are OK also with the CH chip. The reason for this is that the CH does not permit 'user changes' to the factory implemented videomodes. It supports only interlaced input slave DVD modes, which is something the RIVA chips apparantly cannot deliver. Because the BT chips are 'fully' programmable, they can be setup to output DVD modes in master mode with non-interlaced input.
To display the DVD modes on Chrontel systems anyway, the CH PAL800x600 'no overscan compensated' mode for the 720x576 resolution is used, which is why with only 720 pixels horizontally you get just a litte bit of overscan, instead of some more as it is meant to be. The CH NTSC640x480 'no overscan compensated' mode is used for 720x480 resolution, so displaying 720 pixels on a 640 pixels wide 'port' means that the rest is overscanning per definition. So this setting overscans a bit more than it was meant to be...
Rest assured though that these settings on the Chrontel chips deliver the most impressive DVD output on TV possible using these chips on RIVA cards anyway.
Oct 13, 2001: The Brooktree chip may be harder to setup than the Chrontel chip, but the Brooktree chip is more flexible in possible TV modes. With Chrontel, you can only use the built-in 'autosetup' modes while the Brooktree is 'freely' programmable. Unfortunately, the Chrontel does not have 'non-interlaced to interlaced' PAL 720x576 (DVD region 2) or NTSC 720x480 (DVD region 1) modes. While a PAL mode exists that is useable (more or less), such a NTSC mode is not there I'm afraid. I'll try to set it up anyway. If it turns out it's not possible, I'll try to get the 'interlaced to interlaced' modes to work. These are the official DVD modes for the Chrontel chip, but dualhead mode will probably not work with it, because the RIVA has to be set to the very-slow (pixelclock wise) interlaced mode then.
Oct 10, 2001: On TNT2-M64 chips the line-character (horizontal display) counter works a little different than on the other RIVA's: You have to end the blanking and sync-pulse one character sooner than on the other chips, otherwise the first 8 pixels (one character) will be blanked out on the next line. Because this cannot be done (without further modifications anyway) on TNT1 chips (You'll create a eight pixel horizontal offset in the mousepointer there!) an extra timing option was included in the app.
Today also the 'cursor trash' issue on TNT1 has been solved. You may vary the vertical blank and sync-pulse 'falling edge' without movement or other changes in the display on TV output. On TNT2 and above the RIVA chip filters the VGA output (at least for cursor trash) so you can freely change this timing. On TNT1 however this filter does not exist, so you have to 'filter' manually using the vertikal blanking period.
Oct 6, 2001: The app has been restructured again. It autodetects if VESA mode is active now and then displays the corresponding menu. VESA mode will not offer the special DVD modes because in order for this to function correctly the VGA screen has to be tuned in resolution. This is done using the videodriver so there has to be one to be able to do it.
For the next version hopefully the Chrontel chips will be programmed for PAL DVD mode also, as should be the NTSC DVD mode for both Brooktree and Chrontel chips.
Sep 22, 2001: The VGA switch did not include the pixelclock register yet. This register is programmed now, so it's fully OK. It's time to look at disabling overscan compensation for the next version. Michael will be working on implementing the GDW soon if all goes well...
Sep 14, 2001: The VGA switch works now. Still it seems that I missed a RIVA register somewhere as the refresh rate is not always predictable yet... It should always be 60Hz as I (try to) set the RIVA to VESA mode. Anyway: rebooting after TVout use is no longer neccessary :-)
Sep 6, 2001: Well, disabling overscan compensation will have to get done now as is the VGA-switch... Thanks to Michael Pfeiffer Chrontel support now is a fact! It's tested on the GeForce2 MX200 mentioned before, which is a ASUS V7100 AGP 32Mb card, which works beautifully now ;-). I also got a report from someone using a GeForce2 with BT868(!) chip, which also works OK...
Aug 19, 2001: Currently on top of my wishlist are disabling overscan compensation and the switchback funtion to VGA-only. Also I am testing a bit with a GeForce2 MX200 card, unfortunately it contains a Chrontel chip. This means I have two unknown 'variables' at the same time to overcome, unless I am lucky and a GeForce with BT chip does work already with my app/driver. (Does someone know this???)
Aug 8, 2001: The next thing I'm going to try is to get the NTSC 640x480 mode working on TNT1 and TNT2... Also disabling 'overscan compensation' has got my attention.. (I would like to optimize for DVD playback if possible ;-)
Aug 5, 2001: Yes! We have a liftoff... With a lot of trying and searching and a bit of luck finally there is a picture on TV!
('Dualhead clone' mode: one Desktop on two displays...)
To be able to safely enable TVout for sure you first have to slow down the RIVA pixelclock and then program the TVout chip to use this clock as an input. Shutting down TVoutput has to be done in the opposite way: first disable the use of the RIVA pixelclock in the TVout chip and then increase the pixelclock in the RIVA. For the Chrontel chips this is a bit tricky: You first have to disable the use of the RIVA pixelclock, then you reprogram the RIVA to use it's internal timing and modify that. Only after this you may shutdown the Chrontel TVout chip so it's TVoutput is blacked out. If you don't use this order of things you will 'crash' the RIVA (it's 'via' pixelclock is stopped and cannot be restarted internally) and loose picture entirely until you reset the PC! This does not apply for use with the BT chips because they stay operational: you just disable it's TV-outputs.
The Chrontel chips are more capable than the Brooktree chips it seems. Thanks to the higher allowable pixelclock in the Chrontel for instance there are no artifacts on VGA during dualhead NTSC 800x600 mode, which uses the highest pixelclock of all modes... 'Downside': The chrontel does not seem to have a testimage built in.
It looks like the RIVA timing can be set for each mode in a more or less universal way. The BT setup however has to be done seperately for each mode and for each RIVA chiptype; at least for the HsynOffset value. Strange thing is that if this value is negative (shifts picture on TV to the left) The image starts to 'jump' vertically. Luckily this can be fixed by shifting the picture down a bit (using VsynOffset).
The RIVA chip always seems to send pixeldata to both the VGA DAC and the TVout chip. The TVout chip normally is always in 24bit (mpx'd) RGB input mode. The RIVA makes sure that the pixeldata is always on the most significant side of the (2x12 bit multiplexed) bus. Furthermore it would not surprise me if it is possible to run the TVout chip in both slave and master mode...
As it turns out the autosetup feature in the BT does not function the way I thought. On the circuit board of every videocard with BT chip there is a NTSC/PAL select jumper. This jumper (which is hardwired on most boards) preselects NTSC (0) or PAL (1) mode. Of course it's hardwired to NTSC. Only the autosetup modes corresponding to the jumper setup function as they should. I used the autosetup feature using SRESET. Apparantly you can also do this using the TIMING_RESET command. In this case if you first set or clear the PAL_MD bit (which overrules the PAL input) the autosetup does function correctly.
Nice. If you set EN_XCLK (you have to because the RIVA has to supply the pixelclock for the BT...) you might experience IIC SDA lockups due to a 'hanging' BT (it does not generate any TV picture anymore then also...). At this point the whole IIC bus is locked so you will have to reset the PC itself to get to anything on that bus!
Printed circuit board info:
You have to be careful not to generate this situation of course... I am only able to succeed with the setup if I don't use the BT autosetup feature. So setting a videostandard can succeed using autosetup, but after that the BT crashes on me if I try to set it to interface with the RIVA chip!
After looking at my ELSA Erasor III ViVo board I noted the following findings:
- Only the lower 12 pixeldata input bits are hardwired to the BT chip, all others are grounded. This means that only the multiplexed input modes are available.
Technical documents used:
- The pixeldata lines are connected to the RIVA chip, so the RIVA has to be instructed to give the BT access to it's framebuffer.
- The BT has a 13.5Mhz crystal just as is recommended in the BT datasheet.
- The video-in chip and the video-out (BT) chip are connected to IIC bus 1, while the VGA connector (VESA DDC2B channel: used for identifying your monitor...) is connected to IIC bus 0.
- The BT is preset (hardwired) for NTSC in MASTER(!) timing mode.
- Chrontel CH700X datasheet;
Measuring equipment used:
- Brooktree advance information BT869 datasheet;
- Rockwell Bt868/Bt869 datasheet;
- Book: Programmer's Guide to the EGA and VGA Cards by Richard F. Ferraro (maybe younger books exist!);
- various Philips techdocs about the IIC bus protocol;
- NVIDIA headerfiles used in the Linux Kernel;
- Different Linux sourcefiles for clarifying the NVIDIA files (so not for coding itself...);
- Different BeOS sourcecode examples to find out how to get an app and a driver to interact.
- A universal meter;
- A digital Oscilloscope.
- Back to BeTVOut main page.
(Page last updated on April 27, 2002)