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