Jump to content

Intel HEX: Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous edit
Content deleted Content added
VisualWikitext
→External links: Revision A January 6, 1988
Rescuing 1 sources and tagging 0 as dead.) #IABot (v2.0.9.5
 
(483 intermediate revisions by 100 users not shown)
Line 1: Line 1:
{{short description|File format for conveying binary information}}
'''Intel HEX''' is a [[file format]] for conveying binary information for applications like programming [[microcontroller]]s, [[EPROM]]s, and other kinds of chips. It is one of the oldest file formats available for this purpose, having been in use since the 1970s. {{Fact|date=April 2008}}
{{distinguish|Intel hexadecimal notation}}
{{redirect|.hex|the file format used by [[GNU Unifont]]|GNU Unifont#.hex format}}
{{use dmy dates|date=February 2020|cs1-dates=y}}
{{use list-defined references|date=December 2021}}
{{cs1 config|mode=cs1|name-list-style=none|display-authors=all}}
{{infobox file format
|name = Intel hex
|_noextcode = true
|extensions = <strong>General-purpose:</strong><br/><code>.hex</code>,<ref name="Arnold_2020_AS"/> <code>.mcs</code>,<ref name="Xilinx_2010_MCS"/> <code>.int</code>,<ref name="Sabnis_2011"/> <code>.ihex</code>, <code>.ihe</code><!-- .ihex stripped down to 3 characters, also used for other purposes -->, <code>.ihx</code><ref name="Schuldt_2018"/><!-- also used for other purposes --><br/><strong>Platform-specific:</strong><br/><code>.h80</code><!-- Intel 8-bit i.e. 8080 -->, <code>.h86</code><!-- x86 version only -->,<ref name="DRI_1981_CPM86-SG"/><ref name="DRI_1983_CPM86-PG"/> <code>.a43</code><!-- TI MPS430, appears to be Intel hex or a close variant -->,<ref name="Ramos_2010"/><ref name="Schuldt_2018"/> <code>.a90</code><ref name="Ramos_2010"/><ref name="Schuldt_2018"/><br/><strong>Split, banked, or paged:</strong><br/><code>.hxl</code>–<code>.hxh</code><!-- IDA, split 8-bit format only -->,<ref name="IDA_2006_Hexforms"/> <code>.h00</code>–<code>.h15</code><!-- ROM banks -->, <code>.p00</code>–<code>.pff</code><ref name="Roche_2020"/><br/><strong>Binary or Intel hex:</strong><br/><code>[[Object file|.obj]]</code>, <code>.obl</code><!-- IDA, split 8-bit format only -->,<ref name="IDA_2006_Hexforms"/> <code>.obh</code><!-- IDA, split 8-bit format only -->,<ref name="IDA_2006_Hexforms"/> <code>[[.rom]]</code><!-- can be binary or Intel hex depending on tool and configuration -->, <code>[[.eep]]</code><!-- can be binary or Intel hex depending on tool and configuration -->
}}

'''Intel hexadecimal object file format''', '''Intel hex format''' or '''Intellec Hex''' is a [[file format]] that conveys [[binary data|binary]] information in [[ASCII]] [[text file|text]] form,<ref name="Intel_1980_FU-UG"/> making it possible to store on non-binary media such as [[paper tape]], [[punch card]]s, etc., to display on [[text terminal]]s or be printed on [[line-oriented printer]]s.<ref name="Intel_1988_Spec"/> The format is commonly used for programming [[microcontroller]]s, [[EPROM]]s, and other types of programmable logic devices and [[hardware emulator]]s. In a typical application, a [[compiler]] or [[assembler (computing)|assembler]] converts a [[computer program|program]]'s [[source code]] (such as in [[C (programming language)|C]] or [[assembly language]]) to [[machine code]] and outputs it into a [[object file|object]] or [[executable file]] in hexadecimal (or binary) format. In some applications, the Intel hex format is also used as a [[container format]] holding [[data packet|packet]]s of [[stream data]].<ref name="Analog_2021"/> Common file extensions used for the resulting files are .HEX<ref name="Arnold_2020_AS"/> or .H86<!-- for the 16-bit variant only -->.<ref name="DRI_1981_CPM86-SG"/><ref name="DRI_1983_CPM86-PG"/> The HEX file is then read by a [[programmer (hardware)|programmer]] to write the machine code into a [[programmable read-only memory|PROM]] or is transferred to the target system for loading and execution.<ref name="Intel_1988_Spec"/><ref name="ARM_hex"/> There are various tools to convert files between hexadecimal and binary format (i.e. [[HEX2BIN]]), and vice versa (i.e. OBJHEX, OH, OHX, BIN2HEX).

==History==
The Intel hex format was originally designed for [[Intel]]'s [[Intellec Microcomputer Development System]]s<ref name="Crosby_1994"/>{{rp|pages=10–11}} (MDS) in 1973 in order to load and execute programs from [[paper tape]]. It was also used to specify memory contents to Intel for [[ROM]] production,<ref name="Intel_1977"/> which previously had to be [[encoding|encode]]d in the much less efficient [[BNPF]] (Begin-Negative-Positive-Finish) format.<ref name="Crosby_1994"/>{{rp|page=11}} In 1973, Intel's "software group" consisted only of Bill Byerly<!-- would join Kildall's Digital Research in 1978 --> and Kenneth Burgett, and [[Gary Kildall]] as an external consultant doing business as [[Microcomputer Applications Associates]] (MAA) and founding [[Digital Research]] in 1974.<ref name="Kildall_1980_CPM"/><ref name="Kildall_1993"/><ref name="Burgett_2017"/><ref name="Roche_2020"/> Beginning in 1975, the format was utilized by [[Intellec Series II]] [[Intel ISIS-II|ISIS-II]] systems supporting diskette drives, with files using the file extension HEX.<ref name="Feichtinger_1987"/> Many [[programmable ROM|PROM]] and [[EPROM]] programming devices accept this format.


==Format==
==Format==
Intel HEX consists of lines of [[ASCII]] text that are separated by [[line feed]] or [[carriage return]] characters or both. Each text line contains uppercase [[hexadecimal]] characters that [[binary-to-text encoding|encode]] multiple binary numbers. The binary numbers may represent data, [[memory address]]es, or other values, depending on their position in the line and the type and length of the line. Each text line is called a ''record''.
The format is a [[text file]], with each line containing [[hexadecimal]] values [[Binary-to-text encoding|encoding a sequence of data]] and their starting [[offset (computer science)|offset]] or [[absolute address]].


===Record structure===
There are three types of Intel HEX: 8-bit, 16-bit, and 32-bit. They are distinguished by their [[Endianness|byte order]].
A [[record (computer science)|record]] (line of text) consists of six [[field (computer science)|field]]s (parts) that appear in order from left to right:<ref name="Intel_1988_Spec"/>
# ''Start code'', one character, an ASCII colon '{{Background color|#FFFFCC|:}}'. All characters preceding this symbol in a record should be ignored.<ref name="Intel_1977"/><ref name="DRI_1981_CPM86-SG"/><ref name="DRI_1984_CCPM-PRG"/><ref name="DataIO_1980_OG"/><ref name="DataIO_1987_TFF"/><ref name="Fujitsu_2001"/> In fact, very early versions of the specification even asked for a minimum of 25 [[NUL (character)|NUL]] characters to precede the first record and follow the last one, owing to the format's origins as a [[paper tape]] format which required some [[leader tape|tape leadin and leadout]] for handling.<ref name="Intel_1977"/><ref name="DRI_1982_CPM-M"/><ref name="DataIO_1980_OG"/><ref name="DataIO_1987_TFF"/> However, as this was a little known part of the specification, not all software written copes with this correctly. It allows to store other related information in the same file (and even the same line),<ref name="Intel_1977"/><ref name="Fujitsu_2001"/> a facility used by various software development utilities to store [[symbol table]]s or additional comments,<ref name="Intel_1974_PLM"/><ref name="Intel_1977"/><ref name="DataIO_1980_OG"/><ref name="Hennig-Roleff_1993"/><ref name="Roche_2020"/><ref name="GeorgG_2021"/> and third-party extensions using other characters as start code like the digits '{{Background color|#FFFFCC|0}}'..'{{Background color|#FFFFCC|9}}' by Intel<ref name="Intel_1979_2920"/> and [[Keil (company)|Keil]],<ref name="Hennig-Roleff_1993"/> '{{Background color|#FFFFCC|$}}' by [[Mostek]],<ref name="Formaniak-Leitch_1977"/><ref name="Ogdin-Colvin-Pittman-Tubb_1977"/> or '{{Background color|#FFFFCC|!}}', '{{Background color|#FFFFCC|@}}', '{{Background color|#FFFFCC|#}}', '{{Background color|#FFFFCC|\}}', '{{Background color|#FFFFCC|&}}' and '{{Background color|#FFFFCC|;}}' by [[Technical Design Labs|TDL]].<ref name="Ogdin-Colvin-Pittman-Tubb_1977"/><ref name="Kreidl_1981"/> By convention, '{{Background color|#FFFFCC|//}}' is often used for comments.<ref name="Rüger_2022"/><ref name="Bull-Dean-Rüger-Wunsch_2023"/> Neither of these extensions may contain any ':' characters as part of the payload.
# ''Byte count'', two hex digits (one hex digit pair), indicating the number of bytes (hex digit pairs) in the data field. The maximum byte count is 255 (0xFF). The values of 8 (0x08),<ref name="Roche_2020"/> 16 (0x10)<ref name="Roche_2020"/> and 32 (0x20) are commonly used byte counts. Not all software copes with counts larger than 16.<ref name="Xilinx_2010_MCS"/>
# ''Address'', four hex digits, representing the 16-bit beginning memory address offset of the data. The physical address of the data is computed by adding this offset to a previously established base address, thus allowing memory addressing beyond the 64 kilobyte limit of 16-bit addresses. The base address, which defaults to zero, can be changed by various types of records. Base addresses and address offsets are always expressed as [[big endian]] values.
# ''Record type'' (see [[#Record types|record type]]s below), two hex digits, {{Intel HEX|||00||}} to {{Intel HEX|||05||}}, defining the meaning of the data field.
# ''Data'', a sequence of ''n'' bytes of data, represented by 2''n'' hex digits. Some records omit this field (''n'' equals zero). The meaning and interpretation of data bytes depends on the application. (4-bit data will either have to be stored in the lower or upper half of the bytes, that is, one byte holds only one addressable data item.<ref name="Intel_1977"/>)
# ''[[Checksum]]'', two hex digits, a computed value that can be used to verify the record has no errors.


====Color legend====
Each line of Intel HEX file consists of six parts:
As a visual aid, the fields of Intel HEX records are colored throughout this article as follows:
# '''Start code''', one character, an [[ASCII]] colon ':'.
# '''Byte count''', two hex digits, a number of bytes (hex digit pairs) in the data field. 16 (0x10) or 32 (0x20) bytes of data are the usual compromise values between line length and address overhead.
# '''Address''', four hex digits, a 16-bit address of the beginning of the memory position for the data. Limited to 64 kilobytes, the limit is worked around by specifying higher bits via additional record types. This address is [[big endian]].
# '''Record type''', two hex digits, ''00'' to ''05'', defining the type of the data field.
# '''Data''', a sequence of ''n'' bytes of the data themselves, represented by 2''n'' hex digits.
# '''[[Checksum]]''', two hex digits - the [[least significant byte]] of the [[two's complement]] of the sum of the values of all fields except fields 1 and 6 (Start code ":" byte and two hex digits of the Checksum). It is calculated by adding together the hex-encoded bytes (hex digit pairs), then leaving only the LSB of the result, and making a 2's complement (either by subtracting the byte from 0x100, or inverting it by XOR-ing with 0xFF and adding 0x01). If you are not working with 8-bit variables, you must suppress the overflow by AND-ing the result with 0xFF. The overflow may occur since both 0x100-0 and (0x00 XOR 0xFF)+1 equal 0x100. If the checksum is correctly calculated, adding all the bytes (the Byte count, both bytes in Address, the Record type, each Data byte and the Checksum) together will always result in a value wherein the least significant byte is zero (0x00). <br/> For example, on :0300300002337A1E <br/> 03 + 00 + 30 + 00 + 02 + 33 + 7A = E2, 2's complement is 1E


{{legend inline|#FFFFCC|Start code}}
There are six record types:
{{legend inline|#CCFFCC|Byte count}}
* '''00''', ''data record'', contains data and 16-bit address. The format described above.
{{legend inline|#CCCCFF|Address}}
* '''01''', ''End Of File record'', a file termination record. No data. Has to be the last line of the file, only one per file permitted. Usually ':00000001FF'. Originally the ''End Of File record'' could contain a start address for the program being loaded, e.g. :00AB2F0125 would make a jump to address AB2F. This was convenient when programs were loaded from punched paper tape.
{{legend inline|#FFCCCC|Record type}}
* '''02''', ''Extended Segment Address Record'', segment-base address. Used when 16 bits are not enough, identical to 80x86 real mode addressing. The address specified by the 02 record is multiplied by 16 (shifted 4 bits left) and added to the subsequent 00 record addresses. This allows addressing of up to a megabyte of address space. The address field of this record has to be 0000, the byte count is 02 (the segment is 16-bit). The least significant hex digit of the segment address is always 0.
{{legend inline|#CCFFFF|Data}}
* '''03''', ''Start Segment Address Record''. For 80x86 processors, it specifies the initial content of the CS:IP registers. The address field is 0000, the byte count is 04, the first two bytes are the [[Code segment|CS]] value, the latter two are the [[instruction pointer|IP]] value.
{{legend inline|#CCCCCC|Checksum}}
* '''04''', ''Extended Linear Address Record'', allowing for fully 32 bit addressing. The address field is 0000, the byte count is 02. The two data bytes represent the upper 16 bits of the 32 bit address, when combined with the address of the 00 type record.
* '''05''', ''Start Linear Address Record''. The address field is 0000, the byte count is 04. The 4 data bytes represent the 32-bit value loaded into the EIP register of the 80386 and higher CPU.


====Checksum calculation====
There are various format subtypes:
A record's checksum byte is the [[two's complement]] of the [[least significant byte]] (LSB) of the sum of all decoded byte values in the record preceding the checksum. It is computed by summing the decoded byte values and extracting the LSB of the sum (i.e., the data checksum), and then calculating the two's complement of the LSB (e.g., by [[ones' complement|inverting]] its bits and adding one).
* '''I8HEX''' or '''INTEL 8''', 8-bit format.
* '''I16HEX''' or '''INTEL 16''', 16-bit format. Allows usage of 02 and 03 records. The data field [[endianness]] may be byte-swapped.
* '''I32HEX''' or '''INTEL 32''', 32-bit format. Allows usage of 04 and 05 records. The data field endianness may be byte-swapped.


For example, in the case of the record {{Intel HEX|03|0030|00|02337A|1E}}, the sum of the decoded byte values is {{Intel HEX|03||||}} + {{Intel HEX||00|||}} + {{Intel HEX||30|||}} + {{Intel HEX|||00||}} + {{Intel HEX||||02|}} + {{Intel HEX||||33|}} + {{Intel HEX||||7A|}} = <code>E2</code>, which has LSB value <code>E2</code>. The two's complement of <code>E2</code> is {{Intel HEX|||||1E}}, which is the checksum byte appearing at the end of the record.
Beware! Byte-swapped data might be more confusing. It is possible to misinterpret the byte order in case of I16HEX and I32HEX.


The validity of a record can be checked by computing its checksum and verifying that the computed checksum equals the checksum appearing in the record; an error is indicated if the checksums differ. Since the record's checksum byte is the two's complement — and therefore the [[additive inverse]] — of the data checksum, this process can be reduced to summing all decoded byte values, including the record's checksum, and verifying that the LSB of the sum is zero. When applied to the preceding example, this method produces the following result: {{Intel HEX|03||||}} + {{Intel HEX||00|||}} + {{Intel HEX||30|||}} + {{Intel HEX|||00||}} + {{Intel HEX||||02|}} + {{Intel HEX||||33|}} + {{Intel HEX||||7A|}} + {{Intel HEX|||||1E}} = <code>100</code>, which has LSB value <code>00</code>.
A similar encoding, with slightly different ASCII formatting, termed [[SREC (file format)|SREC]] is used with Motorola processors.


===Text line terminators===
== Example ==
Intel HEX records are usually separated by one or more ASCII line termination characters so that each record appears alone on a text line. This enhances readability by visually [[delimiter|delimiting]] the records and it also provides padding between records that can be used to improve machine [[parsing]] efficiency. However, the line termination characters are optional, as the '{{Background color|#FFFFCC|:}}' is used to detect the start of a record.<ref name="Intel_1977"/><ref name="DRI_1981_CPM86-SG"/><ref name="DRI_1982_CPM-M"/><ref name="DRI_1984_CCPM-PRG"/><ref name="DataIO_1980_OG"/><ref name="DataIO_1987_TFF"/><ref name="Fujitsu_2001"/>
<span style="background-color: #FFFFCC">:</span><span style="background-color: #CCFFCC">10</span><span style="background-color: #CCCCFF">0100</span><span style="background-color: #FFCCCC">00</span><span style="background-color: #CCFFFF">214601360121470136007EFE09D21901</span><span style="background-color: #FFCCFF">40</span>

<span style="background-color: #FFFFCC">:</span><span style="background-color: #CCFFCC">10</span><span style="background-color: #CCCCFF">0110</span><span style="background-color: #FFCCCC">00</span><span style="background-color: #CCFFFF">2146017EB7C20001FF5F160021480119</span><span style="background-color: #FFCCFF">88</span>
Programs that create HEX records typically use line termination characters that conform to the conventions of their [[operating system]]s. For example, Linux programs use a single LF ([[line feed]], hex value <code>0A</code>) character to terminate lines, whereas Windows programs use a CR ([[carriage return]], hex value <code>0D</code>) followed by a LF.
<span style="background-color: #FFFFCC">:</span><span style="background-color: #CCFFCC">10</span><span style="background-color: #CCCCFF">0120</span><span style="background-color: #FFCCCC">00</span><span style="background-color: #CCFFFF">194E79234623965778239EDA3F01B2CA</span><span style="background-color: #FFCCFF">A7</span>

<span style="background-color: #FFFFCC">:</span><span style="background-color: #CCFFCC">10</span><span style="background-color: #CCCCFF">0130</span><span style="background-color: #FFCCCC">00</span><span style="background-color: #CCFFFF">3F0156702B5E712B722B732146013421</span><span style="background-color: #FFCCFF">C7</span>
===Record types===
<span style="background-color: #FFFFCC">:</span><span style="background-color: #CCFFCC">00</span><span style="background-color: #CCCCFF">0000</span><span style="background-color: #FFCCCC">01</span><span style="background-color: #FFCCFF">FF</span>
Intel HEX has six standard record types:<ref name="Intel_1988_Spec"/>
{{legend|#FFFFCC|Start code}}

{{legend|#CCFFCC|Byte count}}
{| class="wikitable"
{{legend|#CCCCFF|Address}}
|-
{{legend|#FFCCCC|Record type}}
! Hex code
{{legend|#CCFFFF|Data}}
! Record type
{{legend|#FFCCFF|Checksum}}
! Description
! Example
|- valign="top"
| align="center" | {{Intel HEX|||00||}}
| Data
| The byte count specifies number of data bytes in the record. The example has {{Intel HEX|0B||||}} (eleven) data bytes. The 16-bit starting address for the data (in the example at addresses beginning at {{Intel HEX||0010|||}}) and the data ({{Intel HEX||||61|}}, {{Intel HEX||||64|}}, {{Intel HEX||||64|}}, {{Intel HEX||||72|}}, {{Intel HEX||||65|}}, {{Intel HEX||||73|}}, {{Intel HEX||||73|}}, {{Intel HEX||||20|}}, {{Intel HEX||||67|}}, {{Intel HEX||||61|}}, {{Intel HEX||||70|}}).
| {{Intel HEX|0B|0010|00|6164647265737320676170|A7}}
|- valign="top"
| align="center" | {{Intel HEX|||01||}}
| End Of File
| Must occur exactly once per file in the last record of the file. The byte count is {{Intel HEX|00||||}}, the address field is typically {{Intel HEX||0000|||}} and the data field is omitted.
| {{Intel HEX|00|0000|01||FF}}
|- valign="top"
| align="center" | {{Intel HEX|||02||}}
| Extended&nbsp;Segment&nbsp;Address
| The byte count is always {{Intel HEX|02||||}}, the address field (typically {{Intel HEX||0000|||}}) is ignored and the data field contains a 16-bit segment base address. This is multiplied by 16 and added to each subsequent data record address to form the starting address for the data. This allows addressing up to one [[mebibyte]] (1048576 bytes) of address space.
| {{Intel HEX|02|0000|02|1200|EA}}
|- valign="top"
| align="center" | {{Intel HEX|||03||}}
| Start Segment Address
| For 80x86 processors, specifies the starting execution address. The byte count is always {{Intel HEX|04||||}}, the address field is {{Intel HEX||0000|||}} and the first two data bytes are the [[Code segment|CS]] value, the latter two are the [[instruction pointer|IP]] value. The execution should start at this address.
| {{Intel HEX|04|0000|03|00003800|C1}}
|- valign="top"
| align="center" | {{Intel HEX|||04||}}
| Extended Linear Address
| Allows for 32 bit addressing (up to 4 [[GiB]]). The byte count is always {{Intel HEX|02||||}} and the address field is ignored (typically {{Intel HEX||0000|||}}). The two data bytes (big endian) specify the upper 16 bits of the 32 bit absolute address for all subsequent type {{Intel HEX|||00||}} records; these upper address bits apply until the next {{Intel HEX|||04||}} record. The absolute address for a type {{Intel HEX|||00||}} record is formed by combining the upper 16 address bits of the most recent {{Intel HEX|||04||}} record with the low 16 address bits of the {{Intel HEX|||00||}} record. If a type {{Intel HEX|||00||}} record is not preceded by any type {{Intel HEX|||04||}} records then its upper 16 address bits default to 0000.
| {{Intel HEX|02|0000|04|0800|F2}}
|- valign="top"
| align="center" | {{Intel HEX|||05||}}
| Start Linear Address
| The byte count is always {{Intel HEX|04||||}}, the address field is {{Intel HEX||0000|||}}. The four data bytes represent a 32-bit address value (big endian). In the case of CPUs that support it, this 32-bit address is the address at which execution should start.
| {{Intel HEX|04|0000|05|000000CD|2A}}
|}
Other record types have been used for variants, including {{Intel HEX|||06||}} ('blinky' messages / transmission protocol container) by Wayne and Layne,<ref name="Beckler_2016"/> {{Intel HEX|||0A||}} (block start), {{Intel HEX|||0B||}} (block end), {{Intel HEX|||0C||}} (padded data), {{Intel HEX|||0D||}} (custom data) and {{Intel HEX|||0E||}} (other data) by the [[BBC]]/[[Micro:bit Educational Foundation]],<ref name="BBC_2021_Universal"/> and {{Intel HEX|||81||}} (data in [[code segment]]), {{Intel HEX|||82||}} (data in [[data segment]]), {{Intel HEX|||83||}} (data in [[stack segment]]), {{Intel HEX|||84||}} (data in [[extra segment]]), {{Intel HEX|||85||}} ([[paragraph address]] for absolute code segment), {{Intel HEX|||86||}} (paragraph address for absolute data segment), {{Intel HEX|||87||}} (paragraph address for absolute stack segment) and {{Intel HEX|||88||}} (paragraph address for absolute extra segment) by [[Digital Research]].<ref name="DRI_1983_CPM86-PG"/><ref name="DRI_1984_CCPM-PRG"/>

==={{anchor|I4|I8|I16|I32}}Named formats===
The original 4-bit/8-bit ''Intellec Hex Paper Tape Format'' and ''Intellec Hex Computer Punched Card Format'' in 1973/1974 supported only one record type {{Intel HEX|||00||}}.<ref name="Intel_1973_Intellec8"/><ref name="Intel_1974_MOD8"/><ref name="Intel_1974_PLM"/> This was expanded around 1975{{when|date=May 2022|reason=It would be great if we could narrow this down to an exact year, possibly even a month and back it up with a reliable source and/or the original publication introducing it.}} to also support record type {{Intel HEX|||01||}}.<ref name="Intel_1977"/> Sometimes called ''symbolic hexadecimal format'',<ref name="Intel_1988_DevTools"/> it could include an optional header containing a [[symbol table]] for [[symbolic debugging]],<ref name="Intel_1974_PLM"/><ref name="Intel_1979_2920"/><ref name="Hennig-Roleff_1993"/><ref name="Roche_2020"/> all characters in a record preceding the colon are ignored.<ref name="Intel_1977"/><ref name="DRI_1981_CPM86-SG"/>

Around 1978{{when|date=May 2022|reason=It would be great if we could narrow this down to an exact year, possibly even a month and back it up with a reliable source and/or the original publication introducing it.}}, Intel introduced the new record types {{Intel HEX|||02||}} and {{Intel HEX|||03||}} (to add support for the segmented address space of the then-new [[8086]]/[[8088]] processors) in their ''Extended Intellec Hex Format''.{{when|date=May 2022|reason=What is still missing is reliable information when the record types 0x04 and 0x05 for 32-bit addressing where introduced by Intel. It would be great if we could back this up with a pointer to the original publication introducing it.}}

Special names are sometimes used to denote the formats of HEX files that employ specific subsets of record types. For example:

* '''I8HEX''' (aka '''HEX-80''') files use only record types {{Intel HEX|||00||}} and {{Intel HEX|||01||}}
* '''I16HEX''' (aka '''HEX-86''') files use only record types {{Intel HEX|||00||}} through {{Intel HEX|||03||}}<ref name="Intel_1980_FU-UG"/>
* '''I32HEX''' (aka '''HEX-386''') files use only record types {{Intel HEX|||00||}}, {{Intel HEX|||01||}}, {{Intel HEX|||04||}}, and {{Intel HEX|||05||}}

==File example==
This example shows a file that has four data records followed by an end-of-file record:
{{Intel HEX|10|0100|00|214601360121470136007EFE09D21901|40}}
{{Intel HEX|10|0110|00|2146017E17C20001FF5F160021480119|28}}
{{Intel HEX|10|0120|00|194E79234623965778239EDA3F01B2CA|A7}}
{{Intel HEX|10|0130|00|3F0156702B5E712B722B732146013421|C7}}
{{Intel HEX|00|0000|01||FF}}

{{legend inline|#FFFFCC|Start code}}
{{legend inline|#CCFFCC|Byte count}}
{{legend inline|#CCCCFF|Address}}
{{legend inline|#FFCCCC|Record type}}
{{legend inline|#CCFFFF|Data}}
{{legend inline|#CCCCCC|Checksum}}

=={{anchor|DRI|Mostek|TDL|TI|MS|ct|Universal}}Variants==
Besides Intel's own extension, several third-parties have also defined variants and extensions of the Intel hex format, including [[Digital Research]] (as in the so-called "Digital Research hex format"<ref name="DRI_1983_CPM86-PG"/><ref name="DRI_1984_CCPM-PRG"/>), [[Zilog]], [[Mostek]],<ref name="Formaniak-Leitch_1977"/><ref name="Ogdin-Colvin-Pittman-Tubb_1977"/> [[Technical Design Labs|TDL]],<ref name="Ogdin-Colvin-Pittman-Tubb_1977"/><ref name="Kreidl_1981"/> [[Texas Instruments]], [[Microchip (company)|Microchip]],<ref name="Kanda_2012"/><ref name="Microchip_2018"/> [[c't]], Wayne and Layne,<ref name="Beckler_2016"/> and [[BBC]]/[[Micro:bit Educational Foundation]] (with its "Universal Hex Format"<ref name="BBC_2021_Universal"/>). These can have information on [[program entry point]]s and [[processor register content|register content]]s, a [[swapped byte order]] in the data fields, [[fill value]]s for unused areas, [[fuse bit]]s, and other differences.

The Digital Research hex format for 8086 processors supports segment information by adding record types to distinguish between code, data, stack, and extra segments.<ref name="DRI_1981_CPM86-SG"/><ref name="DRI_1983_CPM86-PG"/><ref name="DRI_1984_CCPM-PRG"/>

Most assemblers for [[CP/M-80]] (and also [[XASM09]] for the [[Motorola 6809]]) don't use record type 01h to indicate the end of a file, but use a zero-length data type 00h entry instead.<ref name="Kildall_1978"/><ref name="Arnold_2020_AS"/> This eases the concatenation of multiple hex files.<ref name="Zschocke_1987"/><ref name="Prior_1989"/><ref name="Arnold_2020_AS"/>

Texas Instruments defines a variant where addresses are based on the bit-width of a processor's registers, not bytes.

{{anchor|INHX08S|INHX08M|INHX16|INHX32}}Microchip defines variants INTHX8S<ref name="Microchip_1994"/> (INHX8L,<ref name="Arnold_2020_AS"/> INHX8H<ref name="Arnold_2020_AS"/>), INHX8M,<ref name="Microchip_1994"/><ref name="Arnold_2020_AS"/><ref name="Lucid_INHX8M"/> INHX16<ref name="Microchip_1994"/> (INHX16M<ref name="Arnold_2020_AS"/>) and INHX32<ref name="Lucid_INHX32"/> for their [[PIC microcontroller]]s.

Alfred Arnold's cross-macro-assembler AS,<ref name="Arnold_2020_AS"/> Werner Hennig-Roleff's [[Intel 8051|8051]]-emulator SIM51,<ref name="Hennig-Roleff_1993"/> and Matthias R. Paul's cross-converter BINTEL<ref name="Paul_1992"/> are also known to define extensions to the Intel hex format.<!-- Details to be added later. -->


== See also ==
== See also ==
* [[Binary-to-text encoding]], a survey and comparison of encoding algorithms
* [[SREC (file format)|SREC]] - File format
* [[Text-based protocol]]
* [[MOS Technology file format]]
* [[Motorola S-record hex format]]
* [[Tektronix hex format]]
* [[Texas Instruments TI-TXT]]<!-- red link with possibilities --> (TI Text)<!-- another hex file format -->
* [[Micro Computer Set (disambiguation)|Intel Micro Computer Set]]<!-- deliberately link to disambiguation page as there are many Intel MCSes --> (MCS)
* [[Object file]] (typically binary, but sometimes also in Intel hex format)


==References==
== External links ==
{{over-quotation|date=October 2023}}
* [http://www.microsym.com/content/index.php?pid=4&id=25 Intel Hexadecimal Object File Format Specification 1988 (PDF)], Revision A, January 6, 1988
{{Reflist|refs=
* [http://www.piclist.com/techref/fileext/hex/intel.htm Format description at PIC List]
<ref name="DRI_1981_CPM86-SG">{{cite book |title=CP/M-86 Operating System - System Guide |chapter=3.1. Intel 8086 Hex File Format |date=June 1981 |edition=2nd printing, 1st |publisher=[[Digital Research]] |location=Pacific Grove, California, USA |pages=15–16 |url=http://www.bitsavers.org/pdf/digitalResearch/cpm-86/CPM-86_System_Guide_Jun81.pdf |access-date=2020-02-28 |url-status=live |archive-url=https://web.archive.org/web/20200228220027/http://www.bitsavers.org/pdf/digitalResearch/cpm-86/CPM-86_System_Guide_Jun81.pdf |archive-date=2020-02-28 |quote-page=16 |quote=[…] The following are output from ASM-86 only: 81 same as 00, data belongs to [[code segment]] […] 82 same as 00, data belongs to [[data segment]] […] 83 same as 00, data belongs to [[stack segment]] […] 84 same as 00, data belongs to [[extra segment]] […] 85 [[paragraph address]] for absolute code segment […] 86 paragraph address for absolute data segment […] 87 paragraph address for absolute stack segment […] 88 paragraph address for absolute extra segment […] All characters preceding the colon for each record are ignored. […]}} (17 pages)</ref>
* [http://www.lucidtechnologies.info/intel.htm Format description]
<ref name="DRI_1983_CPM86-PG">{{cite book |title=CP/M-86 - Operating System - Programmer's Guide |chapter=Appendix C. ASM-86 Hexadecimal Output Format |date=January 1983 |orig-date=1981 |edition=3 |publisher=[[Digital Research]] |location=Pacific Grove, California, USA |pages=97–100 |url=http://www.bitsavers.org/pdf/digitalResearch/cpm-86/CPM-86_Programmers_Guide_Jan83.pdf |access-date=2020-02-27 |url-status=live |archive-url=https://web.archive.org/web/20200227225328/http://www.bitsavers.org/pdf/digitalResearch/cpm-86/CPM-86_Programmers_Guide_Jan83.pdf |archive-date=2020-02-27 |quote-pages=97–99 |quote=[…] The [[Intel]] format is identical to the format defined by Intel for the [[Intel 8086|8086]]. The [[Digital Research]] format is nearly identical to the Intel format, but adds segment information to hexadecimal records. Output of either format can be input to [[GENCMD (CP/M command)|GENCMD]], but the Digital Research format automatically provides segment identification. A segment is the smallest unit of a program that can be relocated. […] It is in the definition of record types 00 and 02 that Digital Research's hexadecimal format differs from Intel's. Intel defines one value each for the data record type and the segment address type. Digital Research identifies each record with the segment that contains it. […] 00H for data belonging to all 8086 segments […] 81H for data belonging to the [[CODE segment]] […] 82H for data belonging to the [[DATA segment]] […] 83H for data belonging to the [[STACK segment]] […] 84H for data belonging to the [[EXTRA segment]] […] 02H for all segment address records […] 85H for a CODE absolute segment address […] 86H for a DATA segment address […] 87H for a STACK segment address […] 88H for an EXTRA segment address […]}} [https://web.archive.org/web/20200227132338/https://www.z80cpu.eu/mirrors/oldcomputers.dyndns.org/public/pub/manuals/cpm86pg.pdf] (1+viii+122+2 pages)</ref>
* [http://sf.net/projects/srecord SRecord], multi-platform [[GPL]]'ed tool for manipulating EPROM load files.
<ref name="DRI_1984_CCPM-PRG">{{cite book |title=Concurrent CP/M Operating System - Programmer's Reference Guide |chapter=4.3 Intel Hexadecimal File Format |date=January 1984 |edition=1 |publisher=[[Digital Research Inc.]] |location=Pacific Grove, California, USA |pages=4-9–4-12 |url=http://www.cpm.z80.de/manuals/ccpmprg.pdf |access-date=2021-12-11 |url-status=live |archive-url=https://web.archive.org/web/20211211143345/http://www.cpm.z80.de/manuals/ccpmprg.pdf |archive-date=2021-12-11 |quote-pages=4-11–4-12 |quote=[…] The following are output from ASM-86 only: 81 same as 00, data belongs to [[Code Segment]] […] 82 same as 00, data belongs to [[Data Segment]] […] 83 same as 00, data belongs to [[Stack Segment]] […] 84 same as 00, data belongs to [[Extra Segment]] […] *85 [[paragraph address]] for absolute Code Segment […] *86 paragraph address for absolute Data Segment […] *87 paragraph address for absolute Stack Segment […] *88 paragraph address for absolute Extra Segment […] * 85, 86, 87, and 88 are Digital Research Extensions. […] All characters preceding the colon for each record are ignored. […]}} (346 pages) (NB. This manual marks only types 85, 86, 87 and 88 as Digital Research extensions, as if types 81, 82, 83, 84 were not.)</ref>
* [http://home.kpn.nl/newlife-software/Binex/binex.htm Binex], a converter between Intel HEX and binary.
<ref name="Intel_1977">{{cite book |title=MCS-80 User's Manual (With Introduction to MCS-85) |chapter=Chapter 6. Microcomputer System Component Data Sheet - EPROMs and ROMs: I. PROM and ROM Programming Instructions - B1. Intellec Hex Paper Tape Format / C1. Intellec Hex Computer Punched Card Format |date=October 1977 |orig-date=1975 |publisher=[[Intel Corporation]] |publication-place=Santa Clara, California, USA |id=98-153D |pages=6-75–6-78 |url=https://archive.org/details/bitsavers_intelMCS80ualOct77_38961682/ |access-date=2020-02-27 |quote-page=6-76 |quote=[…] In the Intel Intellec Hex Format, a data field can contain either 8 or 4-bit data. Two ASCII hexadecimal characters must be used to represent both 8 and 4-bit data. In the case of 4-bit data, only one of the characters is meaningful and must be specified on the Intel PROM/ROM Order Form. […] Preceding the first data field and following the last data field there must be a leader/trailer length of at least 25 null characters. Comments (except for a colon) may be placed on the [[tape leader]]. […] If the data is 4 bit, then either the high or low-order digit represents the data and the other digit of the pair may be any ASCII hexadecimal digit. […]}} [https://archive.org/stream/bitsavers_intelMCS80ualOct77_38961682/98-153D__MCS-80_Users_Manual_Oct77_djvu.txt][https://archive.org/download/bitsavers_intelMCS80ualOct77_38961682/98-153D__MCS-80_Users_Manual_Oct77.pdf] (468 pages) (NB. This manual also describes a "[[BPNF]]<!-- no typo! --> Paper Tape Format", a "Non-Intellec Hex Paper Tape Format" and a "PN Computer Punched Card Format".)</ref>
* [http://www.x-ways.net/winhex Winhex], WinHex is a universal hexadecimal editor which can parse Intel Hex files.
<ref name="Intel_1979_2920">{{cite book |title=2920 Assembly Language Manual |chapter=Appendix A. Example of Listing Format / Appendix C. Hexadecimal Object File Format |publisher=[[Intel Corporation]] |publication-place=Santa Clara, California, USA |date=August 1979 |id=Order Number 9800987-01 |pages=A-3, C-1–C-2 |url=http://www.bitsavers.org/components/intel/2920/9800987-01_2920_Assembly_Language_Manual_Aug79.pdf |access-date=2023-11-26 |url-status=live |archive-url=https://web.archive.org/web/20231126184042/http://www.bitsavers.org/components/intel/2920/9800987-01_2920_Assembly_Language_Manual_Aug79.pdf |archive-date=2023-11-26 |quote-page=C-1 |quote=[…] The code is formatted in hexadecimal bytes of data. The file contains the ASCII representation of the hexadecimal bytes of data. The object code itself is preceded by a symbol table. These two parts may be loaded or saved together or separately. The symbol table is a series of records, terminated by a dollar sign. Each record contains three fields separated by one or more ASCII spaces: […] a number field […] a label field containing the ASCII representation of a source program symbol […] an address field containing the hexadecimal address assigned to the symbol […] The symbol table is terminated by a record whose first nonblank character is a dollar sign. The object code […] follows the symbol table […] Each of these records or physical lines is six logical fields of varying length in characters or frames. […]}} (90 pages) (NB. The [[Intel 2920]] was a [[digital signal processor]] released in 1979.)</ref>
<ref name="Intel_1980_FU-UG">{{cite book |title=8086 Family Utilities - User's Guide for 8080/8085-Based Development Systems |chapter=Appendix D. MCS-86 Absolute Object File Formats: Hexadecimal Object File Format |id=Order Number 9800639-04 |edition=A620/5821 6K DD |version=Revision E |date=May 1982 |orig-date=1980, 1978 |publisher=[[Intel Corporation]] |publication-place=Santa Clara, California, USA |pages=D-8–D-13 |url=http://bitsavers.trailing-edge.com/pdf/intel/ISIS_II/9800639-04E_8086_Famility_Utilities_Users_Guide_May82.pdf |access-date=2020-02-29 |url-status=live |archive-url=https://web.archive.org/web/20200229032355/http://bitsavers.trailing-edge.com/pdf/intel/ISIS_II/9800639-04E_8086_Famility_Utilities_Users_Guide_May82.pdf |archive-date=2020-02-29}}</ref>
<ref name="Intel_1988_DevTools">{{cite book |title=Development Tools Catalog 1988 |date=1988 |publisher=[[Intel Corporation]] |id=Order Number 280199-004 |pages=25–26, 30–32 |url=http://bitsavers.informatik.uni-stuttgart.de/components/intel/_dataBooks/1988_Intel_Development_Tools_Catalog.pdf |access-date=2023-11-26 |url-status=live |archive-url=https://web.archive.org/web/20231126190845/http://bitsavers.informatik.uni-stuttgart.de/components/intel/_dataBooks/1988_Intel_Development_Tools_Catalog.pdf |archive-date=2023-11-26}} (46 pages)</ref>
<ref name="Intel_1988_Spec">{{cite book |title=Hexadecimal Object File Format Specification |publisher=[[Intel Corporation]] |version=Revision A |date=1998 |orig-date=1988-01-06 |url=https://archive.org/details/IntelHEXStandard |access-date=2019-07-23}} [https://archive.org/stream/IntelHEXStandard_djvu.txt][https://archive.org/download/IntelHEXStandard.pdf][https://web.archive.org/web/20210303163219/http://grantronics.com.au/docs/intelhex.pdf][https://web.archive.org/web/20210213214209/http://www.interlog.com/~speff/usefulinfo/Hexfrmt.pdf][https://web.archive.org/web/20170713170953/http://microsym.com/editor/assets/intelhex.pdf]<!-- originally available at: ftp://download.intel.com/support/processors/i960/devtools/intelhex.pdf--> (11 pages)</ref>
<ref name="ARM_hex">{{cite web |title=General: Intel Hex File Format |date=2018-05-07 |orig-date=2012 |publisher=[[ARM Germany GmbH]] |id=KA003292 |work=ARM Keil |url=http://www.keil.com/support/docs/1584/ |access-date=2017-09-06 |url-status=dead |archive-url=https://web.archive.org/web/20200227152235/http://www.keil.com/support/docs/1584/ |archive-date=2020-02-27}} [https://developer.arm.com/documentation/ka003292/latest/]</ref>
<ref name="Zschocke_1987">{{cite magazine |title=Nicht nur Entwicklungshilfe - Down-Loading für Einplatinencomputer am Beispiel des EPAC-09: Intel-Hex-Format |author-first=Jörg |author-last=Zschocke |language=de |date=November 1987 |volume=1987 |issue=11 |magazine=[[c't - magazin für computertechnik]] |publisher=[[Verlag Heinz Heise GmbH & Co. KG]] |issn=0724-8679 |pages=198, 200, 202–203, [200<!-- relevant page -->] |quote=[…] Den Vorspann beschließt ein Byte, dessen Wert den Typ des Blockes angibt: 0 = Datenblock, 1 = Endblock. Auf diese Unterscheidung kann jedoch verzichtet werden, wenn sich ein Endblock auch durch eine Blocklänge gleich Null eindeutig kennzeichnen läßt. (So verfahren die meisten Assembler unter [[CP/M-80|CP/M]], auch der XASM09; das Typbyte ist dann immer Null). […]}} [https://web.archive.org/web/20200227163021/https://www.z80cpu.eu/mirrors/oldcomputers.dyndns.org/public/pub/User-Clubs/Genie_und_TRS80_User_Club/Club-80_heft_37.pdf<!-- on page 21, this journal cites the corresponding c't article -->] (NB. [[XASM09]] is a [[Motorola 6809]] assembler.)</ref>
<ref name="Prior_1989">{{cite newsgroup |title=Re: Intel hex (*.HEX) format questions |author-first=James E. |author-last=Prior |date=1989-02-24 |newsgroup=comp.os.cpm |url=https://groups.google.com/d/msg/comp.os.cpm/jR7XFEd-dBA/ULjghMjqj5MJ |access-date=2020-02-27}}</ref>
<ref name="Feichtinger_1987">{{cite book |author-first=Herwig |author-last=Feichtinger |title=Arbeitsbuch Mikrocomputer |trans-title=Microcomputer work book |chapter=1.8.5. Lochstreifen-Datenformate: Das Intel-Hex-Format |trans-chapter=1.8.5. Paper tape data formats |language=de |location=Munich, Germany |publisher=[[Franzis-Verlag GmbH]] |isbn=3-7723-8022-0 |date=1987 |edition=2 |pages=240–243 [243<!-- relevant page -->]}}</ref>
<ref name="Arnold_2020_AS">{{cite book |title=Macro Assembler AS - User's Manual |version=V1.42 |author-first=Alfred "Alf" |author-last=Arnold |translator-first1=Alfred "Alf" |translator-last1=Arnold |translator-first2=Stefan |translator-last2=Hilse |translator-first3=Stephan |translator-last3=Kanthak |translator-first4=Oliver |translator-last4=Sellke |translator-first5=Vittorio |translator-last5=De Tomasi |publisher=none |publication-place=Aachen, Germany |date=2020 |orig-date=1996, 1989 |chapter=6.3. P2HEX |chapter-url=http://john.ccac.rwth-aachen.de:8000/as/as_EN.html#sect_6_3_ |url=http://john.ccac.rwth-aachen.de:8000/as/as_EN.html |access-date=2020-02-28 |url-status=live |archive-url=https://web.archive.org/web/20200228144943/http://john.ccac.rwth-aachen.de:8000/as/as_EN.html |archive-date=2020-02-28 |quote=[…] For the [[PIC microcontroller]]s, the switch -m <0..3> allows to generate the three different variants of the Intel Hex format. Format 0 is INHX8M which contains all bytes in a Lo-Hi-Order. Addresses become double as large because the PICs have a word-oriented address space that increments addresses only by one per word. […] With Format 1 (INHX16M), bytes are stored in their natural order. This is the format [[Microchip Technology|Microchip]] uses for its own programming devices. Format 2 (INHX8L) resp. 3 (INHX8H) split words into their lower resp. upper bytes. […] Unfortunately, one finds different statements about the last line of an Intel-Hex file in literature. Therefore, P2HEX knows three different variants that may be selected […] :00000001FF […] :00000001 […] :0000000000 […] By default, variant 0 is used which seems to be the most common one. […] If the target file name does not have an extension, an extension of HEX is supposed. […]}}</ref>
<ref name="Microchip_1994">{{cite book |title=Microchip Databook |chapter=PIC16C5X Programming Specification 5.0 - PIC16C5X Hex Data Formats: 5.1. 8-Bit Split Intellec Hex Format (INHX8S) / 5.2. 8-Bit Merged Intellec Hex Format (INHX8M) / 5.3. 16-Bit Hex Format / 5.4. 8-Bit Word Format / 5.5. 16-Bit Word Format |date=April 1994 |publisher=[[Microchip Technology Inc.]] |edition=1994 |id=DS00018G |pages=3-10–3-11, ((9-10)), ((9-15)), ((9-17)), ((9-21)), ((9-23)), ((9-27)) |url=https://archive.org/details/MicrochipDatabook1994/ |access-date=2020-02-28 |quote=[…] Assemblers for the PIC16C5X can produce PIC16C5X object files in various formats. A PIC16C5X programmer must be able to accept and send data in at least one of following formats. The 8-bit merged (INHX8M) format is preferred. […] format […] INHX8S […] produces two 8-bit Hex files. One file will contain the address / data pairs for the high order 8-bits and the other file will contain the low order 8-bits. File extensions for the object code will be '.obl' and '.obh' for low and high order files […] format […] INHX8M […] produces one 8-bit Hex file with a low byte / high byte combination. Since each address can only contain 8 bits in this format, all addresses will be doubled. File extensions for the object code will be '.obj' […] format […] INHX16 […] produces one 16-bit Hex file. File extension for the object code will be '.obj'. […]}} [https://archive.org/stream/MicrochipDatabook1994/MicrochipDatabook1994_djvu.txt][https://archive.org/download/MicrochipDatabook1994/MicrochipDatabook1994_text.pdf]</ref>
<ref name="Microchip_2018">{{cite book |title=MPLAB XC16 Assembler, Linker and Utilities - User's Guide |chapter=15.3 XC16-BIN2HEX Utility - 15.3.3 Input/Output Files |date=2018 |orig-date=2013 |publisher=[[Microchip Technology Inc.]] |isbn=978-1-5224-2828-2 |id=DS50002106D |pages=240–241 |url=https://ww1.microchip.com/downloads/en/DeviceDoc/DS50002106D.pdf |access-date=2023-12-05 |url-status=live |archive-url=https://web.archive.org/web/20190122055940/http://ww1.microchip.com/downloads/en/DeviceDoc/DS50002106D.pdf |archive-date=2019-01-22 |quote-page=240 |quote=[…] Because the Intel hex file format is byte-oriented, and the 16-bit PC is not, program memory sections require special treatment. Each 24-bit program word is extended to 32 bits by inserting a so-called "phantom byte". Each program memory address is multiplied by 2 to yield a byte address. For example, a section that is located at 0x100 in program memory will be represented in the hex file as 0x200. Consider the following assembly language source: […] ; file test.s […] .section foo,code,address(0x100) […] .pword 0x112233 […] The file […] will be produced, with the following contents: […] :020000040000fa […] :040200003322110096 […] :00000001FF […] the data record (line 2) has a load address of 0200, while the source code specified address 0x100. […]t the data is represented in "[[little-endian]]" format, meaning the least significant byte appears first. The phantom byte appears last, just before the checksum. […]}} (277 pages)</ref>
<ref name="Lucid_INHX8M">{{cite web |title=Microchip INHX8M HEX-record Format |author-first=Brian |author-last=Beard |date=2016 |orig-date=2010 |work=[[Lucid Technologies]] |url=http://www.lucidtechnologies.info/inhx8m.htm |access-date=2020-02-28 |url-status=live |archive-url=https://web.archive.org/web/20200228153648/http://www.lucidtechnologies.info/inhx8m.htm |archive-date=2020-02-28}}</ref>
<ref name="Lucid_INHX32">{{cite web |title=Microchip INHX32 HEX-record Format |author-first=Brian |author-last=Beard |date=2016 |orig-date=2013 |work=[[Lucid Technologies]] |url=http://www.lucidtechnologies.info/inhx32.htm |access-date=2020-02-28 |url-status=live |archive-url=https://web.archive.org/web/20200228153623/http://www.lucidtechnologies.info/inhx32.htm |archive-date=2020-02-28}}</ref>
<ref name="IDA_2006_Hexforms">{{cite web |title=The Interactive Disassembler - Hexadecimal fileformats |date=2006 |publisher=[[Hex-Rays]] |url=https://hwiegman.home.xs4all.nl/fileformats/hex/hexforms.htm |access-date=2020-03-01 |url-status=dead |archive-url=https://web.archive.org/web/20200301141412/https://hwiegman.home.xs4all.nl/fileformats/hex/hexforms.htm |archive-date=2020-03-01 }} [http://www.idea2ic.com/File_Formats/Hexadecimal%20file%20formats.pdf] {{Webarchive|url=https://web.archive.org/web/20211116195244/http://www.idea2ic.com/File_Formats/Hexadecimal%20file%20formats.pdf |date=2021-11-16 }}</ref>
<ref name="Xilinx_2010_MCS">{{cite web |title=AR#476 PROMGen - Description of PROM/EEPROM file formats: MCS, EXO, HEX, and others |at=Intel MCS-86 Hexadecimal Object - File Format Code 88 |date=2010-03-08 |publisher=[[Xilinx]] |url=https://www.xilinx.com/support/answers/476.html |access-date=2020-03-03 |url-access=registration |url-status=live |archive-url=https://web.archive.org/web/20200303085851/https://www.xilinx.com/support/answers/476.html |archive-date=2020-03-03}}</ref>
<ref name="Formaniak-Leitch_1977">{{cite magazine |title=A Proposed Microprocessor Software Standard |author-first1=Peter G. |author-last1=Formaniak |author-first2=David |author-last2=Leitch |series=Technical Forum |magazine=[[BYTE]] - the small systems journal |publisher=[[Byte Publications, Inc.]] |publication-place=Peterborough, New Hampshire, USA |volume=2 |number=7 |date=July 1977 |id=ark:/13960/t32245485 |pages=34, 62–63 |url=https://archive.org/details/byte-magazine-1977-07/page/n35/mode/1up |access-date=2021-12-06}} (3 pages) (NB. Describes an extension of the Intel hex format by [[Mostek]].)</ref>
<ref name="Ogdin-Colvin-Pittman-Tubb_1977">{{cite journal |title=Relocatable Object Code Formats |author-first1=Carol Anne |author-last1=Ogdin |author-first2=Neil |author-last2=Colvin |author-first3=Tom |author-last3=Pittman |author-first4=Philip |author-last4=Tubb |series=Technical Forum |journal=BYTE - the Small Systems Journal |publisher=[[Byte Publications, Inc.]] |publication-place=Peterborough, New Hampshire, USA |volume=2 |number=11 |date=November 1977 |id=ark:/13960/t59c88b4h, ark:/13960/t3kw76j24 |pages=198–205 |url=https://archive.org/details/byte-magazine-1977-11-rescan/page/n199/mode/1up |access-date=2021-12-06}} (8 pages) (NB. Besides others describes an incompatible extension of the Intel hex format used by [[Technical Design Labs]] (TDL).)</ref>
<ref name="Intel_1973_Intellec8">{{cite book |title=Intellec 8 Microcomputer System Operator's Manual |publisher=[[Intel Corporation]] |date=November 1973}}</ref>
<ref name="Intel_1974_MOD8">{{cite book |title=Intellec 8/MOD 80 Operators Manual |chapter=Appendix D. Hexadecimal Program Tape Format |date=June 1974 |id=98-003A |publisher=[[Intel]] |quote=[…] Frames 7,8: Record Type […] Two ASCII characters. Currently (1974), all records are type 0. This field is reserved for future expansion […]}} [https://web.archive.org/web/20211206162538/https://groups.google.com/g/comp.os.cpm/c/UDECGfCYw6w]</ref>
<ref name="Intel_1974_PLM">{{cite book |title=MCS-8 A Guide to PL/M programming |version=Rev 1 |orig-date=September 1973 |date=1974-03-15 |edition=printed September 1974 |chapter=Appendix A: A Sample Program in PL/M: Hexidecimal Object Tape<!-- Hexidecimal is a typo in the original source! --> |page=102<!-- on PDF page 114 --> |id=MCS180-0774-1K, MCS280-0974-1K |publisher=[[Intel Corporation]] |publication-place=Santa Clara, California, USA |url=http://bitsavers.informatik.uni-stuttgart.de/components/intel/MCS8/MCS-8_A_Guide_to_PLM_Programming_Sep73.pdf |access-date=2022-05-18 |url-status=live |archive-url=https://web.archive.org/web/20220129035351/http://bitsavers.informatik.uni-stuttgart.de/components/intel/MCS8/MCS-8_A_Guide_to_PLM_Programming_Sep73.pdf |archive-date=2022-01-29 |quote-page=102 |quote=<code><br/>&nbsp;&nbsp;&nbsp;&nbsp;1 CARRY 05714<br/>&nbsp;&nbsp;&nbsp;&nbsp;2 ZERO 05715<br/>&nbsp;&nbsp;&nbsp;&nbsp;3 SIGN 05716<br/>&nbsp;&nbsp;&nbsp;&nbsp;4 PARITY 05717<br/>&nbsp;&nbsp;&nbsp;&nbsp;5 MEMORY 06000<br/>&nbsp;&nbsp;&nbsp;23 SQUAREROOT 04003<br/>[…]<br/>&nbsp;&nbsp;&nbsp;83 MONITORUSES 05766<br/>&nbsp;$<br/>****************************************<br/>:1008000044520A2E0B36D0F930FA31CF30D730F9B6<br/>[…]<br/>:100AF0000936F4C730D70401C8C20C0031F930F808<br/>:040B0000445E0AFF46<br/>****************************************<br/>:0000000000<br/>&nbsp;$</code>}} (1+i+100+1+11+1 pages) (NB. Shows an example containing [[asterisk]]-based separators and a space-indented header with symbol names to be processed by [[Intel ISIS]]'s [[HEXOBJ]] command as well as by [[INTERP/8]] or [[INTERP/80]] for [[symbolic debugging]]. This optional header is not documented as part of Intel hex or [[BNPF]] formats but in Intel's [[PL/M]] and assembler programming manuals producing such symbol tables.)</ref>
<ref name="Kildall_1978">{{cite journal |author-first=Gary Arlen |author-last=Kildall |author-link=Gary Arlen Kildall |title=A simple technique for static relocation of absolute machine code |journal=[[Dr. Dobb's Journal of Computer Calisthenics & Orthodontia]] |publisher=[[People's Computer Company]] |volume=3 |issue=2 |id=#22<!-- |number=22 --> ark:/13960/t8hf1g21p |date=February 1978 |orig-date=<!-- November -->1976 |pages=10–13<!-- in the issue --> (66–69<!-- in the volume -->) |isbn=0-8104-5490-4<!-- of the volume --> |url=https://archive.org/details/dr_dobbs_journal_vol_03/page/n67/mode/1up |access-date=2017-08-19}} [https://web.archive.org/web/20170819141800/http://www.retrotechnology.com/dri/d_dri_refs.html][https://web.archive.org/web/20170819173516/http://archive.computerhistory.org/resources/access/text/2016/12/102762506-05-01-acc.pdf][https://archive.today/20170909091943/https://groups.google.com/forum/%23!msg/comp.os.cpm/TLHgIi16yTo/gupNB1ai8UQJ#!topic/comp.os.cpm/TLHgIi16yTo]. Originally presented at: {{cite conference |title=Conference Record: Tenth Annual Asilomar Conference on Circuits, Systems and Computers: Papers Presented November 22–24, 1976 |editor-first=Harold A. |editor-last=Titus |chapter=A Simple Technique for Static Relocation of Absolute Machine Code |author-first=Gary Arlen |author-last=Kildall |journal=Asilomar Conference on Signals, Systems & Computers |author-link=Gary Arlen Kildall |<!-- written-at -->location=[[Naval Postgraduate School]], Monterey, California, USA |publisher=Western Periodicals Company |publication-place=Asilomar Hotel and Conference Grounds, Pacific Grove, California, USA |date=1977 |orig-date=22–24 November 1976 |issn=1058-6393 |pages=420–424 |url=https://books.google.com/books?id=cyBGAQAAIAAJ&q=relocation |access-date=2021-12-06}} (609 pages)</ref>
<ref name="Kildall_1993">{{Cite book |orig-date=1993 |date=2016-08-02 |title=Computer Connections: People, Places, and Events in the Evolution of the Personal Computer Industry |author-first=Gary Arlen |author-last=Kildall |author-link=Gary Kildall |editor-first1=Scott |editor-last1=Kildall |editor-link=Scott Kildall |editor-first2=Kristin |editor-last2=Kildall |publisher=Kildall Family |type=Manuscript, part 1 |url=http://www.computerhistory.org/atchm/computer-history-museum-license-agreement-for-the-kildall-manuscript/ |access-date=2016-11-17 |url-status=live |archive-url=https://web.archive.org/web/20161117232745/http://s3data.computerhistory.org/kildall-p.1-78-publishable-lowres.pdf |archive-date=2016-11-17}} (NB. Part 2 not released due to family privacy reasons.)<!-- For the reason why Part 2 was not released to the public, see url=https://spectrum.ieee.org/view-from-the-valley/geek-life/history/cpm-creator-gary-kildalls-memoirs-released-as-free-download | Quote: "Later chapters, they indicated, did "not reflect his true self," but rather his struggles with alcoholism, and will remain unpublished." --></ref>
<ref name="Kildall_1980_CPM">{{Cite journal |title=The History of CP/M, The Evolution of an Industry: One Person's Viewpoint |author-first=Gary Arlen |author-last=Kildall |author-link=Gary Kildall |date=January 1980 |journal=[[Dr. Dobb's Journal of Computer Calisthenics & Orthodontia]] |pages=6–7 |volume=5 |issue=1 |id=#41 |url=http://www.retrotechnology.com/dri/CPM_history_kildall.txt |access-date=2013-06-03 |url-status=live |archive-url=https://web.archive.org/web/20161124221907/http://www.retrotechnology.com/dri/CPM_history_kildall.txt |archive-date=2016-11-24 |quote=[…] Programs had been written and tested by Intel's software group, consisting of myself and two other people, and we were ready for the real machine. […]}}</ref>
<ref name="Hennig-Roleff_1993">{{cite web |title=HEX.DOC: Intel-HEX-Format |author-first=Werner |author-last=Hennig-Roleff |language=de |date=1993-02-01 |orig-date=1988 |version=1.04 |work=SIM51 |url=http://spot.fho-emden.de/ftp/micro/sim51_04.zip |access-date=2021-12-08 |url-status=live |archive-url=https://web.archive.org/web/20170811161238/http://spot.fho-emden.de/ftp/micro/sim51_04.zip |archive-date=2017-08-11 |quote=[…] Beim Absolut-Hex Konvertierprogramm von [[Keil (company)|Keil]] können optional […] Symbol-Informationen in den Hex-File aufgenommen werden. Die Symbol-Informationen stehen dabei am Anfang des Files, vor dem ersten ':'. Die Symbol-Informationen sind allerdings nicht sehr aussagekräftig, da nicht unterschieden wird zwischen Modul-Name, CODE, XDATA, DATA, IDATA, BIT, NUMBER. Für jeden Symboleintrag werden nur ASCII-Zeichen verwendet. Pro Zeile ist 1 Symbol angeschrieben und zwar in der Form: "0 SymbolName Wert" […]}} [https://web.archive.org/web/20210806202253/https://www.dos4ever.com/8031board/SIM51D_BASIC.zip][https://web.archive.org/web/20210806202253/https://www.dos4ever.com/8031board/SIM51_06.zip] (NB. This is an older version of SIM51, the software and documentation was maintained up to 1996.)</ref>
<ref name="Roche_2020">{{cite newsgroup |title=The Intel HEX File Format |author-first=Emmanuel |author-last=Roche |newsgroup=comp.os.cpm |date=2020-04-01 |location=France |id=INTELHEX.WS4 |url=https://groups.google.com/g/comp.os.cpm/c/QJmImGGNXko |access-date=2021-12-08 |url-status=live |archive-url=https://web.archive.org/web/20211208211459/https://groups.google.com/g/comp.os.cpm/c/QJmImGGNXko |archive-date=2021-12-08 |quote=[…] the [[Intel]] HEX file format can contain much more than the "data bytes". As long as the lines do not start with a colon (":"), they can contain anything that you want. […] I once saw a big HEX file […] It contained, at the beginning, the source code of a [[PL/M]] program, followed, at the end, by the resulting HEX file produced by the PL/M compiler. […] I found another HEX file containing several lines of comments, not at the beginning or at the end, but separating several lines of "absolute records". […] it was from an "(Intel) [[Intel 8008|8008]] Simulator". So, at the beginning of its use, it was well known that HEX files could contain explanations. […] under [[CP/M]] or any 8-bit 64K system, there remains one case: "Page addresses". Since CP/M, it is standard to display memory addresses using the hexadecimal system […] as we said for BIN/COM files, the memory addresses are 0000/0100. […] those memory addresses can be written 00-00/01-00 […] to say: Page zero, address zero / Page one, address zero. […] the highest memory address in a 8-bit 64K computer is FFFF […] Page FF, address FF […] the lowest addresses are in Page zero (or 00) and the highest addresses are in Page FF. […] CP/M filetypes are 3-letters long, one could use filetypes of the form P00–PFF […] to indicate at which memory address where to load the HEX file. […] I noticed that most of my addresses were ending with "00", so the loading address could be reduced to the Page address, which […] could be put inside the filetype […]}}</ref>
<ref name="BBC_2021_Universal">{{cite web |title=micro:bit Universal Hex Format Specification - Specification for the micro:bit Universal Hex Format |version=0.4.0 |work=micro:bit |publisher=[[Micro:bit Educational Foundation]] |date=2021-01-26 |orig-date=2020 |url=https://tech.microbit.org/software/spec-universal-hex/ |access-date=2021-12-08 |url-status=live |archive-url=https://web.archive.org/web/20210814141056/https://tech.microbit.org/software/spec-universal-hex/ |archive-date=2021-08-14}} [https://web.archive.org/web/20211208215259/https://tech.microbit.org/software/hex-format/][https://web.archive.org/web/20211208223209/https://github.com/microbit-foundation/spec-universal-hex/blob/master/spec/format-deprecated.md] (NB. This represents kind of a [[fat binary|fat hex]] file format.)</ref>
<ref name="Beckler_2016">{{cite web |title=Blinky Grid - serial optical bit stream |author-first=Matthew L. |author-last=Beckler |date=2016-07-25 |orig-date=2016-07-19 |publisher=Wayne and Layne, LLC |work=Discourse |publication-place=Minneapolis, Minnesota, USA |url=https://discuss.wayneandlayne.com/t/blinky-grid-serial-optical-bit-stream/161 |access-date=2021-12-11 |url-status=live |archive-url=https://web.archive.org/web/20211211113049/https://discuss.wayneandlayne.com/t/blinky-grid-serial-optical-bit-stream/161 |archive-date=2021-12-11}}</ref>
<ref name="Kanda_2012">{{cite web |title=PIC Microcontrollers: PIC Hex File Format |date=2012-04-26 |work=Kanda Electronics Blog |publisher=Embedded Results Ltd |publication-place=Canolafan, Llanafan, Aberystwyth, Wales, UK |url=https://www.kanda.com/blog/microcontrollers/pic-microcontrollers/pic-hex-file-format/ |access-date=2021-12-11 |url-status=live |archive-url=https://web.archive.org/web/20210816160452/https://www.kanda.com/blog/microcontrollers/pic-microcontrollers/pic-hex-file-format/ |archive-date=2021-08-16}}</ref>
<ref name="Analog_2021">{{cite web |title=LT Programming Hex File Format Documentation -- In Circuit Programming |date=2021 |publisher=[[Analog Devices, Inc.]] / [[Linear Technology]] |url=https://www.analog.com/en/technical-articles/lt-programming-hex-file-format-documentation-in-circuit-programming.html |access-date=2021-12-11 |url-status=live |archive-url=https://web.archive.org/web/20210307035214/https://www.analog.com/en/technical-articles/lt-programming-hex-file-format-documentation-in-circuit-programming.html |archive-date=2021-03-07}}</ref>
<ref name="Kreidl_1981">{{cite journal |title=Relocator: Das TDL-Format |language=de |author-first=Günter |author-last=Kreidl |journal=Nascom journal - Zeitschrift für Anwender des NASCOM 1 oder NASCOM 2 |department=Hardware |publisher=Verlag NASCOM Journal, MK-Systemtechnik |publication-place=Germersheim, Germany |date=June 1981 |volume=2 |issue=6 |pages=12–14 [12] |url=https://tupel.jloh.de/nascom/journal/81/06/12/text/ |access-date=2021-12-11 |url-status=live |archive-url=https://web.archive.org/web/20211201161142/https://tupel.jloh.de/nascom/journal/81/06/12/text/ |archive-date=2021-12-01}} (20 pages) (NB. Shows a variant of the [[Technical Design Labs|TDL]] format, which itself is a variant of the Intel hex format.)</ref>
<ref name="Fujitsu_2001">{{cite book |title=Fujitsu Semiconductor Controller Manual: FR/F<sup>2</sup>MC Family Softune Linkage Kit Manual for V3 |chapter=Appendix B: Intel Hex and Intel Extended Hex Format - B.1 Common Format |date=2001 |publisher=[[Fujitsu Limited]] |pages=319–525 [320–321] |url=https://www.fujitsu.com/downloads/MICRO/fme/displaycontrollers/sm-fr-softune-linkage-kit-rev3.pdf |access-date=2021-12-12 |url-status=live |archive-url=https://web.archive.org/web/20211212030218/https://www.fujitsu.com/downloads/MICRO/fme/displaycontrollers/sm-fr-softune-linkage-kit-rev3.pdf |archive-date=2021-12-12 |quote-page=321 |quote=[…] (g) Generally, a control code (such as CR and LF) is added. Data in this field is skipped until the start character ":" of (a) appears. Since the (a), (b), (c), (d), and (f) fields always exist, the minimum length of a record is 11 bytes long and the maximum length is 521 bytes long. […]}} (4+x+350 pages)</ref>
<ref name="DRI_1982_CPM-M">{{cite book |title=CP/M Operating System Manual |chapter=1.6.4 PIP |publisher=[[Digital Research]] |publication-place=Pacific Grove, California, USA |date=July 1982 |orig-date=1976 |edition=First printing |pages=17–23 |url=https://archive.org/details/CPM_Operating_System_Manual |access-date=2021-12-12 |quote-pages=19–21 |quote=[…] [[PIP (CP/M command)|PIP]] performs a special function if the destination is a disk file with type "HEX" (an [[Intel]] hex-formatted machine code file), and the source is an external peripheral device, such as a [[paper tape reader]]. In this case, the PIP program checks to ensure that the source file contains a properly formed hex file, with legal hexadecimal values and checksum records. When an invalid input record is found, PIP reports an error message at the [[command-line interface|console]] and waits for corrective action. It is usually sufficient to open the reader and rerun a section of the tape (pull the tape back about 20 inches). When the tape is ready for the reread, a single [[carriage return]] is typed at the console, and PIP will attempt another read. If the tape position cannot be properly read, the user continues the read (by typing a return following the error message), and enters the record manually with the [[ED (CP/M command)|ED]] program after the disk file is constructed. For convenience, PIP allows the [[end-of-file]] to be entered from the console if the source file is an [[RDR: (PIP)|RDR:]] device. In this case, the PIP program reads the device and monitors the keyboard. If [[ctl-Z]] is typed at the keyboard the read operation is terminated normally. […] <code>PIP [[PUN: (PIP)|PUN:]]=[[NUL: (PIP)|NUL:]],X.ASM,[[EOF: (PIP)|EOF:]],NUL:</code> […] Send 40 [[null character|null]]s to the [[punch (computing)|punch]] device; copy the X.ASM file to the punch, followed by an end-of-file (ctl-Z) and 40 more null characters. […] <code>H</code> […] HEX data transfer: all data are checked for proper Intel hex file format. Nonessential characters between hex records are removed during the copy operation. The console will be prompted for corrective action in case errors occur. […] <code>I</code> […] Ignore ":00" records in the transfer of Intel hex format file (the I parameter automatically sets the H parameter). […] <code>PIP PUN:=X.HEX[i],Y.ZOT[h]</code> […] First copy X.HEX to the PUN: device and ignore the trailing ":00" record in X.HEX; continue the transfer of data by reading Y.ZOT, which contains HEX records, including any ":00" records it contains. […]}} [https://ia600902.us.archive.org/20/items/CPM_Operating_System_Manual/CPM_Operating_System_Manual.pdf] (6+250 pages)</ref>
<ref name="DataIO_1980_OG">{{cite book |title=Operator Guide To Serial I/O Capabilities of Data I/O Programmers - Translation-Format Package |chapter=2.8. Microprocessor Formats, 2.8.1. Input Requirements: Intel Intellec 8/MDS Format. Select Code 83 |id=055-1901 |version=Revision C |date=October 1980 |publisher=[[Data I/O Corporation]] |page=2-10 |url=http://bitsavers.trailing-edge.com/test_equipment/dataIO/055-1901_System19_transPkg.pdf |access-date=2020-03-01 |url-status=live |archive-url=https://web.archive.org/web/20200301134810/http://bitsavers.trailing-edge.com/test_equipment/dataIO/055-1901_System19_transPkg.pdf |archive-date=2020-03-01 |quote-page=2-10 |quote=[…] Input […] This space can be used for line feed, carriage return or comments. […] Output […] 2) Each line ends with nonprinting line feed, carriage returns and nulls. […]}} (1+ii+19 pages)</ref>
<ref name="DataIO_1987_TFF">{{cite book |title=Translation File Formats |chapter=Intel Intellec 8/MDS Format, Code 83 |date=1987-09-03<!-- or 1987-03-09? --> |publisher=[[Data I/O Corporation]] |pages=22, 26–27, 52–53, 54 |url=ftp://ftp.dataio.com/main/Manuals/UniFam/Translation%20Formats.pdf |access-date=2020-03-01 |url-status=live |archive-url=https://web.archive.org/web/20210728190952/ftp://ftp.dataio.com/main/Manuals/UniFam/Translation%20Formats.pdf |archive-date=2021-07-28 |quote-pages=22, 26, 52 |quote=[…] Nonprinting Carriage Return, line feed, and nulls determined by null count […]}} (56 pages)</ref>
<ref name="Paul_1992">{{cite book |title=BINTEL: Binär-Image-Konverter mit Intel-Hex-Unterstützung - Bedienungsanleitung |language=de |trans-title=Binary image converter with Intel Hex support - User manual |author-first=Matthias R. |author-last=Paul |date=1992}} (NB. As a consequence of the tool's use to process, analyze, compare, split, cut, fill, combine, relocate or convert binary firmware images (f.e. for or from one or more ROMs) with deliberately sticky (fixed "1" or "0"), inverted, omitted ("[[don't care (logic)|don't care]]"), interconnected or swapped data or address lines (as sometimes used to ease [[PCB routing]] of [[parallel bus]]es or for [[code obfuscation|obfuscation]] reasons to make [[disassembly]] more difficult), this binary image converter supported a number of extensions to the Intel Hex format.)</ref>
<ref name="Crosby_1994">{{cite journal |author-last=Crosby |author-first=Kip |date=January–March 1994 |title=Dawn of the Micro: Intel's Intellecs |journal=The Analytical Engine |publisher=Computer History Association of California |volume=1 |issue=3 |issn=1071-6351 |pages=10–14 |url=http://bitsavers.informatik.uni-stuttgart.de/pdf/chac/CHAC_Analytical_Engine/1.3_January_1994.pdf |access-date=2023-10-17 |url-status=live |archive-url=https://web.archive.org/web/20231017214519/http://bitsavers.informatik.uni-stuttgart.de/pdf/chac/CHAC_Analytical_Engine/1.3_January_1994.pdf |archive-date=2023-10-17 |quote-pages=10–11 |quote=[…] the [[Intel Intellec 8]] […] first appeared sometime in 1972 or 1973, two years or more before the [[Altair 8800]] often credited as the "first microcomputer" by standard histories […] [[Intel]] maintains that the 8 Mod 8 was first produced in 1973 and discontinued in 1975. Tony Duell has an 8 Mod 80 CPU board dated 1972, and the 8 Mod 8 and 4 Mod 40 are both listed in the Intel Data Catalog published in February 1976, so the actual period of production may have been somewhat longer. (Pertinent Intel docs must be read carefully because the names MCS4, MCS40, MCS8 and MCS80 were used almost indiscriminately to refer to chipsets, computers or full systems.) […]}} (52 pages) (NB. This article does not mention Intel Hex, but specifically mentions that Intel's Intellec system was officially introduced in 1973, but some units dated 1972 exist.)</ref>
<ref name="Ramos_2010">{{cite web |title=intel-hex-mode.el --- Mode for Intel Hex files. |author-first=Rubens |author-last=Ramos |date=2010 |orig-date=2008 |url=https://www.emacswiki.org/emacs/intel-hex-mode.el |access-date=2023-10-20 |url-status= |archive-url= |archive-date=}}</ref>
<ref name="Schuldt_2018">{{cite web |title=intel-hex-mode |author-first= Michael |author-last=Schuldt |date=2018 |website=github.com |url=https://github.com/mschuldt/intel-hex-mode |access-date=2023-10-20 |url-status=live |archive-url=https://web.archive.org/web/20201024210042/https://github.com/mschuldt/intel-hex-mode |archive-date=2020-10-24 |quote=By default, this mode is enabled for files with a .a90, .hex, .a43, or .ihx extension.}}</ref>
<ref name="Sabnis_2011">{{cite web |title=How to convert .out file to .int, .hex, .a43 |author-first=Abhishek |author-last=Sabnis |date=2011-02-04 |work=Code Composer Studio forum |publisher=[[Texas Instruments]] |url=https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/92174/how-to-convert-out-file-to-int-hex-a43 |access-date=2023-10-20 |url-status=live |archive-url=https://web.archive.org/web/20231020221751/https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/92174/how-to-convert-out-file-to-int-hex-a43 |archive-date=2023-10-20 |quote=TI-gang programmer needs .int, .hex, .a43 file format.}}</ref>
<ref name="Rüger_2022">{{cite web |title=Provide file format I: Intel HEX with comments that ignores checksum errors |author-last=Rüger |author-first=Stefan M. |date=2022-06-16 |work=AVRDUDE |url=https://github.com/avrdudes/avrdude/pull/1030 |access-date=2023-11-25 |url-status=live |archive-url=https://web.archive.org/web/20231125042310/https://github.com/avrdudes/avrdude/pull/1030 |archive-date=2023-11-25}} (NB. AVRDUDE's comment option :I can incorrectly produce ":" characters as part of the [[hex dump]].)</ref>
<ref name="Bull-Dean-Rüger-Wunsch_2023">{{cite web |title=AVRDUDE - A program for downloading/uploading AVR microcontroller flash, EEPROM and more for AVRDUDE |author-first1=Hans Eirik |author-last1=Bull |author-first2=Brian S. |author-last2=Dean |author-first3=Stefan M. |author-last3=Rüger |author-first4=Jörg |author-last4=Wunsch |version=Version 7.2 |date=2023-07-15 |url=https://avrdudes.github.io/avrdude/7.2/avrdude.pdf |access-date=2023-11-23 |url-status=live |archive-url=https://web.archive.org/web/20231123201951/https://avrdudes.github.io/avrdude/7.2/avrdude.pdf |archive-date=2023-11-23 |quote-page=12 |quote=[…] I […] Intel Hex with comments on download and tolerance of checksum errors on upload […]}} (66 pages)</ref>
<ref name="GeorgG_2021">{{cite web |title=Hex-File Flashen |language=de |author-first=Georg |author-last=G. |date=2021-09-05 |orig-date=2021-09-04 |website=mikrocontroller.net |department=Mikrocontroller und Digitale Elektronik |url=https://www.mikrocontroller.net/topic/524261 |access-date=2023-11-23 |url-status= |archive-url= |archive-date= |quote=[…] Debug Infos fingen bei Intel mit einem "$" an. Dann kamen der Name des Symbols und die Adresse. Kommentare hatten als erstes Zeichen ein ";". […] Der [[ASM48]] unter [[ISIS-II|ISIS-2]] produzierte solche Hexfiles, […] der [[ASM86]] auch. […]}}</ref>
<ref name="Burgett_2017">{{cite web |title=Development of Intel ISIS Operating System - An interview with Ken Burgett |author-first=Kenneth "Ken" |author-last=Burgett |date=2017-11-10 |url=https://www.rogerarrick.com/osiris/burgett.txt |access-date=2023-11-25 |url-status=live |archive-url=https://web.archive.org/web/20231124165914/https://www.rogerarrick.com/osiris/burgett.txt |archive-date=2023-11-24}} [https://web.archive.org/web/20231125032320/https://00362628054895325210.googlegroups.com/attach/1cc719e8305ed/burgett.txt?part=0.1&view=1&vt=ANaJVrFYjqMX6NCUFa_l-LUDCL-Mu3EqJS1xO4wZczmxImZg2kP3F8E1qEWYTXI5rHv6URyeMi3pcc1oH5LeyEkzHUSeSnUncsii1D7SyIa5EcFQPzu1fzM][https://web.archive.org/web/20231125121523/https://www.rogerarrick.com/kenburgett/]</ref>
}}

==Further reading==
* {{cite web |title=How Do I Interpret Motorola S & Intel HEX Formatted Data? Intel Hex-32, Code 99 |work=Home > Hardware > … > In-circuit Test Systems > Automated Test Equipment [Discontinued] > Details |publisher=[[Keysight Technologies]] |url=https://www.keysight.com/main/editorial.jspx?ckey=25084%3Aatg%3Afaq&id=25084%3Aatg%3Afaq&nid=-35181.0.00&lc=ger&cc=DE |access-date=2020-03-01 |url-status=dead |archive-url=https://web.archive.org/web/20200301171624/https://www.keysight.com/main/editorial.jspx?ckey=25084%3Aatg%3Afaq&id=25084%3Aatg%3Afaq&nid=-35181.0.00&lc=ger&cc=DE |archive-date=2020-03-01}}
* {{cite web |title=Intel HEX Format |author-first=San |author-last=Bergmans |date=2019-06-02 |orig-date=2001 |work=SB-Projects |url=http://www.sbprojects.com/knowledge/fileformats/intelhex.php |access-date=2020-03-01 |url-status=dead |archive-url=https://web.archive.org/web/20200301224049/https://www.sbprojects.net/knowledge/fileformats/intelhex.php |archive-date=2020-03-01}}
* {{cite web |title=Intel HEX-record Format |author-first=Brian |author-last=Beard |date=2016 |orig-date=2007 |work=[[Lucid Technologies]] |url=http://www.lucidtechnologies.info/intel.htm |access-date=2020-02-28 |url-status=live |archive-url=https://web.archive.org/web/20200228153634/http://www.lucidtechnologies.info/intel.htm |archive-date=2020-02-28}}
* {{cite book |title=The Telemark Assembler (TASM) User's Manual |chapter=Intel Hex Word Address Object Format |version=3.1 |date=February 1998 |author-first=Thomas N. |author-last=Anderson |publisher=Squak Valley Software |publication-place=Issaquah, Washington, USA |pages=25–26 |url=https://www.mikrocontroller.net/attachment/339967/TASMMAN.pdf |access-date=2021-12-11 |url-status=live |archive-url=https://web.archive.org/web/20211211145506/https://www.mikrocontroller.net/attachment/339967/TASMMAN.pdf |archive-date=2021-12-11 |quote=Intel Hex Word Address Object Format […] This format is identical to the Intel Hex Object Format except that the address for each line of object code is divided by two thus converting it to a word address (16 bit word). All other fields are identical. Here is an example: […] :180800000102030405060708090A0B0C0D0E0F101112131415161718AC […] :02080C00191AA3 […] :00000001FF […]}} (32 pages)
* {{cite web |title=ADuC70xx Serial Download Protocol |type=Application Note |date=2016 |publisher=[[Analog Devices]] |publication-place=Norwood, Massachusetts, USA |version=Revision C |id=AN-724 |url=https://www.analog.com/media/en/technical-documentation/evaluation-documentation/an-724.pdf |access-date=2023-10-05 |url-status=live |archive-url=https://web.archive.org/web/20231005181920/https://www.analog.com/media/en/technical-documentation/evaluation-documentation/an-724.pdf |archive-date=2023-10-05}} (8 pages)

==External links==
* [http://www.nlsw.nl/software/ binex] - a converter between Intel HEX and binary for Windows.
* [http://srecord.sourceforge.net/ SRecord], a converter between Intel HEX and binary for Linux ([https://tewarid.github.io/2011/05/26/convert-a-bin-file-to-hex.html usage]), C++ source code.
* [https://github.com/arkku/ihex kk_ihex], open source C library for reading and writing Intel HEX
* [https://github.com/vsergeev/libGIS libgis], open source C library that converts Intel HEX, Motorola S-Record, Atmel Generic files.
* [https://pypi.python.org/pypi/bincopy bincopy] is a Python package for manipulating Intel HEX files.
* [https://github.com/oliverbrehm/SwiftIntelHex SwiftIntelHex] - a Swift package to parse Intel HEX files for iOS and macOS.


[[Category:Binary-to-text encoding formats]]
[[Category:Binary-to-text encoding formats]]
[[Category:Embedded systems]]
[[Category:Embedded systems]]
[[Category:Computer file formats]]

[[cs:Intel HEX]]
[[de:Intel HEX]]
[[es:Intel HEX]]
[[hu:Intel HEX]]
[[pl:Intel Hex]]
[[ru:Intel HEX]]

Latest revision as of 16:18, 8 September 2024

Not to be confused with Intel hexadecimal notation.
".hex" redirects here. For the file format used by GNU Unifont, see GNU Unifont § .hex format.

Intel hex
Filename extensionsGeneral-purpose:
.hex,[1] .mcs,[2] .int,[3] .ihex, .ihe, .ihx[4]
Platform-specific:
.h80, .h86,[5][6] .a43,[7][4] .a90[7][4]
Split, banked, or paged:
.hxl–.hxh,[8] .h00–.h15, .p00–.pff[9]
Binary or Intel hex:
.obj, .obl,[8] .obh,[8] .rom, .eep

Intel hexadecimal object file format, Intel hex format or Intellec Hex is a file format that conveys binary information in ASCII text form,[10] making it possible to store on non-binary media such as paper tape, punch cards, etc., to display on text terminals or be printed on line-oriented printers.[11] The format is commonly used for programming microcontrollers, EPROMs, and other types of programmable logic devices and hardware emulators. In a typical application, a compiler or assembler converts a program's source code (such as in C or assembly language) to machine code and outputs it into a object or executable file in hexadecimal (or binary) format. In some applications, the Intel hex format is also used as a container format holding packets of stream data.[12] Common file extensions used for the resulting files are .HEX[1] or .H86.[5][6] The HEX file is then read by a programmer to write the machine code into a PROM or is transferred to the target system for loading and execution.[11][13] There are various tools to convert files between hexadecimal and binary format (i.e. HEX2BIN), and vice versa (i.e. OBJHEX, OH, OHX, BIN2HEX).

History

[edit]

The Intel hex format was originally designed for Intel's Intellec Microcomputer Development Systems[14]: 10–11  (MDS) in 1973 in order to load and execute programs from paper tape. It was also used to specify memory contents to Intel for ROM production,[15] which previously had to be encoded in the much less efficient BNPF (Begin-Negative-Positive-Finish) format.[14]: 11  In 1973, Intel's "software group" consisted only of Bill Byerly and Kenneth Burgett, and Gary Kildall as an external consultant doing business as Microcomputer Applications Associates (MAA) and founding Digital Research in 1974.[16][17][18][9] Beginning in 1975, the format was utilized by Intellec Series II ISIS-II systems supporting diskette drives, with files using the file extension HEX.[19] Many PROM and EPROM programming devices accept this format.

Format

[edit]

Intel HEX consists of lines of ASCII text that are separated by line feed or carriage return characters or both. Each text line contains uppercase hexadecimal characters that encode multiple binary numbers. The binary numbers may represent data, memory addresses, or other values, depending on their position in the line and the type and length of the line. Each text line is called a record.

Record structure

[edit]

A record (line of text) consists of six fields (parts) that appear in order from left to right:[11]

  1. Start code, one character, an ASCII colon ':'. All characters preceding this symbol in a record should be ignored.[15][5][20][21][22][23] In fact, very early versions of the specification even asked for a minimum of 25 NUL characters to precede the first record and follow the last one, owing to the format's origins as a paper tape format which required some tape leadin and leadout for handling.[15][24][21][22] However, as this was a little known part of the specification, not all software written copes with this correctly. It allows to store other related information in the same file (and even the same line),[15][23] a facility used by various software development utilities to store symbol tables or additional comments,[25][15][21][26][9][27] and third-party extensions using other characters as start code like the digits '0'..'9' by Intel[28] and Keil,[26] '$' by Mostek,[29][30] or '!', '@', '#', '\', '&' and ';' by TDL.[30][31] By convention, '//' is often used for comments.[32][33] Neither of these extensions may contain any ':' characters as part of the payload.
  2. Byte count, two hex digits (one hex digit pair), indicating the number of bytes (hex digit pairs) in the data field. The maximum byte count is 255 (0xFF). The values of 8 (0x08),[9] 16 (0x10)[9] and 32 (0x20) are commonly used byte counts. Not all software copes with counts larger than 16.[2]
  3. Address, four hex digits, representing the 16-bit beginning memory address offset of the data. The physical address of the data is computed by adding this offset to a previously established base address, thus allowing memory addressing beyond the 64 kilobyte limit of 16-bit addresses. The base address, which defaults to zero, can be changed by various types of records. Base addresses and address offsets are always expressed as big endian values.
  4. Record type (see record types below), two hex digits, 00 to 05, defining the meaning of the data field.
  5. Data, a sequence of n bytes of data, represented by 2n hex digits. Some records omit this field (n equals zero). The meaning and interpretation of data bytes depends on the application. (4-bit data will either have to be stored in the lower or upper half of the bytes, that is, one byte holds only one addressable data item.[15])
  6. Checksum, two hex digits, a computed value that can be used to verify the record has no errors.

Color legend

[edit]

As a visual aid, the fields of Intel HEX records are colored throughout this article as follows:

  Start code   Byte count   Address   Record type   Data   Checksum

Checksum calculation

[edit]

A record's checksum byte is the two's complement of the least significant byte (LSB) of the sum of all decoded byte values in the record preceding the checksum. It is computed by summing the decoded byte values and extracting the LSB of the sum (i.e., the data checksum), and then calculating the two's complement of the LSB (e.g., by inverting its bits and adding one).

For example, in the case of the record :0300300002337A1E, the sum of the decoded byte values is 03 + 00 + 30 + 00 + 02 + 33 + 7A = E2, which has LSB value E2. The two's complement of E2 is 1E, which is the checksum byte appearing at the end of the record.

The validity of a record can be checked by computing its checksum and verifying that the computed checksum equals the checksum appearing in the record; an error is indicated if the checksums differ. Since the record's checksum byte is the two's complement — and therefore the additive inverse — of the data checksum, this process can be reduced to summing all decoded byte values, including the record's checksum, and verifying that the LSB of the sum is zero. When applied to the preceding example, this method produces the following result: 03 + 00 + 30 + 00 + 02 + 33 + 7A + 1E = 100, which has LSB value 00.

Text line terminators

[edit]

Intel HEX records are usually separated by one or more ASCII line termination characters so that each record appears alone on a text line. This enhances readability by visually delimiting the records and it also provides padding between records that can be used to improve machine parsing efficiency. However, the line termination characters are optional, as the ':' is used to detect the start of a record.[15][5][24][20][21][22][23]

Programs that create HEX records typically use line termination characters that conform to the conventions of their operating systems. For example, Linux programs use a single LF (line feed, hex value 0A) character to terminate lines, whereas Windows programs use a CR (carriage return, hex value 0D) followed by a LF.

Record types

[edit]

Intel HEX has six standard record types:[11]

Hex code Record type Description Example
00 Data The byte count specifies number of data bytes in the record. The example has 0B (eleven) data bytes. The 16-bit starting address for the data (in the example at addresses beginning at 0010) and the data (61, 64, 64, 72, 65, 73, 73, 20, 67, 61, 70). :0B0010006164647265737320676170A7
01 End Of File Must occur exactly once per file in the last record of the file. The byte count is 00, the address field is typically 0000 and the data field is omitted. :00000001FF
02 Extended Segment Address The byte count is always 02, the address field (typically 0000) is ignored and the data field contains a 16-bit segment base address. This is multiplied by 16 and added to each subsequent data record address to form the starting address for the data. This allows addressing up to one mebibyte (1048576 bytes) of address space. :020000021200EA
03 Start Segment Address For 80x86 processors, specifies the starting execution address. The byte count is always 04, the address field is 0000 and the first two data bytes are the CS value, the latter two are the IP value. The execution should start at this address. :0400000300003800C1
04 Extended Linear Address Allows for 32 bit addressing (up to 4 GiB). The byte count is always 02 and the address field is ignored (typically 0000). The two data bytes (big endian) specify the upper 16 bits of the 32 bit absolute address for all subsequent type 00 records; these upper address bits apply until the next 04 record. The absolute address for a type 00 record is formed by combining the upper 16 address bits of the most recent 04 record with the low 16 address bits of the 00 record. If a type 00 record is not preceded by any type 04 records then its upper 16 address bits default to 0000. :020000040800F2
05 Start Linear Address The byte count is always 04, the address field is 0000. The four data bytes represent a 32-bit address value (big endian). In the case of CPUs that support it, this 32-bit address is the address at which execution should start. :04000005000000CD2A

Other record types have been used for variants, including 06 ('blinky' messages / transmission protocol container) by Wayne and Layne,[34] 0A (block start), 0B (block end), 0C (padded data), 0D (custom data) and 0E (other data) by the BBC/Micro:bit Educational Foundation,[35] and 81 (data in code segment), 82 (data in data segment), 83 (data in stack segment), 84 (data in extra segment), 85 (paragraph address for absolute code segment), 86 (paragraph address for absolute data segment), 87 (paragraph address for absolute stack segment) and 88 (paragraph address for absolute extra segment) by Digital Research.[6][20]

Named formats

[edit]

The original 4-bit/8-bit Intellec Hex Paper Tape Format and Intellec Hex Computer Punched Card Format in 1973/1974 supported only one record type 00.[36][37][25] This was expanded around 1975[when?] to also support record type 01.[15] Sometimes called symbolic hexadecimal format,[38] it could include an optional header containing a symbol table for symbolic debugging,[25][28][26][9] all characters in a record preceding the colon are ignored.[15][5]

Around 1978[when?], Intel introduced the new record types 02 and 03 (to add support for the segmented address space of the then-new 8086/8088 processors) in their Extended Intellec Hex Format.[when?]

Special names are sometimes used to denote the formats of HEX files that employ specific subsets of record types. For example:

  • I8HEX (aka HEX-80) files use only record types 00 and 01
  • I16HEX (aka HEX-86) files use only record types 00 through 03[10]
  • I32HEX (aka HEX-386) files use only record types 00, 01, 04, and 05

File example

[edit]

This example shows a file that has four data records followed by an end-of-file record: 

:10010000214601360121470136007EFE09D2190140
:100110002146017E17C20001FF5F16002148011928
:10012000194E79234623965778239EDA3F01B2CAA7
:100130003F0156702B5E712B722B732146013421C7
:00000001FF

  Start code   Byte count   Address   Record type   Data   Checksum

Variants

[edit]

Besides Intel's own extension, several third-parties have also defined variants and extensions of the Intel hex format, including Digital Research (as in the so-called "Digital Research hex format"[6][20]), Zilog, Mostek,[29][30] TDL,[30][31] Texas Instruments, Microchip,[39][40] c't, Wayne and Layne,[34] and BBC/Micro:bit Educational Foundation (with its "Universal Hex Format"[35]). These can have information on program entry points and register contents, a swapped byte order in the data fields, fill values for unused areas, fuse bits, and other differences.

The Digital Research hex format for 8086 processors supports segment information by adding record types to distinguish between code, data, stack, and extra segments.[5][6][20]

Most assemblers for CP/M-80 (and also XASM09 for the Motorola 6809) don't use record type 01h to indicate the end of a file, but use a zero-length data type 00h entry instead.[41][1] This eases the concatenation of multiple hex files.[42][43][1]

Texas Instruments defines a variant where addresses are based on the bit-width of a processor's registers, not bytes.

Microchip defines variants INTHX8S[44] (INHX8L,[1] INHX8H[1]), INHX8M,[44][1][45] INHX16[44] (INHX16M[1]) and INHX32[46] for their PIC microcontrollers.

Alfred Arnold's cross-macro-assembler AS,[1] Werner Hennig-Roleff's 8051-emulator SIM51,[26] and Matthias R. Paul's cross-converter BINTEL[47] are also known to define extensions to the Intel hex format.

See also

[edit]

References

[edit]
  1. ^ a b c d e f g h i Arnold, Alfred "Alf" (2020) [1996, 1989]. "6.3. P2HEX". Macro Assembler AS - User's Manual. V1.42. Translated by Arnold, Alfred "Alf"; Hilse, Stefan; Kanthak, Stephan; Sellke, Oliver; De Tomasi, Vittorio. Aachen, Germany. Archived from the original on 2020-02-28. Retrieved 2020-02-28. […] For the PIC microcontrollers, the switch -m <0..3> allows to generate the three different variants of the Intel Hex format. Format 0 is INHX8M which contains all bytes in a Lo-Hi-Order. Addresses become double as large because the PICs have a word-oriented address space that increments addresses only by one per word. […] With Format 1 (INHX16M), bytes are stored in their natural order. This is the format Microchip uses for its own programming devices. Format 2 (INHX8L) resp. 3 (INHX8H) split words into their lower resp. upper bytes. […] Unfortunately, one finds different statements about the last line of an Intel-Hex file in literature. Therefore, P2HEX knows three different variants that may be selected […] :00000001FF […] :00000001 […] :0000000000 […] By default, variant 0 is used which seems to be the most common one. […] If the target file name does not have an extension, an extension of HEX is supposed. […]
  2. ^ a b "AR#476 PROMGen - Description of PROM/EEPROM file formats: MCS, EXO, HEX, and others". Xilinx. 2010-03-08. Intel MCS-86 Hexadecimal Object - File Format Code 88. Archived from the original on 2020-03-03. Retrieved 2020-03-03.
  3. ^ Sabnis, Abhishek (2011-02-04). "How to convert .out file to .int, .hex, .a43". Code Composer Studio forum. Texas Instruments. Archived from the original on 2023-10-20. Retrieved 2023-10-20. TI-gang programmer needs .int, .hex, .a43 file format.
  4. ^ a b c Schuldt, Michael (2018). "intel-hex-mode". github.com. Archived from the original on 2020-10-24. Retrieved 2023-10-20. By default, this mode is enabled for files with a .a90, .hex, .a43, or .ihx extension.
  5. ^ a b c d e f "3.1. Intel 8086 Hex File Format". CP/M-86 Operating System - System Guide (PDF) (2nd printing, 1st ed.). Pacific Grove, California, USA: Digital Research. June 1981. pp. 15–16. Archived (PDF) from the original on 2020-02-28. Retrieved 2020-02-28. p. 16: […] The following are output from ASM-86 only: 81 same as 00, data belongs to code segment […] 82 same as 00, data belongs to data segment […] 83 same as 00, data belongs to stack segment […] 84 same as 00, data belongs to extra segment […] 85 paragraph address for absolute code segment […] 86 paragraph address for absolute data segment […] 87 paragraph address for absolute stack segment […] 88 paragraph address for absolute extra segment […] All characters preceding the colon for each record are ignored. […] (17 pages)
  6. ^ a b c d e "Appendix C. ASM-86 Hexadecimal Output Format". CP/M-86 - Operating System - Programmer's Guide (PDF) (3 ed.). Pacific Grove, California, USA: Digital Research. January 1983 [1981]. pp. 97–100. Archived (PDF) from the original on 2020-02-27. Retrieved 2020-02-27. pp. 97–99: […] The Intel format is identical to the format defined by Intel for the 8086. The Digital Research format is nearly identical to the Intel format, but adds segment information to hexadecimal records. Output of either format can be input to GENCMD, but the Digital Research format automatically provides segment identification. A segment is the smallest unit of a program that can be relocated. […] It is in the definition of record types 00 and 02 that Digital Research's hexadecimal format differs from Intel's. Intel defines one value each for the data record type and the segment address type. Digital Research identifies each record with the segment that contains it. […] 00H for data belonging to all 8086 segments […] 81H for data belonging to the CODE segment […] 82H for data belonging to the DATA segment […] 83H for data belonging to the STACK segment […] 84H for data belonging to the EXTRA segment […] 02H for all segment address records […] 85H for a CODE absolute segment address […] 86H for a DATA segment address […] 87H for a STACK segment address […] 88H for an EXTRA segment address […] [1] (1+viii+122+2 pages)
  7. ^ a b Ramos, Rubens (2010) [2008]. "intel-hex-mode.el --- Mode for Intel Hex files". Retrieved 2023-10-20.
  8. ^ a b c "The Interactive Disassembler - Hexadecimal fileformats". Hex-Rays. 2006. Archived from the original on 2020-03-01. Retrieved 2020-03-01. [2] Archived 2021-11-16 at the Wayback Machine
  9. ^ a b c d e f Roche, Emmanuel (2020-04-01). "The Intel HEX File Format". France: Newsgroup: comp.os.cpm. INTELHEX.WS4. Archived from the original on 2021-12-08. Retrieved 2021-12-08. […] the Intel HEX file format can contain much more than the "data bytes". As long as the lines do not start with a colon (":"), they can contain anything that you want. […] I once saw a big HEX file […] It contained, at the beginning, the source code of a PL/M program, followed, at the end, by the resulting HEX file produced by the PL/M compiler. […] I found another HEX file containing several lines of comments, not at the beginning or at the end, but separating several lines of "absolute records". […] it was from an "(Intel) 8008 Simulator". So, at the beginning of its use, it was well known that HEX files could contain explanations. […] under CP/M or any 8-bit 64K system, there remains one case: "Page addresses". Since CP/M, it is standard to display memory addresses using the hexadecimal system […] as we said for BIN/COM files, the memory addresses are 0000/0100. […] those memory addresses can be written 00-00/01-00 […] to say: Page zero, address zero / Page one, address zero. […] the highest memory address in a 8-bit 64K computer is FFFF […] Page FF, address FF […] the lowest addresses are in Page zero (or 00) and the highest addresses are in Page FF. […] CP/M filetypes are 3-letters long, one could use filetypes of the form P00–PFF […] to indicate at which memory address where to load the HEX file. […] I noticed that most of my addresses were ending with "00", so the loading address could be reduced to the Page address, which […] could be put inside the filetype […]
  10. ^ a b "Appendix D. MCS-86 Absolute Object File Formats: Hexadecimal Object File Format". 8086 Family Utilities - User's Guide for 8080/8085-Based Development Systems (PDF). Revision E (A620/5821 6K DD ed.). Santa Clara, California, USA: Intel Corporation. May 1982 [1980, 1978]. pp. D-8–D-13. Order Number 9800639-04. Archived (PDF) from the original on 2020-02-29. Retrieved 2020-02-29.
  11. ^ a b c d Hexadecimal Object File Format Specification. Revision A. Intel Corporation. 1998 [1988-01-06]. Retrieved 2019-07-23. [3][4][5][6][7] (11 pages)
  12. ^ "LT Programming Hex File Format Documentation -- In Circuit Programming". Analog Devices, Inc. / Linear Technology. 2021. Archived from the original on 2021-03-07. Retrieved 2021-12-11.
  13. ^ "General: Intel Hex File Format". ARM Keil. ARM Germany GmbH. 2018-05-07 [2012]. KA003292. Archived from the original on 2020-02-27. Retrieved 2017-09-06. [8]
  14. ^ a b Crosby, Kip (January–March 1994). "Dawn of the Micro: Intel's Intellecs" (PDF). The Analytical Engine. 1 (3). Computer History Association of California: 10–14. ISSN 1071-6351. Archived (PDF) from the original on 2023-10-17. Retrieved 2023-10-17. pp. 10–11: […] the Intel Intellec 8 […] first appeared sometime in 1972 or 1973, two years or more before the Altair 8800 often credited as the "first microcomputer" by standard histories […] Intel maintains that the 8 Mod 8 was first produced in 1973 and discontinued in 1975. Tony Duell has an 8 Mod 80 CPU board dated 1972, and the 8 Mod 8 and 4 Mod 40 are both listed in the Intel Data Catalog published in February 1976, so the actual period of production may have been somewhat longer. (Pertinent Intel docs must be read carefully because the names MCS4, MCS40, MCS8 and MCS80 were used almost indiscriminately to refer to chipsets, computers or full systems.) […] (52 pages) (NB. This article does not mention Intel Hex, but specifically mentions that Intel's Intellec system was officially introduced in 1973, but some units dated 1972 exist.)
  15. ^ a b c d e f g h i "Chapter 6. Microcomputer System Component Data Sheet - EPROMs and ROMs: I. PROM and ROM Programming Instructions - B1. Intellec Hex Paper Tape Format / C1. Intellec Hex Computer Punched Card Format". MCS-80 User's Manual (With Introduction to MCS-85). Santa Clara, California, USA: Intel Corporation. October 1977 [1975]. pp. 6-75–6-78. 98-153D. Retrieved 2020-02-27. p. 6-76: […] In the Intel Intellec Hex Format, a data field can contain either 8 or 4-bit data. Two ASCII hexadecimal characters must be used to represent both 8 and 4-bit data. In the case of 4-bit data, only one of the characters is meaningful and must be specified on the Intel PROM/ROM Order Form. […] Preceding the first data field and following the last data field there must be a leader/trailer length of at least 25 null characters. Comments (except for a colon) may be placed on the tape leader. […] If the data is 4 bit, then either the high or low-order digit represents the data and the other digit of the pair may be any ASCII hexadecimal digit. […] [9][10] (468 pages) (NB. This manual also describes a "BPNF Paper Tape Format", a "Non-Intellec Hex Paper Tape Format" and a "PN Computer Punched Card Format".)
  16. ^ Kildall, Gary Arlen (January 1980). "The History of CP/M, The Evolution of an Industry: One Person's Viewpoint". Dr. Dobb's Journal of Computer Calisthenics & Orthodontia. 5 (1): 6–7. #41. Archived from the original on 2016-11-24. Retrieved 2013-06-03. […] Programs had been written and tested by Intel's software group, consisting of myself and two other people, and we were ready for the real machine. […]
  17. ^ Kildall, Gary Arlen (2016-08-02) [1993]. Kildall, Scott; Kildall, Kristin (eds.). Computer Connections: People, Places, and Events in the Evolution of the Personal Computer Industry (Manuscript, part 1). Kildall Family. Archived (PDF) from the original on 2016-11-17. Retrieved 2016-11-17. (NB. Part 2 not released due to family privacy reasons.)
  18. ^ Burgett, Kenneth "Ken" (2017-11-10). "Development of Intel ISIS Operating System - An interview with Ken Burgett". Archived from the original on 2023-11-24. Retrieved 2023-11-25. [11][12]
  19. ^ Feichtinger, Herwig (1987). "1.8.5. Lochstreifen-Datenformate: Das Intel-Hex-Format" [1.8.5. Paper tape data formats]. Arbeitsbuch Mikrocomputer [Microcomputer work book] (in German) (2 ed.). Munich, Germany: Franzis-Verlag GmbH. pp. 240–243 [243]. ISBN 3-7723-8022-0.
  20. ^ a b c d e "4.3 Intel Hexadecimal File Format". Concurrent CP/M Operating System - Programmer's Reference Guide (PDF) (1 ed.). Pacific Grove, California, USA: Digital Research Inc. January 1984. pp. 4-9–4-12. Archived (PDF) from the original on 2021-12-11. Retrieved 2021-12-11. pp. 4-11–4-12: […] The following are output from ASM-86 only: 81 same as 00, data belongs to Code Segment […] 82 same as 00, data belongs to Data Segment […] 83 same as 00, data belongs to Stack Segment […] 84 same as 00, data belongs to Extra Segment […] *85 paragraph address for absolute Code Segment […] *86 paragraph address for absolute Data Segment […] *87 paragraph address for absolute Stack Segment […] *88 paragraph address for absolute Extra Segment […] * 85, 86, 87, and 88 are Digital Research Extensions. […] All characters preceding the colon for each record are ignored. […] (346 pages) (NB. This manual marks only types 85, 86, 87 and 88 as Digital Research extensions, as if types 81, 82, 83, 84 were not.)
  21. ^ a b c d "2.8. Microprocessor Formats, 2.8.1. Input Requirements: Intel Intellec 8/MDS Format. Select Code 83". Operator Guide To Serial I/O Capabilities of Data I/O Programmers - Translation-Format Package (PDF). Revision C. Data I/O Corporation. October 1980. p. 2-10. 055-1901. Archived (PDF) from the original on 2020-03-01. Retrieved 2020-03-01. p. 2-10: […] Input […] This space can be used for line feed, carriage return or comments. […] Output […] 2) Each line ends with nonprinting line feed, carriage returns and nulls. […] (1+ii+19 pages)
  22. ^ a b c "Intel Intellec 8/MDS Format, Code 83". Translation File Formats (PDF). Data I/O Corporation. 1987-09-03. pp. 22, 26–27, 52–53, 54. Archived (PDF) from the original on 2021-07-28. Retrieved 2020-03-01. pp. 22, 26, 52: […] Nonprinting Carriage Return, line feed, and nulls determined by null count […] (56 pages)
  23. ^ a b c "Appendix B: Intel Hex and Intel Extended Hex Format - B.1 Common Format". Fujitsu Semiconductor Controller Manual: FR/F2MC Family Softune Linkage Kit Manual for V3 (PDF). Fujitsu Limited. 2001. pp. 319–525 [320–321]. Archived (PDF) from the original on 2021-12-12. Retrieved 2021-12-12. p. 321: […] (g) Generally, a control code (such as CR and LF) is added. Data in this field is skipped until the start character ":" of (a) appears. Since the (a), (b), (c), (d), and (f) fields always exist, the minimum length of a record is 11 bytes long and the maximum length is 521 bytes long. […] (4+x+350 pages)
  24. ^ a b "1.6.4 PIP". CP/M Operating System Manual (First printing ed.). Pacific Grove, California, USA: Digital Research. July 1982 [1976]. pp. 17–23. Retrieved 2021-12-12. pp. 19–21: […] PIP performs a special function if the destination is a disk file with type "HEX" (an Intel hex-formatted machine code file), and the source is an external peripheral device, such as a paper tape reader. In this case, the PIP program checks to ensure that the source file contains a properly formed hex file, with legal hexadecimal values and checksum records. When an invalid input record is found, PIP reports an error message at the console and waits for corrective action. It is usually sufficient to open the reader and rerun a section of the tape (pull the tape back about 20 inches). When the tape is ready for the reread, a single carriage return is typed at the console, and PIP will attempt another read. If the tape position cannot be properly read, the user continues the read (by typing a return following the error message), and enters the record manually with the ED program after the disk file is constructed. For convenience, PIP allows the end-of-file to be entered from the console if the source file is an RDR: device. In this case, the PIP program reads the device and monitors the keyboard. If ctl-Z is typed at the keyboard the read operation is terminated normally. […] PIP PUN:=NUL:,X.ASM,EOF:,NUL: […] Send 40 nulls to the punch device; copy the X.ASM file to the punch, followed by an end-of-file (ctl-Z) and 40 more null characters. […] H […] HEX data transfer: all data are checked for proper Intel hex file format. Nonessential characters between hex records are removed during the copy operation. The console will be prompted for corrective action in case errors occur. […] I […] Ignore ":00" records in the transfer of Intel hex format file (the I parameter automatically sets the H parameter). […] PIP PUN:=X.HEX[i],Y.ZOT[h] […] First copy X.HEX to the PUN: device and ignore the trailing ":00" record in X.HEX; continue the transfer of data by reading Y.ZOT, which contains HEX records, including any ":00" records it contains. […] [13] (6+250 pages)
  25. ^ a b c "Appendix A: A Sample Program in PL/M: Hexidecimal Object Tape". MCS-8 A Guide to PL/M programming (PDF). Rev 1 (printed September 1974 ed.). Santa Clara, California, USA: Intel Corporation. 1974-03-15 [September 1973]. p. 102. MCS180-0774-1K, MCS280-0974-1K. Archived (PDF) from the original on 2022-01-29. Retrieved 2022-05-18. p. 102:
        1 CARRY 05714
        2 ZERO 05715
        3 SIGN 05716
        4 PARITY 05717
        5 MEMORY 06000
       23 SQUAREROOT 04003
    […]
       83 MONITORUSES 05766
     $
    ****************************************
    :1008000044520A2E0B36D0F930FA31CF30D730F9B6
    […]
    :100AF0000936F4C730D70401C8C20C0031F930F808
    :040B0000445E0AFF46
    ****************************************
    :0000000000
     $     (1+i+100+1+11+1 pages) (NB. Shows an example containing asterisk-based separators and a space-indented header with symbol names to be processed by Intel ISIS's HEXOBJ command as well as by INTERP/8 or INTERP/80 for symbolic debugging. This optional header is not documented as part of Intel hex or BNPF formats but in Intel's PL/M and assembler programming manuals producing such symbol tables.)
  26. ^ a b c d Hennig-Roleff, Werner (1993-02-01) [1988]. "HEX.DOC: Intel-HEX-Format". SIM51. 1.04 (in German). Archived from the original on 2017-08-11. Retrieved 2021-12-08. […] Beim Absolut-Hex Konvertierprogramm von Keil können optional […] Symbol-Informationen in den Hex-File aufgenommen werden. Die Symbol-Informationen stehen dabei am Anfang des Files, vor dem ersten ':'. Die Symbol-Informationen sind allerdings nicht sehr aussagekräftig, da nicht unterschieden wird zwischen Modul-Name, CODE, XDATA, DATA, IDATA, BIT, NUMBER. Für jeden Symboleintrag werden nur ASCII-Zeichen verwendet. Pro Zeile ist 1 Symbol angeschrieben und zwar in der Form: "0 SymbolName Wert" […] [14][15] (NB. This is an older version of SIM51, the software and documentation was maintained up to 1996.)
  27. ^ G., Georg (2021-09-05) [2021-09-04]. "Hex-File Flashen". Mikrocontroller und Digitale Elektronik. mikrocontroller.net (in German). Retrieved 2023-11-23. […] Debug Infos fingen bei Intel mit einem "$" an. Dann kamen der Name des Symbols und die Adresse. Kommentare hatten als erstes Zeichen ein ";". […] Der ASM48 unter ISIS-2 produzierte solche Hexfiles, […] der ASM86 auch. […]
  28. ^ a b "Appendix A. Example of Listing Format / Appendix C. Hexadecimal Object File Format". 2920 Assembly Language Manual (PDF). Santa Clara, California, USA: Intel Corporation. August 1979. pp. A-3, C-1–C-2. Order Number 9800987-01. Archived (PDF) from the original on 2023-11-26. Retrieved 2023-11-26. p. C-1: […] The code is formatted in hexadecimal bytes of data. The file contains the ASCII representation of the hexadecimal bytes of data. The object code itself is preceded by a symbol table. These two parts may be loaded or saved together or separately. The symbol table is a series of records, terminated by a dollar sign. Each record contains three fields separated by one or more ASCII spaces: […] a number field […] a label field containing the ASCII representation of a source program symbol […] an address field containing the hexadecimal address assigned to the symbol […] The symbol table is terminated by a record whose first nonblank character is a dollar sign. The object code […] follows the symbol table […] Each of these records or physical lines is six logical fields of varying length in characters or frames. […] (90 pages) (NB. The Intel 2920 was a digital signal processor released in 1979.)
  29. ^ a b Formaniak, Peter G.; Leitch, David (July 1977). "A Proposed Microprocessor Software Standard". BYTE - the small systems journal. Technical Forum. Vol. 2, no. 7. Peterborough, New Hampshire, USA: Byte Publications, Inc. pp. 34, 62–63. ark:/13960/t32245485. Retrieved 2021-12-06. (3 pages) (NB. Describes an extension of the Intel hex format by Mostek.)
  30. ^ a b c d Ogdin, Carol Anne; Colvin, Neil; Pittman, Tom; Tubb, Philip (November 1977). "Relocatable Object Code Formats". BYTE - the Small Systems Journal. Technical Forum. 2 (11). Peterborough, New Hampshire, USA: Byte Publications, Inc.: 198–205. ark:/13960/t59c88b4h, ark:/13960/t3kw76j24. Retrieved 2021-12-06. (8 pages) (NB. Besides others describes an incompatible extension of the Intel hex format used by Technical Design Labs (TDL).)
  31. ^ a b Kreidl, Günter (June 1981). "Relocator: Das TDL-Format". Hardware. Nascom journal - Zeitschrift für Anwender des NASCOM 1 oder NASCOM 2 (in German). 2 (6). Germersheim, Germany: Verlag NASCOM Journal, MK-Systemtechnik: 12–14 [12]. Archived from the original on 2021-12-01. Retrieved 2021-12-11. (20 pages) (NB. Shows a variant of the TDL format, which itself is a variant of the Intel hex format.)
  32. ^ Rüger, Stefan M. (2022-06-16). "Provide file format I: Intel HEX with comments that ignores checksum errors". AVRDUDE. Archived from the original on 2023-11-25. Retrieved 2023-11-25. (NB. AVRDUDE's comment option :I can incorrectly produce ":" characters as part of the hex dump.)
  33. ^ Bull, Hans Eirik; Dean, Brian S.; Rüger, Stefan M.; Wunsch, Jörg (2023-07-15). "AVRDUDE - A program for downloading/uploading AVR microcontroller flash, EEPROM and more for AVRDUDE" (PDF). Version 7.2. Archived (PDF) from the original on 2023-11-23. Retrieved 2023-11-23. p. 12: […] I […] Intel Hex with comments on download and tolerance of checksum errors on upload […] (66 pages)
  34. ^ a b Beckler, Matthew L. (2016-07-25) [2016-07-19]. "Blinky Grid - serial optical bit stream". Discourse. Minneapolis, Minnesota, USA: Wayne and Layne, LLC. Archived from the original on 2021-12-11. Retrieved 2021-12-11.
  35. ^ a b "micro:bit Universal Hex Format Specification - Specification for the micro:bit Universal Hex Format". micro:bit. 0.4.0. Micro:bit Educational Foundation. 2021-01-26 [2020]. Archived from the original on 2021-08-14. Retrieved 2021-12-08. [16][17] (NB. This represents kind of a fat hex file format.)
  36. ^ Intellec 8 Microcomputer System Operator's Manual. Intel Corporation. November 1973.
  37. ^ "Appendix D. Hexadecimal Program Tape Format". Intellec 8/MOD 80 Operators Manual. Intel. June 1974. 98-003A. […] Frames 7,8: Record Type […] Two ASCII characters. Currently (1974), all records are type 0. This field is reserved for future expansion […] [18]
  38. ^ Development Tools Catalog 1988 (PDF). Intel Corporation. 1988. pp. 25–26, 30–32. Order Number 280199-004. Archived (PDF) from the original on 2023-11-26. Retrieved 2023-11-26. (46 pages)
  39. ^ "PIC Microcontrollers: PIC Hex File Format". Kanda Electronics Blog. Canolafan, Llanafan, Aberystwyth, Wales, UK: Embedded Results Ltd. 2012-04-26. Archived from the original on 2021-08-16. Retrieved 2021-12-11.
  40. ^ "15.3 XC16-BIN2HEX Utility - 15.3.3 Input/Output Files". MPLAB XC16 Assembler, Linker and Utilities - User's Guide (PDF). Microchip Technology Inc. 2018 [2013]. pp. 240–241. ISBN 978-1-5224-2828-2. DS50002106D. Archived (PDF) from the original on 2019-01-22. Retrieved 2023-12-05. p. 240: […] Because the Intel hex file format is byte-oriented, and the 16-bit PC is not, program memory sections require special treatment. Each 24-bit program word is extended to 32 bits by inserting a so-called "phantom byte". Each program memory address is multiplied by 2 to yield a byte address. For example, a section that is located at 0x100 in program memory will be represented in the hex file as 0x200. Consider the following assembly language source: […] ; file test.s […] .section foo,code,address(0x100) […] .pword 0x112233 […] The file […] will be produced, with the following contents: […] :020000040000fa […] :040200003322110096 […] :00000001FF […] the data record (line 2) has a load address of 0200, while the source code specified address 0x100. […]t the data is represented in "little-endian" format, meaning the least significant byte appears first. The phantom byte appears last, just before the checksum. […] (277 pages)
  41. ^ Kildall, Gary Arlen (February 1978) [1976]. "A simple technique for static relocation of absolute machine code". Dr. Dobb's Journal of Computer Calisthenics & Orthodontia. 3 (2). People's Computer Company: 10–13 (66–69). ISBN 0-8104-5490-4. #22 ark:/13960/t8hf1g21p. Retrieved 2017-08-19. [19][20][21]. Originally presented at: Kildall, Gary Arlen (1977) [22–24 November 1976]. "A Simple Technique for Static Relocation of Absolute Machine Code". Written at Naval Postgraduate School, Monterey, California, USA. In Titus, Harold A. (ed.). Conference Record: Tenth Annual Asilomar Conference on Circuits, Systems and Computers: Papers Presented November 22–24, 1976. Asilomar Conference on Signals, Systems & Computers. Asilomar Hotel and Conference Grounds, Pacific Grove, California, USA: Western Periodicals Company. pp. 420–424. ISSN 1058-6393. Retrieved 2021-12-06. (609 pages)
  42. ^ Zschocke, Jörg (November 1987). "Nicht nur Entwicklungshilfe - Down-Loading für Einplatinencomputer am Beispiel des EPAC-09: Intel-Hex-Format". c't - magazin für computertechnik (in German). Vol. 1987, no. 11. Verlag Heinz Heise GmbH & Co. KG. pp. 198, 200, 202–203, [200]. ISSN 0724-8679. […] Den Vorspann beschließt ein Byte, dessen Wert den Typ des Blockes angibt: 0 = Datenblock, 1 = Endblock. Auf diese Unterscheidung kann jedoch verzichtet werden, wenn sich ein Endblock auch durch eine Blocklänge gleich Null eindeutig kennzeichnen läßt. (So verfahren die meisten Assembler unter CP/M, auch der XASM09; das Typbyte ist dann immer Null). […] [22] (NB. XASM09 is a Motorola 6809 assembler.)
  43. ^ Prior, James E. (1989-02-24). "Re: Intel hex (*.HEX) format questions". Newsgroup: comp.os.cpm. Retrieved 2020-02-27.
  44. ^ a b c "PIC16C5X Programming Specification 5.0 - PIC16C5X Hex Data Formats: 5.1. 8-Bit Split Intellec Hex Format (INHX8S) / 5.2. 8-Bit Merged Intellec Hex Format (INHX8M) / 5.3. 16-Bit Hex Format / 5.4. 8-Bit Word Format / 5.5. 16-Bit Word Format". Microchip Databook (1994 ed.). Microchip Technology Inc. April 1994. pp. 3-10–3-11, 9-10, 9-15, 9-17, 9-21, 9-23, 9-27. DS00018G. Retrieved 2020-02-28. […] Assemblers for the PIC16C5X can produce PIC16C5X object files in various formats. A PIC16C5X programmer must be able to accept and send data in at least one of following formats. The 8-bit merged (INHX8M) format is preferred. […] format […] INHX8S […] produces two 8-bit Hex files. One file will contain the address / data pairs for the high order 8-bits and the other file will contain the low order 8-bits. File extensions for the object code will be '.obl' and '.obh' for low and high order files […] format […] INHX8M […] produces one 8-bit Hex file with a low byte / high byte combination. Since each address can only contain 8 bits in this format, all addresses will be doubled. File extensions for the object code will be '.obj' […] format […] INHX16 […] produces one 16-bit Hex file. File extension for the object code will be '.obj'. […] [23][24]
  45. ^ Beard, Brian (2016) [2010]. "Microchip INHX8M HEX-record Format". Lucid Technologies. Archived from the original on 2020-02-28. Retrieved 2020-02-28.
  46. ^ Beard, Brian (2016) [2013]. "Microchip INHX32 HEX-record Format". Lucid Technologies. Archived from the original on 2020-02-28. Retrieved 2020-02-28.
  47. ^ Paul, Matthias R. (1992). BINTEL: Binär-Image-Konverter mit Intel-Hex-Unterstützung - Bedienungsanleitung [Binary image converter with Intel Hex support - User manual] (in German). (NB. As a consequence of the tool's use to process, analyze, compare, split, cut, fill, combine, relocate or convert binary firmware images (f.e. for or from one or more ROMs) with deliberately sticky (fixed "1" or "0"), inverted, omitted ("don't care"), interconnected or swapped data or address lines (as sometimes used to ease PCB routing of parallel buses or for obfuscation reasons to make disassembly more difficult), this binary image converter supported a number of extensions to the Intel Hex format.)

Further reading

[edit]
[edit]
  • binex - a converter between Intel HEX and binary for Windows.
  • SRecord, a converter between Intel HEX and binary for Linux (usage), C++ source code.
  • kk_ihex, open source C library for reading and writing Intel HEX
  • libgis, open source C library that converts Intel HEX, Motorola S-Record, Atmel Generic files.
  • bincopy is a Python package for manipulating Intel HEX files.
  • SwiftIntelHex - a Swift package to parse Intel HEX files for iOS and macOS.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Intel_HEX&oldid=1244692998"