443
edits
-
Changes
Created page with "The HI-TECH linker is capable of producing simple binary files, or object files as output. Any other format required must be produced by running the utility program OBJTOHEX...."
The HI-TECH linker is capable of producing simple
binary files, or object files as output. Any other format
required must be produced by running the utility program
OBJTOHEX. This allows conversion of object files as pro-
duced by the linker into a variety of different formats,
including various hex formats. The program is invoked thus:
OBJTOHEX options inputfile outputfile
All of the arguments are optional. If outputfile is
ommitted it defaults to l.hex or l.bin depending on whether
the -b option is used. The inputfile defaults to l.obj.
The options are:
-B_�a_�d_�d_�r
Produce a binary image output. This is similar to the
-C option of the linker. If addr is supplied, the
start of the image file will be offset by addr. If addr
is omitted, the first byte in the file will be the
lowest byte initialized. Addr may be given in decimal,
octal or hexadecimal. The default radix is decimal, and
suffix letters of o or O indicate octal, and h or H
indicate hex. Thus -B100H will produce a file in .COM
format.
-I Include symbol records in the Intel format hex output.
Each symbol record has a form similar to an object
record, but with a different record type. The data
bytes in the record are the symbol name, and the
address is the value of the symbol. This is useful for
downloading to ROM debuggers.
-C Read a checksum specification from the standard input.
The checksum specification is described below. Typi-
cally the specification will be in a file.
-E_�s_�t_�a_�c_�k
This option produces an MS-DOS .EXE format file. The
optional stack argument will determine the maximum
stack size the program will be allocated on execution.
By default the program will be allocated the maximum
stack available, up to the limit of 64K data. If a
stack argument is supplied, the stack size will not
exceed the argument. This is useful to limit the amount
of memory a program will use. The stack argument takes
the same form as the argument to -B above.
-8_�s_�t_�a_�c_�k
This option will produce a CP/M-86 .CMD file. The stack
argument is the same as for the -E option.
-A_�s_�t_�a_�c_�k
This is used when producing a.out format files for unix
systems (specifically Venix-86). If the stack argument
is zero, the size of the data segment will be 64k, oth-
erwise the stack will be placed below the data segment,
and its size set to stack. This must be co-ordinated
with appropriate arguments to the -p option of the
linker.
-M This flag will instruct objtohex to produce Motorola
'S' format hex output.
-L This option is used when producing large model pro-
grams; the linker will have been used with the -LM
option to retain segment relocation information in the
object file. Use of the -L option to objtohex will
cause it to convert that segment relocation information
into appropriate data in the executable file for use
when the program is loaded. Either the operating system
or the run-time startup code will use the relocation
data to adjust segment references based on where in
memory the program is actually loaded. If the -L
option is followed by a symbol name, then the reloca-
tion information will be stored at the address
represented by that symbol in the output file, e.g.
-L___�B_�b_�s_�s will cause it to be stored at the base of the
bss psect (___�B_�b_�s_�s is defined by the linker to be the
load address of the bss psect). If the special symbol
_�D_�o_�s__�h_�d_�r is used then the relocation information will be
stored in the .EXE file header. This is only valid in
conjunction with the -E option.
-S The -S option instructs objtohex to write a symbol
file. The symbol file name is given after the -S, e.g.
-S_�x_�x._�s_�y_�m.
Unless another format is specifically requested,
objtohex will produce a file in Intel hex format. This is
suitable for down-line loading, PROM programming etc. The
HP format is useful for transferring code to an HP64000 for
emulation or PROM programming.
The checksum specification allows automated checksum
calculation. The checksum specification takes the form of
several lines, each line describing one checksum. The syntax
of a checksum line is:
addr1-addr2 where1-where2 +offset
All of addr1, addr2, where1, where2 and offset are hex
numbers, without the usual H suffix. Such a specification
says that the bytes at addr1 through to addr2 inclusive
should be summed and the sum placed in the locations where1
through where2 inclusive. For an 8 bit checksum these two
addresses should be the same. For a checksum stored low byte
first, where1 should be less than where2, and vice versa.
The +offset is optional, but if supplied, the value offset
will be used to initialize the checksum. Otherwise it is
initialized to zero. For example:
0005-1FFF 3-4 +1FFF
This will sum the bytes in 5 through 1FFFH inclusive,
then add 1FFFH to the sum. The 16 bit checksum will be
placed in locations 3 and 4, low byte in 3. The checksum is
initialized with 1FFFH to provide protection against an all
zero rom, or a rom misplaced in memory. A run time check of
this checksum would add the last address of the rom being
checksummed into the checksum. For the rom in question, this
should be 1FFFH. The initialization value may, however, be
used in any desired fashion.
binary files, or object files as output. Any other format
required must be produced by running the utility program
OBJTOHEX. This allows conversion of object files as pro-
duced by the linker into a variety of different formats,
including various hex formats. The program is invoked thus:
OBJTOHEX options inputfile outputfile
All of the arguments are optional. If outputfile is
ommitted it defaults to l.hex or l.bin depending on whether
the -b option is used. The inputfile defaults to l.obj.
The options are:
-B_�a_�d_�d_�r
Produce a binary image output. This is similar to the
-C option of the linker. If addr is supplied, the
start of the image file will be offset by addr. If addr
is omitted, the first byte in the file will be the
lowest byte initialized. Addr may be given in decimal,
octal or hexadecimal. The default radix is decimal, and
suffix letters of o or O indicate octal, and h or H
indicate hex. Thus -B100H will produce a file in .COM
format.
-I Include symbol records in the Intel format hex output.
Each symbol record has a form similar to an object
record, but with a different record type. The data
bytes in the record are the symbol name, and the
address is the value of the symbol. This is useful for
downloading to ROM debuggers.
-C Read a checksum specification from the standard input.
The checksum specification is described below. Typi-
cally the specification will be in a file.
-E_�s_�t_�a_�c_�k
This option produces an MS-DOS .EXE format file. The
optional stack argument will determine the maximum
stack size the program will be allocated on execution.
By default the program will be allocated the maximum
stack available, up to the limit of 64K data. If a
stack argument is supplied, the stack size will not
exceed the argument. This is useful to limit the amount
of memory a program will use. The stack argument takes
the same form as the argument to -B above.
-8_�s_�t_�a_�c_�k
This option will produce a CP/M-86 .CMD file. The stack
argument is the same as for the -E option.
-A_�s_�t_�a_�c_�k
This is used when producing a.out format files for unix
systems (specifically Venix-86). If the stack argument
is zero, the size of the data segment will be 64k, oth-
erwise the stack will be placed below the data segment,
and its size set to stack. This must be co-ordinated
with appropriate arguments to the -p option of the
linker.
-M This flag will instruct objtohex to produce Motorola
'S' format hex output.
-L This option is used when producing large model pro-
grams; the linker will have been used with the -LM
option to retain segment relocation information in the
object file. Use of the -L option to objtohex will
cause it to convert that segment relocation information
into appropriate data in the executable file for use
when the program is loaded. Either the operating system
or the run-time startup code will use the relocation
data to adjust segment references based on where in
memory the program is actually loaded. If the -L
option is followed by a symbol name, then the reloca-
tion information will be stored at the address
represented by that symbol in the output file, e.g.
-L___�B_�b_�s_�s will cause it to be stored at the base of the
bss psect (___�B_�b_�s_�s is defined by the linker to be the
load address of the bss psect). If the special symbol
_�D_�o_�s__�h_�d_�r is used then the relocation information will be
stored in the .EXE file header. This is only valid in
conjunction with the -E option.
-S The -S option instructs objtohex to write a symbol
file. The symbol file name is given after the -S, e.g.
-S_�x_�x._�s_�y_�m.
Unless another format is specifically requested,
objtohex will produce a file in Intel hex format. This is
suitable for down-line loading, PROM programming etc. The
HP format is useful for transferring code to an HP64000 for
emulation or PROM programming.
The checksum specification allows automated checksum
calculation. The checksum specification takes the form of
several lines, each line describing one checksum. The syntax
of a checksum line is:
addr1-addr2 where1-where2 +offset
All of addr1, addr2, where1, where2 and offset are hex
numbers, without the usual H suffix. Such a specification
says that the bytes at addr1 through to addr2 inclusive
should be summed and the sum placed in the locations where1
through where2 inclusive. For an 8 bit checksum these two
addresses should be the same. For a checksum stored low byte
first, where1 should be less than where2, and vice versa.
The +offset is optional, but if supplied, the value offset
will be used to initialize the checksum. Otherwise it is
initialized to zero. For example:
0005-1FFF 3-4 +1FFF
This will sum the bytes in 5 through 1FFFH inclusive,
then add 1FFFH to the sum. The 16 bit checksum will be
placed in locations 3 and 4, low byte in 3. The checksum is
initialized with 1FFFH to provide protection against an all
zero rom, or a rom misplaced in memory. A run time check of
this checksum would add the last address of the rom being
checksummed into the checksum. For the rom in question, this
should be 1FFFH. The initialization value may, however, be
used in any desired fashion.
