Re: Color fringe hires behavior

["Bryan Parkoff" <nospam@nospam.com>]

"Linards Ticmanis" <ticmanis@gmx.de> wrote in message 
1163698015.811473.204290@h48g2000cwc.googlegroups.com">news:1163698015.811473.204290@h48g2000cwc.googlegroups.com...
>
> Bryan Parkoff schrieb:
>
>> > 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.
>
>>     If you are referring to start from position 0 through position 559, I
>> assume that orange pixel is in position 559 and position 560.  The 
>> cut-off
>> occured when half pixel in position 559 becomes brown and position 560
>> becomes black because orange bit data is in Load/Shift Register.  It is
>> ready to display another half orange pixel in position 560, but blanking
>> screen blocked it to become black.
>
> Right, that's what I meant. The blanking always kicks in at the same
> place on the right edge of the screen.

Linards,

    Did you remember reading Jim Sather's article about HAL16R8 chip 
(emulated HAL16R8 using Applesoft BASIC) as timing from "Understanding the 
Apple //e" manual?  Jim Sather claimed that HAL16R8 chip was unable to 
cut-off orange pixel into brown pixel when he used Logic Analyzer to analyze 
timing.  I bet what he had forgotten the horizontial blanking!!  It has 
nothing wrong with HAL16R8 chip because it is not HAL16R8 chip's job to do 
cut-off.

Bryan Parkoff