Hi,
Inspired by Pitfall Jones's excellent looking Nyan cat game, I've been looking in to how hardware scrolling works on the Beeb. I can't seem to get my head round it fully.

I've read Richard Talbot-Watkins's explanation of the "vertical rupture" scrolling technique. I understand most of that.. but I think I'm missing a few fundamentals.

so:

a) What is the concept behind the writing to the screen beyond &7FFF?
b) How do you implement it?
c) What happens to screen addressing? e.g. I have a pixel on the screen whose address is known prior to scroll. Screen is then scrolled. Will it's address be the same?

Thanks,
jbnbeeb

When the screen is scrolled so that the display address goes beyond &7FFF, the address is wrapped-around to the screen start by adding in a value that's appropriate to the current screen size. This value is controlled by something called the addressable latch but only certain values can be set (corresponding to the sizes of the Beeb's standard modes 0-6):



The latch value can changed by programming the System VIA - page 419 of the Advanced User Guide has more details but you only need to change the latch value if you are looking to scroll a custom made mode. For example, if you've created a 128 x 256 pixel "Mode 2", this will create a 16K screen. To scroll it correctly, the addressable latch needs to be setup as it would be for Mode 3 and not Mode 2.

Assuming the latch has been set correctly, which it will be if you're using a standard mode, scrolling is "just" a matter of adjusting the screen start address in registers 12 and 13 (R12, R13) of the CRTC. There's an example in BASIC on page 374 of the Advanced User Guide.


If you're thinking of the pixel as having a particular location on the screen (e.g. the top-left corner) then its address will have changed following scrolling. However, if you're thinking of the pixel as the red dot that you've drawn, then although the red dot will have moved following scrolling, its address won't have changed.

When writing something like a vertically scrolling game, you have to bring in new data at the top of the screen when it has been scrolled. This means keeping track of the screen start address (the top left corner) and writing the appropriate amount of new data over the old data that has just passed off the bottom of the screen and wrapped around to the top. Of course, you also need to keep track of the screen start address so that you can update R12 and R13.

Hope this helps - I'm sure others can explain it much better than me.

Cheers,

Rob

Wow Rob, you know your s***.

You should write a game some time ...

how to set the screen start address (div 8)

Thanks RobC and PJ. I'm almost there with this.. will study some more and post back if I'm still stuck.

Following your snake diary with interest jbnbeeb.

I remember trying to do this scrolling as a kid. But it was pretty flickery, it was all guess work and bodging.

I'm trying to get my head around it all again... and wondering if it's possible to set the wrap around address independently of the start address?

I'm not even sure if that would have any advantages. I'm thinking write to this 'off screen' area before the scroll.

So, a start address at 0x3000, end at 0x7ffff. Could I set the wrap around to say, 0x2DC0 (or whatever the line above is). So... er... setting start address to 0x3240. Would show a screen full 0x3240 to 0x7ffff plus the wrap stuff at 0x2dc0. The off screen area now at 3000... no, wait... er... does that make sense. My brain hurts.

There are only four possible wraparound addresses - $3000, $4000, $5800, and $6000. In order to get an off-screen portion you have to shrink the display.

Hi,
I've not yet had a proper play with hardware scrolling, but between reading bits of the AUG, Rich TW's articles here and RobC's explanation above, I think I pretty much understand the principle of the simplest approach. I'm not yet fully au fait with RTW's vertical rupture approach for line by line vertical scrolling
RS Wiki Sample Code: How to do the smooth vertical scrolling

- but I can see why it is needed as otherwise, vertical hardware scrolling is limited to character row increments as I understand it.

Mode 2 sideways scrolling doesn't look too bad (i.e 2 pixel increments due to the way Mode 2 chars are implemented).. except for going up or down a line when wrapped around to other side of screen So a scroll routine would have to offset the wrapped around column accordingly.

I wasn't going to put scrolling in my Snake game.. I've other problems to tackle first with my limited skills

..Maybe once I've got the basic Snake game completed I'll incorporate scrolling.. or perhaps even in another game!