The HISOFT NASPAS compiler comes on tape in two versions. One runs under HISOFT’s own NASMON, the other, with which we are here concerned, runs under Nas-Sys. On the review machine, it is running under Nas-Sys 3, but I see no obstacle to it running under Nas-Sys 1. As supplied, you receive a tape, recorded in CUTS at 300 baud, and a documentation package consisting of a manual of 9 A4 pages to the NASLIN editor supplied as part of the package, a manual of 63 pages to the NASPAS itself, and a three page implementation note describing how to get the package running under Nas-Sys.

The tape loaded first go, with no tape errors. As the program is so long, the tape is recorded on both sides. After loading the first side, which is set up using the ‘G’ command, the tape is turned over and the second side loaded. When loading is finished, the Nascom prompts with a message to

E**** XXXX YYYY

where the **** address is supplied (43B1H in my copy) on the screen, XXXX marks the start of the compiler proper, and YYYY marks the start of the runtime support routines. The compiler is 27AAH bytes long (just under 10K) and the runtimes are 0B88H bytes long (just under 3K). The implementation note supplied indicates that the compiler should not be located below 1C00H in memory, presumably as it will overwrite itself in the relocation. Normally, the compiler and runtime routines would live at the top of memory, and suggested addresses are supplied in the implementation note. In a 32k system, the compiler lives at 5CCEH, and the runtimes at 8478H. In a 48k system, the addresses are 9CCEH and C478H. The note doesn’t give the addresses for a full system, but they are easily calculated to be CCCEH and F478H.

When the relocation has taken place, the Nas-Sys message is displayed, and an execute address for the compiler. In the case of the three memory sizes I have been discussing, these addresses are 5F9EH, 9F9EH, and CF9EH. This address should be carefully noted, as it is the entry point for the compiler at all stages. The relocated compiler can now be recorded on tape, including the runtime support routines. According to the implementation note supplied, the original compiler – that before relocation – can not be dumped to tape.

All set? Then we can enter the compiler. WAIT! The implementation note requires four parameters to be specified along with the execute address – the positions of where the code generated by the compiler is to be placed, the location of the runtime stack, used for variable storage etc., the address from which you would like the compiled code to execute, as opposed to where it resides during compilation (this facility allows the code to be placed on top of the source or even of the compiler itself. NOTE: NOT the runtimes!) and finally the position of the start of the current text file. However, this complication of specifying four parameters is simplified for us by the compiler writer. If these parameters are entered as 0 – NOT left blank!– then the compiler automatically allocates default values. For general messing about, this is quite satisfactory, and allows you the option of specifying your various workspace areas etc. as you need. Do not forget to enter the four zeros seperated by spaces after the execute address. Otherwise very unpleasant things may happen!

The NASLIN editor supplied is very similar to a BASIC line editor, or to the ZEAP editor. Each Line has a number, and the editor puts them in their correct place relative to each other.