Date   : Sat, 09 Sep 2000 17:31:17 +0100
From   : "Rich Talbot-Watkins" <Richard_Watkins@...>
Subject: Re: FRAK!

Tom Seddon wrote:
> I had a bit of a go at reproducing the effect myself the other day. As you
> found, big changes in R5 seem to make the screen jump a bit. On my emulator,
> R5 moves the screen up and down (0 is normal position, 10 (the maximum) is
> ten scanliens down; the timing for the frame is unaffected), and Firetrack
> works fine. It would appear that it sets R5 to 0, 1, 2... 7, then back to 0
> at which point the screen is scrolled using R12 and R13. Because the
> blanking of the top and bottom few lines doesn't work under the emulator,
> it's also possible to see that only one character line is drawn in advance;
> there's nothing funny like drawing a few in advance and scrolling through
> all of them.

I was always under the impression that 8 lines were drawn as with a normal
hardware scroll, and colour interrupts which stayed stationary on screen
masked the stuff which you shouldn't see yet... hmmm, dunno where I heard
that.  But if it is updating the screen line-by-line, that does admittedly
make more sense.

OK, I've never been entirely 100% sure how the video display on the beeb
works - I guess it's easier if you've written an emulator!  Can you just clear
up a few points.  Taking Mode 2 as an example:

R4 = (total number of character rows - 1): default 38
R5 = (extra scanlines per frame)         : default 0
R9 = (scanlines per row - 1)             : default 7

All well and good so far.  (R4+1)*(R9+1)+R5 = 312 = PAL scanline count.

R6 = (number of displayed rows)          : default 32.  Fair enough.

What is R7 all about exactly?  I assume this register contains the character
row it should be generated at, and the TV then syncs this to be at a certain
physical point on the screen (the top?  the bottom, before flyback?)

> On my real Beeb, however (again, as you too found) R5 appears to move the
> screen in half scanline increments -- it appears this is the case whether in
> interlace mode or not, as well.

It's supposedly a 5 bit register, but setting R5 to 31 (for example) resulted
in a horrible 'stretching' of scanlines towards the bottom of the screen.
With experimentation, I couldn't get *any* value of R5 to appear to move the
screen down 7 lines but it is difficult to tell.

> My Beeb is not set up right now, but I'm going to have more of a play over
> the next couple of days. Does anybody have any more suggestions or tips? And
> as a question of my own, does anybody know whether changing R12 and R13
> mid-frame should work? I can't tell whether the problem is my code or the
> 6845; I presume it's a 6845 limitation, because palette and mode changes
> work as expected, but I could be wrong...

Again, I never had any luck doing that - the CRTC seems to use the value it
had at Vsync throughout the screen render.  However it's certainly feasible to
change other regs midframe, eg R1,R2 (and shear the screen as it's drawn), so
maybe it's possible to change R5, R6, R7 etc.

This has become one of those annoying little challenges!  Anyone else know
anything?

Cheers,
Rich
Rich Talbot-Watkins
Sony Computer Entertainment Europe, Cambridge.
Richard_Watkins@...