J. Maynard Gelinas wrote:
> OK, This is mildly on topic. My monitor is an HP 1097C, making
> it at least 10 years old. However, I am using it with a modern PC, so
> that's where the 'on topic' issue gets a little iffy. I'm sure there
> are plenty of people here who can answer this question. A pointer to
> a FAQ would be most welcome.
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. :-)
> These old monitors are Fixed frequency, unlike our modern
> monitors which multisync. The 1097C supports only a 78.125 khz
> Horizontal Scan Rate and a 72hz Vertical Refresh Rate. Now a couple
> of years ago I foolishly bought one of those cards by Mirage
> (www.mirage-mmc.com) which is supposed to be a 'fixed freq video
> card'. Actually, it's an OEM Diamond card, basically an S3/968 video
> processor with an IBM 52x RAMDAC - ala Diamond Stealth VRAM. The
> fixed Freq hacks are basically a resistor (and a jumper selection) to
> drive sync over green, and a homebrew PROM to skew the VESA
> frequencies for several video and text modes.
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.
> It works, but Mirage hasn't been too helpful with getting a
> variety of XFree86 modelines, even though they claim to support Linux
Darn, shame on them.
> and XFree86. They give out _one_ modeline for 1280 x 1024, which they
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?
> swiped from the XFree86 distribution in 'Monitors.txt'. For Windows
> and Dos, they give out a video driver which seems to work just fine.
> It will even display 320x200 full screen (Quake works great in DOS!),
> and boots to a functional 80x24 col text mode. How the hell do they
> do this?
>
> Here is how I'm calculating my video modes based in the
> XFree86VideoModes HOWTO (found in every Redhat 5 distribution):
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
>
> Dot Clock Per Second
> Total Horizontal Pixels Per Line = --------------------------
> Horizontal Scanning Rate
This is right, dots / line * line / sec = dots/sec
>
> Since my refresh rate must be at 72hz to sync with the HP1097C:
>
> Dot Clock
> Refresh Rate = -------------------------------------------------
> Horizontal Frame Length * Vertical Frame Length
frames / sec = (dots / sec) / (dots / line * lines / frame)
= (dots / sec) / (dots / frame)
= frames / sec
yep
>
> So, it's really more constructive to think of this as how many
> pixels _total_ do I need to display in order to get a 72 hz vertical
> scan rate with any arbitrary dot clock? In this case I need
>
> Dot Clock
> Total Pixels Per Frame (HFLxVFL) = -------------
> Refresh Rate
You did algebra on above, correct
>
> Since I know my Horizontal Pixels Per Line, I can use this to
> determine the number of vertical lines which will support a 72 hz
> refresh rate.... hmmm, this is where things get sticky. We'll start
> with a DCL of 10Mhz...
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>
> BTW: no one responded to this message, so I guess no one
I'm sorry, I must have missed it. Normally that subject would catch my eye.
:-)
> knew the answer. I received a responce to a USENET post about
> this and thought there might be some interest in the group.
> The VGA spec supports 'doublescan' mode for low resolution
> compatability with CGA apps. This essentially forces the card
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.
> to draw each horizontal line twice, thus doubling the refresh
> rate (or your vertical resolution in half at the same refresh
> rate) at any arbitrary horizontal scan rate. Well, some
> chipsets (like the 968, Matrox Millenium, and most ATI
> chipsets), allow for tripplescanning which does exactly what
> one would expect... it scans each horizontal line three times
> before skipping down to the next line, thus allowing one to
> drop down to a third of the vertical resolution at the same
> refresh rate (same horizontal rate always, of course).
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. :-)
>
> OK. XFree86 and SVGAlib don't support tripplescan mode, but
> they do support doublescan mode because it's part of the VGA
> spec. Tripplescan is vendor specific, and so thus is enabled
> in different ways for each chipset. I'm attempting to hack
> svgalib to support tripplescan for the S3/968... waiting for
XFree you mean, or svgalib?
> the 968 docs to arrive so I can find the register and register
> values to set for my adapter. The rest seems fairly easy, just
> hack in parsing for 'tripplescan' on the modeline and such.
>
> Why does this matter to you? Well, if you have an Hitachi
> HM-4119, HP1097C, or somesuch fixed freq monitor, getting it to
> work under Linux is pretty easy once you know the trick. Why
> buy a $1500 monitor when you've got a perfectly fine one
> sitting on your VaxStation 3100? Well, for the purposes of
> this list, why not just use the 3100 as the xterm... but that
> defeats the purpose of this message. ;-)
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 _at_ KC7Y.AZ.US.NOAM ecloud_at_bigfoot.com
(_ | |_) Shawn T. Rutledge http://www.goodnet.com/~ecloud
__) | | \_____________________________________________________________
Received on Mon Apr 13 1998 - 23:30:55 BST