Specifications

Developer Technical Support September 1989
Apple IIGS
#70: Fast Graphics Hints 3 of 4
lda |164,y ; accumulator is 16 bits for
pha ; best efficiency
lda |162,y
pha
lda |160,y
pha
In this example, the Y register is used to point to data to be moved to the graphics memory, and
hard-coded offsets from the Y register are used to avoid register operations between writes.
Hard-Code Instructions and Data
In desperate circumstances, it is necessary to remove overhead from the previous code example.
This can be accomplished by hard-coding pixel data into your code instead of loading pixel
values from a separate data space and transferring them to the graphics memory (as in the
example). If you are writing an arbitrary pattern of three or fewer constant values to the screen,
for example, the following method is the fastest known:
lda #val1
ldx #val2
ldy #val3
pha ; arbitrary pattern of pushes
phx
phy
phy
phx
In cases where many different values must be written to the screen, pixel data can be written to
the screen using immediate push instructions:
pea $5389 ; some arbitrary pixel values
pea $2378
pea $A3C1
pea $39AF
Your program can generate this mixture of PEA instructions and pixel data itself, or it could load
pixel data that already has PEA instructions intermixed (thus increasing the data size by one
half).
Be Aware of Slow-Side and Fast-Side Synchronization
Estimating execution speed by counting instruction cycles is always a challenging task on the
IIGS, but it is particularly tricky when one is writing to the graphics memory. The graphics
memory resides in the side of the IIGS system controlled by the 1 MHz Mega II chip, which
means that during all writes to this memory, the fast side of the system controlled by the Fast
Processor Interface (FPI) chip must be synchronized with slow side of the system controlled by
the Mega II, even if the system is running code at full native speed. This synchronization is
performed automatically and transparently by the FPI in the IIGS, and it isn’t normally of
concern to the programmer. Animation programmers must worry about synchronization delays,
however, because slight changes in graphics update code may change the frequency of these
delays, and hence the speed of the program. In practical terms, this means that one loop writing