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

Re: Color fringe hires behavior



Colin Klipsch wrote:

> 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 far as I know, if the rightmost byte is shifted right (i.e. if it's a
"blue/orange byte"), the rightmost half-pixel is lost. And if the
leftmost byte is shifted, a half-pixel from somewhere else in memory
enters the picture (the infamous "thin orange line", although this is
not visible on a IIe or newer). So it's not 561, but 560.

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

Correct. The "Home" space of every byte is the space it occupies when
unshifted (i.e. a "green/purple byte"). The shifted byte simply doesn't
do anything at all to the video signal in its leftmost half-pixel (the
rightmost half-pixel of the previous byte is simply repeated.) The
rightmost half-pixel of a shifted byte is lost (unless the next byte is
also shifted, in which case it's display through the mentioned
"inaction" of shifted bytes during their first half-pixel).

-- 
Linards Ticmanis