Block Copying

[Blacklord]

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.