Date   : Tue, 05 Feb 2002 08:55:21 -0000
From   : Daniel Luton <DLuton@...>
Subject: Re: Firetrack

I've not seen Firetrack, is it available anywhere as a disk image (with the
intention of transferring it to a real Beeb) anywhere, to satisfy my
curiosity?

What exactly does the program do?

:))

-----Original Message-----
From: Richard_Talbot-Watkins@...
[mailto:Richard_Talbot-Watkins@...]
Sent: 04 February 2002 16:43
To: BBC Micro Mailing List
Subject: RE: [BBC-Micro] Firetrack



[please excuse the awful quoting - work have just moved us to Lotus Notes,
which refuses to do anything but top-post in this awful way :-(  It's
probably going to come out in Rich Text too isn't it... *sigh*]

I was in the middle of writing a short document, explaining how the
Firetrack scrolling works, aimed in particular at emulator writers.. I may
finish it tonight when I get back to my real Beeb.  I knocked up a few
demos a little while ago that reproduced not only the line-by-line
scrolling technique that Firetrack uses, but also the natural progression
from that which turns out to be the ability to have stationary unscrolled
parts of the screen at the same time as a scrolled window!  Looks really
nice... shame the method wasn't exploited more.... (or "at all"!)

It's kinda involved, but the actual line-by-line scrolling technique
doesn't require any particularly harsh timing at all, and could probably
even be reproduced (with care) using Basic!

It's true that Firetrack needs to do midscreen palette changes to
effectively mask the top seven lines of the screen (as the technique does
indeed use CRTC R5 in order to move the screen up and down by scanlines,
which means that the top of the visible screen moves).  However, it uses
some other cunning techniques to ensure that the total number of PAL
scanlines is always 312 each frame, regardless of what has been put in R5 -
if this scanline count varies between frames, the result is a horrible
picture judder.  The number of scanlines per character register (R9) is
never changed... at least, not in *my* implementation....  However R4, R5,
R6, R7, R12 and R13 are written to twice a frame refresh.....

I'll post my explanation and examples to this mailing list when I've
finished writing it all up (may be tonight.. however I have a killer
hangover so maybe it won't be :-)
--
Rich Talbot-Watkins,
SCEE Cambridge.
Richard_Talbot-Watkins@...     
All views expressed are mine, not my employer's... blah blah...



 

                    "Richard Gellman"

                    <R.Gellman@...            To:     "BBC Micro Mailing
List"           
                    net.com>                  <bbc-micro@...         >

                    Sent by:                  cc:

                    owner-bbc-micro@...        Subject:     RE: [BBC-Micro]
Firetrack     
                    oud9.co.uk

 

 

                    04.02.02 16:01

 

 



>Does anyone know how Firetrack's scrolling works? I'm trying to fix it in
>B-em (it's jumpy at the moment).

Dont ask.

It works by reprogramming the 6845 at a very fast rate, such that the
number
of lines per character is changed, and the total scanline adjust is
changed.
This results in the whole screen being moved by a line at a time, without
any physical movement of data. At the same time, the screen address is
reprogrammed to provide wraparound, so that when the screen is scrolled,
the
new data automatically appears in the new lines at the top of the screen.

There is also some scanline-based palette switching so that the top and
bottom of the whole screen are blanked off, as these are used for storing
the data for the screen scroll.

The only way to keep track of all this is to actually determine verticall
screen offset on the fly (i.e. as the frame is being drawn).
BeebEm's method of vertical screen offset is to just take the current CRTC
values are perform an evil equation to convert that to number lines to
shift
the whole screen. This works for almost everything except Firetrack.

I haven't entirely worked out how to do this, because it involves rewriting
a lot of code, and using the total height generated by the previous frame
as
a guide to where the current frame starts, e.g. if frame 2 generates 264
lines, then frame 3 must have line 132 as dead centre. Either that or doing
some devious data re-arrangement at time of writing the screen data to the
PC screen.




**********************************************************************
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 2001
This e-mail has been received from the Internet, scanned for viruses and
forwarded to you after passing entrance criteria.



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 the
originator of the message. This footer also confirms that this
email message has been scanned for the presence of computer viruses.

Any views expressed in this message are those of the individual
sender, except where the sender specifies and with authority,
states them to be the views of Acclaim.