BINCVT - S19 & Hex file Converter

• This utility converts Motorola S19 and Intel Hex files to a pure binary format. The S19 output of the author's Motorola 68HC11 macro assembler ASHC11 can be converted to a format required by other utilities.

Download version 1.0 of BINCVT as a zip file.

• The author also has a GM checksum generator GMCKS that generates 16 bit GM C3/P4 ECM checksums.

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.

Features of BINCVT

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.

Command Line & Switches

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.

BINCVT Switches

File Formats

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.

Motorola S19

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

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.

Microsoft DEBUG (DBG)

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)

Note 1: There is no checksum.

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.