AMSTRAD CPC - TO SCROLL OR NOT TO SCROLL

I used to think it was strange that Commodore 64 and Speccy owners always claimed that their respective machines were far superior to the Amstrad CPC? I mean, c’mon, had they seriously never seen or played the likes of Wec Le-Mans, Robocop, ChaseHq, Sorcery+ and Rainbow Islands on the CPC?

The C64 versions of Chase HQ, Continental Circus and Wec-Le-Mans look, and churn along, like a badly curled poo! For sure, there are plenty of examples of this being the case with the CPC (Out Run), and likewise with the Speccy. But I don't want to get too lavatorial or reduce this article into 8-bit zealotry. Instead, I’d simply like to air my frustrations and thoughts in order to quantify and better collect all the facts.

Undoubtedly, the Amstrad is the machine of personal choice for me, it left me with some of the best and worst memories (Green Beret), and it was, and still is, a very pleasant machine to program and play games on. One of the biggest complaints I hear about the CPC is that it can’t scroll properly. So here's a look at how Amstrad’s specs stack up, I think that'll help to better understand the machines good and bad points:

The Amstrad had a 4 MHz Z80 based CPU (but only actually gave around 3.3 MHz for programs), with 64K of Ram and 3 different modes: 640x200@2cols, 320x200@4cols, 160x200@16cols, I believe each mode uses exactly the same amount of data for the screen buffer (16k), regardless of the colours on screen or resolution, and there is no hardware support for the software sprites. If we compare the screen to the Commodore 64’s (1k) character mapped screen, you’ll suddenly notice that the CPC has a much bigger, i.e. heavier screen, to contend with, and minimal hardware assistance - which really counts for nothing in this scenario, but I’ll come back to that later. The 16k screen size is definitely a problem, and the programmer of old was left with only a few choices.

In order to reduce the impact of a heavy 16k screen, the programmer could reduce the game playing window in size (as seen in Robocop), or by scrapping scrolling altogether in favour of a static flip screen, as seen in many games such as Renegade and Gryzor. However, there’s usually no smoke without fire, strange but disgustingly obvious, so try to remain calm when I merely suggest that the CPC is seriously out of its comfort zone when it comes to side-scrolling, I mean smoothly at 50FPS. Well, that’s probably bending the truth a little – it’s, in fact, the worst by a country mile. Well, that's almost true. Sure there's some assistance from the hardware, and in some cases it's useful, but when you realise the hardware scroll’s a full screen, at four pixels a push, at 50 fps, you kinda get that sinking feeling. In other words, programming an ultra-smooth, full-screen shoot-em-up on the CPC 464 is probably nigh on impossible. Kinda hard to swallow, isn’t it?

You could say every system out there had its own set of problems. Look at the Sega Saturn, it could easily do 2D graphics like no other console before it, but throw a 3D game at it and suddenly the programmer was presented with a massive challenge, a challenge that only a few programmers in the world were up to. There were some exceptions, just look at Sega Rally… but it took huge amounts of money, effort and time to achieve such results. Basically, it was a heck of a lot easier and cheaper to do 3D games on the Sony Playstation.

Don’t slit your wrists just yet, it’s probably not as black and white as I'm suggesting. When it comes to vertical scrolling, the CPC can fine scroll with a little bit of trickery, see games like Mission Genocide and Warhawk, but it's clear the same rule applies when implementing the software sprites. It'll be interesting to see if newer games can pull off a single pixel scroll, but even if they do, it'll be moving in steps equal to one multicolour pixel, whereas on the C64, a shoot-em-up would usually fine scroll in increments of one hi-res pixel. However, although complicated – there were programmers late into the CPC’s life who kinda discovered how to push a little more out of the old CPC hardware (A natural progression and true of all the other 8-bits). For emergencies such as this, here's an easier explanation, I think? Imagine we had a CPC side scroller running with the limitations highlighted above and at 50fps, the object (sprite) would enter and then leave the screen in just under one second, (blimey, blink and you'll miss it action). On the surface, it seems as though the CPC can cope, but I'm not convinced this is the case as the hardware doesn't really lend itself to side scrolling games, for instance, how could you possibly play a shoot-em-up where the enemy ships flew by in less than a second. Now if that wasn’t bad enough, we also need to take into consideration the impact on memory and CPU due to the size of the 16k screen, and so forth with the bits per pixel being used, everything soon adds up.

CRTC based 'jiggery-pokery' is possible but it all comes at the cost of memory, and in theory, a CPC 464 with 64K would need really tight code to prevail. Star Sabre, Fres Attack, Dead on Time and Sub Hunter are probably the closest examples I can think of, but these games, with the exception of Fres Attack, only manage around 25FPS using a similar technique. In other words, and at risk of repeating myself, to have smoother scrolling in a game, with a high frame rate, you’d need to mess around and buffer the screen with an offset of one or more pixels using the CRTC tricks. I'm informed this drastically chomps away at the memory, and would inevitably force the programmer's hand towards reducing the size and overall quality of the game. I’ve also read a few rumours (still unproven) that a CPC fully equipped 128K machine, could in theory, use a technique called 'quad buffering', with the display set at mode 0 graphics, the hardware takes care of scrolling down to a four pixel resolution, the four buffers shift it finely, and the whole thing moves at one pixel a frame. I’m not sure how you’d get the CRTC to see the extra 64k of RAM, normally it’s restricted and can only see the first 64k of memory. Maybe if the area was fairly small to scroll, the 4 screens would, in theory, use the main bulk, i.e. 64K of initial memory, then the programmer would somehow put the stack/restart block into the other bank, and map things into the extra extended 64K of usable RAM. This, I imagine, would probably require some clever bank switching, and interrupt updates.

A massive problem using this method might be when you try to draw pixel aligned background tiles and sprites all moving at the same time, and it doesn’t help that using 4 whole screens leaves you with zilch for memory. Another issue might arise if you needed to display a score panel, so not the sort of task even the best of programmers would take on lightly. Despite all the above doom and gloom, the Amstrad is home to many great arcade conversions and original games. I hope this article goes some way to explaining things, writing it all down has certainly helped me in regards to the fundamental and bigger picture. I'd certainly welcome your thoughts on such a subject, what is for certain is that the programmers responsible for programming the best games on the CPC, especially considering everything discussed above, were in all respects of the word, simply genius.