Bryan Parkoff wrote:
"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, Iassume that orange pixel is in position 559 and position 560. The cut-offoccured 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.
He didn't forget HBL at all. On page 8-34, he describes how the second half of the furthest right delayed pixel is cut off by HBL, changing an orange pixel to brown. He never attributed the cutoff to the HAL logic. -michael NadaNet networking for Apple II computers! Home page: http://members.aol.com/MJMahon/ "The wastebasket is our most important design tool--and it's seriously underused."