Date   : Sat, 26 Jun 1993 02:57:55 +1200
From   : David Andrew Sainty <David.Sainty@...>
Subject: Unrolling loops & fast routines

   From: "M.J.Ebourne" <M.J.Ebourne@...>
   Date: Fri, 25 Jun 93 11:11:40 BST

   > If you have multiple screens and are DIMing lots of screen buffers,
   > allocating an extra 256 bytes each time is going to get expensive!

   If he's got multiple screens he only needs one dim, and so at worst loses
   255 bytes.

This much is true. But still... waste is waste....

   My personal prefered way would be to lower HIMEM and allocate yourself the
   memory. That is guaranteed to be in the same place all the time, and be page
   aligned. Much more sensible.

Yes, it is.

   > Note also that the mode 7 screen is only 40x25 bytes, which is 24 bytes
   > less than 1k. Not only can you dim less than 1k per screen, but you
   > can also transfer less and gain speed that way (Note that this is a
   > little messy, you need two loops transferring 3 pages concurrently, and
   > the 4th page in a 2nd loop).

   Indeed, but it would not NECESSARILY be quicker. Its worth counting the
   cycles to make sure. Also, to save 24 bytes requires a lot of messing around
   for very little gain.

Hmm, I thought I'd worked it out to be cheaper, perhaps not. In that case, you
can still write the whole 1k block, but only allocate 1k-24 bytes per screen.
The 24 bytes will still be saved, and whatever happens to be there will never
be seen.

   Also the fact that the screen is being copied in several different places
   simultaneously makes it look smoother because you cannot see one bit appearing
   before another.

I was assuming the code would be synced with the screen vsync, in which case
teh code is FAR too fast for the updates in different places to be noticed.
If the screen copy is not synced, it'll look messy WHATEVER copy scheme
memory->screen is used...

D.