80-Bus News

‘lcode’ for ‘a’, ‘ldata’ for ‘b’, and ‘alength’ for ‘c’. However if you precede the label names with a ‘%’ sign, M80 treats them in a different way. Instead of replacing parameter ‘a’ by the character string in the corresponding position in the macro call, it replaces it by the VALUE of that character string, (assumed to be a label), converted to the current radix. That brings me to one final ‘tweak’ to using the macro — we normally think in HEX when confronted with addresses and opcodes, (or at least I do), and so in order that the information is displayed in hex we need to change the current radix to 16. So the code in the source file should look like:

.radix 16   ; Change radix to 16
            ;so we get Hex display
show %lcode,%ldata,%alength   ; Use
            ;the VALUES of the labels
.radix 10   ; Back to normal radix of 10.

If you only want to see the message once, rather than on each pass of the assembler, the code can be bracketed by:

if2         ; If pass 2
... as above..
endif

Microsoft’s L80

If you have a large program it is sometimes convenient to split it into several smaller modules. There are then two approaches you can take on combining these modules. The first is to combine them during assembly by using the ‘include’ command of M80. The second is to assemble them separately, and combine them at link time with L80. In the latter case use is made of the ‘entry’ and ‘extrn’ commands of M80 to specify which labels can be referenced from outside a particular module, (the entry points), and which labels are in other modules, (the externals). However this approach may give you quite a long command line for L80 which it can be irritating to keep retyping:

e.g. l80 bitmain,bit1,bit2,bit3,
     bit4,bit5,bit6,library/s,fred/n/e

Which links together the seven programs bitmain, bit1 – bit6, items from the library file ‘library’, and saves the lot under the filename ‘FRED.COM’. You can save yourself effort by creating a submit file with the above in it, or by programming up one of the function keys on the Gemini keyboard with the command string. Alternatively you can make M80 and L80 do some of the work. This is done by using the ‘.request’ command of M80. The ‘request’ causes M80 to code-up a request to L80 to search the specified file(s) for the routines to satisfy any undefined externals. In the above example ‘bitmain’ could be edited to contain the line:

.request bit1,bit2,bit3,bit4,bit5,bit6,libry
and as a result the L80 command would reduce to:
L80 bitmain,fred/n/e

There are two caveats to using this approach: Firstly M80 restricts external names to six characters, and thus your file names in the ‘request’ command must six characters or less. If they are seven or eight characters long M80 will truncate them to six characters, and then L80 will be unable to find the files. Secondly L80 does a library search. i.e. L80 will only link in those files that contain entry points that are in its table of as yet undefined externals. e.g. If the entry points in ‘bit2’ are only referenced by ‘bit6’, then the file ‘bit2’ will not be loaded when it is reached, as its entry points will not match any of the ‘wanted’ externals referenced by ‘bitmain’ and ‘bit1’. It is only when the file ‘bit6’ is reached that the external references of that file to ‘bit 2’ are added to the ‘undefined externals’ table. Thus the files in the ‘request’ list must be in an order which ensures that they are all loaded. (If ‘bitmain’ references all of them you have nothing to worry about.)

$MEMRY

If you are linking together several routines to form a large program, the problem of workspace may arise. By workspace I mean ‘where is the workspace?’. In the case of a single program requiring — say — two 4k buffers the answer is simple. The program can end with:

 buff1   equ $           ; Start of buffer 1
 buff2   equ buff1+4096  ; Start of buffer 2
bufend  equ buff2+4096  ; End of buffer area

(Note the program ended with EQUs. If DEFS had been used, the data space would have been saved as part of the program — a total waste of disk space.) The same approach can be used when you link programs together with L80, BUT you must ensure the module with the above definition is THE LAST MODULE linked in, (including any library modules), otherwise the ‘buff1’ and ‘buff2’ areas will overlay program code. Replacing the EQUs with DEFS would solve the problem, but once again would lead ta wasted space on disk.

However L80 does provide a mechanism for getting round this problem, but it is slightly clumsy to use. This is the variable $MEMRY. When L80 finishes linking a program it looks