Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!sharkey!atanasoff!deimos.cis.ksu.edu!harris.cis.ksu.edu!mac
From: mac@harris.cis.ksu.edu (Myron A. Calhoun)
Newsgroups: comp.os.cpm
Subject: Re: Intel hex (*.HEX) format questions
Keywords: from Intel's 1977 "MCS-80 USER'S MANUAL", page 6-75
Message-ID: <980@deimos.cis.ksu.edu>
Date: 24 Feb 89 20:00:37 GMT
References: <1796@uop.edu>
Sender: news@deimos.cis.ksu.edu
Reply-To: mac@harris.cis.ksu.edu (Myron A. Calhoun)
Organization: Kansas State University, Dept of Computing & Information Sciences
Lines: 65

In article <1796@uop.edu> mrapple@uop.edu (Nick Sayer) writes:
>Anyone have some cold, hard facts concerning the Intel .HEX format?
>I've managed to figure out a little bit of it, and have come up with this:

All of my insertions are from Intel's 1977 "MCS-80 USER'S MANUAL",
pages 6-75 and 6-76, which describe "Intellec Hex Paper Tape Format".
A "BPNF Paper Tape Format", a "Non-Intellec Hex Paper Tape Format",
an "Intellec Hex Computer Punched Card Format", and a "PN Computer
Punched Card Format" are described on later pages!

>Each line looks like this
   EACH CHARACTER POSITION IS CALLED A "FRAME"

>:10020000C30CDFC308DF7F00202020202020202007
>^ ^   ^ ^^                              ^ ^
>| |   | ||---8 * num bits - data bytes--| |
   DATA FIELD:  frames 9 to 9+2*(record length)-1
>| |   | |                                 |
>| |   | |    Checksum---------------------+
   CHECKSUM FIELD:  the checksum field contains the ASCII hexadecimal
                    representation of the two's complement of the 8-bit
                    sum of the 8-bit bytes that result from converting
                    each pair of ASCII hexadecimal digits to one byte of
                    binary, from the record length field to and including
                    the last byte of the data field.  Therefore, the sum
                    of all the ASCII pairs in a record after converting
                    to binary, from the record length field to and
                    including the checksum field, is zero.
>| |   | |
>| |   | +----Always 0. Why?
   RECORD TYPE FIELD:  all data records are type 0; end-of-file records
                       are type 1.  Other possible values for this field
                       are reserved for future expansion.
>| |   |
>| |   +------16 bits - address to start
   LOAD ADDRESS FIELD; this field in an end-of-file record contains
                       zeros or the starting address of the program
>| |
>| +----------8 bits - the number of bytes on this line
   RECORD LENGTH FIELD
>|
>+------------always a :
   RECORD MARK FIELD
>
>Final line looks like this
>
>:0000000000
>^ ^   ^ ^ ^
>| |   | | |
>| |   | | +-------Checksum
>| |   | +---------Always 0. Why?
   RECORD TYPE FIELD:  all data records are type 0; end-of-file records
                       are type 1.  Other possible values for this field
                       are reserved for future expansion.
>| |   +-----------Address. Can be non-zero, but what does that mean?
   LOAD ADDRESS FIELD; this field in an end-of-file record contains
                       zeros or the starting address of the program
>| +---------------Zero bytes on this line
>+-----------------Always a :
--Myron
--
Myron A. Calhoun, PhD EE, W0PBV, (913) 532-6350 (work), 539-4448 (home).
INTERNET: mac@ksuvax1.cis.ksu.edu
BITNET:   mac@ksuvax1.bitnet
UUCP:  ...{rutgers, texbell}!ksuvax1!harry!harv