Click Here To Go To The Your Computer Archive



Written By P. Andrews


Cover Art
Click Here To Enlarge Loading Screen

Loading Screen
Click Here To Enlarge Opening Screen

Opening Screen
Click Here To Enlarge Screenshot

Game Screenshot

Disc Overlays

P. Andrews squeezes more into the BBC

The BBC computer is a sophisticated machine with many facilities including an excellent Basic interpreter which sets it apart from most other home computers. The main limitation of the machine is the restriction of having only 32K of Ram. Cassette-based machines have about 27K bytes available to Basic when using Mode 7, but disc-based machines have only 25K because the Disc Filing System - DFS - claims about 2.75K for workspace. Using any other screen mode reduces this even further.

Very little can be done to help the cassette-based owner, but it is possible for a BBC com-puter with disc drive to run a Basic program whose size is limited only by the capacity of the floppy disc being used and the skill of the programmer. The way to achieve this apparently impossible task is to split the program into a number of separate modules - which every programmer should do anyway - and store them on a floppy disc.

The separate modules are only loaded into memory when required and so the modules not being used do not occupy any store Ram. An area of Ram is set aside for the program modules to occupy when they are called and loaded from disc. This area is known as the overlay area, and the modules to be loaded from disc to this area are known as overlay modules. The term overlay is used because when a module is called it is "overlaid" onto the overlay area overwriting any module previously called.

Because modules will overwrite each other a control section is required to ensure that overlay modules are loaded whenever they are required. A routine called the overlay handler is used to control the loading of overlay modules.

As well as the overlay handler a section of code will zlways be present in Ram. This constitutes the main program and will contain the main body of the program and any routines which are frequently called. It is unwise - unless absolutely necessary - to put frequently called routines into an overlay since the program will be slowed down by the routine being loaded from disc many times over.

Figure 1 shows the memory map for a typical Basic program. Figure 2 shows the memory map for an overlaid Basic program. Since Lomem indicates to the interpreter where all identifiers are to be stored then the overlay area can be created by moving LOMEM to make room for the overlay modules to be loaded from disc. Although the overlay scheme can save the space occupied by a Basic program it cannot easily be used to save the space used by variables.

Each overlay module may contain several separate routines. To use any of the routines the overlay module in which they are contained must be present in store. If the module must be continually loaded this will be slow; conversely if already loaded then access will be fast. The program will run faster if those routines which are called in sequence are put into the same module wherever possible.

In BBC Basic two types of overlay routine are possible - functions and procedures. The overlay handler must intercept function and procedure calls to overlay routines in order to ensure that the correct module is loaded. Also the handler must know which overlay module contains the routine being called.

To ensure that the modules are loaded correctly all overlay routines must be accessed via the overlay handler. The handler calls the routines once loaded by using the Eval function. To make this possible the call to an overlay routine is made by calling the handler with a string as a parameter containing a call to the routine. A second parameter gives the number of the module within which the routine is stored. Overlay modules are numbered sequentially starting from one and are kept on disc as a series of Basic files "Over1", "Over2" and so on.

Three separate routines are provided to allow overlay routines to be called. Each routine ensures that the correct overlay module is present in store before the overlay routine is actually called. The string parameter containing the routine call need not normally contain the FN or Proc keywords.

For procedures use: PROCo("the text of procedure call" overlay module number). For example:

PROCo("initialise routine", 1)

For numerical functions use FNo("text of function call", overlay module number). For example:

LET sum=FNo("difference(a-6)",2)

For string functions use FNs("text of function call", overlay module number). For example:

LET x$=x+FNs("string function (""BBC"")",2)

Because the handler calls the overlay routines using Eval it is not possible to code procedures in the normal way. Where an overlay routine is used as a procedure then DEFPROC should be replaced by DEFFN and ENDPROC should be replaced by =0.

Any parameters can be passed to the overlay routines but care is required for string constants. Because a string constant uses quotes any string parameter passed to the overlay routine must have the quote characters put in pairs otherwise they will be taken as being the end of the string. For example a string function normally called using FNroutine("string") when not using overlays might be called using the overlay manager as FNSo("routine(""string"")",1.

Most overlay routine calls involve only a single function and so rather than supply the FN keyword as the first characters in the parameter string the overlay manager will insert these before calling the EVAL function. This saves two bytes per call. If a second function is to be called at the same time then the FN keywords must be added to the function name. If the function is overlaid a nested call to the overlay handler is necessary. For example function funa exists in overlay 1 and function funb exists in overlay 2; func and fund are in the Root. An overlaid function call with both functions could be made with:

10 LET x=func+FNo("funa + 2*FNo(""funb"",2) + FNfund",1)

Listing 1 contains a demonstration root and overlay handler. Listings 2 and 3 contain the code for overlay modules 1 and 2. Type in each listing and save each program as "Root", "Overl" and "Over2" repsectively. The demonstration shows on the screen the loading of overlay modules from disc and the nested calls being processed. To run the demonstration type CHAIN"ROOT"

Examine the demonstration listing. When you are familiar with its operation you can use listing 4 which is the overlay handler to be incorporated in your own programs. The handler in the demonstration should not be used since it has been modified.

In the demonstration listing the size of the overlay area is specified. *INFO should be used to determine the size of the overlay files produced. For example:

e.g. *INFO OVER1
OVER1 1900 801F 2000 A7

The size of Over1 is &2000 bytes so the overlay area must be at least this big for the overlay to fit. The total size of the program will be:

program size = TOP-PAGE + overlay size-2

When choosing line numbers, the root must have the lower line numbers and the overlay routine the higher numbers. No overlay module can contain the same range of numbers as the root, but separate overlay modules can share the same range.

Care must be taken when correcting errors. If the root is changed after an overlay is loaded and then Saved it will be too big because both root and overlay will have been saved. Always load the root or relevant overlay before making alterations.

Obscure errors can arise if the overlays are called incorrectly. Two errors can cause great confusion - clashing line numbers between the root and overlay modules and also two routines with the same name occurring in different overlay modules.