Re: Color fringe hires behavior

[Colin Klipsch <cklipsch@radix.net>]

In article <1163432337.622478.229380@h54g2000cwb.googlegroups.com>,
 "BLuRry" <brendan.robert@gmail.com> wrote:

> > For example, each of the seven low bits of an HGR line translates to
> > two consecutive bits in the DHR line, and the high bit shifts their
> > position in the DHR line by one DHR bit position.
> >
> 
> Yeah, I got that part -- but that doesn't quite cut it.  If the hi-bit
> is set on one byte, but not the byte next to it, then only a half-pixel
> is shown.  So there's more to it than just simple bit expansion.  At
> byte boundaries when the hi-bit goes from hi to low, pixels get cut in
> half.  So I'm trying to find the best logical representation of that
> behavior, hence represent (or "explain") the behavior algorithmically.

I try to get this feature right in Catakig, at least as far as 
monochrome pixels are concerned.  Getting all the possible color effects 
correct -- as everyone here notes -- is a much bigger challenge.  But 
the color output is ultimately a function of the underlying monochrome 
output anyway.

In the simple case of no shifted bytes on a line, or *nothing but* 
shifted bytes on a line, each byte in video memory determines the state 
of 14 monochrome pixels.  That's regarding each line as having 560 
pixels, not 280, even though we're talking about HGR graphics.  (And 
actually it's 561 pixels, if you think about it.)

As you say though, the interesting bit happens when two adjacent bytes 
are in different shift states.

There's one particular monochrome pixel between each video byte pair 
that is "fought" over.  If the left byte is unshifted and the right byte 
is shifted, then the left byte wins the pixel.  (Meaning, its bit-6 
state determines the pixel's state.)  On the other hand, if the left 
byte is shifted and the right byte is unshifted, then the right byte 
wins the pixel.  (Its bit-0 state determines the pixel state.)

This is the behavior I've observed empirically anyway with my IIc, after 
poking various byte values into video RAM.  (Poke $00, 40, 80, and C0 
into a "left" byte, and poke $00, 01, 80, and 81 into the adjacent 
"right" byte.  Observe and record all 16 possible combinations.)

Hope this is helpful.

-- Colin K.