Re: Double HIgh Resolution Question

[Doug Kwan <XXXXdkwanXXXX@gauge.transmeta.com>]

Michael J. Mahon <mjmahon@aol.com> wrote:
: Andy McFadden wrote:

: <snip>

:>The trouble with DHR is that you need a 12-bit lookup table to determine
:>the color of each pixel.  You have to consider the four bits that "should"
:>be determining the color, plus the previous 4 bits, plus the following 4
:>bits, because the color can be different depending on what came before or
:>after.  And there isn't a simple logic function that explains it.  (If
:>there is, it has eluded me.)

: This is interesting--and strange.

: What we are calling a 4-bit pixel is just the display's "interpretation"
: of the luminance and chrominance components of some composite
: "wiggles".

: I have not examined the logic that synthesizes RGB outputs
: from the composite luminince-chrominance signal synthesized
: by the Apple, but I would be surprised if it took much of the
: following 4-bit group into account when determining its current
: outputs.

Some emulators use a sliding window method to emulator the NTSC
colour generation to get "Apple II" like Hires/DHires colours.
In general you only need to sample 4-5 pixels to generate the require colour.
To speed things up though, you want to do table look up for the
whole byte (or two bytes in DHR). 

My emulator uses a 2K (11 bit) table for each 8 consecutive pixels.
You can use a smaller table, but you would need to do more
table look-ups. It is 11 bits because it the windows size
is 4 and there are 8 pixels. 8 + (4 - 1) = 11

If you use a 5 bit window for an 8 bit group, the look up table is 12-bit. 

-Doug

PS. Remove XXXX to for my mail address.