Specifications

Apple II Technical Notes
4 of 4 #70: Fast Graphics Hints
data to the graphics memory may run at the same speed as a second loop with a higher cycle
count.
A careful analysis of the synchronization problem leads to the following tables, which are useful
as a rough estimate of the speed attained by different pieces of code. Each entry is based on the
number of cycles consumed during consecutive write instructions. For example, a series of PEA
instructions requires five cycles for each 16-bit write. A short PHA instruction followed by a
branch requires six cycles for each 8-bit write.
Fast Cycles per Write (byte) Actual Speed (µsec./byte)
3 to 5 2.0
6 to 8 3.0
9 to 11 4.0
Fast Cycles per Write (word) Actual Speed (µsec./word)
4 to 6 3.0
7 to 8 4.0
9 to 11 5.0
The times given in the tables apply only if the same number of fast cycles separate each
consecutive write operation. The first write operation in a set of write instructions usually takes
longer than subsequent writes, because the potentially long synchronization operation is
accomplished at that time. Unpredictable delays caused by memory refresh slow things down
further, although refresh delays byte-wide writes more often than word-wide writes. Therefore,
it is usually preferable from a speed standpoint to use word-wide writes to the graphics memory.
For more information on synchronization cycle timing within the IIGS, see Chapter 2 of the
Apple IIGS Hardware Reference and Apple IIGS Technical Note #68, Tips for I/O Expansion Slot
Card Design.
Use Change Lists
The timing data given in the preceding section shows that it is not possible to perform full-screen
updates in the time it takes the IIGS to scan the entire screen. In fact, it would be difficult to
update more than one-sixth of the screen in one scan time. Therefore, it is necessary to update
only those pixels which have actually changed from the previous frame of animation. One
method of doing this is to precalculate the pixels which change by comparing each frame against
the preceding frame. For interactive animation, fast methods must be developed for predicting
which areas of the screen must be updated (a determination of the exact pixels might require
more computation than the actual update would require).
Using the Video Counters
To achieve “tear-free” screen updates, it is necessary to monitor the location of the scan-line
beam when writing to graphics memory. As described in Apple IIGS Technical Note #39, Mega
II Video Counters, the VertCnt and HorizCnt Mega II video counter registers at $C02E-
C02F allow you to determine which scan line is currently being drawn.