17

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 1-bit per pixel video memory map. These games performed very poorly on the Amstrad machines. Why was this? Poor programming, or other limitations of the CPC?

Mark Williams
  • 4,062
  • 1
  • 23
  • 50
  • 2
    Pedant's point: the CPC supports hardware scrolling, but non-obviously. Of the contemporaneous releases, see e.g. Warhawk http://youtube.com/watch?v=sF6LC-4xeZI for a vertical scroll or Super Cauldron http://youtube.com/watch?v=nMTiqVCuBGw for a horizontal (albeit a nudge scroller). http://cpcwiki.eu/index.php/… has some exposition and a very incomplete list of titles that use hardware scrolling. https://www.youtube.com/watch?v=JiJ8Aejj7Fg is a modern take. – Tommy Nov 05 '18 at 23:59
  • eight directions? –  Nov 06 '18 at 14:42
  • 3
    @JanDoggen, 4 compass points and 4 diagonals – TonyM Nov 13 '18 at 21:21

4 Answers4

18

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.

Toby Speight
  • 1,611
  • 14
  • 31
introspec
  • 4,172
  • 1
  • 19
  • 29
  • 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 05 '18 at 14:13
  • 2
    (Video of Cobra, unemulated: https://www.youtube.com/watch?v=4fU1RjYgsj8 ) – Tommy Nov 05 '18 at 17:01
  • 2
    @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 05 '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 05 '18 at 22:00
  • I cannot argue with a bunch of anecdotal places. So I would like to put my reputation on the line and announce here an anecdotal place stating 25Hz frame rate in "Cobra" and pretty much every other relevant Jonathan Smith game on Spectrum (i.e. "Firefly" or "Hysteria"). I do not recommend trying to verify my claim via YouTube because it is the worst possible source for reliable videos possible. Use any good emulator instead. – introspec Nov 05 '18 at 22:38
  • I'm not asking you to argue with anecdotal data, I'm saying that we seem to have differing impressions and that if there were a 50hz capture that would allow an objective resolution — with a direct reference, which is even better than "I tried it, and I got this result". I am unaware of an emulator with frame stepping for my chosen platform but if necessary will video one and step through that. Not because I necessarily believe that 50Hz is correct, but because this also is just an anecdotal source and producing hard evidence will help to prove it. – Tommy Nov 05 '18 at 22:48
  • 1
    How about the author's own admission? https://worldofspectrum.org/forums/discussion/comment/418796/#Comment_418796 – introspec Nov 05 '18 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 05 '18 at 23:14
  • This is a good question for meta. I know fact X because I disassembled games etc, but how do I prove fact X, if someone comes with an opposing claim? I was lucky to remember that Joffa talked about Cobra on several occasions; in most cases I won't be quite as lucky. So, why do I have to carry the burden of proof vs places that you do not even provide link to? Esp. since my claim is trivially verified in about 2 minutes by recording a 50Hz video in an emulator? – introspec Nov 05 '18 at 23:22
  • agreed on the Meta issue; not sure about the accusative tone though, given my earlier comment "I am unaware of an emulator with frame stepping for my chosen platform but if necessary will video one and step through that. Not because I necessarily believe that 50Hz is correct, but because this also is just an anecdotal source and producing hard evidence will help to prove it." — to my mind that's pretty explicit that I don't see either of us as necessarily having the burden, and that I had planned to invest effort on resolving the disparate claims. Maybe I'm misreading you; apologies if so. – Tommy Nov 05 '18 at 23:25
  • No worries, I just was a bit shocked by your "am inclined to believe that" comment, because in my mind that placed me into a situation where your comment 1. invalidated my claim and 2. also made it sound unreliable vs unspecific multiple other sources. Hence my somewhat strong reaction. – introspec Nov 05 '18 at 23:37
  • 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 https://www.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 05 '18 at 23:51
  • I'm pretty sure some of the Defender-style sideways scrollers on the Speccy were fast. Ones that just drew a vague terrain, starfield, enemies, and bullets, with no bitmap tiles. But those are probably from the days before anyone synched screen drawing with the CRT beam, so not 50hz framerates for a dfferent reason. – hippietrail May 03 '20 at 04:41
  • @hippietrail, no disrespect but I don't trust most people's ability to reliably tell the difference between 25hz and 50hz updates. Moreover, if a coder is unaware of 50hz sync, the chances that the rest of the code is efficient enough to run at 50hz are very slim. Overall, give particular examples and we can talk. Otherwise, the stats on average frame rates in Speccy games are definitely on my side. – introspec May 03 '20 at 08:04
  • @introspec: I don't even trust my own ability. I wrote some simplistic refresh-synced scrolling code on the Speccy 35 years ago, like scrolling 8-pixel tall lines of text. Cobra came out after I'd moved to the Amiga but looking at videos of it the scrolling looks 25fps to me but it's harder for me to tell if the sprites could 50 or 25fps. The game that blew my mind for smooth fast graphics was Starion. I disassembled parts of it and it was the first game I saw using the stack for fast screen clearing, and possibly drawing from an offscreen buffer. – hippietrail May 03 '20 at 12:26
  • For games fast enough to be 50hz but ignoring the raster beam, most of Ultimate's pre-isometric games looked that way to me. A lot more screen tearing that slow downs, until there were too many sprints of course. – hippietrail May 03 '20 at 12:28
  • @hippietrail, none of them are scrollers... There are definitely many games with 50Hz updates on ZX Spectrum if the background can be kept static. – introspec May 03 '20 at 12:51
11

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.

John Dallman
  • 13,177
  • 3
  • 46
  • 58
  • 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 04 '18 at 22:26
  • 2
    So the memory layout is basically interlaced chunky. – snips-n-snails Nov 06 '18 at 03:42
  • 1
    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 01 '21 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. https://acpc.me/ACME/DOCS_TECHNIQUES/The_AMSTRAD_CPC_Firmware_Guide%28Bob_TAYLOR_Thomas_DEFOE_1994%29%28ENG%29.pdf ). – Stéphane Gourichon Mar 06 '23 at 23:02
10

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.

Laurent Giroud
  • 388
  • 3
  • 9
Stéphane Gourichon
  • 801
  • 4
  • 14
  • 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 '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
  • 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 '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 '19 at 18:47
  • Another recent production: Pinball Dreams Amstrad CPC (Preview) - YouTube. – Stéphane Gourichon Feb 17 '19 at 19:58
  • When viewing a video featuring frame-accurate effects, you have to set your screen refresh to 50 Hz (or a multiple, like 100Hz) to really see the perfect smoothness of the scrolling (or even the dithered color shades) properly. I just did, and the difference is spectacular. – Stéphane Gourichon Feb 17 '19 at 20:01
3

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.

Mark Williams
  • 4,062
  • 1
  • 23
  • 50