Re: Double hires mode color artifacts

["Michael J. Mahon" <mjmahon@aol.com>]

Jerry wrote:
> Michael J. Mahon wrote:
>
> [...]
>
> > > > Although it *would* be nice to have the contrast, brightness, hue, and
> > > > saturation controls.  ;-)  (Adjusting them would perform a transform on
> > > > a standard table to produce the actual table to be used.)
> > >
> > >
> > > Yes, I plan to put those in, and was thinking that I could just update
> > > the lookup table and the video emulation would simply repaint with the
> > > alterations.
> >
> > It would be necessary to keep a master copy of the "standard" table,
> > otherwise, bits would be lost if you turned a control up and then
> > down again.
>
>
> Mmmm... I think it will be necessary only to have
> a "reset-to-default-settings" of the input controls.  The algorithm is
> going to generate the bit-pattern/phase to RGB values.  One thing I've been
> toying with is allowing for a tweaking of the filters.  Let's say you want
> to have the luminance filter 4.5 MHz instead of 3.58, or crank it down to
> 3.0 MHz.  Ditto for playing with the chroma filters.  But I am getting
> ahead of myself.

I see.  I was thinking in terms of precomputing the reference table with
another program.  And I was thinking in terms of sliders or knobs to
adjust the parameters back and forth.  Many adjustments, like contrast,
brightness, hue, and saturation, could be done as on-the-fly transforms
of the RGB vector fetched from the standard table without much
computation.  Other parameters, like sharpness, would require
adjustments to blending over the whole table, and are therefore
harder to do.

It's interesting to think in terms of storing not the RGB vector at
each table entry, but the YUV vector, so that post filtering of the
NTSC components could be done on-the-fly as well...then even sharpness
could be varied somewhat without changing the table.

One factor in chroma processing that has changed over the years that
might make a difference is the bandwidth of the chroma signals.  The
original NTSC specification allowed for 1.3MHz bandwidth (from
2.3-4.2MHz, assymetrical about 3.58MHz), but practice moved toward
0.6MHz (from 3-4.2MHz, symmetrical about 3.58MHz).  To faithfully
simulate "blending" in that low bandwidth case would require a window
on the order of 14.3/0.6 bits, or 24 bits!  That's clearly too big a
table for several years to come.  ;-)

Given the clocking of the Apple II, you'll have to keep the chroma
demodulation at exactly 3.5879545MHz or solid colors will become
rainbows.  ;-)  Moving the filters will alter the frequency response
curve of the chroma channels, with occasionally interesting effects
on edges.

> I do think for simplicity's sake in an emulator, it would be nice to be able
> to choose NTSC color, IIgs RGB, AppleColor, etc emulation.  I only have at
> my disposal a couple CRT TVs (one with component video in), a Commodore
> 1541 monitor, and a IIgs RGB monitor.  Oh, and some green-screens.

I agree--this would be a nice suite of emulated displays.

> And of course, I don't spend too much time on this (well, I think it's not
> too much time :) ).

As long as you're having fun and nothing else suffers, it's not
too much.  ;-)

-michael

NadaPong: Network game demo for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."