CP/M/CPM_CDROM.iso/jsage/znode3/asm/myload.lbr/MYLOAD.DZC/MYLOAD.DOC

Text File | 1990-02-17 | 5.9 KB | 114 lines

        Release Version 1.0            17 February 1990

MYLOAD - Intel HEX file loader/overlayer.

   While trying to test some new system software consisting of oddball CCP
and BDOSes, it rapidly became apparent that the family of MLOADs were not
capable of proper operation under NZ-COM, nor with non-standard CCP/BDOS
sizes.  Also, the lack of built-in help and Z-System support is a continuing
annoyance.  Because of these factors, I decided to re-invent the proverbial
wheel and write my own program.  This is the result.

   MYLOAD is written as a Z-System Tool, and relys heavily on Version 4 of
The Libraries for proper operation.  As a Z-System tool, it accepts DU: or
DIR: specifications for re-direction of file input.  It also contains an
extensive parser to alleviate excessive typing.  File Types may be specified
or default, but the file format is somewhat restricted by the basic function
of overlaying/loading Intel-standard HEX files to produce a standard COM file.

   While this program is primarily intended to apply HEX overlays onto COM
files, it was a trivial matter to make it function as the old CP/M LOAD.COM.
The syntax for this form is:

        MYLOAD file

   Myload will load FILE.HEX from and write FILE.COM to the current Drive and
User ares.  If operating in the Verbose mode (See Configuration), a message
will be displayed that FILE.COM cannot be located (assuming none exists), and
that the program is switching to FILE.HEX.  If FILE.COM already exists in the
current user area, it will simply be loaded and written to the destination.
Before writing the new file to disk, a check is made for the presence of the
output file, and you have the option of replacing the existing file, or
aborting the write.  To load FILE.HEX to a COM file in another User area, or
on another drive, use the syntax:

    MYLOAD DU:=file   or   MYLOAD DIR:=file   (on a Z-System)

   Multiple HEX files may also be loaded and combined into a single COM file
by simply listing their names separated by spaces, commas or other recognized
delimiters as:

        MYLOAD file1,file2, file3,...

   As in the simple load case, this example will produce FILE1.COM from a
successive load of FILE1.COM being overlayed by FILE2.HEX and FILE3.HEX.  If
FILE1.COM is not located, FILE1.HEX will be loaded followed by FILE2.HEX,
FILE3.HEX, etc.  Explicit DU: or DIR: specifications are accepted for all file
entries.  An example of multiple file overlaying is:

    MYLOAD A15:newfile=b3:oldfile work:ovrlay1 newpatch.hx

   In this example, the file NEWFILE.COM would be written to Drive A, User
15.  It would be comprised of OLDFILE.COM (or OLDFILE.HEX if no COM found)
from User Area 3 on Drive B, overlayed with OVRLAY1.HEX in the WORK: Named
Directory and NEWPATCH.HX (which must be a standard HEX file) in the current
Drive and User area.

   Likewise, Named Directories will be printed in a Z-System where a Name has
been defined for a Drive/User.  If no Name is located, then status lines will
use the DU: form.  When operating in a "vanilla" CP/M system, the DU: form is
always used for input and output.

   MYLOAD also senses specified File Types, and will not override any which
are so entered with the default COM or HEX.  It is therefore possible to make
an OBJ or other user-specified type for output, or overlay an input file with
types other than HEX.  The primary source file may be explicitly declared
with a type other than COM or HEX in order to perform specialized functions
such as loading a ZCPR Type 4 loader onto a PRL transient routine.  When a
specified file type is entered, it is loaded as a binary COM file with no
translation and an assumed load location of 100H.  An example of loading the
Type-4 loader on a transient routine would take the form:

    MYLOAD routine.prl,t4ldr

  The contents of all overlay files must follow the required Intel-standard
Hex file formats with the restriction that no writes are permitted to
addresses less than that of the first source file (100H for COM or other
binary files, the first record load address for HEX files).  It is therefore
important when writing programs for HEX inputs to MYLOAD that you not use
the ORG directive to locate code prior to the current relative stack pointer.

CONFIGURATION.

Three options may be specified by configuration bytes in the MYLOAD header.
The first of these bytes, located at 115H, controls use of the ZCPR 3.x
QUIET flag from the Environment Descriptor.  If set to 0FFH, the Quiet Flag
from any located Z3 Environment will be used to control print of unneeded
messages.  If this configuration byte is set to Zero, or no valid ZCPR 3
Environment is found, then printing of these "noise" messages will be under
the control of the next configuration byte.

The second configuration byte at 116H controls printing of all status and
information messages when either No ZCPR 3 Environment is found or when the
first byte is a Zero.  Setting this byte to a binary Zero will cause all
messages to be printed on the terminal.  Setting this byte to 0FFH will
reduce output to the terminal to only essential messages, and errors.

The third byte at 117H controls whether a BELL character is sent to the
terminal when errors are detected.  If this beeping creates an annoyance, it
may be disabled by setting the byte at 117H to Zero.

All three configuration bytes may be changed with Al Hawley's excellent
ZCNFG tool via the MYLOAD.CFG file contained in this package.  As an alter-
native, you may generate a HEX file with the desired settings for the three
flags, and overlaying it onto MYLOAD.COM.

COMMENTS.

This program was hastily thrown together to satisfy an immediate need, and
is being released as a sample of applications programming for an adaptive
environment.  Many thanks to Howard Goldstein for running this humble program
through his veritable meat grinder of a test cycle.

                Harold F. Bower        "Hal" WA5JAY