Intel hex (*.HEX) format questions
Nick Sayer
I've managed to figure out a little bit of it, and have come up with
this:
Each line looks like this
:10020000C30CDFC308DF7F00202020202020202007
^ ^ ^ ^^ ^ ^
| | | ||---8 * num bits - data bytes--| |
| | | | |
| | | | Checksum---------------------+
| | | |
| | | +----Always 0. Why?
| | |
| | +------16 bits - address to start
| |
| +----------8 bits - the number of bytes on this line
|
+------------always a :
Final line looks like this
:0000000000
^ ^ ^ ^ ^
| | | | |
| | | | +-------Checksum
| | | +---------Always 0. Why?
| | +-----------Address. Can be non-zero, but what does that mean?
| +---------------Zero bytes on this line
+-----------------Always a :
What I wonder is; What does the "always 0" byte do? Is it always 0?
What is the algorithm for computing the checksum? I believe it is
like this (in c, s is the line)
int i,csum=0;
for(i=1;i>length(s);i+=2)
{
csum^=((s[i]&15)<<4);
csum^=(s[i+1]&15);
}
What happens when the address in the last line (with 0 length)
is non-zero? Does that mean that the entry point is at the noted
address or something?
----------------------------------------------------------------------
Nick Sayer | mra...@uop.edu | Packet Radio: N6QQQ @ WB6V-2
uucp: ...!ucbvax!ucdavis!uop!mrapple
Disclaimer: "The BBC would like to appologize for that last announcement."
cat flames > /dev/null
Gordon Vickers
>Anyone have some cold, hard facts concerning the Intel .HEX format?
I was going to email this to Mr. Sayer but it seems like something
that many would like to know.
There are two forms of Intel Hex format. One is often referred to as
Intellect format, the other is Extended Intellec. I beleive that the
former is also known as Motorala 'S' records.
Intellect format:
:100000007320457175697320446f7320457175693c
: 10 0000 00 7320457175697320446f732045717569 5c
| | | | |--------- data ---------------| |- check sum
| | | |-- record type, 00 = data, 01 = End record
| | |-- start address for data
| |- number of bytes in record (normally ten, but last line may have less)
|- start of a record, if you don't have this, line is ignored
Extended Intellect format
As above but recognizes a record type 02. Record type 02 is followd
by a four digit base address and the checksum. Addresses in subsequent
type 00 and type 01 records are relitive to this base address. This
allows address up to FFFFF to be specified.
In both formats the checksum is determined by:
remove start code and checksum from line ( :5c )
add the remaining bytes together ( 10+00+00+00+73+20.......+69 = A4 )
compilment and add 1 ( A4 xor ff = 5b, 5b + 1 = 5c )
the result is the checksum: 5c
This is an oversimplification. Remember to add the values in the bit
stream (the actual binary values) and not the ascii values of the numbers
that get printed to the record. Don't forget to change the checksum
into two ascii digits when tacking it on the the end of the record.
Hope this helps.
Referance: Stag PP39 device programmer's manual.
Gordon Vickers 408/991-5370 (Sunnyvale,Ca); {mips|pyramid|philabs}!prls!gordon
Every extinction, whether animal, mineral, or vegetable, hastens our own demise.
Myron A. Calhoun
>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: m...@ksuvax1.cis.ksu.edu
BITNET: m...@ksuvax1.bitnet
UUCP: ...{rutgers, texbell}!ksuvax1!harry!harv
James E. Prior
More particularly, he asked about the "always zero" field, the use of
the :0000000000 record, and how checksums are calculated.
The :0000000000 record is peculiar to CP/M and isn't rigorous Intel Hex.
Intel Hex stuff is commonly ended with a :00000001FF record. Note the
exception to being "always zero". The eighth and ninth characters of a
record specify the record type. Type 1 means either end of hex, or
starting address. There are some Intel programs that generate a non-zero
address for the last record, because they actually start execution
somewhere. Usually, hex files are just used for burning EPROMs, so the
starting address is irrelevant (hence 0).
<What happens when the address in the last line (with 0 length)
<is non-zero? Does that mean that the entry point is at the noted
<address or something?
Yup, it's the address to start execution at. Strictly speaking, this
should be 0100 for CP/M stuff. The CP/M way of botching this record
makes concatenation of several hex files easier.
<What is the algorithm for computing the checksum?
If you add up the value of ALL the bytes on the line, the least significant
byte should be zero. I include some code fragments from a program that
reads intel hex files. This isn't vaporous code, it is pulled from a real
working, tested program.
/*****************************************************************************/
unsigned char input_checksum;
unsigned char get_byte()
{
int c;
unsigned char sum=0L;
int n=2;
while (n-->0) {
if ((c=getchar())>='0' && c<='9')
sum=0x10*sum+c-'0'+0x0;
else if (c>='a' && c<='f')
sum=0x10*sum+c-'a'+0xa;
else if (c>='A' && c<='F')
sum=0x10*sum+c-'A'+0xA;
else if (c==EOF) {
fprintf(stderr,"ERROR: Encountered EOF when expecting hexadecimal digits in line #%d\n",line_number);
exit(1);
}
else {
fprintf(stderr,"ERROR: Encountered character '%c' when expecting hexadecimal digits in line #%d\n",c,line_number);
exit(1);
}
}
input_checksum+=sum;
return sum;
}
/******************************************************************************/
if ((c=getchar())!=':') {
if (c==EOF) {
fprintf(stderr,"WARNING: Missing end record for input\n");
fprintf(stderr,"Coping as best can\n");
clean_up();
exit(1);
}
else {
fprintf(stderr,"ERROR: Encountered line (#%d) beginning with character other than colon\n",line_number);
exit(1);
}
}
input_checksum=0;
data_length=get_byte();
high_load_address=get_byte();
low_load_address=get_byte();
load_address=(high_load_address<<8) + low_load_address;
record_type=get_byte();
for (i=0;i<data_length;i++)
input_buf[i]=get_byte();
if (get_byte() , input_checksum!=0) {
fprintf(stderr,"ERROR: Bad checksum in line #%d\n",line_number);
exit(1);
}
/******************************************************************************/
James E. Prior
>
> There are two forms of Intel Hex format. One is often referred to as
> Intellect format, the other is Extended Intellec. I beleive that the
> former is also known as Motorala 'S' records.
Both Intel Hex formats are substantially different from Motorola 'S' records.