Date   : Tue, 10 Sep 2002 19:01:12 +0100
From   : Richard_Talbot-Watkins@...
Subject: Re: Firetrack Scrolling

james watson wrote:

> This firetrack scrolling program listing was posted a while ago.
> Can somebody actually explain on how it works and the principles
> behind it in a little more detail. I have little knowledge of
> assembly language but am no expert. Also the scroll window is
> scrolling upwards, how would you alter the program so the window
> scrolls downwards.

Well, making it scroll downwards is easy enough:

just change the following lines:
  560 LDAline:SEC:SBC#1:BPLskip
  570 LDAaddr:SEC:SBC#80:STAaddr
  580 LDAaddr+1:SBC#0:CMP#&B:BCSP%+4
  590 LDA#&F:STAaddr+1:LDA#7

I kinda explained its workings in an earlier post ages ago...  I
haven't got time to go into it in too much depth at the moment.

Effectively there are three crucial tricks:-

1) Altering CRTC R5 increases the number of scanlines in the PAL
   refresh.  It also has the effect of appearing to move the
   top of the visible screen down by scanline amounts - this is the
   way we physically move the displayed screen on the VDU to create
   the illusion of pixel-by-pixel scrolling.

2) A PAL refresh must always have a constant number of scanlines
   (312 is correct).  However, by modifying R5, we immediately
   change the number of scanlines in the refresh to be greater than
   312.  To get around this, we effectively "split" the screen, so
   that we have TWO separate CRTC cycles within one TV frame.

   In the first CRTC cycle (for example), we have:
       16 character rows ( = 128 scanlines)
      + 3 scanlines (because R5 set to 3)

   In the second CRTC cycle, we then ensure that we have:
       22 character rows ( = 176 scanlines)
      + 5 scanlines (by setting R5 to 5)

   Total = 312 scanlines, therefore the TV is happy, and we get
    no judder.

   A consequence of this method is that we always end up splitting
   the screen.  In my demo I chose to exploit this by creating
   a deliberately still bottom half - in a game this would probably
   be reduced to just one or two character rows, just to provide
   some static status like a score/energy bar.  It'd be possible to
   split the screen somewhere "offscreen" but I think it's nice to
   have a stationary area.

3) Altering R5 simply moves the visible screen boundaries.  This
   means that, without more trickery, we can see the top boundary
   of the screen moving.  The trick here is to mask a top area of
   the screen by ensuring the palette is blanked while they are
   being rasterised.  If we turn all palette colours to black upon
   VSync, and then wait a set amount of time before restoring them,
   we get a stationary palette fringe (just like many many games use
   to try and get more colours on the screen at once).  Because the
   top of the "scrolled" screen can be moved above this fringe, we
   get the impression that the topmost lines are disappearing and
   hence we have a constant top boundary.

Eeek this is so hard to explain without pictures and stuff.... I
think I'm not making a good job of explaining this!

Will try again when I have more time!

(As an aside, it transpires that Firetrack seems to use a more
complicated method to achieve basically the same thing - Firetrack's
method requires much more delicate timing, whereas in mine it's much
less crucial and allows us to have a stationary area of the screen
too!  Hurrah!)

Cheers,
Rich

--
Rich Talbot-Watkins
SCEE Cambridge
Richard_Talbot-Watkins@...     




**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
postmaster@...     

This footnote also confirms that this email message has been checked
for all known viruses.

**********************************************************************
 SCEE 2002