★ APPLICATIONS ★ DIVERS ★ Pull Down Menus ★ |
| Pull Down Menus (Computing with the Amstrad) | Graphic - Pull Down Menu (Amstrad Action) |
Pull-down menus are definitely "in" and no program of any standing can afford to be without them. For best effect the pulldown needs to be fast and smooth and this is not so easy on the Amstrad, with its slow printing on screen. One obvious solution on the CPC6128 is to store the menus in the spare RAM and to use the Bank Manager routines to copy them to the screen when required. Unfortunately Bank Manager can really only move whole screens which makes it unhelpful for single menus. Another difficulty arises from the fact that the copying is done in one continuous run from start to finish, and because of the way the screen is mapped to memory this causes the infamous Venetian blind appearance. We need a set of routines that can move the contents of a selected window between the screen and banks 2 to 5 with a nice, even pull-down. Before a menu can be pulled from one of the banks of spare RAM it must obviously first be put in there, and all this cunning is going to be wasted if the only way to do that is first print it out on the screen in full view. So it would be handy if there were a way of printing, or plotting, or whatever, directly into the spare RAM without ever going on the screen. Of course you wouldn't be able to see what you were printing at the time, but you would have tried it out on the screen beforehand to make sure that your program was properly debugged. PULLM is a suite of routines for the CPC 6128 that provides all these facilities. Program 1 enters the machine code, checks that it is correct and, when it is, saves it to disc as PULLMMC.BIN. Program 2 is the program which will load and initialise the RSXs. Typo it in and save it on the disc as PULLMRSX. The code is completely relocatable, so it can beloaded and run regardless of the value of HIMEM as long as it is not below &8000. After it has been called, the relocating routine is no longer needed and the space is reclaimed. You will now have a set of four RSXs and one CALL. The first three RSXs, |PUSHM, |PULLM and |SWAPM, move data between the spare RAM and the screen. They all have the same syntax-|PUSHM, [,1] If the stream is not specified the default value is 0. As their names suggest, |PUSHM will push data from the front screen the specified rear screen, |PULLM will pull data from the rear to the front and |SWAPM will swap the contents of the front and rear screens. Thus, |PUSHM,3 pushes the contents of window 0 to screen 3, |PULLM,2,4 pulls the contents of window 2 from screen 4 to the front screen and |SWAPM,1,5, swaps the contents of window 1 between the front screen and screen 5. As with Bank Manager you need lo be careful of the screen hardware-roll effect. You should arrange that all PUSHing, PULLing and SWAPping is done with the screen set to the same hardware position. The remaining RSX is |WRITEM, again with the same syntax, |WRITEM,1,1. This is the one that allows you to write invisibly on to one of the rear screens. It can be followed by any of the whole range of PRINT, PLOT and DRAW commands and you use them in the normal way. When the program is run you will see nothing and all the printing and graphics will he sent to the rear screen of your choice. So |WRITEM,3,1 allows you to print directly to window 3 on screen 1. But there is a price to pay for all this versatility. There are so many possible commands that it is hardly practicable to modify each one separately. Instead the trick is to intercept LOW JUMP, which is a call to address &0008 through which the Basic interpreter gains access to the firmware routines. Then we can divert all the calls through our own switching routine to bring the extra banks of RAM in and out at the right times. That deals with all the text and graphics routines, but it can make life difficult for many of the other commands that don't want to use the screen at all. You'll find that many of them won't work until ! WRITEM has been switched out again using CALL closem which is described later. For example - |WRITEM,1,3:LOCATE 3,3: PRINT"m": CALL closem: WHILE INKEY$="": WEND will work perfectly, where as: |WRITEM,1,3:LOCATE 3,3: PRINT"m": WHILE INKEY$="": WEND: CALL closem will cause the computer to hang. In fact calling any RSX while |WRITEM is in operation is likely to crash the system. Even calling the |WRITEM is in operation is likely to crash the system. Even calling the |WRITEM command itself, such as to change a window destination, will not work unless the CALL to closem is made first. The line- |WRITEM,1,3: LOCATE 3,3: PRINT"m": LOCATE 4,3: PRINT "n":CALL closem will work, but- |WRITEM,1,3: LOCATE 3,3: PRINT"m": |WRITEM,2,3: LOCATE 4,3: PRINT "n": CALL closem will not, without a: CALL closem before the second RSX command. The fifth and last command in the PULLM set is CLOSEM, the one we've just met briefly and which restores normal printing and resets LOW JUMP back to its proper value. Unfortunately when |WRITEM is called it will also interfere with the RSX mechanism and that means that CLOSEM cannot be an RSX. Instead CLOSEM has to be a simple CALL, but to make life easier the address to call is picked up in the variable closem - note no I - when the program is set up. If you forget and run the program and lose your variables it is still there as HIMEM+1 -unless of course you have also moved HIMEM. To see PULLM in action, once you have PULLMC.BIN and PULLMRSX.BAS safely on disc reset the computer and run PULLMRSX. That will set up all the routines and it can then be deleted - but don't use NEW or you will lose the value in closem. Type in Program 3 and save it. Don't use RUN, but GOTO 10 to prevent the value of closem from being reset. Now PULLM will show off its tricks, including a piece of simple but impressive animation.
|
