Animation [ This was a series of two articles by the same author, both dealing with animation through direct storage and recall of whole screens. Both articles are below. You should also have a TZX file with all the programs, and some screen shots representing the illustrations that went with the articles. Most of these consisted of the screens used in the programs themselves; I wasn't going to put these on the TZX a second time, but in the pro- cedure described it turned out to be necessary to have them on some TZX, so I decided it might as well be the same one.] Moving pictures Is your Spectrum inanimate? Mike Rapps demonstrates how to put it through the motions One of the significant advantages of the 48K Spectrum over its 16K little brother is the ability to store and recall four or more screen displays. The recalling of such screens, using a short machine code routine, can result in very effective animation displays. Use is made of the powerful LDIR instruction, which recalls an entire screen in a fraction of a second. Interchanging the screens rapid- ly in this manner gives rise to the animation effect. The technique is illustrated by two examples, first a simple representation of an internal combustion engine piston and, second, a practical application turning your TV into a very workable disco light set. The technique is limited only by the user's imagination. The screen storage program which enables screens to be stored safely above RAMTOP is shown in figure one. The data for the store routine is contained in line 100 and that for the recall in line 110. Lines 220 and 230 calculate the POKE values which are necessary to adapt the routines for the various individual screens. Each screen, including its attributes, occupies 6,912 bytes. For security and conve- nience they are stored 7,000 bytes apart and start at bytes 33,000, 40,000, 47,000 and 54,000. Enter the storage program and SAVE it. [It's on the TZX as "Storage".] To produce flicker-free animation, it is important that each screen is based on a template which remains constant. The template for the "piston" program is shown in figure two. That was produced using the Melbourne Draw program, which is also very useful at a later stage when adding details and attributes to the individual screens. Similar professionally-produced programs would no doubt serve as well and home-made drawing programs could suffice. [This is on the TZX as "piston tpl". My version, which is somewhat cruder than the original, was made in... Gilsoft's PAW! In case someone wants to improve on it, the PAW database is also on the TZX.] Once the template has been produced it should be saved on tape as a SCREEN$. It can then be re-loaded and modified to produce the four individual screens, adding details and attributes as necessary - for the "piston" screens see figure three. They should also be saved on tape, sequen- tially, as individual SCREEN$. ["piston 1" ... "piston 4".] We need a program to control the animation. The program for the piston animation, which can easily be adapted for other uses, is shown in figure four. Lines 100, 110, 120 and 130 call the machine code routine to supply the various screens in order. That is achieved by poking into the fifth and sixth bytes of the recall routine - see line 110 of the storage program - the following values relating to the addresses from which the screen is being recalled: Screen Poke Poke start byte fifth byte sixth byte 33,000 232 128 40,000 64 156 47,000 152 183 54,000 240 210 The overall effect is that the four individual screen eventually will be recalled sequentially, producing an animation effect. As a refinement, the program has been modified to give two options. Either it will run slowly, allowing the individual screens to be seen and labelled, or it will run at speed, in which case it appears to rival the original. Once the control program has been evolved, it should be saved - SAVE "" LINE 999 - at the beginning of the tape which is eventually to be used for the whole program. Leave the tape set at the end of the program, clear the computer, LOAD the storage program and RUN it. With the storage program running, return to the tape on which the four screens are saved. Load the first of them and activate the storage routine with GO TO 200 - do not use RUN, since that will clear the screen, which is some- what counter-productive. In response to the prompt, store that screen with storage number 1. Then CLS [or not, since the next step is:] load the second screen and store as number 2. Repeat the procedure for the third and fourth screens. Once that has been done, return to your main tape and, immediately after the control program, save the block of score which includes the four screens. That should be done as SAVE "name"CODE 32000,29000 - see line 999 of control program. That will pick up the recall routine automatic- ally, stored at byte 32,000 onwards, which the control program will use. The tape can then be re-wound and the program run automatically. [The program is on the TZX as "Piston", and autoruns to load "pistons"CODE.] An interesting variation is used in the program listed in figure five. The procedure is largely the same, the program being saved on tape and followed by the block of code, including the recall routine and four screens. The template for those screens consists of a screen produced by the following CIRCLE commands: 39, 40,32 127, 40,32 215, 40,32 39,135,32 127,135,32 215,135,32 The six circles thus produced simulate disco lights and each is filled with a different INK colour in each indivi- dual screen, so that a flashing effect is produced - my view is that a block PAPER background produces the best effect. [This program is on the TZX as "Disco".] Once the program has been saved and is running it con- trols the flashing effect by using the value of up to 255 returned on the computer EAR input socket, using the simple machine code routine contained in subroutine 400 to deter- mine it. Each time the value jumps by three or more from its previous value, line 115 calls in the next screen by means of the main subroutine - line 500 - and various subsidiary subroutines - lines 1000-1310. The figure of three is obvi- ously adjustable but appears to produce the best results. With the program running a musical input can be directed through the EAR socket and at a suitable volume will pro- duce the flashing effect, controlled by the beat of the music. The difficulty with using a cassette player is that the use of the EAR socket on the player cuts out the loud- speaker, which is somewhat self-defeating. On my player, the jack plug can be manoeuvred into a half-in, half-out position, which allows both functions simultaneously but that is somewhat precarious. I have produced a much more satisfactory arrangement on my music centre where I have run an extra two-core sound wire out of one of the loudspeakers, terminating it with a standard Sinclair jack plug which can then be plugged into the Spectrum EAR socket. The music centre is thus effec- tively interfaced through the Spectrum to the TV. ___________________________________________________________ Night moves Mike Rapps brews up a midnight storm using machine code animation In the August issue of Sinclair User we investigated simple machine code routines to store and recall, virtually instantaneously, a number of different screens of graphic information to produce simulated animation. This month we will explore further the possibilities of animating scenes on the 48K Spectrum. The end result is a visual effect which, hopefully, is both interesting and entertaining. One problem of exploring the technique is that the pro- gram which controls the animation is related very closely to the actual screens on which it operates. As these are stored as a literal SCREEN$ it is obviously impractical to convey them exactly. However, illustrations of the three screens used initially appear in Figure 1, and for those who wish to reproduce the screens used, a second illustra- tion of the first screen with a grid superimposed on it - Figure 2 - is provided; the other two screens are, as can be seen, developments from this. [The screens themselves are on the TZX as "scene 1" ... "scene 3". They were made in the PAW, just as for the first article, and again the database is on the TZX as well. The illustration with the grid is _not_ on the TZX. If you want something similar, load the database in the PAW, modify the Graphic for loca- tion 1, and press Symbol Shift-Y.] The screens were produced using the Melbourne Draw program, and the machine code routines used are largely derived from Super Charge Your Spectrum by David Webb, published by Melbourne House. Other routines could just as well have been used to produce other effects, but the main object is merely to illustrate possibilities. The Basic control program used is listed in Figure 3. That should be typed in and saved: SAVE "storm" LINE 999. Immediately following that should be saved the block of code, a dump of which is given in Figure 4. The code is given in hexadecimal and should be read in rows from left to right. It may be entered using the short loader program listed in Figure 5, eltters to be entered in lower case. The dump contains reference numbers underlined to show the first byte of each of the various routines, and should be ignored when entering the code. They refer to the list of routines - Figure 6. When the routines have been entered, they should be saved after the Basic program: SAVE "rou- tines"CODE 32000,360. Finally, the three screens used should be assembled into a single block of code using the prodedure and the screen storage program given in the August article. That block should then be saved as the third element of the program, immediately after the routines. The screens will commence at address 33000, and should be saved: SAVE "scenes"CODE 33000,21000. Let us take a look now at how the action unfolds. It is the dead of night. One by one, the lights of the house on the hill go out. A violent thunderstorm erupts, with lightning casting eerie reflections on the house. The storm abates, the moon rises, the stars come out - even a few shooting start. As morning approaches, the lights are re- kindled. _________________________________________________________ Program explanation Line 20 Deals with the initial colour settings. Lines 30-40 The machine code recall routine at 32012 calls in the second screen as a title screen. Before it can do that, the routine has to be given two POKEs - in the fifth and sixth bytes - which tell it the start address of the screen to be recalled. A table of which POKEs is given in figure 7. A text title is printed, with a pause following. Line 60 Clears the screen, using the routine at 32320 Lines 90-100 Supplies fresh POKEs to the recall routine and calls in the first screen. Line 110 Prints three lit windows on house Line 120 Pause, then re-calls first screen Line 130 Prints two lit windows on house Line 140 As 120 Line 150 Prints one lit window on house Lines 160-170 As 120 followed by a pause Lines 200-210 Sets up an outer loop of three, so that the following action takes place three times. On each occasion, a nested loop uses the recall routine, suitably POKEd, to call in the second screen (line 200) followed by the first (line 210) in rapid succession, thus giving the "lightning" effect Line 220 A further loop produces the 'thunder' - what do you expect on a Spectrum? Lines 230-240 Pause. Return the outer loop. Line 300 Provides the POKEs necessary to use the rightward pixel scroll routine at 32025 to scroll away the clouds. The routine works on a defined rectangle within the screen. The rectangle has co-ordinates for its upper left (x1, y1) and lower right (x2, y2) corners. The x co-ordinates are the usual horizontal character positions (0-31), but the y co-or- dinates work on a pixel scale (0-175) reading vertically down the screen, not the usual PLOT co-ordinates which read upwards. The POKEs, taking s to equal the routine's start address of 32025, are: s+32, x1; s+37, x2; s+1, y1; s+23, y2. POKE 23361, 0 leaves a clear screen immediately behind the scroll. The POKEs used in the line define a rectangle which covers the clouds Line 310 Calls the routine set up in line 300 a suffi- cient number of times to scroll away the clouds, with suitable pauses to slow the action Line 320 Similar to 300, but sets the upwards pixel scrolling routine at 32150 to operate on the moon. The rectangle co-ordinates are simi- larly defined, the POKEs being: s+15, x1; s+36, x2; s+1, y1; s+23, y2. Line 330 Similar to 310, scrolling the moon Line 400 Sets up a loop for plotting the start to random co-ordinates. The parameters of the y co-ordinates are set to encompass only the upper sky part of the screen Line 410 Excludes any random co-ordinates which would plot stars over the moon Line 420 Carries out plotting of stars, with random colour, and returns loop Line 430 Saves, as screen four, the existing screen. To do that, the screen save routine at 32000 is used, with appropriate POKEs as set out in Figure 7. In the case of this routine, it is the second and third bytes which must be POKEd. Lines 500-510 Sets up UDGs for shooting stars Line 520 Sets screen recall routine to fourth screen Line 525 Sets up outer loop of six, so that there are six shooting stars, followed by a semi-random initial horizontal co-ordinate for each Line 530 Sets up inner loop of eight, and prints the shooting star on each return of the loop Line 540 After a pause, recalls the fourth screen, thus overprinting the star. The star horizon- tal co-ordinate is then decreased by one, which within the loop makes the star move diagonally across the screen. Line 550 Returns inner and outer loops Line 560 Brings house lights back on Line 570 After a pause, clears the screen using the routine at 32270 Line 600 Resets recall routine to daytime and calls in that screen Lines 630-650 Opportunity to review Line 999 The auto-run line, which sets RAMTOP to protect the code and loads the two blocks of code. _________________________________________________________ Figure 6. List of routines Start address Routine 32000 Screen save 32012 Screen recall 32025 Horizontal scroll 32150 Up scroll 32270 Screen clear (fade) 32320 Screen clear (shift) _________________________________________________________ Figure 7. List of POKEs Screen number Start address Poke 1 Poke 2 1 33000 232 128 2 40000 64 156 3 47000 152 183 4 54000 240 210 For screen save routine POKE 1 should be in second byte of routine, POKE 2 in third byte. For screen recall routine POKE 1 should be in fifth byte of routine, POKE 2 in sixth byte. _________________________________________________________