Well, if you have chipset programming info, databooks, datasheets, "normal" programming books, you can mail them to me, should I need them (so ask first) and if they're files. If you have printed stuff, just tell me what you have, and you can tell me what I need when I ask for it. Don't worry, normally it's just a couple of register descriptions, bit meanings, etc.
  If you feel you must send me anything else, you can mail me using my home mail address, which is on VGATV.DOC.

  Sure, I'm glad I can help you in whatever way you need. Just don't forget to give credit where due...:-)

 When I have the time to get it done. A working man has no time for this stuff! Still, lets see if I can keep up now. Things haven't really improved on the video card marktet since when I first did this. Sure, more and more cards have TV out, but if we can't use them as we want, what's the point?

  I have an Asus TNT2Pro Deluxe with Video In/Out. When, one day, I tried to use the Video out to record on video an image I made, things started to crumble down. Of the 2 programs that promised full screen (overscan) video, none worked satisfactorily.

 Ok, first read the answer to question #7. Have you understood it? No doubts? Good. 'Coz now I'm going down and dirty, to the real stuff 8-P

  I hope to have some pictures here to illustrate things a little better.

  Both the TV and a VGA monitor work in a similar manner, despite scan rate differences and the fact that TV is interlaced and VGA isn't (usually). So, making a VGA mode compatible with TV is as easy as reprogramming the VGA registers so that the VGA chipset outputs an half-image every 1/50 or 1/60 sec., depending on the video system being used.
  In NTSC we have 30 complete images per second, with 60 half-images (due to interlacing), resulting in line rate of 15750Hz (15750 horizontal lines per second). PAL has 25 images per second, thus 50 frames per second, with therefore 15625 lines per second. Why 15750 and 15625? We just multiply the total number of lines times the number of images per second (60x525 lines and 50x625 lines, respectively).

  How does this compare with VGA? Well, it's the same thing really. Using mode 12h (640x480 at 16 colors) as an example, we have a total of 525 lines (just like NTSC!) and exactly 59.94047619...Hz, giving a grand total of 31468.75Hz as line frequency.

  First of all you must understand that the total number of lines is not the same as total visible lines. This is because a certain amount of lines are reserved for things such as blanking, inside of which occurs the retrace, a time where the electron beam returns to the top of the image. This happens just like TV, except timings and number of lines used vary, of course. This also happens regardless of video mode, video board and video chipset.

  And do I got that 59.94Hz magic number? Read on, this gets interesting!

  Remember all those video board adverts telling you of a RAMDAC of 220, 250, 300 or 330Mhz? Well, standard VGA has a RAMDAC of 28.322Mhz. The so-called RAMDAC is none all than the video Master Clock, and value advertised is the maximum value it can be driven. Like VGA, this means a whole plethora of slower clocks are attainable. For example, VGA has 2 video clocks available, 25.175Mhz and 28.322Mhz. Each can be further divided by 2, if desired, resulting in rates of 12.5875Mhz and 14.161Mhz respectively. Lets call the Master Clock now VCLK (Video Clock). MCLK is Memory Clock, not used here.

  Mode 12h uses a VCLK of 25.175Mhz. Remember it is set up with 525 vertical lines. This value is called Vertical Total (VT). The 480 lines reside in a value called Vertical Display End (VDE). It happens that the horizontal part of the screen also has the same registers, a Horizontal Total, a Horizontal Display End, among others. The HT is set as 800 pixels. So now you have a logical screen composed of 800x525=420000 pixels. Big deal, so what?

  Okay, so now the DAC (RAMDAC) reads your memory, taking in account the display timings you just set up: you have 525 lines of image, and each line is 800 pixels long, even if only part of this will be displayed. So, if you divide those 25175000Hz by 420000, you get that funny 59.94Hz number. That's the maximum number of images you can build per second using that clock. Besides that, each line takes 31.8ns to draw by the electron beam. Fast huh? And it takes 16.6ms to draw a complete image on screen.

  Back to TV, we don't have a dot clock. Using NTSC as an example, since mode 12h is just uninterlaced NTSC, we do have 525 lines and a line takes 63.5ns to draw. Just about double time that of VGA, because the TV is slower too. PAL has 64ns long lines, BTW.

  So, how do we make VGA, TV compatible? Well, first thing is to turn interlace on. However, standard VGA doesn't support interlace. In that case we use a register in the CRT Controller registerset, in which is recorded the number of memory bytes that exist between 2 adjacent lines. This is register 13h, the Offset register. Because we're in a 16-color mode, using bit-planes, only 4 bits are necessary, thus, 40 bytes seperate 2 adjacent lines in memory. So...we double it!! Now, after each scanline, the DAC will read memory 2 lines ahead, effectively skipping every other line, and cramming 480 lines into 240 (of course, you loose half resolution...). Other than this, if you can set interlace, the rest is just the same.

  Now, with interlace on, we must halve all vertical definition values, so we define the VT (Vertical Total) with 262 lines (can't write 262.5, so it's either 262 or 263) and the VDE with 240 lines. The video chipset will take care of the rest in this respect.

  Now, getting back to the horizontal portion of the setup, we must find a Horizontal Total value, such as when multiplied by the total number of lines, and used as the divisor by VCLK, attains frequencies close or equal to TV.

  NOTE: It's actually impossible to have the same frequencies because the horizontal setup values are set as character clocks. A character can either be 8 or 9 pixels wide, so the HT of 800 pixels is actually stored as the value 100 (really 95, but that's not for now) with 8 pixels per clock. This limits resolution to 8 pixel boundaries, effectively limiting the accuracy by which we output a TV compatible picture.

  Using this formula:

    VLCK
————— = FPS
  HT x VT

we can readily replace FPS by 60 and VT by 262, so we get:

    VCLK
————— = 60
  HT x 262

  So, all we must do now is find a VCLK and HT value, so that the line duration is close to 63.5µs. This is made easier by the limited number of dot clocks available. As I said above, we only have 28, 25, 14 and 12.5Mhz clocks, so all we must do is find the best close one and hope that it looks ok. Let's do some calculations:

  VCLK=28322Hz => HT=1801.65/1808, 63.8ns
  VCLK=25175Hz => HT=1601.46/1608, 63.8ns
  VCLK=14161Hz => HT=900.82/904, 63.8ns
  VCLK=125875Hz => HT=800.73/100, 63.5ns

  As you can see, all setups are valid. But, to display only 640 pixels? Well, in that case, only the 3rd case is really suitable. The top setups display so many pixels in the line, that a mode 640 pixels wide appears crammed and skinny. Great for SVGA modes, but not low-res modes. The 4th mode is too short, since we need space for blanking and retrace, and the image is too wide and appears stretched with wrong aspect ratio. Therefore the 3rd is the winner.

  I tend to round up numbers to the next byte boundary so that I can have that little bit more of space. On some modes, such as 800x600 and 1600x1200, there is no space for blanking and retrace, so some display is blanked to make room, but since at this point there's already some overscanning (picture hidden around the edges of the CRT tube) no one can notice this.

  Now, for some words about blanking and retrace. As said before, retrace occurs when the electron beam returns to the top of the image. The retrace signals are the ones that actually trigger this behaviour. Blanking is when the image is blanked (blackened) so that there is no image information being displayed that may confuse the retrace electronics, thus screwing up the whole image. Worse, if you program the retrace to occur after HT or VT (depending on the type of retrace, horizontal or vertical), retrace *never* happens, thus sending the electron beam into Neverland...

  Blanking may be as wide as possible, and as short as possible. It all depends on the retrace signal. Some modes are more picky than others. If you're not tight in timings, you better stick with the standard timings. These appear on the table below:

 

	Line length	Blank size	Back porch	Retrace size	Front Porch
NTSC	63.5µs	-	-	-	4.6µs
PAL	64.0µs	12.05µs±0.15µs	1.5µs	4.7µs	5.85µs±0.15µs

  The start of the retrace is flexible. Moving it (and the blank surrounding it) will also move the image (horizontally and/or vertically depending on which you move), thus allowing an image to be centered on screen.

VGATV does all of this automagically. Using a table describing each of the supported screen widths, and a table describing when vertical retrace starts and ends (because the vertical setup is more or less fixed, we only have to tune the screen to center the image, changing where retrace starts), the program goes on doing all this things, but on a different order.

  First, it unprotects the extended register sets (often protected against writes), then proceeding to set the horizontal portion of the screen, where also the dot clock is set. After that, it goes on to the vertical setup, turning on interlace when possible and if needed. After everything, there is a special setup part that occurs should we be setting up a text mode.

  There are a couple of things that are "different" than your normal setups.

  First, mode 0Dh (320x200x16 colors) is setup in such a way, that to properly set it up on screen, we need to set a dot clock of 7Mhz, and this isn't standard. Therefore, when we don't know how to set it, or it can't be set (Oak087 shows 2 screens side by side when at 7Mhz!), I set the board for 12.5875Mhz, the lowest standard VCLK possible. But if we can, we set the clock to 14.161Mhz and divide the thing by 2, using some special bit(s) on the chipset's extended registerset, thus giving us 7.0805Mhz to play width, allowing a full-screen 320x200x16 color mode.

  Second, the text modes with 132 columns are setup with 9-bit characters. All other modes are set up with 8-bit character times. This allows me to maximize the screen space used.

  Hope I made myself clear on this subject of mode creation. If you want to produce a driver or something compatible with any other output device, such as a fixed frequency monitor (a TV is such a beast, BTW), all you need to do is change the target frequencies.

  After you read and understand reply #11, we can start to get into this.

  Having 640x400x256 colors in standard VGA seemed logically possible since the memory is there. All 256000 bytes of it. The problem is accessing it. Native VGA is planar based. This means that memory is logically accessed as if it existed in 4 bit planes, vertically overimposed. A pixel in 16 color modes takes it's value from the 4 bits from the same position, but on each of the different planes.
  The 256 color mode uses a trick to make memory access faster to the user, though slower to the VGA, which must convert the way the memory access is setup right now, to it's native planar way. It's easier for the user to access the memory (sequencially) making programming easier, but performance is hit. Worse, memory gets limited to 64Kb, thus *wasting* the remaining 192Kb of RAM!!!

  The famous ModeX works by turning this off, allowing the app to use memory as it is set up natively. In an awkward way, but faster way, and above all, without wasting any memory.

  So, the first obstacle is overcome. Now, anyone could do this, right? It's just a bit in the Sequencer registers, nothing weird. Ahh, but the real problem is screen timing. See, the 320x200x256 mode is special because it's really set up as 640 pixels wide. Therefore, the timing is the same as mode 12h. However, to get 640 pixels in that line we must therefore set the line for 1280 pixels! Eeek! With the needed extra room for blanking/retrace, the line would have around 1400 pixels. With 525 lines, this gives about 38fps or just about 20Khz. Way below standard VGA, even using the highest dot clock, 28.322Mhz. But check it out, 20Khz. For TV we only need 15Khz! So, it's perfectly possible to use this mode on a standard VGA, even if older than your granny, yet still useable.

  Same goes to the other weird modes, such as 16:9 768x432x16 color modes. You just set mode 12h and readjust it. Just remember to set the offset to 48 and you're set.

  Since these modes aren't standard, the only way a VGA board can take advantage of such a feature would be a VESA extension built on VGATV, so that it told the application about these modes making them available to any VESA-aware application.

  No, I don't do hardware. It takes too much time from me, and it's not trivial if you want to do things right. Try to get someone else to do it for you. Sorry...

As explained by a user who had this problem, Nik Cain:

  I was having trouble with a toshiba 2140CDS laptop and vgatv, but now it works. The problem was something to do with running the lcd screen simultaneously with the monitor. If I set my laptop to run *only* on the monitor, everything was fine - this was a bit of a juggle, since switching the laptop from lcd to just monitor would stop the vgatv driver (since it changes to its own driver). You have to have the display settings (in the advance box) open as well as the winvgatv program open so that after pressing apply on the display settings, and then blindly you can do something like alt-tab followed by down arrow (which switches to the vgatv control panel, and then moves down from vga to pal). Then you're on the tv and everything's hunky dory.

Video output settings for S3