★ DEMOSCENE ★ DEMOS ★ Amstrad Computer User ★ |
| Snow fun (Amstrad Computer User) | Demoscene Demos |
John Kennedy tries to inject some early seasonal cheer. As winter closes in and the season of goodwill, presents, alcohol and TV repeats approaches (and only seven weeks to go before Christmas) I thought I would write a little program to delight all those of you with an interest in silly graphic routines. The machine code I proudly present you with will scatter any display you wish to put on the screen with liberal quantities of snow. What is more, you have a choice of two different types: synthetic snow or the real, settling, white stuff. Synthetic snow is the sort of snow you see on television. You know the kind I mean; actors come in from a sudden snowstorm covered from head to foot in a white powder which has completely vanished by the next scene. (This is not to be confused with dandruff.) The real stuff will settle into huge heaps that have to be cleared away in the morning with a quick CLS or MODE statement. As a special treat, not only have we listed the customary assembly language listing for you to type into the assembler you are hoping Santa will bring, but we have even given you a complete Basic program that will produce a pleasant little display for you. The Snowstorm program is a perfect example of modularisation and the speed of machine code over Basic. Writing a similar program in Basic would be a waste of time, as the snow would seem to be crawling around like bacteria instead of drifting smoothly down the screen. First we must decide on the number of flakes and how they will be moved. I have chosen to animate fifty flakes, for no particular reason. Instead of using an X and Y co-ordinate to describe their position on the screen, we will use their Screen Address. As you will no doubt be aware from previous discussions, the screen is simply an area of memory that also happens to appear on a visual display unit. By writing directly to this memory we influence what appears on the screen. Writing directly also speeds things up considerably and allows fifty snowflakes to move with no discernable effort whatever. A table of one hundred bytes is reserved to store all the screen memory address we will use; one of the first things the program must do is initialise this table, by making up random screen addresses. The very first thing the program does, however, is draw a line at the bottom of the screen to stop the snow drifting away and corrupting memory left, right and centre. We have two main problems to overcome. The first is how to move the snow down the screen. How do we calculate the new screen address? The second problem is how to find out whether the snow has hit the ground or an obstacle. The answer to the first problem has thoughtfully been provided in a routine which already exists in the computer's operating system. All we have to do is load the HL register pair with the old screen address, call the magic routine and voilà! The new screen address is magically calculated for us. The second problem is of a slightly more taxing nature. Obviously to decide if the flake has hit something we will have to examine the screen memory at its address. Unfortunately, this presents us with a further small problem. Examining the memory by attempting a LD A,(HL) instruction will not work. This is because it just so happens that a ROM is sitting right slap-bang over our screen memory! Tragedy! How can we read the screen RAM when all we can discover is the contents of an irrelevant ROM? Again the operation system comes to our rescue by providing a special routine to do the job for us. This time the routine is a bit special and is not of the common or garden CALL & address variety. Instead it is what we in-the-know refer to as an RST or RESTART instruction. RESTART instructions are special ‘definable op-codes'. To those of us %vho prefer speaking in English, this means that when the system engineer was designing the way in which the Amstrad CPC was going to work, he decided what would happen if one of these special RESTART instructions was executed. These are, of course, completely different to all the other instructions that the Z80 uses; they are all totally pre-programmed and can on no account ever be changed, not even by me. There are several of these REST A RTS, imaginately numbered from 0 to 7. The codes that you would type into your assembler are therefore RST 0 to RST 7. (Note! Some assemblers are a bit picky about this and may try to number the RESTARTS 0,8,16,24,32,40,48,56.) Anyway, the RST instruction that we are going to use is number 4, and this does a LD A,(HL) with all the ROMs switched off. We may return to RESTART number 6, which has no special function and which is available for us to experiment with. So we have now solved the problem of looking to see if the snowflake has hit anything. If it has not, then we can continue as before; if, however, something has got in the way, we jump out of the loop and into a routine called HIT, in order to decide what to do next. One instruction here is commented out, and it is this one that determines whether you are using real or synthetic snow. When the line is in place, it will draw a heap of snow on whatever has been hit; otherwise the flake will completely vanish. The choice is yours - unless you do not have an assembler, of course, in which case you are stuck with the fake snow supplied in the Basic listing. Try typing in the Basic program and loading in some drawings of your own. Using snow on some digitised pictures will produce some extremely strange results! See you next month!
|
