[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NTSC Emulation

Sheldon Simms wrote:

On 2011-01-23 03:23:53 -0500, Michael J. Mahon said:


Sheldon Simms wrote:


MDJ mentioned NTSC video emulation yesterday and that piqued my
interest because I have been working on Apple II video emulation by
NTSC decoding/demodulation in software.



Very nice--it was just such an emulation that I envisioned being
the method of populating a table of 4096 32-bit color entries,
each corresponding to the NTSC response to the previous 12 bits
of (14MHz) Apple video signal.



In order to then use a table lookup to emulate the Apple II screen?

My intention has been to use the NTSC emulation directly in an Apple II
emulator. The CPU load is acceptably low on any relatively recent
computer: about 50% of one core on my 2.0 Ghz Core 2 Macbook.
By being careful about only calculating new output when it is needed,
the load drops to near zero for mostly static screens.


That's great if it is a tolerable computational load.

I was hoping that by making it table-driven, it would become trivial
to add faithful NTSC monitor emulation to almost any emulator--as long
as it processes all video with a simulated 14.3MHz dot clock (560x192).


Something looks a little off in your colors, however.  What filter
bandwidths are you using for Y, U, and V signals?  Then there's
the delay in the Y signal to compensate for the U and V filters...
Gamma may also be an issue...



Gamma may be an issue and I don't know about you, but I have
a dim LCD screen on my computer and it doesn't saturate like an
old CRT.

Here's a comparison of a screen capture with a photo I just took
of my real Apple IIe with AppleColor Composite Monitor IIe.

http://wsxyz.net/compare.html


The saturation is too low on the real //e monitor.

The hues are a little off on the emulation.


I'm doing YIQ decoding. I am not a DSP expert and I picked up
what seemed to work after a little bit of introductory reading, so
the filtering is very simple - I pretend I'm sampling the Apple II
picture signal at 14 Mhz and run that through a very simple ~3.58
Mhz low pass filter to extract Y. Then I subtract that out from the
input signal to get chroma, which I then demodulate and filter
each component with the same filter adjusted to half the
bandwith (i.e. ~1.79 Mhz)


Actual analog NTSC processing separates chroma with a broadly
tuned 3.58MHz filter.  The retained bandwidth is only about 1MHz
for the I and Q signals.  (To compensate for the group delay of
the filter, the Y signal was delayed about a microsecond.)

The Y signal is just lowpassed to about 3+MHz to remove most
of the chroma signal (though some remains present).  This creates
the blurring characteristic of analog NTSC.


The real code is kind of hard to follow because I use fixed point
math and combine and simplify expressions for performance
reasons, but it generally goes like this:

Y = Y + (signal - Y) / 4;
IQ = signal - Y;
isignal = IQ * cos(phase);
qsignal = IQ * sin(phase);
I = I + (isignal - I) / 8;
Q = Q + (qsignal - Q) / 8;
RGB = /* calculate from YIQ */
phase = next(phase);


This low-pass filtering provides a single pole, or -6dB per
octave, while the bandpass filters used in NTSC monitors were
LC filters with, typically, two poles (-12dB/octave).

The non-ideal implementation of real NTSC monitors produced
a more varied and subtle palette exploited by graphic designers.

Because of the bandwidth limiting, several prceding pixel values
participate in determining the current pixel color/brightness.
I proposed that the current pixel concatenated with about 11 prior
raw pixel values (all binary) would be a satisfactorily long index
into a 4096-entry RGB table for the current pixel value.

This approach would allow the NTSC emulation to be done just once,
and simply looked up by emulators.  It would even be possible to
load different tables for different monitors (bandwidths, phosphors,
etc.).

(Brightness and contrast control emulation is easy table arithmetic,
but hue and saturation would likely require re-emulation to compute
new table entries.)

Of course, if the arithmetic to do the emulation is fast enough,
then tables are unnecessary (though getting the DSP into a lot
of emulators--and working properly--might be harder than just
providing a table).  ;-)

-michael

NadaNet 3.1 for Apple II parallel computing!
Home page:  http://home.comcast.net/~mjmahon/

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