> So, is there essentially TWO video buffers in play? It seems that
> if there was only one, the mouse pointer would "corrupt it", and
> it would need to be always refreshed by the program running?
> I guess there could be some clever XOR trickery to get an inverse
> pointer, but then if the graphics "underneath" the pointer changed,
> you'd get bad interactions?
The Apple had various graphics modes (character and bitmap). The character
graphics were hardwired into ROM, and there were no sprite capabilities on
the machine. So we're talking about using a bitmap display to get a mouse
pointer. The bitmap capability of the Apple II was rather odd - if I recall
correctly, three pixels to a byte, two of those being 8-colours (3 bits) and
the last being 4 colours (2 bits). So every third pixel had to be one of 4
colours, the others could be one of 8 colours.
Now to do the actual display, the Apple hardware simply pulled a byte out of
the video display memory area, created three pixels from it -- based on
preset bit pattern to colour associations (there was no palette) and
displayed that on the TV. The system did not write or corrupt video memory
when using it to display the TV image. So no, two video buffers were not
necessary, and no, there's no reason why a mouse pointer would corrupt it --
provided the software doing writes to video memory always removed the mouse
pointer first, then put it back afterwards -- and that the mouse pointer
code was able to replace the data it overlaid when being removed.
One other option for realtime updates -- flicker free, and without having
double-buffering. And that's CHASING the video beam down the screen.
Typically one would wait until a scanline had just been displayed, then
start doing your mods to video memory for that scanline - you know that it
won't be displayed again for another 1/60th of a second, and by that time
you're hopefully done drawing. You'd wait until your first scanline was
just behind the current line counter (ie: had just been drawn) and then
you'd draw the whole shape as quick as possible. Another method is to know
exactly how long it takes you to draw your shape, and make sure the scanline
being drawn won't overlap your image before you're finished. These
techniques were a pretty common approach to flicker avoiding.
Gotta say, I still like the bizarre 3:3:2 Apple bitmap ;)
Cheers
A
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
