------------------------------------------------------------------------------- PROBLEM ATTIC ------------------------------------------------------------------------------- We've had a lot of letters in the Problem Attic postbag this month asking about hardware scrolling, and how it can be used in Basic programs. Well, this is rather too complicated a subject for a straightforward three-paragraph reply - three pages would be more like it. Normally at such times we just mutter 'Not enough space' and move on to the letters we can answer briefly. It's a pretty interesting subject though, and it neatly ties in with a letter in last month's PA about Ghosts and Goblins. Just this once then, we're going to give a complicated subject the space it needs - but you needn't think we're going to make a habit of it. Vertical scrolling is very easy, and there's no real problem adding it to Basic games. This program illustrates scrolling the screen up and down. [Listing - VSCROLL.BAS] [A correction to this listing was published in the December 1986 issue (#15), which fixed an error in line 10; "POS(0#)" should have read "POS(#0)".] This doesn't do anything very impressive, 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 Basic 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 what I mean: [Listing - HSCROLL.BAS] As you'll see if you run this, Arnold can't cope with the changes you've made. All printing carries on as if the screen was still unscrolled. To get your screen back to normal you can either type MODE 2, or force a vertical scroll using the cursor keys. This last point is another reason why the OUT method of horizontal scrolling 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 properly. NON-TECHNICAL To start with, here's a Basic 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. [Listing - HSCROLL2.BAS] 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. BOFFINS ONLY 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: scleft: CALL &BC0C ;SCR-GET-LOCATION ;No entry conditions -- on exit, HL ;contains the current 'screen offset'. INC HL ;Increases HL INC HL ;by two. JP &BC05 ;SCR-SET-OFFSET ;Value in HL is used as new 'screen ;offset'. The second one's the same, but with DECs instead of 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 scoll 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. GHOSTS AND GOBLINS Yes, it's that horrifying saga of colour modulators producing black-and-white pictures again. This isn't a change of subject though, since it turns out that a clever scrolling technique is the culprit. For those who missed last month's Problem Attic, the tale goes like this. Software house Elite produced the AA Rave game Ghosts and Goblins a couple of months back, believing it to be compatible across the CPC range. Imagine their (and our) surprise when it turned out to be incompatible with Amstrad's TV modulator, producing only a black-and-white picture even on a colour TV set. Compatibility problems between machines happen all the time, but this was the first time we'd heard of modulator problems. The modulator simply converts the RGB (red-green-blue) signal meant for a colour monitor into the modulated 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 90 CALL &BD19 100 OUT &BC00,3:OUT &BD00,5 110 CALL &BD19 120 OUT &BC00,3:OUT &BD00,&8E 130 NEXT a 140 MEMORY oldmem [The modified listing is saved as HSCROLL3.BAS.] This looks ugly, and would probably give you a headache 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 does, so the next question is 'Why?' Pixel detail from Ghosts'n'Goblins [Screenshot of Ghosts'n Goblins] PROBLEMS WITH SCROLLING A couple of issues ago I made some bold statements about Arnold's hardware scrolling capabilities compared to those of other machines. In fact, Arnold's hardware scroll does have one slight problem: it's too fast. As you may remember, the horizontal scroll routines can only scroll the screen a fortieth of its width at a time. That's not just the way the routines are written: the hardware simply can't manage a smaller scrolling action. Fast scrolling on Vortex's TLL [Screenshot of TLL] 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 are 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 gameplay, 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 cases 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 'SOLUTION' The aim in Ghosts and Goblins was to provide a slow hardware scroll, so that the 'burst' 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: [Listing - HSCROLL4.BAS] 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. Green Beret uses Burst scrolling [Screenshot of Green Beret] 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 screen to the left by an eightieth. After another fifieth 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 won't 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 see 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 appears on the glass tube of the monitor. NOW YOU TRY IT 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 blurred columns at each side alternately - 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 border 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 to Type-Ins? 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! BUT BEAR IN MIND ... 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 at the PCW show put it down to the poor quality of the Amstrad units. If this is true it's not exactly surprising: after all, Amstrad keeps costs down by cutting specifications fine. The modulator works okay for normal purposes, and 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 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. /\ / \ / \ T Y P E I N S /________________\ POSTER MAKER Ingenious program, this, from PETER DOEL. It produces a giant printout of whatever you've got on the screen, using eight sheets of normal continuous stationery. The printer uses the computer's normal character set, so that when you look at the printout close up you can barely make out what it is. But stick the pages together, walk away 20 feet, then turn round and look and...WOW! You can change the 'contrast' in your giant picture by altering the characters separated by commas in line 240 - each of these characters corresponds to one of the 16 possible screen colours. The program starts at line 100, and if you just run it as it is, it will simply produce a magnified printout of the text that's on the screen. A better idea is to add some more program lines below line 100 to create something interesting on screen, even if it's just loading in a loading screen from a game. 10 MODE 0:FOR i=2 TO 13: PEN i:PRINT" AMSTRAD ACTION":PRINT"":NEXT Adding this line creates one very simple screen display for turning into a poster. You could replace it with any other graphics routine, for example one which loads in a screen display from a graphics package or (if you're clever) the title screen of a game. [Listing - POSTER.BAS] TORUS Here's another of those listings that take three minutes to type in, yet give a very, very pretty demonstration of the Amstrad's graphic capabilities. In fact the program takes longer to run than it does to type in! Nice one, ROGER WILSON of Blackburn. [Listing - TORUS.BAS] SIMON You probably remember the game in which you have to remember a sequence of coloured lights and sounds and repeat it. This is that game. Simple, but challenging and surprisingly addictive. This program mimics the game very nicely indeed, giving you a choice of two playing speeds. So, with your Amstrad you can copy a game that took the Christmas market by storm ten years ago at a cost of £20! Our thanks to T MAGEE of Marlow, Bucks. [Listing - SIMON.BAS] [Amstrad Action forgot to mention that Simon only works on CPC664 and CPC6128 machines. An apology was published in the December 1986 issue (#15). There is also a minor bug: when entering the playing speed, you must enter F or S in upper case. The program does not accept lower case letters. Amstrad Action did not print a correction in any subsequent issues.] [The letter below was published in the "Re-Action" column in the Christmas 1986 issue (#16). Amstrad Action offer another apology regarding Simon, in addition to the one that was published in the December 1986 issue (#15).] Simple Simon Oh, dear me, you've made a boob. In the November type-ins the Simon program had four errors in it. Or was this written on a machine other than a 464? Daryl Wardle Wentbridge, Yorkshire Yes, Daryl, we flubbed it. We omitted to say that Simon was for the 664 or 6128 only. [The letter below was published in the "Problem Attic" column in the July 1987 issue (#22). Amstrad Action suggest some alterations to Simon to make it work on CPC464 machines. However, the game still does not work properly because some CLEAR INPUT commands are still present. Also, the modifications remove the colour from the game, which makes it much more difficult to play, as the player must rely on sound alone, instead of sound and colour.] Simon says... AA 14 had a listing called Simon Says. Having typed it in and run it numerous times, I keep getting a syntax error in line 280. Why is this? The line reads: +-----------------------------------------------------------------------------+ | 280 BORDER 0:INK 0,0:INK 1,26:INK 2,6:INK 3,24:INK 4,18:INK 5,2:MOVE 0,0,1: | | RETURN | +-----------------------------------------------------------------------------+ I've given up in despair and wonder if there is a typing error. My machine is a 464. Mrs J Wandless Newcastle-upon-Tyne There is nothing wrong with your typing or the listing. The problem lies with the computer. Don't panic: your machine is not faulty. The listing is for the 664 or 6128. At the time we did not realise this and did not mention it in the text. If you want to use the program on the 464, alter the lines below. Note, however, that you won't get the same display - which may make the game awkward to play. +-----------------------------------------------------------------------------+ | 280 BORDER 0:INK 0,0:INK 1,26:INK 2,6:INK 3,24:INK 4,18:INK 5,2:MOVE 0,0: | | RETURN | | 290 FOR d=1 TO 4:MOVE d*100,250:DRAWR 75,0:DRAWR 0,-75:DRAWR -75,0:DRAWR | | 0,75:MOVER -10,10 | +-----------------------------------------------------------------------------+