🚀 go-pugleaf

[ Changed to .tech only ]

In article <736@cord.UUCP> nsw@cord.UUCP (Neil Weinstock) writes:
>	Question #1:  Can the copper reload just the bitplane pointers
>	    quickly enough to avoid blank scan lines between slices?  If not,
>	    then we're hosed.

It can.  The Amix console driver does this.  It only uses one bitplane
at the moment, so to load several planes it might have to WAIT for a
slightly earlier point.  Currently it waits for the beginning of the
line.  (BTW, if it for some reason couldn't load them fast enough, the
result would not be blank lines, but some extra continuation of the
previous "slice"'s bitmap, and the current slice would be shifted to
the right.)

>Now, horizontal scrolling is achieved with "standard" copper list twiddling.

(Hopefully this means by modifying the places in the copper list where the
bitplane-start and horizontal-scroll registers are set.)

>Vertical scrolling, on the other hand, is achieved by creating (via tiles,
>or algorithms, or who knows what) the next slice to be scrolled onto the screen,
>and integrating it into the copper lists.  When a slice gets scrolled
>completely off the edge of screen, it can be freed up and reused.  It may
>be desirable to leave some sort of "buffer zone" at the top and bottom if you
>don't know which direction you'll be needing to scroll.

The Amix console driver does this with a few variations:  A "slice" is one
scanline (i.e. it doesn't really use slices, it just starts the display
at whatever line it feels like).  Since each slice (except the first one
in memory) happens to immediately follow the previous one in memory, no
copper action is necessary between slices except when the "last" slice
wraps around into the first.  This means the copperlist really only needs
one change to support this scrolling system:  At what would have been the
end, it must WAIT for the spot where the memory bitmap will wrap around,
and just MOVE the new BPLxPT values.  The current version does not have
any "buffer zone" -- exactly the number of pixels that will be displayed
are allocated.  Since the modified copper list is only "installed" at
the top of the next field, this means that it is possible that it might
be scribbling in the part of bitmap that is supposed to be at the
bottom of the screen (and will be there after the new copper list takes
effect next field) but is currently displayed at the very top.  This is
actually noticable sometimes.

>So, the end result is that you have created a circular queue of display slices
>which allows the display memory to be run like a treadmill.  The height of each
>slice would determine how long you have to create the off-screen slice, but
>also how much you have to create.

The height of a "slice" actually has no effect, it's the amount of "buffer
zone" that determines how far you can stay ahead.  The "slice" essentially
becomes an arbitrary, variable thing equal to however much you scroll in
a given field.  For a video game you probably have to finish the update by
the next frame, so it basically limits how many pixels you can scroll per
frame without having some possibility of re-using some memory that is
still being displayed.  If you're double buffering, you wouldn't need any
buffer zone.

>I am convinced that if pulled off correctly, this could make for absolutely
>lightning fast scrolling of an arbitrarily tall but finitely wide field, with
>many bitplanes.

It does.  Type "cat /etc/termcap" and you'll be dizzy real quick.
-- 
					-=] Ford [=-

"The number of Unix installations	(In Real Life:  Mike Ditto)
has grown to 10, with more expected."	ford@kenobi.cts.com
- The Unix Programmer's Manual,		...!sdcsvax!crash!kenobi!ford
  2nd Edition, June, 1972.		ditto@cbmvax.commodore.com