80-Bus News

L80 is much easier to use, which probably accounts for its popularity, but does not give you the same facilities as LINK. LINK, for example, will allow you to generate overlay files (OVL), page relocatable files (PRL), and will output a symbol table to disk which could be useful. I only ever use LINK when I need to generate any of these special filetypes for the simple reason that the copy I have demands that all the program modules are entered at the start of the loading process and thus is not very forgiving of the person that forgets to enter the odd module name or two.

Back to overlays now, I recommend that you get hold of the LINK program as it will make your life a lot easier. A word of warning before we start. It must be realized that whatever source language has been used the first byte of the overlay file must be an executable instruction and not a data area as some compilers will create. All my ‘C’ programs compile down into MAC files and so I can alter the data areas to suit before I create the overlays. Not all of you will have this luxury so beware!

I will now explain the ins & outs of overlaying using the DR LINK linking loader. Let’s assume that we have created a program called ROOT and 3 overlay modules called OV1, OV2 & OV3, that will be used by ROOT and are to be run in the same area of memory. The source code has been compiled and we have ROOT.REL, OV1.REL, OV2.REL and OV3.REL on the disk ready to be turned into a COM file with overlays. We now invoke LINK to do its stuff by entering the following:

    LINK ROOT (OV1} (OV2) (OV3) <RET>

And off it goes. Easy isn’t it? On completion you will have created ROOT.COM and 3 overlays, OV1.OVL and so on. LINK will have resolved any global references between ROOT and the overlays allowing an overlay to call routines or access variables in the ROOT module. All the overlays will have the same base address and that will be at the start of the next 128 byte boundary above the top of the root module.

It is possible to nest overlays using LINK so that overlays themselves can call in and execute their own overlays (Complex eh?). I will give you the example in the book as I have not yet used this facility and had better stick to safe ground. If you take a look at the system memory map on the overlay techniques diagram it may make the following clearer. By way of an example let’s say we have a six overlay system; OV1 to 4 are to be run in the main overlay area, while OV5 & OV6 are to be run in the secondary overlay area. 5 & 6 are to be called from OV2. If you enter the following:

LINK ROOT (OV1) ((OV2) (OV5) (OV6)) (OV3) (OV4) 186
                 |- - - - - - - -|
                         |
                 5&6 nested above 2

all the overlays will be sorted out for you. Note the parentheses are nested to indicate the relationship between the overlay sections.

So you can see how easy it is once you have got to this stage but we still have to understand some more on the nitty gritty to enable us to program the overlay loader that handles it all from the root module.

When LINK creates a .OVL file it reads the REL file and resolves the references as normal. It will generate overlay code beginning from the start of the next 128 byte boundary above the root end. The output file (fname.OVL) is in effect a .COM file but LINK will have added a 256 byte header to the beginning of the OVL file. This header area is zero filled except for four bytes. Bytes 1 and 2 (0 based) will contain the length of the executable overlay code, and bytes 7 and 8 will contain the base address of the overlay code. What you as the writer of the overlay loader have to do is extract this information from the header and then read the code into memory starting at the given base address. Once the load is complete then you simply transfer control to the base of the overlay code using a CALL and away you go. As each OVL file contains its own base address a single overlay loading routine is all that is required to load any OVL file.

The above process is a bit of a cheat as the generation of overlay files by LINK was designed specifically to interface with the DR PL-1 language, which has an overlay manager in its library. We can use it however if we take note of the little idiosyncracies.

You will notice that the sample overlay loaders (programs 2 & 6) have the variables ?MEMRY and ?OVLA0 in them apparently doing nothing. These are looked for by LINK and reported as undefined if they do not exist as globals. The ?MEMRY word is set to the overall top of program address by LINK as it is creating the overlays. In other words it tells you what the top address of the biggest overlay is and may be used to determine free space or whatever without jeopardizing any of the program memory.

I have not got a clue what ?OVLA0 is meant to do, if anyone knows, please let me in on the secret. I have put it in the programs as a dummy global just to get rid of those undefined global messages from LINK.

Program 2 is an assembler source listing of a working overlay loader, it can be used in conjunction