Date : Wed, 06 Feb 2002 10:54:30 +0000
From : Richard_Talbot-Watkins@...
Subject: Re: Firetrack
I suspect that in order to get Firetrack working correctly you may need to
rethink your video emulation a little bit. If you use the CRTC registers
to determine things like the screen centring in exactly the way that the
CRTC does, you shouldn't have a problem.
For example, I would go about emulating the screen centring like this:
We know there are 312 PAL scanlines, and we can confirm this by looking at
the default CRTC register settings for a mode like MODE 1: R4=38, R5=0,
R9=7. Total number of scanlines = (R4+1)*(R9+1)+R5 = 312. So far so good.
We know that VSync is generated at character row 34 (R7=34). When the CRTC
sends a VSync pulse to the VDU, the VDU commences vertical retrace
(flyback).
We need to find out somehow how many scanlines of the PAL screen are
occupied with vertical retrace. My deduction goes like this: we know the
character rows 0..31 are the actual displayed visible screen. Rows 32 and
33 must therefore be the bottom border. At row 34, we have VSync, and
hence the beginning of vertical retrace. The last displayed character row
is row 38. Since the display area is centred on the VDU, we can probably
assume that the top border height equals the bottom border height, i.e. the
top border is rows 37 and 38, which means that retrace happens during rows
34, 35 and 36. Remember that the number of scanlines per character row is
given, as ever, by (R9+1).
The next leap we need to make is that the start point of the CRTC cycle
does not coincide with the start point of the TV refresh (or emulated
display) cycle. In fact, Firetrack almost certainly has to pack more than
one CRTC cycle into a TV frame in order to achieve its effect - more on
that later.
Let's think about the CRTC cycle and its relationship to the TV frame.
The following piece of c-like pseudocode describes the operation of the
CRTC (only interested in the 'vertical' cycle - we assume that we don't
need to emulate the horizontal cycle properly):-
repeat forever
{
screen_addr = R12 * 256 + R13
// Deal with character rows
vsync_scanline_count = 0
screen_row = 0
repeat
{
// Deal with VSync emulation
if (screen_row == R7)
{
set vsync high
vsync_scanline_count = R3_top4bits
}
// Deal with 'within the character row'
scanline = 0
repeat
{
if (scanline < 8 and screen_row < R6)
{
// This is a scanline in the visible area
plot screen line whose address starts at (screen_addr * 8 +
scanline)
}
else
{
// just a blank line (maybe border or 'gap mode' gaps)
plot a blank line
}
// maintain vsync pulse for the required number of scanlines
if (vsync is high)
{
vsync_scanline_count = vsync_scanline_count - 1
if (vsync_scanline_count == 0) { set vsync low }
}
scanline = scanline + 1
} until (scanline > R9)
screen_addr = screen_addr + R1
deal with wraparound for screen addr based on addressable latch bits
4,5
screen_row = screen_row + 1
} until (screen_row > R4)
// Deal with vertical total adjust (R5)
scanline = 0
while (scanline < R5)
{
plot a blank line
scanline = scanline + 1
}
}
An important thing to notice is that, with exception of R12/R13, all the
CRTC registers can be altered mid-update and the CRTC will respond to these
changes instantly. This also explains why it's not normally possible to
change the start of screen address midway through a frame.
The relationship between the CRTC cycle and the VDU cycle is fairly
straightforward. When the vsync is set low again following it being set
high (I think this is the case, rather than the actual moment when it's set
high), we effectively reset a scanline position counter to 0 which
effectively we use to determine the physical position of the scanline on
the emulated screen. Each time we plot a row, we increment this counter.
Simple. Of course, we don't want to plot the flyback, so on the assumption
from above that flyback lasts for 24 scanlines, we just ignore the first 24
scanlines. This leaves us with 288 lines to plot, which will hence also
plot the top and bottom borders. We can even make the leap that a 'normal'
screen of 256 active scanlines fits exactly into our emulated screen with
no border, so we ignore the first 24+16 scanlines, hence not plotting the
top border, and then ignore all scanlines after and including 24+16+256.
Hope that makes sense. The beauty of this approach is that everything
should work properly, because we're doing it in *exactly* the same way as
the CRTC and VDU work.
How's this going to help with Firetrack?
Well, I don't have too much time to explain how it works in great detail,
but it uses a technique which crams two CRTC updates into a VDU refresh.
We notice from the above pseudocde that the length of the CRTC cycle is
determined mainly by the value in R4 (total number of character rows).
Normally its value is 38, which results in 39 character rows (correct for
PAL). Suppose we set it to produce 28 character rows (set it to 27), and
inhibit the VSync by setting R7 to an out of range value (anything greater
than 27). When we deemed that the cycle had finished, we then set R4 to
produce 11 character rows (set it to 10), and set R7 to generate VSync at
an appropriate point in this second cycle (a value of 6 would be perfect).
We would not notice any change in the displayed screen, but there is a big
difference!! We now have two CRTC cycles inside one TV frame, which means
that the start-of-screen address from R12/13 is fetched midway down the
screen (allowing us to split the screen and have stationary windows and
hardware scrolled windows), and also the R5 scanline total adjust is
actioned twice in a frame too!
If in the first CRTC cycle we set R5 to 'n' and in the second cycle (bottom
half of the screen) we set R5 to 8 minus 'n', we can effectively control
where the first displayed row of the screen physically appears on the VDU
scanline-by-scanline, whilst ensuring that we can always have a constant
312 PAL scanlines. As I mentioned before, if there's not always 312
scanlines, we see an awful screen roll/judder as the VDU tries to
recalibrate to the varying refresh frequency.
Hopefully you can see how this might work.. I have no time at the moment to
go into this in any more depth, but I'll explain in more detail with
examples later on.
Hope I've made some sense... but I really think that if the CRTC is
emulated in a 'real life' way, Firetrack should just work! Of course, the
real challenge is actually coding something which reproduces it!!
cheers,
Rich
--
Rich Talbot-Watkins,
SCEE Cambridge.
Richard_Talbot-Watkins@...
All views expressed are mine, not my employer's... blah blah...
"Tom Walker"
<tommowalker@... To: bbc-micro@...
il.com> cc:
Sent by: Subject: [BBC-Micro] Firetrack
owner-bbc-micro@...
oud9.co.uk
05.02.02 16:57
So let me see if I understand :
Firetrack uses R5 to adjust start of screen. Other vertical size registers
are used to adjust size of screen. The top 8 lines are blanked.
Is that right? If so, I think I know what the problem is (B-em always
centres the screen depending on the screen size).
Tom
**********************************************************************
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