Graphic - Hardware Scroll (The Amstrad User)Coding Listings
★ Ce texte vous est présenté dans sa version originale ★ 
 ★ This text is presented to you in its original version ★ 
 ★ Este texto se presenta en su versión original ★ 
 ★ Dieser Text wird in seiner Originalfassung präsentiert ★ 

Although colour modulators have long since ceased to be imported due to incompatibility problems, there is a legacy of users in Australia who operate this piece of equipment with a separate colour television instead of the Amstrad monitor. Most will tell you that the quality is less than adequate and the graphics in games is pitiful.

With this background in mind, we can tell you that a particular problem with Elite's Ghost and Cdblus has reared its ugly head. (Don't panic - remember, we are talking about using the game through a colour TV and modulator). What happens is that the loading picture comes up In colour but when the game is started it reverts to black and white. (It works normally on a standard Amstrad system).

As the problem is caused by some clever scrolling techniques, it seems a good idea to look at scrolling in general and 'the problem' in particular.


Vertical scrolling is verv easy, and there s no real problem adding it to Basic games. This program illustrates scrolling the screen up and down.

10 x.coord=POS(0#)

This is doesn't do anything very impassive, but you should be able to get the general idea from the comments on each line.

Horizontal scrolling isn't anywhere near so easy . If you want to scroll the screen sideways from Baic you'll need to use the OUT command, which sends a number to a peripheral chip. That'll be enough to put quite a lot of people off but it isn't too difficult. The only problem is that it messes up the way Arnold writes things to the screen. This listing should give you an idea of what I mean:

10 MODE 2

As vou'll see if you run this. Arnold can't cope with the changes vou've made. All printing carries on as if the screen was still unscrolled. To get your screen back to normal you can cither type MODE 2, or force a vertical scroll using the cursor keys.

This last point is another reason why the OUT method of horizontal scroling doesn't work too well. Every time you force a vertical scroll using the simple method we started with, you undo any horizontal scrolling you've done using OUT.

Horizontal scrolling is much easier if you know a little machine-code. Two firmware routines make the programming very easy indeed, and they let Arnold know what you're doing so he can print to the screen property.


To start with, here's a program which uses the firmware routines. You don't need to know a thing about machine-code to use them, but there's an explanation afterwards for anyone who's interested.

10 DATA  &CD,&0B,&BC

The important bits of the program are lines 10 to 70 which set up the scroll routines, and line 180 which dismantles them after you've finished with them. If you start your program with the commands in lines 10-70 and finish with the MEMORY command from line 180, you can use the commands CALL scleft and CALL scright whenever you want to scroll the screen left or right.


That's all you need to know to use the routines from Basic. If you're interested though, here's how the first routine disassembles: 


The second one's the same, but with DECs instead if INCs. In other words, one increases the 'screen offset' by two and the other decreases it by two. Clearly the screen offset is the key to horizontal scrolling -increase it by two to scroll left a fortieth of a screen's width, or decrease it by two to scroll right. It's also, incidentally, the key to vertical hardware scrolling from machine-code. Increase the offset by 80 (decimal) to scroll up one line, or decrease it similarly to scroll down. This accounts for something you'll have noticed with the Basic horizontal-scroll program: scrolling left or right by a whole screenful also scrolls the screen up or down one line.
None of this tells you what the screen offset actually is, but we'd be here all day if I tried explaining that. If you're really keen to know about such things get hold of Amsoft's CPC Firmware Guide, read it and inwardly digest it. Once you've done that, you'll be ready for the technical stuff that follows.


Now on to that horrifying saga of colour modulators producing black-and-white pictures. This isn't a change of subject though, since it turns out that a clever scrolling technique is the culprit.

The modulator simply converts the RGB (red-green-blue) signal which most TV sets require through their antenna socket. For Ghosts and Goblins to mess up the modulator output, it had to be doing some very strange things with the RGB signal.

Needless to say, it was. To be precise it was moving the 'logical'screen (ie. the picture of the ghosts, goblins etc)backwards and forwards across the surface of the 'physical'screen (ie. the hard glass bit you look at). You can see this effect for yourself, with this little bit of Basic. It replaces lines 80-180 of the poked-in machine-code horizontal scroll listing, so these must be deleted before typing in the new lines.

80 FOR a=1 to 50


This looks ugly, and would probably give you a headcache if you stared at it for too long. If you're looking at it through a modulator, it should also look distinctly colourless (I don't have a modulator to test this, but I'm pretty sure of it) Now you know what Ghosts and Goblins docs, so the next question is 'Why?'

To get a smooth continuous scroll you need to make one scrolling movement every fiftieth of a second - the timing for this is handled in our scrolling programs by those CALL &BD19 statements. If there arc fifty movements per second, and they each have to be at least a fortieth of the screen width, you're clearly going to scroll past a whole new screen of landscape in less than a second.

This is too fast for anything much more than reflex game-play, though Vortex's TLL did quite well using these techniques. Another notable hardware scroller was Gremlin's Thing on a Spring, though there were slight problems at the screen edges on this one.

For the most part games programmers use either software scrolling or what you might call 'burst' scrolling. Software scroll only works well on very small windows (eg Rambo, Stainless Steel) and causes an ugly rippling effect if used on large areas - Bounder and the tank stage of Beach-Head are eases in point.

The preferred technique is 'burst' scrolling - keeping the screen fixed until the player reaches the edge of it, and then fast-scrolling the next screen into position. Prime examples of this are Green Beret and Thrust. This is still far from perfect, and it was an attempt to improve on this that brought Ghosts and Goblins its problems.


The aim in Ghosts and Goblins was to provide a slow hardware scroll, so that the 'buret' scrolling wouldn't be so abrupt as it is in, for example, Green Beret. The method used involved both scrolling the screen and moving it. If you've typed in the program so far, you can get a Ghosts and Goblins- style scroll by altering line 100 as shown below If you haven't, here it is in full:

10 DATA &CD,&0B,&BC

The OUT commands in lines 100 and 120 move the screen left and right by an eightieth of its width - you'll have seen this already if you've been typing things in and running them as you've been reading. (Note that 'moving is not the same as 'scrolling' - I'll explain the difference in a minute.) The difference now is that CALL scleft' in line 100.

The CALL in line 100 scrolls the screen left by a fortieth of its width, and the OUTs move it back to the right by an eightieth: net result, a scroll/move of an eightieth to the left-A fiftieth of a second later the OUTs in line 120 move the scrocn to the left by an eightieth. After another fiftieth of a second line 100 scrolls/moves the screen another eightieth to the left; and so on.

If you've still got the default colours on screen you be able to see this happening: it just looks like a slow smooth scroll. Set the border and screen background to different colours and you'll be able to what 's happening quite clearly - the left and right edges of the screen blur where it's being moved rapidly from side to side. Here 'moving' literally means changing where the detailed picture part of Arnold's display appeals on the glass tube of the monitor.


This method is a very nice way of halving the scroll speed without losing smoothness, and could usefully be applied to Basic versions of Scramble and similar scrolling games. You'd need to do the timing with the EVERY command rather than using CALL &BD19 or FRAME, and make sure the scroll/move commands were on a higher timer priority than any other interrupt-driven sequence you had running.

Another good idea is to blank off the blurrod columns at each side alternatively - the right-hand one at line 100 and the left-hand one at line 120. If you set these to the same colour as the bonier you cut the apparent screen width down a little, but the loss of that unsightly 'edge-flicker' more than makes up for this.

If you can make a decent scrolling game out of any of this, why not send it in? Make sure you keep it short under 3K if possible - and give it plenty of grab-factor. Otherwise it's up to you: knock our socks off and we'll print your program!


There are problems with this kind of technique. For one thing, OUTs like the ones in lines 100-120 bypass Arnold's firmware. In this case they work on all the machines I can find to try them on, but you can't run crying to Alan Sugar if you get compatibility problems - Amsoft advises software houses not to use them.

More seriously, it looks like Amstrad's modulators can't produce a colour TV signal out of this kind of monitor input. One (non-Elite) programmer I met put it down to the poor quality of the Amstrad units. If this is true it'8 not exactly surprising: after all, Amstrad keeps costs down by cutting specifications fine. Amstrad can hardly be blamed if it can't cope with Ghosts and Goblins.

That's certainly not to say that Elite is to blame: indeed I d say the company has been unlucky. I don't think anyone in the industry expected this kind of problem, and other houses are just grateful it didn't happen to them. Moral: Those who live on the cutting edge of technology will be sacrificed upon it, as Adam Osborne said. Or they get a bit of bad publicity, at any rate.

Scrolling is a fascinating subject If you feel that you could put together a series of articles covering the more advanced aspects of CPC graphics, please drop a line to the Editor with an outline of your ideas.


★ PUBLISHER: The Amstrad User (Australia)
★ YEAR: 1986
★ AUTHOR(S): ???

CPCrulez[Content Management System] v8.7-desktop/cache
Page créée en 092 millisecondes et consultée 1803 fois

L'Amstrad CPC est une machine 8 bits à base d'un Z80 à 4MHz. Le premier de la gamme fut le CPC 464 en 1984, équipé d'un lecteur de cassettes intégré il se plaçait en concurrent  du Commodore C64 beaucoup plus compliqué à utiliser et plus cher. Ce fut un réel succès et sorti cette même années le CPC 664 équipé d'un lecteur de disquettes trois pouces intégré. Sa vie fut de courte durée puisqu'en 1985 il fut remplacé par le CPC 6128 qui était plus compact, plus soigné et surtout qui avait 128Ko de RAM au lieu de 64Ko.