Download version 1.0 of BINCVT as a zip file.
This is release 1.0 and has been bug free for over 12 months. We hope to have version 2 with many new features soon! Tell me about BINCVT bugs.
Multiple files may be combined into the one binary file by specifying more than one input file to process. Successive files simply overwrite any overlapping address ranges.
Automatic detection of all supported input file formats is performed on the first line of the file only. If auto-detection somehow fails then the input file type can be forced with the -convert switch.
BINCVT reads each line of the input file, which contains the data's start address, and places each data byte into a 64 kbyte output array that has been pre-initialised to zeros. The lowest and highest data addresses encountered at each line is calculated. After all the file has been read, these two addresses are used to determine what part of the output array is to be written to the output file.
The start=address switch overrides the calculated minimum address and the length=size switch overrides the calculated maximum address This allows a smaller section of a binary image to be extracted from a larger hex file, or a larger binary image to be forced if not all of the input file image was defined. Remember that the fill=hex character can pre-initialise the entire output array to any byte value.
The DOS command line to invoke BINCVT is:
C:\> BINCVT sourcefilelist [-switchlist]
Each item in the sourcefilelist and the switchlist must be separated by at least one white space. The square brackets indicate that the switchlist is optional, but if supplied, it is delimited from the file names by a preceding hyphen (-) so that a valid source file name may not begin with a hyphen. Here are some practical examples of command lines:
All optional processing is handled by supplying command line switch options. Only an abbreviated form of the command line switch is required. The minimum number of characters required for each switch is indicated by the upper case characters in the following description (eg for Fill=, just F= is required).
Either an equals sign (=), or a colon (:) can be used to to separate the switch and its parameter.
|Convert=||The input file's format is forced to be this kind. This overrides the automatic detection capability that determines the file type directly from its data content. Supported file types are S19, HEX and DBG|
|Fill=||Hex fill character for any uninitialised data. The default is 0.|
|Length=||Length of data sent to the output file. The default is determined from the lowest and highest address found in the input file.|
|Output=||Output file name. The default filename is the same base name as the input file but with the file extension of bin.|
|OVerwrite||Overwrite the output file if it already exists. This allows you to either change the output file's name, or to move the existing file to another location.|
|Startaddr=||Start address for collecting data to be sent to the output file. The default is the lowest address in the hex input file.|
|?||Force the basic help screen to be displayed.|
This section briefly describes the file formats recognised. Note that all supported file types are limited to 16 bit addresses, this means the maximum output file size is limited to 65536 bytes.
The file format is called S19 because there are two "S" record types; the variable length S1 data records, and the fixed length S9 EOF record. Here's an example of three records at the end of a longer file. The record type field is highlighted.
S123008096329633963496359636963796389612000C00018630862286318630863C8631D6 S10A00A0863E8632000100D8 S9030000FC Here's how each character is decoded: Stnnaaaadddddddddddddddddddddddddddddddd ... cc Where: S = 'S' indicates a Motorola S record t = Record type, '0' = Header, '1'=data, '9'=end of file. nn = Count of number of bytes in record. (in ASCII/HEX) aaaa = Load address of data record. (in ASCII/HEX) dd = Actual data bytes in record. (in ASCII/HEX) cc = Checksum of count, address, and data. (in ASCII/HEX) Note 1: Checksum is computed as one's complement of eight bit sum of all values from 'nn' to end of data. Note 2: Count 'nn' is three greater than the number of data bytes in the record.
Intel HEX records begin with a colon (:). As for S19 records, there are just two types of records, a variable length data and a fixed length EOF record. Here's an example of two records at the end of a longer file. The record type field is highlighted.
:20FFE0000000000000000000000000000000000060009369B3346000900290009004900612 :00000001FF Here's how each character is decoded: :nnaaaattdddddddddddddddddddddddddddddd ... cc Where: : = Indicates an Intel an Hex record nn = Count of number of bytes in record. (in ASCII/HEX) aaaa = Load address of data record. (in ASCII/HEX) t = Record type (00=Data, 01=End of file) dd = Actual data bytes in record (in ASCII/HEX) cc = Checksum of address, type and data (not count). (in ASCII/HEX) Note 1: Checksum is computed as two's complement of eight bit sum of all values from 'nn' to end of data (ie. to just before checksum). Note 2: End of file record contains count of 00.
The DEBUG.EXE program that comes with DOS/Windows can be used to "capture" the contents of a binary file. The output of DEBUG can be piped to a file, edited and converted back to a binary file.
Note that there's no checksum like the other formats. This is good in that you can "edit" each record, but it's bad in that there's no way to check the accuracy of each record.
Here's what the DEBUG dump command's output looks like:
543C:0230 77 6E 20 69 6E 74 2E 00-49 6C 6C 65 67 61 6C 20 wn int..Illegal Here's an explanation of each field: ssss:ffff dd dd dd dd dd dd dd dd-dd dd dd dd dd dd dd dd xx............xx Where: ssss = Segment address debug has loaded the binary file at : = separates Segment and Offset ffff = Offset plus 0100h of the current displayed from the file dd = Actual data bytes in record (in ASCII/HEX) xx.. = ASCII data (ignored)
The segment is a PC segment address, and is fixed for the whole file of a normal DUMP command. The offset is the offset into the file, which begins at 0100h (a 32 k byte file would have lines beginning with offset 0100, 0110, 0120 through 40E0, 40F0). Then come 16 data bytes as hex values. The 16 characters on the right are the ASCII representations of the first 16 hex characters, and they are ignored by BINCVT.
Although we have included this format somewhat tongue-in-cheek, it can be quite convenient to load a file into DEBUG, move it around, and save it. The important thing to remember is that all addresses are displayed as 100h more than they really are in the original binary file (just because of a peculiarity of .COM files and DEBUG's default mode of operation). this 100h offset is removed when BINCVT reads the file (so be careful).
With DEBUG's output, make sure each line of the DBG file has only valid dump command output - if you use a batch file to pipe the output (make sure you use a quit command after the dump, or you'll hang in DEBUG.
Statistics by www.digits.com
Approx. unique hits since September 03 2000.
Last updated 28 November 2001 | Tell me about broken links
This document is copyright © 2001, Tech Edge Pty. Ltd.
Previous | Home | Feedback | Copyright