Breathe fresh life into your graphics. With Alan Mynett's animation routines, you can store enough frames to produce some superb sequences.

With careful programming, it is possible to increase the number of whole screen frames on a 48K Spectrum beyond the normal five and use these to create spectacular animation sequences.

You can do this either by using part screens or more generally by the use of a simple data compression technique.

A short machine code program is described here which allows the storage of a large number of animation frames and permits their successive replay. An accompanying Basic program is provided for use with the machine code. And things are followed by a simple demonstration program which creates a 32-frame animated sequence.

The 48K Spectrum, with its 40K of user available memory, can hold five full screens, including attributes, at any one time. This allows for a Basic driver and the necessary machine code routine to do the copying of bytes into the display file.

Program 1 is a loader program for a general purpose byte-moving routine. Although Program 1 loads it into the UDG area above RAMTOP, it could go anywhere. It is called from a Basic program by the line:

RANDOMIZE FN m(from,to,bytes)

The function is defined with:

DEF FN m(a,b,c)=USR address

The address is the location of the machine code. The variables from, to and bytes are the locations of the stored bytes, the display file address (16384) and the number of bytes (6912) respectively.

The function is used to pass parameters to a machine code routine. Remember that when you include a DEF FN command in a program, storage space for the parameters is set up in the Basic line. When the program then encounters the use of the function, the values of the parameters (either numbers, variables or expressions) are temporarily stored, in five byte numerical form in the Basic line containing the function definition. The address of this storage area is kept in the system variable DEFADD at 23563.

The assembly language version is:

LD IX (DEFADD)
LD L (IX+4)
LD H (IX+5)
LD E (IX+12)
LD D (IX+13)
LD C (IX+20)
LD B (IX+21)
LDIR
RET

When the routine is called, the address of the function parameter location is loaded into the IX register. The bytes at four and five locations further on hold the first parameter in the order low byte, high byte. Similarly, displacements 12,13 hold the second and displacements 20,21 hold the third. These bytes are loaded into the HL, DE and BC registers prior to a block move instruction.

The problem with storing whole screens is that five is usually not enough for smooth animation. Very often the need arises to scroll through many more screens. One simple solution is to restrict the animation to just one third of the screen area. Again the function call of Program 1 can be used. The relevant values for the variables to and bytes are shown in Figure 1. Since we can keep three part-screens in the space occupied by one whole screen, the number of frames rises to 15.

Remember, however, that because of the parallel attribute file this can also be done in colour by making two function calls for each frame - one for the pixel information and the second for the attribute information.

Suppose though, we can't restrict our animation to just one third of the screen. It is still possible to increase the number of frames? The answer is yes - if we store, not the whole screen, but the differences between successive screens.

The key to how this can be done is the Exclusive OR (XOR) operation. An example should make this clear. Let's assume that we have two screens in the computer's memory. Let's call them A and B. We can compare two equivalent bytes in the two screens by XORing the byte in screen A with the byte in screen B.

If the two bytes are the same then the result of this operation will be zero and we need take no further action. If the bytes are different then the result is a byte which is, in effect, a measure of the difference between the two screens.

Suppose:

Now, if we have screen A in the display file and the XOR result in memory, then a second XORing will reconstruct the screen B byte as we can see from:

So, in order to achieve an animated sequence the computer needs to contain the starting frame in full, but for each successive frame only a list of display file addresses and the XOR result of each byte which has to be changed.

Provided that the changes to be made are less than one third of the total screen bytes (each difference is stored as two address bytes and one resultant byte), a considerable increase in the number of frames is usually possible.

Program 2 contains the necessary machine code routines to implement these ideas. CLEAR 26754 and then type in the program and run it. Once the program runs satisfactorily the machine code can be saved using:

SAVE "squeeze" CODE 26755,97

This machine code contains three routines. The routine at 26755 performs the XOR on the display file and a screen in memory at 26864. It stores the display file address of any non-zero result together with the result in a file from 33776.

The routine at 26810 reads this memory store and carries out the reconstruction of successive screens. The routine at 26840 is a move bytes routine to shift the screen at 26864 into the display file.

Program 3 is a Basic control program which allows the construction of files of compressed screen data using the routines in Program 2. Type it in, run and load in the previously saved machine code. The Basic and code can be saved together by a GOTO 9999.

To use the program, you will need a tape containing all your animation frames one after the other. Run the main program and when asked to load the first screen start the tape and let it run.

One word of warning - to prevent damage, headers are printed on line 24. This is made possible by the poke in line 1080. Do not try to break during the load or you will crash the program. Once completed, the whole file can be saved.

To see the completed animation use Menu option 2. Option 2 is written as a subroutine so that it can be easily removed for use in any other program by removing REMs at lines 2010/2020.

For a demonstration, Program 4 produces 32 frames for an animated sequence. Type the program into the computer and place a C60 tape into the cassette recorder. Start the tape recording and run the program. It is not necessary to press any keys since the POKE 23736,181 bypasses the 'Start Tape' message.

It takes about 25mins to generate and save the 32 screens. This tape can then be used with program 3 to make the animation file.