Scor­pio News

a section of the overlay file, the other prints a section of the help file. Both routines take a reference number on entry and look up in a table stored at the beginning of the relevant file. Since both these tables are also constant, and since both files are constantly open, the tables and the file control blocks are resident also.

This raises another drawback of chained files. As I mentioned, I leave the overlay file open. This can cause problems if the disk is changed, but this is the case whenever code is juggled. If each section of code is in a separate file, it will obviously be necessary to open t the file before loading the code, which means extra disk accesses.

To recap then, if we cannot fit the whole program in memory (along with a reasonably large data area) our first step should be to attempt to identify distinct, non-related, self-contained, units which run to completion so as to be used only occasionally and never twice in succession. If we cannot do this, or if we need to break one of these sections further, we should separate only the most infrequently used parts and leave space for one at a time so that they can return instantly. We should also keep a record of which one was loaded last so that we do not load it reloading code which is still resident such as common runtime support. If our program contains long messages we should remove these to another file and load them only when needed. And one very important point. In many programs the initialisation and startup messages etc. account for a significant portion of code which is used only once so as soon as it has been used throw it away.

Well so much for the basic theory. Let’s now take a look at some details. I shall start with the simplest improvement I suggested above, disposing of the startup code. The Gemini CP/M BIOS does this with its introductory message simply by storing it in what will become the sector deblock buffer. This approach is very useful for the assembler programmer, who can very often put such messages in disk I/O buffers or above the other code in an area which will become data storage. Unfortunately, high level languages do not often lend themselves to this sort of treatment. If, however, we are going to use overlays then we can always put the opening bits in the overlay patch area. In the case of my PCB package I had to write assembler code to operate the overlay which then had to be relocated on loading. This code, which forms the opening .COM file, is some 18K in total of which only 1K is resident. Another 1K is the relocator, system checks, and code to open the overlay files and analyse the command line. This leaves 16K of introductory graphics which may seem excessive, but it does not significantly delay the system and takes no room after it has been used.

As I mentioned earlier, I do not consider chained files to be a satisfactory solution for a final version. Since I know of no compiler which provides any other method, it will be necessary to include a small amount of resident machine code with which