Subject: Re: SHARK TV-Out Update
To: Erik E. Fair <fair@clock.org>
From: Mark J. Foster <mfoster@mail.com>
List: port-arm32
Date: 01/15/1999 08:21:12
"Erik E. Fair" wrote:

> OK, pccons (pcvt, whatever) is too inflexible to do the right thing, and
> it's being replaced anyway.
>
> Can wscons be modified/configured to "do the apparently right thing"?

Since I'll be working on these patches within a couple of weeks, if anyone is
turning developing wscons, I'd love to know about it.  That way, I can skip
having to modify pccons, and we'll just let wscons inherit the OFW-supplied
video
parameters.

>
> And if what the OF does to generate video is the wrong thing, can someone
> explain why that is, using small words?
>

OFW is actually doing fine, but it's TV sets that do wrong.  Due to the
limitations of slow electronics back when NTSC was created, it took a long
time for the CRT tube to "wrap-around" the electron beam from right to left,
or from top to bottom of the screen (at the end of a line/frame,
respectively).  Thus, TVs need a lot more "blank space" at the end of each
line or screen.  Without this, the TV tries to display information when it
wants to be "wrapping around", so it cuts off some of the stuff you want to
see.  By changing the timings of the video out chip, we can fix the
horizontal overscanning (chars cut off on left or right), by running the
video output faster, and then giving more blank space at the start and end of
each line.

To fix the vertical overscanning, there are two approaches.  The first is to
use the IGS chip's interpolation mode, which basically just throws away every
'n' lines of the screen.  While this lets the screen still seem to be 480
lines tall to software, it degrades the image (characters tend to look
funny).  The other way, which gives the best appearance, is to simply set up
the display to have fewer lines, and to add blank space around the lines
which are left.  While this does mean that the display will be something like
640x450, it looks much better.  This is the direction I plan to take...

To fix color, the IGS chip has what I consider to be an architectural mistake
that leaves it <extremely> picky about the way the color oscillator is set
up.  To fix this, we'll have OFW start with better defaults, and then
probably find a way to allow you to patch the color frequency for your
specific system, via a non-volatile patch to the OFW setup...  That way, each
individual system can be "tuned" for the best output color.

Make sense?

Cheers!
MarkF