The usage of the block copy feature is incredibly fast and
not to be under estimated. You can recopy the entire visible
screen at near 10-11 frames a second. If you reduce the size of
the screen and reduce the size of data segments to be copied (say
10cols by 10 rows or 80x80 pixels) you can approach 30 updates a
second (very suitable for animation) Granted, if you restrict
yourself to a 16k VDC setup, obviously there is going to be some
updating from the 128 side, that would bring everything to a
screeching halt.
Using block copy for speed, takes some experimenting. Here are
some of the things I've learned through trial and error:
- Try to block copy data in multiples of 8. It takes just as long
to copy 9 bytes as it does 15 bytes; but 8 bytes is much faster
than 9 bytes. Evidently there is an internal bit mask
operation where the VDC must calc the remainder off a multiple
of 8.
- It takes longer to setup and copy non-consecutive columns that
it does to copy the whole set of rows. For example, suppose
you want to copy columns 5 through 10 on rows 15 to 20. The
destination is the screen and the source is elsewhere in VDC
memory. To copy the 5 rows by 5 columns would take 5 separate
block copy commands, but if you were to copy the entire set of
rows it would be quicker. This is because all the overhead
involved in setting up each of the 5 block copies. To copy all
the rows all that is required is to keep resetting the number
of bytes to copy.
To use this fact to your advantage, you can copy the screen ram
out to a separate vdc location, update the ram there, and then
block copy the whole chunk back to the screen in one fell
swoop.
- When working with large numbers of rows to be scrolled via
block copy routines, be careful not to copy to many at a time
without updating the accompanying attribute ram. The screen
will flicker with the text moving with out the colors. (watch
pocket writer 2)
- If speed is not critical, block copying during the vertical
blanking period is much smoother and seamless; however you
don't have long to work with.
- Block copying is close to 1 byte per cycle (+- 5% overhead).
- You don't have to wait for an operation to be completed before
doing other things. Such as, you initiate a block copy or
fill, and then immediately go do something else on the 128 side
- no need to set around and wait for the update status register
to get ready. If you copy 255 bytes max, (my guess) is that it
takes between 300-400 cycles to complete depending on the state
of the vertical blanking period. 400 cycles of code at an
average of 3-4 cycles per instruction is over 100+ instructions
of code you can execute elsewhere while the VDC does the block
copy thing.
- Don't get caught in the WRITEREG lie. With 2 exceptions: you
do not have to wait for update status to become ready while
writing to a register. The first exception is that you can not
be in the middle of a block fill or a block copy (must wait
till it finishes), and two is you can't do consecutive writes
to vdc ram.