So how did they code...

[Georg]

I vaguely recall an article in a magazine (Amiga Format?) written by the programmer of Blood Money who used a neato trick to create a horizontal scroller. It boiled down to having only two screens in memory, and using some simple manipulation via the Copper to shift the 'view' slowly from left to right. However, at the same time you were building up a copy of the screen you were scrolling into in the part of the screen which wasn't visible, so by the time you reached the border of the right screen, you could reset the pointers to the left one, and start anew. The author encouragingly stated that other scrollers were just a matter of sitting down with pencil and paper and working out the details. Well, try as I might, I never got something elegant to work in the 2D-variant. Can someone explain how that was done?

Bah! That technique sucks. Can be done much better. Faster, too. For a X-only scroller on 320x256 screenmode you need a "screen" whose byte size is about:

(320 x 256 / * numplanes +
(320 / * number_of_screens_of_map +
a handful more bytes (depends on size of tiles)

For any-direction scroller only a few more bytes are needed. Have a look at ScrollingTrick.lha on Aminet. It explains how it works and has example source in C.

[Georg]

The drawback is it eats chip RAM.

It's possible to make any-direction scrolling routine where map size can be unlimited big, but screen size stays fixed at:

width: (visible_width + tile_width * 2)
height: (visible_height + tile_height * 2)

btw, another trick: do not just use two screens (for double buffering). Instead use three screens. The third screen is scrolled like the others, but you don't blit any bobs/objects into it. This way it's always empty. So you can use it as restore-buffer. And can skip the backup-parts-of-screen-which-bob-will-overpaint part for game objects. Big speedup as scrolling is so fast anyway.