[net.micro.cpm] looking for information on Intel Hex file format

tuba@ur-tut.UUCP (Jon Krueger) (10/08/86)

I have a file in Intel Hex format.  This is a hex representation of a binary
file.  I need to decode it and, ultimately, load it into memory.  Does
anyone know how to read these files?  How to interpret the different
fields?  Any leads or pointers?


-- 
--> Jon Krueger
uucp: {seismo, bullwinkle, allegra, decvax, harvard}!rochester!ur-tut!tuba
Phone: (716) 275-2811 work, 235-1495 home	BITNET: TUBA@UORDBV
Drop in next time you're in the tri-planet area!

larry@kitty.UUCP (Larry Lippman) (10/09/86)

In article <753@ur-tut.UUCP>, tuba@ur-tut.UUCP (Jon Krueger) writes:
> 
> I have a file in Intel Hex format.  This is a hex representation of a binary
> file.  I need to decode it and, ultimately, load it into memory.  Does
> anyone know how to read these files?  How to interpret the different fields?

	The start of record character is a colon [:].  This is followed by a
2-digit (in HEX) byte count that establishes the record length.  This is
followed by a 4-digit loading address.  This is followed by a 2-digit record
type, for which ``00'' denotes a data record, and ``01'' denotes end-of-file 
record.  The next field consists of data in HEX, with two characters per
byte.  The last field is a 2-digit HEX field which is a checksum, based upon
the 2's complement of the binary sum of all the the bytes in the record.
	For _contiguously_ loaded memory data, the record length is generally
always 16 bytes of data, with the last record often being less than 16 bytes.
If the first loading address does not begin on a ``0'' boundary, then the
first record may be adjusted to be less than 16 bytes so that all subsequent
records begin on boundaries ending in ``0''.  There is no requirement for
this boundary adjustment other than to improve human readability of the
HEX file.  Since there are no spaces in the hex file, human readability is
a bitch - but one gets used to it after a while...

==>  Larry Lippman @ Recognition Research Corp., Clarence, New York
==>  UUCP:  {allegra|decvax|rocksanne|rocksvax|watmath}!sunybcs!kitty!larry
==>  VOICE: 716/688-1231           {hplabs|ihnp4|seismo|utzoo}!/
==>  FAX:   716/741-9635 {G1,G2,G3}      "Have you hugged your cat today?" 

sdh@inuxm.UUCP (Stephen Hoskins) (10/09/86)

> 
> I have a file in Intel Hex format.  This is a hex representation of a binary
> file.  I need to decode it and, ultimately, load it into memory.  Does
> anyone know how to read these files?  How to interpret the different
> fields?  Any leads or pointers?
> 
> 
> -- 
> --> Jon Krueger
> uucp: {seismo, bullwinkle, allegra, decvax, harvard}!rochester!ur-tut!tuba
> Phone: (716) 275-2811 work, 235-1495 home	BITNET: TUBA@UORDBV
> Drop in next time you're in the tri-planet area!


First thing on every line is a colon.
Then, 2 hex digits saying how many data bytes are in this line.
Then, 4 hex digits giving the memory address where the data should be loaded.
Then, 2 hex digits that I always ignore.
Then, there are 2 hex digits for every data byte contained in this line.
Finally, there are 2 hex digits that are a checksum over the whole line.

Here is a sample:

:10E00000C37AE0C3FAE0C3EBE0C36BE1C39CE1C3B6
:00000000

This line has 10 (hex) bytes of data and loads into RAM at E000 (hex).
The first data byte is C3 (hex); the last is C3 (hex).
The checksum is B6 (hex).
Get the idea?

By the way.  The last line in the file has a byte count of 0.
That's how you know when you're at the end of the file.

Stephen Hoskins
AT&T Consumer Products Labs
ihnp4!inuxc!inuxm!sdh