Re: Double hires mode color artifacts

[Dirk Thierbach <dthierbach@usenet.arcornews.de>]

Michael J. Mahon <mjmahon@aol.com> wrote:
> Dirk Thierbach wrote:
>> Michael J. Mahon <mjmahon@aol.com> 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? 

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

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.

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

>> [...] 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.

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

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

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

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

So let's just try.

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

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

- Dirk