Strings

We have recieved the following article from Dr. Michael Hendry, he passes some nice remarks about us lot at the INMC (modesty never was one of our better virtues), endorses our comments about reading the manuals, and passes a message to those in Liverpool (LSG issue 8/1 p36) that, “POKEing isn’t everything; the POKE they suggest is already there as the WIDTH command in Basic.” He also comments that if anyone is throwing away a NASPEN and a golfball printer, he could find them a nice friendly home. He should be so lucky !!

Nascom owners with Basic, who want to process string data will no doubt recognise the scenario.

The intrepid programmer has just typed in 200 names and addresses, and called the alpha-sort routine, which he has checked with a few names while writing the program. To his surprise, it won’t handle 200 names, but he spots the bug and corrects if at once. He calls the alpha-sort routine, and congratulates himself on how fast it now is .... but because he re-RUN (ran) the program, Basic has destroyed all the data for him !!

Simply dumping the whole Basic program and data section of the memory on to tape does not help, as the Basic program can still not be modified without re-initializing the various pointers, and there is no provision for SAVEing string variables as there is for numeric variables. It is possible to use a subroutine to convert each string into a numeric array, which can be SAVEd and LOADed by Basic, but this takes a long time, and is error prone, because of the need to stop and start the tape under program control. You see, Basic indulges in a periodic ‘garbage hunt’, which may take ten seconds or so, and you don’t know when that will happen.

The following short program illustrates another approach, which involved a little detective work into the Basic interpreter’s use of workspace, and of available RAM. The user’s Basic program is stored from 10F9H upwards, and is followed by a table of variables, numeric variables first, then string variables. The strings themselves are saved at the top of memory, and the string variable table comprises pointers to these strings. Between the table and the strings is a free section of RAM. As a program is entered, the variable table is shifted towards the strings, and as strings are encountered they fill the memory towards the variable table. Should the user try to make the two overlap, an OM message will be printed, unless Basic can make more string space by disposing of unwanted strings (a garbage hunt).

This empty RAM between the table and the strings provides the answer to the problem. The program copies the table to the top of RAM, just below the strings. The Basic program can then be modified. When the modifications are finished the program copies the table back down into the new position above the end of the user’s program. Care must be taken now, not to use the RUN command, but to GOTO a point in the program after all the array dimensions have been declared. The former zeroes all variables, a mistake in the latter will result in a DD message, signifying that there has been an attempt to redefine the dimensions of a variable.

Once the various workspace pointers are known, it is not hard to use them in a program, and the source listing is (I hope) self-explanitory. Note the use of RST 18H, the NAS-SYS subroutine call facility to call the NAS-SYS ‘I’ and ‘Z’ commands (intelligent copy and Basic warm start respectively).

With this program to hand, the user can simply dump the whole Basic program and its associated string files to tape using NAS-SYS, knowing that he can later make modifications to the Basic program, or even manipulate the same data with another program.