12

As I understand, neither the Amstrad CPC or the Sinclair Spectrum had any support for hardware scrolling, and arcade conversions struggled compared to the C64 or NES.

However, isometric 3D games such as 'The Great Escape' leveraged the fast Z80 chip on the Spectrum to give an impression of smooth scrolling in 8 directions.

I imagine this was due to the Spectrum's small video memory map and some efficient double buffering. These games performed very poorly on the Amstrad machines. Why was this? Poor programming, or other limitations of the CPC?

Improve this question
3

4 Answers 4

Reset to default
14

The fundamental issue with scrolling is that, unless your hardware does it for you, it involves moving around the contents of your whole video memory. In other words, scrolling is the type of video programming task that is mainly limited by your system's fillrate. And, unfortunately, the fillrates of the majority of retro platforms are not particularly good.

The video memory size on ZX Spectrum is 6912 bytes (this is bitmap + colour attributes together). The fastest way to copy on Z80 is about 12.5 T-states per byte. ZX Spectrum has 70K T-states per single video frame. Thus, one cannot copy more than 70000/12.5 ~ 5600 bytes per frame. Therefore, most smooth scrolls you'd see would be done by filling i.e. constantly re-drawing pre-generated content. Filling is possible at 5.5 T-states per byte; hence, it at least gives you a theoretical chance to fit into a frame.

I keep talking about frames because the only way to get truly smooth scrolling is by updating your screen every frame, at 50Hz framerate. The challenges involved in this are such that during the commercial life of the Spectrum, I am not aware of a single 50Hz scroller released. Zynaps was famous for 25Hz updates (which were sometimes slower than this). There were several other scrolling platformers at 25Hz, each considered a massive engineering feat. R-Type runs at 12.5 updates; I never measured the frame rates in isometric games, but I can guarantee that they will not run faster than 12.5-18.7 frames per second. It is simply impossible to do it faster due to the limited fill-rate of the platform.

Now, the reason why I gave you all these numbers is as follows: Amstrad CPC has the same CPU as ZX Spectrum and 16Kb video memory. Essentially, Amstrad CPC has a similar fillrate and twice as large screen. Thus, any code trying to work with video memory as originally designed for ZX Spectrum is going to be automatically delayed by a factor of 16Kb/6.75Kb > 2. Zynaps slowed down by a factor of two would only be as smooth as R-Type was on Spectrum; R-Type, not an icon of smoothness by itself, would become properly jerky if slowed down this much.

Of course, modern demo-scene for Amstrad CPC shows that some of the fillrate issues can be addressed by getting help from the video chip. I believe that, for example, people can generate repeated scanlines, so that only half or quarter of scanlines would need to be actually updated. This would tilt the fillrate balance into somewhat more tolerable situation.

Improve this answer
17
  • 2
    (Video of Cobra, unemulated: youtube.com/watch?v=4fU1RjYgsj8 )
    – Tommy
    Nov 5, 2018 at 17:01
  • 1
    @Tommy, this is a very famous game :) Interestingly, the only part of the screen that is updated at 50Hz is the thin strip at the bottom, which gives an illusion of parallax scrolling. You can easily verify that the main screen is updated only at 25Hz. This is partly due to the chosen render strategy: that game awaits for the top line of the screen and then redraws it after the beam, which means that before the beam catches up during the next frame you have >1 full frame available for drawing without tearing artefacts. So, yes, 25Hz also looks pretty smooth. Just not as smooth as an arcade.
    – introspec
    Nov 5, 2018 at 21:16
  • 1
    How about the author's own admission? worldofspectrum.org/forums/discussion/comment/418796/…
    – introspec
    Nov 5, 2018 at 23:06
  • 1
    That's objective enough for me; and certainly a lot more persuasive than the previous level of debate of anecdotes A versus anecdotes B. I withdraw my earlier claim.
    – Tommy
    Nov 5, 2018 at 23:14
  • 1
    Sorry, yeah, that's why I made sure I branded the other sources as anecdotal, to emphasise the appropriate pinch of salt, and wanted to find a way to show it empirically. I mean, this isn't Wikipedia, you shouldn't feel the need to provide a citation for everything. I've also separately found the Youtube proof: check out youtube.com/watch?v=T-NMhQc_v34 , a 30fps capture, skip to anywhere with scrolling (I'm looking at 02:39) and single step (pause and use <>). Frequently enough you'll see the very bottom scroll without the rest, which would be impossible if the entirety were 50Hz.
    – Tommy
    Nov 5, 2018 at 23:51
10

The two machines had very different video memory layouts. The Spectrum had only 6144 bytes of video bitmap, plus 768 bytes of colour attributes for it. The bitmap was monochrome, but one could set foreground and background colours for 8x8 pixel blocks.

The Amstrad had much more video memory, at 16384 bytes, and it was a "proper" colour bitmap, with two, four or eight pixels per byte. The video memory layout was rather complicated, as demonstrated at this website. That made code for scrolling the display much more complicated and thus slower, and there wasn't really room in memory for a second screen buffer.

Improve this answer
4
  • 1
    Not to mention that all too often market realities meant that teams developed a Spectrum version, then ported that to the CPC. Sometimes going as far as having the full Spectrum display in memory and mapping it to the CPC in real-time, but usually just doing that at a sprite level. Otherwise the sprites would need to be 2/4bpp, and therefore twice the footprint, and it's not like you have any extra memory on a CPC once both are 128kb machines.
    – Tommy
    Nov 4, 2018 at 22:26
  • 2
    So the memory layout is basically interlaced chunky.
    – snips-n-snails
    Nov 6, 2018 at 3:42
  • Also note that the Spectrum video bitmap layout is optimized to make adding rows to a pointer into it as easy as possible; this was intended to make standard drawing routines more efficient but may also affect the efficiency of block copy operations, too.
    – occipita
    Apr 1, 2021 at 20:40
  • "there wasn't really room in memory for a second screen buffer." -> There was: you can fit easily 2, also 3, with much effort 4 in memory with hardware flipping, even on a CPC 464. A second buffer was even supported by the firmware, although seldom used this way (see BC08 SET SCR BASE on e.g. acpc.me/ACME/DOCS_TECHNIQUES/… ).
    – Stéphane Gourichon
    Mar 6 at 23:02
8

The Amstrad CPC was not slow at scrolling.

Hardware scrolling as originally intended

Ever since the Amstrad CPC was released, even BASIC programs could use vertical hardware scrolling of the whole screen by just printing text past the bottom line.

It is true, though, that when used in the simplest way, the granularity of the hardware scrolling is a bit big: 2 bytes horizontally (which makes 16, 8 or 4 pixel columns depending on mode) and 8 lines vertically.

Regarding directions, all are possible. Actually, you can jump to any of 2048 position at each frame.

The relatively high granularity caused a number of game programmers to use alternate solutions, either double buffering or software scrolling with redraw.

If the scene to display can afford high speed, it can render beautifully, here is an example scrolling above 3D isometric color mountains: (1) Isometrikum Vanity - YouTube

Isometrikum by Vanity

Refined hardware scrolling

Advanced tricks by reprogramming the CRTC while displaying a video frame allow to overcome those limitations: scrolling with finer granularity, scrolling only part of the screen, scrolling several areas of the screen independently. Some tricks highly impact CPU availability, but in some cases one can keep CPU available for other work.

More details on: Programming:Hardware scrolling - CPCWiki and more on CPCWiki including a reference to a 1987 game that uses one-line-by-one-line vertical hardware scrolling (1) Mission Genocide - Amstrad CPC (Firebird, 1987) - YouTube

Combining tons of clever use of what is originally intended as hardware scrolling capability, highly spectacular effects are possible. Some recent examples:

Many other prods for original CPC use those tricks in one form or another, see prodlist :: pouët.net.

Improve this answer
6
  • 4
    This is an important point -- if you're scrolling in software (e.g. because you're only scrolling part of the screen), then the CPC's larger colour bitmap frame buffer gets in the way. But if you can use it, it supports hardware scrolling (i.e., you can change the base address of the buffer and therefore don't actually need to perform the copy in many cases), whereas the Spectrum has a fixed-location frame buffer so can't do anything as advanced as that.
    – Jules
    Nov 12, 2018 at 21:11
  • 1
    I really liked your answer because of the technical information you provided. However, the majority of the examples of scrolling that you supplied are newer and usually demoscene related. So, even though you state that CPC was not slow at scrolling, you evidence does not really support the idea that it was not :)
    – introspec
    Nov 16, 2018 at 18:40
  • 2
    @introspec Thank you for your observations. Here is a famous 1991 production: The Demo. As John Dallman mentioned, many games of the era were ported from Spectrum which, from a pure CPC perspective, means artificial limitations. Demoscene, on the contrary, is motivated by showing the best a platform can do, so no surprise they demonstrate that better. :-)
    – Stéphane Gourichon
    Nov 17, 2018 at 16:44
  • 1
    This is a brilliant answer, and makes me realise that the real reason for the poor performance in the games I mentioned was porting from the spectrum, and failing to use the unique hardware features of the CPC.
    – Mark Williams
    Feb 14, 2019 at 18:47
  • Another recent production: Pinball Dreams Amstrad CPC (Preview) - YouTube.
    – Stéphane Gourichon
    Feb 17, 2019 at 19:58
2

Thanks to the excellent answers to this question, I have now learned that

  1. The Amstrad CPC did have hardware scrolling (vertically and horizontally) as well as double buffering and
  2. The ZX Spectrum had to copy / redraw content (software scrolling) so
  3. Games ported from Spectrum to Amstrad often suffered because the software scroll (redraw or memcopy) took longer on the Amstrad.

Though I had my doubts that contemporary games used hardware scrolling on the Amstrad, I found the following comment from Pete Wiseman, regarding Scramble clone 'Killer Cobra':

There were some well known hardware registers that you could use to offset the screen and scroll it one 4-pixel block at a time but that produced scrolling that was just miles too fast for this type of game... Anyway, the technique published in Amstrad Action revealed a second hardware register that nudged the screen horizontally to the right by 2 pixels. I think it was some kind of screen centering register that wasn't documented but if you used this in conjunction with the hyperspeed 4-pixel scroll, you could slow the scrolling down to something more playable. To do that you would scroll the screen left by 4 pixels but also nudge it right by 2, effectively scrolling left 2 pixels. Then the next frame you could just nudge the screen centering register back to it's normal position scrolling left 2 pixels again. Then repeat and you'd end up with a 2 pixel scroll which although is probably twice as fast as arcade games like Scramble and Super Cobra, it's playable ... and silky smooth as it uses hardly any CPU.

Vertical hardware scrolling was much trickier, and required accurate timing, though it still uses documented CRTC registers.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .