[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