5

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?

7

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.

A 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 challanges involved into this are such that during the commercial life of 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 framerate 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 demoscene 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.

  • I think Cobra was a contemporaneous 50hz scroller for the Spectrum! Its solution is lots of long horizontal platforms with a short repeating pattern. So you can do most of the fill as just chained PUSHs, no loading. Nothing at all like a generalised solution; not suitable for most games. – Tommy Nov 5 '18 at 14:13
  • (Video of Cobra, unemulated: youtube.com/watch?v=4fU1RjYgsj8 ) – Tommy Nov 5 '18 at 17:01
  • @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 '18 at 21:16
  • I've seen this cited as running at 50Hz, no caveats, in a bunch of anecdotal places and am inclined to believe that because — as you say — there's actually quite a lot of time to achieve a 50Hz scroll if you're using write-only construction of a frame. But alas all the Youtube videos I can find are recorded at 25 fps (or, yuck, 30) so that avenue of investigation is seemingly closed. I'll try a more thorough search. Frame-by-frame inspection of the Youtube confirms "at least 25" though, so that's something. – Tommy Nov 5 '18 at 22:00
  • 1
    How about the author's own admission? worldofspectrum.org/forums/discussion/comment/418796/… – introspec Nov 5 '18 at 23:06
6

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.

  • 1
    Not to mention that all too often market realities meant that teams developed a Spectrum version, then posted 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 '18 at 22:26
  • @Tommy, s/posted/ported/, presumably :-) – user6464 Nov 4 '18 at 23:08
  • Ugh, yes. Typed on a phone though, so I guess my phone disagrees. – Tommy Nov 4 '18 at 23:14
  • 2
    So the memory layout is basically interlaced chunky. – snips-n-snails Nov 6 '18 at 3:42
6

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.

  • 3
    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 '18 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 '18 at 18:40
  • 1
    @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 '18 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 at 18:47
  • Another recent production: Pinball Dreams Amstrad CPC (Preview) - YouTube. – Stéphane Gourichon Feb 17 at 19:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.