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 produced 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:

-Baddr

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. Typically the specification will be in a file.

-Estack

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.

-8stack

This option will produce a CP/M-86 .CMD file. The stack argument is the same as for the -E option.

-Astack

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, otherwise 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 programs; 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 relocation information will be stored at the address represented by that symbol in the output file, e.g.

-L__Bbss

will cause it to be stored at the base of the bss psect (__Bbss is defined by the linker to be the load address of the bss psect). If the special symbol Dos_hdr 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. -Sxx.sym.

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.