Help needed: Emulation of AppleII Graphic modes

[Holger Picker <pickerh@uni-muenster.de>]

Hello,

I wonder if someone could help me, please, and tell me a bit more on how the
AppleII graphic circuits generate the colour pixels.

While writing the graphic emulation code for my little emulator, I came
across a rather strange problem I cannot solve with the limited knowledge of
mine. I tried to write code to generate a "blurry" output like ApplePC does
and succeeded in that with the exception of the left and right border.
ApplePC treats double hires or lores like a row of 560 pixels whose colour
is determined by 4 consecuting bits.
For example:
byte in memory: 010100
This will produce colour 0101 for the first pixel, 1010 for the second, 0100
for the third and so on.
Unfortunately, if you use 4 consecuting bits for every colour pixel on
screen, you need 560+3 bits to determine the colour of every pixel. My
assumption is that the graphic circuits of the AppleII work like a 4-bit shift
register which is filled with the bytes from the memory while the
corresponding colour pixels are drawn on screen. In this example you would
start with a value of 0101 in the shift register, then the value would be
shifted to the left (to keep the picture) to 101x and the x would be loaded
with 0 to give the value 1010... At the end of the horizontal line,
however, you would need the additional three bits mentioned, since the shift
register would contain a value of 1xxx (if the last bit in memory was set)
or 0xxx (if the last bit in memory was cleared) and three unknown values (x).
I just guess that these would be simply 0, but I do not know. These added
0s, of course, will be seen as some kind of blob at the right border of
the screen, and, indeed, that is exactly what ApplePC's output shows. However,
it would also have been possible to start the shift register with a value of
xxx0 for the first pixel (x may be set to 0 again), and then continue with
xx01, x010, 0101... In this case, the blob would occure at the left
border. My question therefore is: What would be correct? Or, perhaps, am I
completely wrong with my assumptions? Any help would be highly appreciated.

Another thing that just comes to my mind: As far as I've heard, the AppleIIe
(and therefore probably the Apple//c as well) had the special feature of
showing monochrome resolutions not as 280x192 pixels but of 560x192 or
something similar. IIRC, setting the highbit in standard hires mode shifts
the 7 hires pixels (1/280) one 1/560 pixel to the right. Is that true? My
questions would be then: a) What size do the hires pixel have (I assume
1/280 i.e. 2/560, not 1/560), b) What happens if there are two bytes, the
first with highbit on, the second with highbit off, like 0000001-1 0000000-0?
The generated output of the first byte would be (I assume):

0-00000000000011 (1/560 pixels)

The left 0 will be added because of the right-shift.
The rightmost 1/560 pixel (1), however, will be in a position normally
generated by the second byte, which consists of 0s in this example. Does it
mean that the rightmost pixel will be cut off, i.e. simply forgotten, or
will it override the 0 generated by the second byte? IOW: Either:

0-0000000000001 10000000000000 (1/560 pixels)
                ^
or:
0-0000000000001 00000000000000 (1/560 pixels)
                ^
?
With the hi-res colour mode I think it did override the 0 and thus produced
lo-res colours (like yellow). At least, this is what you get with ApplePC and
other emulators. As far as I remember, there was a post about the special
monochrome mode a while ago here on comp.sys.apple2. Unfortunately, I did not
make a copy of it. Sorry. Perhaps someone could either repost it here or
send it directly to me.
Thanks a lot in advance

  Holger