[OFF TOPIC?] Fixed Freq Monitor Questions

J. Maynard Gelinas wrote: Here's one interesting URL: http://rugmd0.chem.rug.nl/~everdij/hitachi.html I've seen others as well but that was the one I made a bookmark to. :-) Hmmm, interesting. Photon also makes fixed-freq. boards, and I was tempted to get one for an old SuperMac monitor I have. I also once attempted to fix a batch of Moniterm monitors that had various problems, and the one board I found to use with them in Windows was a Vermont Microsystems model that cost way too much to begin with, and is now no longer made. There was also no driver later than Windows 3.1, so my dad has it now since he still has a slow 486. Anyhow, I thought Photon's boards were probably better than Mirage's, I forget why. They are at www.photonweb.com I think, but I can't seem to get there at the moment. Darn, shame on them. Well at least it works eh? Can you at least upgrade the VRAM to get more colors, or did you want low-res for some other reason? You understood what they said, that your horizontal line includes enough "dots" to allow time for the gun to sweep back to the beginning of the next line? So to get 1280 dots across, you might need to allow 1350-1400ish dot-clock-periods per line (or maybe even more). (dots/sec) / (dots/line) = lines/sec = lines/frame * frames/sec For example: if you want 1024 lines, allow around 1150 total lines (to allow time to sweep back to top-left between frames); so 1150 lines/frame * 72 frames/sec = (x dots/sec) / (1350 dots/line) now solve for x to get the dot clock, and to double check the formula, make sure that all the units cancel out. x dots/sec = 1150 lines/frame * 72 frames/sec * 1350 dots/line yep, line / line * frame / frame * dots / sec = dots / sec and you need a dot clock of 111,780,000 dots/sec This is right, dots / line * line / sec = dots/sec frames / sec = (dots / sec) / (dots / line * lines / frame) = (dots / sec) / (dots / frame) = frames / sec yep You did algebra on above, correct Why? That is too slow a dot clock to be useful. You should work backwards - figure out what resolution you want, find the corresponding dot clock, pick the closest supported dot clock to the one you calculated, and then calculate forward again to figure out what resolution you can actually get. You can also play with the blanking intervals, because the monitor has a minimum time that it takes for the gun to scan back to the beginning of the next line (or next frame), but no maximum time. If your supported dot clock is a little too slow, you can waste the time in the blanking interval to keep a standard resolution, or else optimize the resolution to use up all the available time/line. But with a fixed frequency monitor, you must also keep the horizontal and vertical scan rates in "range" - however wide that happens to be. So really, with those two constraints plus your quantized available dot clocks, that's why "fixed frequency" also means "fixed resolution". If the monitor was designed for 1280 x 1024, the card must output about that many dots in each frame and at the correct frame rate. You could output half the dots per line, and also halve the dot clock, and halve all the other values (front porch, back porch, vertical blanking interval, etc.) but if you tried to also cut the vertical resolution in half, you'd violate the line rate constraint. So as you say below, line doubling makes a lot of sense; you could simulate 640 x 480 on a 1280 x 960 screen by halving the dot clock and line-doubling each line. Text mode can be simulated by custom programming on the graphics chip, so that it actually produces dot data at 640 x 480. Keep in mind the monitor will have "total bandwidth" limitations too - it might not be able to accept too fast a dot clock even if you don't exceed the horizontal scan rate or frame rate. <second message> I'm sorry, I must have missed it. Normally that subject would catch my eye. :-) Cool, makes sense, I didn't know that was a standard. I used to have a DOS CGA simulator for the Hercules card, several years ago, that must have worked this way also; simulating 640 x 200 on a 720 x 400-something display. The displayable area was smaller too, so evidently they only used 640 of the available 720 dots across. It was very useful for playing old CGA games on my mono card anyhow. Hmmm, so 1024 / 3 = 341, 960 / 3 = 320, I don't see how that would be very useful since there aren't many (any?) modes that have vertical res. in the 320-340ish range. Maybe it could be stretched a little to get 640 x 400. Quad-scan would be useful for doing 320 x 200, or they could just be wasteful with memory and do 4 pixels in VRAM for every pixel and get 640 x 400 out of it. 800 x 600 would just be plain nasty. :-) XFree you mean, or svgalib? Yep, I've been wanting to do this for years. I did it briefly with that Vermont card (and kept the hercules card also, for text mode, because the Vermont card made no attempt to support any standard modes at all; it was really intended to be a secondary display for CAD) but couldn't do any newer Windows or X with it. It also had an interesting high-level proprietary command language for drawing the primitives; I got the impression from its sketchy docs that you could actually send textual commands to its I/O port and it would interpret them in real-time. That and being an ISA card made it kindof slow. And it only had enough VRAM to do 16 colors, and Vermont wanted an arm and a leg to upgrade to 256 colors. My SuperMac monitor worked fine with my ATI All-in-Wonder, but only in Windows 95, for which there is a nice driver that lets you tweak every parameter. Tweaking similarly might be possible, if harder, in X, but I haven't tried it yet. Unfortunately the Win95 ATI driver won't tell me the numbers to plug into X modelines; I wish it would, but there are just these arrow buttons on the screen to adjust position, size, etc. My experience has been, if you are in the ballpark and the monitor is behaving itself, you can tweak it a little bit to adjust size and position; but then all of a sudden it will just go bonkers, and to get back to where you were right before that, you have to overshoot and then edge your way back (not moving the mouse, because you can't see the on-screen button anymore!) So reproducing the same results with xvidtune's tricky interface would be difficult. Someday, maybe somebody will produce a video card with a video-scaling chip built-in, so that you can multiply dots by something other than a whole number. This is the sort of thing that's already being done for LCD video projectors, video digitizers that can put the image into an arbitrarily-sized window (like my All-in-Wonder), the digital HDTVs now being designed, and maybe even some of the better laptop displays. I don't see why if they can do it for TV input they can't do it on the output signal as well. As the dot clock asks for each output dot, the chip would just have to take into account the colors of the adjacent dots, and blend smoothly; so to avoid having to read VRAM at, say, 9x dot clock, it would have to have some fast registers to store the values of the adjacent dots temporarily, and it could then read VRAM at a mere 3x dot clock. Or, it could store 3 lines in its fast memory and read the line past the next one during each horizontal blanking interval. Maybe the need for fast VRAM is the limiting factor; no, because actually scanning at 1280 x 960 requires 4x the speed of scanning at 640 x 480, whereas simulating 640 x 480 at a dot clock to achieve 1280 x 960 only requires reading VRAM at 3x the rate. So I don't know why this hasn't been done. Maybe Photon does this, I'm not sure. I think I'm going to post this on a newsgroup or two and see if we get any better answers. -- _______ KB7PWD @ KC7Y.AZ.US.NOAM ecloud(a)bigfoot.com (_ | |_) Shawn T. Rutledge http://www.goodnet.com/~ecloud __) | | \_____________________________________________________________