IAN SHARPE presents another selection of useful routines LAST month's utilities toolbox went down so well that I decided to do another. Rather than providing one utility. I'm giving you three which wouldn't merit features individually, but are useful enough to deserve an airing. Basic line mover When writing a Basic program you should aim to structure it so that the main functions each have their own well-defined section of program, clearly labelled with a REM comment. However, a lot of people cobble programs together without much planning and the result is a morass of GOTOs, few REMs, and is impossible to follow - even for the pro grammer. Such programs are known in the trade as spaghetti Basic, and the culprits are unlikely to produce anything worthwhile. If you catch yourself in the act of creating spaghetti Basic, never fear, these days it can be treated. Program I enables you to move Basic lines to another part of the program. With it you can restructure your work without laboriously moving lines manually. Run it before starting a programming session, and whenever you want to move a chunk of program, use this command: |LMOVE,first,last,beforeThe parameters first and last denote the first and last line numbers of the block of lines to be moved. These will be taken out and inserted before the line number specified by before. Here's an example: 10 REM part of a program
20 PRINT"Hello"
30 a=a+1
40 PRINT"there"
50 PRINT"world"
60 PRINT a|LMOVE,40,50,30 LIST 10 REM part of a program
20 PRINT"Hello"
40 PRINT"there"
50 PRINT"world"
30 a=a+1
50 PRINT RENUM As you can see, lines 40 to 50 have been slotted in before line 30, giving the program a more logical layout. In this example we could have achieved the same effect by moving a single line like this: |LMOVE,30,30,60But what do we do when we want to move some lines right to the end of the program? In other words, to the place where there is no line which can be specified as before. The obvious way is like this: 10 REM line 10
20 REN line 20
30 REN line 30|LMOVE,20,30,10 Instead of taking line 10 to the end, we're moving the rest of the program to before line 10, relocating two lines instead of one. There is, however, a disadvantage to this method which is well to be aware of before sending me irate letters. One way of writing a utility like this is to copy the lines to be moved into a buffer, slide the section of Basic between the source and destination along to fill the gap, and finally copy the moved lines from the buffer to the hole created by move. This way is quick, but assumes enough memory is available to use as a buffer, which might not always be the case. The method I chose was to move the lines a byte at a time, sliding the intervening section along one byte every time a byte is copied. In this way no buffer is used, as the byte taken out in each step is stored in a register. The trouble is that if you are copying a lot of lines it is a slow way of doing things. It's one of those situations where there is a choice between a fast program which uses a lot of memory, or a slow one which needs a minimal amount of space. Imagine you had a Basic program with line numbers 10 to 3000 in increments of 10. It's a 10k program, and you want to move lines 10-50 right to the end. Your first thought might be to do this: |LMOVE,60,3000,10For every character in lines 60-3000, a byte is taken out, 10k of program is moved up a byte, and the taken character inserted in its new position. This is repeated over 10,000 times. Even in machine code this is a lot of work to do, and takes long enough to make you think the micro has crashed. A better idea is to put a dummy line at the end: 3010 :and do the move like this: |LMOVE,10,60,3010which is a lot quicker. Tasword Basic editor The Tasword word processor is tremendously popular, and has many thousands of satisfied users. It isn't the slickest word processor around, but many find it simple to use and quite adequate for their needs. If you save a Basic program as an Ascii file like this: SAVE"name",ait can be loaded into a word processor where the superior facilities make the entry and editing of Basic much easier. The problem with Tasword is that it amputates any Basic line more than 120 characters long. Program II is a utility to solve the problem. The program is in two parts. The first option on the menu (Split) takes an Ascii file, and any line longer than 79 characters is split into separate lines. The processed file is saved as temp on tape or disc, and may be loaded into Tasword - or any other word processor with the same problem - for editing. The file should be resaved as temp afterwards. The second option (Join) takes a temp file and rejoins split lines, resaving a file whose name you will be asked for. This can now be loaded and run as a normal Basic program. In order to achieve the feat of splitting lines and knowing which ones to join at a later date, the program needs to leave markers at appropriate places. When you load temp you will see an underline character at the start of lines not to be rejoined. I chose the underline character because it rarely, if ever, crops up in Basic listings. Even if it does, you'd be unlucky to find it at the start of a line when it has been split up, and you can always modify the splitter to use some other character. The only limitation of this program is that the Basic you want to edit should not be larger than the file space available in Tasword. I think this is around 12k for the CPC464 version. Multiface screen loader We often use Romantic Robot's Multiface 2 for capturing screens in commercial software and CP/M programs. These can then be reloaded, and either dumped or photographed. Screens saved in this way have the disadvantage that when loaded from Basic as soon as you touch a key the CPC resets, and all is lost. This prevents you doing anything but look at the screens. If you want to load a Multiface screen and still keep control of your micro, Program III is what you need. It installs a short machine code routine that will load a Multiface screen and return to Basic. You can then do what you like with the screen, such as dumping it to the printer, or resaving it in the normal format so that you can load it without my routine. When Program III has been run, there is a new RSX: |MFLOAD,@a$,@inks%(0) ,@md%The variable a$ holds the name of the saved screen on tape or disc. When the screen has been loaded and the routine returns to Basic, the array inks% will have the ink values, and md% will hold the screen mode. You need to dimension inks% beforehand, and md% must already exist as well. Here's an example of how you would load a screen saved as sen.bin after Program III has been run: 10 MEMORY &3FFF:DIM inks%(15):md%=0 :a$="scn.bin"
20 |MFLOAD , @a$ , @inks%(0) , @md% : MEMORY &8FFF
30 CALL &BB18:FOR i=0 TO 15:PRINT "Ink "; i ;" is" ; inks%(i):NEXT:PRINT"mode is" md%You could now resave it like this: SAVE"scn.bin', b , &c000 , &4000Which will produce a file on disc which may be reloaded without Program III having been run. The machine code poked into place by Program III takes the ink values and screen mode out of the loader that is saved along with Multiface screens. It is just possible that other versions of the Multiface have a different loader, and this will cause the wrong mode and colours to be selected. If this happens, the first thing to do is save the screen as I've described. Then you'll have to take an educated guess at the correct mode and colours before reloading. CWTA | 
