Re: Double hires mode color artifacts

Dirk Thierbach wrote:
Michael J. Mahon <mjmahon@xxxxxxx> wrote:

Dirk Thierbach wrote:

Michael J. Mahon <mjmahon@xxxxxxx> wrote:


How exactly are the tables calculated? Just extract Y, U and V (or I and Q)
with a suitable filter window curve (Gaussian? Something else?)? That won't
change the "blocky" appearance much, because areas with the same pattern
will still look "solid", and only the borders will change a bit (but
not much).


I'd go with YUV, since that's more typical of the TVs of the era.


The filters should be FIR filters approximating the RLC chroma filters
of the day. For this purpose, it would be advantageous to pick an
actual monitor and simulate its filters.


So we need to know how the filters worked in an actual monitor. Any
information about that?

There are schematics available for many monitors. They would
tell the whole tale.

Care to do a simple test implementation?


My interest is more conceptual at this point. I'm not writing
an emulator and I've got my plate pretty full with other things.


A quick example to actually find out if you can or cannot get rid
of the "blocky" look by using a 14 bits window instead of 4 bits
should take 15 minutes or so (once the filter coefficients are
settled on). That's less effort than this discussion so far needed :-)

If you give me the filter coefficients, I can do that, if you want.

I don't know what they would be, but the chroma channels typically
had about 1MHz bandwidth and the luminance channel had about 3+MHz
bandwidth. There was a small delay added in the luminance channel
to compensate for the group delay of the chroma channel filter.

Most monitors used a bandpass filter on the chroma signal, most
often staggered tuned circuits in the primary and secondary of the
chroma pickoff transformer. Then the chroma signal was quadrature
demodulated along the UV axes, so both U and V typically have the
same bandwidth.

Of course, measurement of an existing monitor would also reveal the
bandwidth and phase response of the filters.

I woudln't add *any* noise. All the effects can be pre-computed and
would be completely deterministic. Any variations in luminance will
be the natural result of the dot patterns and the luminance filter,
for example.


Then my guess that you won't get rid of the "blocky" look. Nothing
gained.

No, the blocky effect is a result of sharp transitions. After the
transitions have been handled, any remaining effect is what the
designers had to work with--"improvements" like adding dither are
not original.

I think the main reason the image doesn't look "blocky" on a TV is
that there is some variation in hue and intensity, even if the input
is constant, because it's an analog process. Have you ever compared
an image with large color areas (say, the typical test image) on
a TV and on a monitor? Looks quite different, even in the interior
of a uniform area.

Of course there is always a small amount of noise in any analog
signal. Broadcast and videotape add considerable noise. The
noise present in the display of a baseband Apple II video signal
should be very small--insignificant compared to the signal itself.

The Apple II video signal is actually three-level digital (white,
black, sync), so there would be nothing but power supply noise on
the signal. Any other noise would be generated in the monitor,
which, for a baseband input, should be negligible.

No, but it alters the size of a memory area that is needed during
*each* access to graphics. And this should stay in the cache. The host
framebuffer is just written to, it's never read.


But I'd expect a memory-mapped frame buffer to show up in the
cache, if only to gain the benefit of "blocking" writes on a line...


It will show up in the cache once, when the writes are done, and then
it will be flushed out of the cache. These writes will be consecutive,
so the CPU can flush out the whole cache often enough. The host
framebuffer is never read during apple simulation.

As I would expect. Note, though, that in a write-back cache,
considerable benefit accrues from writing multiple contiguous
items to the cache prior to writeback.

Any large sequential passes through the address space will tend
to thrash the cache--associativity is a good thing. ;-)

[...] and I'm probably already getting more cache misses than I'd like. Didn't test, though, that's
just a rough estimation.


Temproal locality is a wonderful thing. Don't expect your cache
miss rates to skyrocket just because worst case estimates overflow
the cache.


Yes. So I'm hoping I'm within limits, if just so. Which is the
reason to be careful about using more memory.

A part of me is so careful about using memory that it hurts! ;-)

But when it comes to performance implications of multi-level cache
mechanisms, experiment often confounds analysis. Put another way,
the interactions of prefetch, replacement algorithms, capacities,
and locality often produce results that are not easily analyzed.
It's best to try an experiment.

You may be surprised (either way ;-) about the impact of changes
on realized performance.

Combinatorics of mapping multiple pixels per table reference will
result in rapid table growth.


Yes. Which is the reason I'm against it, unless it's really necessary.

I wouldn't bother with mapping multiple pixels at once--just a loop
that handles the neighborhood of each changed "dot" in sequence.

I've been talking throughout about working at the "single Apple dot"
per iteration level.


Which will be slower, and need a code rewrite. Both speaks against it.

But the code would be simpler. ;-)

We have 3GHz processors now,


You have, I don't. Why should I write code that will force me to buy
a new computer to be able to use it? :-) If people with 3GHz processers
want that feature, they should write the code, not me.

I understand. Sorry, but I was just looking at the "market", which
has had several years and two processor generations to absorb the
higher-performance processors.

Most "retro-computists" have their retro machines and their modern
workhorses (certainly if they are into video ;). It would be
interesting to see a histogram of processor performance of the
participants of this group.

My machine is a 3-1/2-year-old Pentium 4 running at 3GHz, so it's
getting long in the tooth in my opinion. My new laptop is a
Core 2 Duo with a pair of 1.83GHz processors, each of which is
faster than my Pentium 4. (I tend to buy my desktop near the
front of the curve, to minimize upgrade frequency, but my laptop
near the middle of the road, to maximize cost-performance.)

Experimentation is required--which means implementation, which
requires someone's curiosity needs to exceed the threshold...


Which is exactly what I am suggesting by my nagging questions for
more details. Experimentation is simple: Pick some concrete
image or game which you think looks much better on an NTSC TV
than on an emulator. Ask someone who has the real hardware (I don't,
but I guess there should be enough people here willing to help out)
to take a photo of the TV, or maybe just a close-up of a part
with interesting details. Run the same game in an emulator,
grab the black-and-white image with shifted lines, dump it into
a C program, run a few filter variations on it.

I can do the last step if other people will help with the first.

That's great!

If no one cares to find out, so be it.


So let's just try.

I'm not a gamer--never was--and my interests actually run in different
directions than this extended conversation might suggest.

I have a background in electronics and video, and have observed the
discontent in the community with the fidelity of emulated Apple II
video--no emulator seems to do a credible job of emulating composite
color video. As a result, and in view of the prevalence of processing
power that can be applied, I have suggested a generalization of some
of the simplified rendering techniques that have been applied in the
past. This technique has the potential to render what an analog
composite monitor displays much more faithfully than current methods.

My interest does not currently extend as far as implementing the
algorithm, or even documenting the need for it, but, since no one
else proposed an approach, I did.

A few years ago, I made essentially the same proposal to developers
working on C=64 and MAME monitor emulations. In that case, I found
that most developers working on video emulation are pretty involved
in the problems *as they see them* and in the algorithms that they
are currently using. This makes them less receptive to a new approach
that might solve the problem.

Since I don't feel much "ownership" of the problem, only a contributor
to a solution, I'm unlikely to attempt my own emulation--in fact, I
don't program modern machines at all!

So for me, this is yet another attempt to plant the seed of a design to see if anything will happen. ;-)

If someone chooses to implement this approach, it opens up the world
of *monitor* emulation, complete with brightness, contrast, hue, and
saturation controls--maybe even "sharpness"! ;-)

For a decade emulation struggled to be "fast enough". That era is
now essentially over--particularly for games with a real-time component.
Now the objective should be higher fidelity emulation, in my opinion.

DSP-like implementation is simple. What's missing are the concrete
filter coefficient values such a filter would need.


And those are readily available in the schematics of actual monitors.


Do you have any you could share? I don't.

I used to have a file cabinet full of Sams Photofacts describing
hundreds of color TVs--long gone. ;-( (I had the fantasy that later,
in retirement, if things got rough, I could always make a good living
fixing TVs--not anticipating that TVs would become 1) more reliable,
and 2) throwaway items. ;-)

I don't have my AppleColor Composite manual handy, and it may not
contain the schematic, but that would be a great one to use, because
so many of them were used with Apple II's. But literally *any* of
the nice Japanese color TVs of the mid-1980s would be fine.

If a later set is chosen, it's likely that some of the filtering
would be embedded in hybrids or ICs for which analysis would be
difficult.

Perhaps the best way to proceed, and one which would not require
a schematic, would be to open a good composite monitor and use a
signal generator at the video input and a scope to probe the
response of the luminance channel and the chroma channels. This
could be translated into filter coefficients.

The good news is that the user can select from a menu of graphics
renderings that would require only different tables--same algorithm.


And that's exactly what will also work with the 4bit window width that's
already implemented :-) Same algorithm, just different tables.

Right--a good approach.

The problem is that a 4-bit window cannot account for *any* effects of
bandwidths less than 3.5MHz, and we know that both the luminance
channel and (especially) the chroma channels have significantly lower
bandwidths.

-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."
.

Relevant Pages

  • Re: Develop file system filter for windows mobile 6
    ... BSP for Device Emulator and included fsdspy in the project. ... Careful as well as on WM you will have to edit the registry to include ... You *can* test your filter by using an sdcard as the filesystem ...
    (microsoft.public.windowsce.platbuilder)
  • Re: DirectShow Filters and windows media player On Smartphone Emulator
    ... It was a problem with the Windows Media Player on Emulator. ... I am currently developing a Directshow filter for Windows Mobile 5.0 ... HRESULT myResult; ...
    (microsoft.public.win32.programmer.directx.video)
  • DirectShow Filters and windows media player On Smartphone Emulator
    ... I am currently developing a Directshow filter for Windows Mobile 5.0 ... Smartphone SDK. ... emulator using VS.NET 2005. ... Windows media Player is unable to play the same video file. ...
    (microsoft.public.win32.programmer.directx.video)
  • Re: Why cant my usbcamd driver work well for MSN messenger?
    ... > To speed up graph building process the graph builder relies on the filter ... > cache information under certain circumstances. ... > call StreamClassRegisterFilterWithNoKSP or call it with wrong params. ...
    (microsoft.public.development.device.drivers)
  • Re: Cached vs Local Database - advice please
    ... Using a database will give you more lexibility with regards to organizing, ... DataSets and DataTables have the ... capability to filter and sort data without looping. ... Now, as to where to cache in-Memory data, you have basically 2 choices ...
    (microsoft.public.dotnet.framework.aspnet)