Analysis of information sources in references of the Wikipedia article "Intel HEX" in English language version.
[…] 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".)
[…] 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. […][13] (6+250 pages)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. […]
[…] 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]
[…] 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. […][13] (6+250 pages)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. […]
[…] I […] Intel Hex with comments on download and tolerance of checksum errors on upload […](66 pages)
[…] 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)
[…] 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)
[…] 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.)
[…] 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.)
[…] (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)
By default, this mode is enabled for files with a .a90, .hex, .a43, or .ihx extension.
[…] 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 […]
[…] 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)
[…] 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. […]
[…] 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. […]
[…] 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. […]
TI-gang programmer needs .int, .hex, .a43 file format.
[…] 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)
[…] 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.)
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
$[…] 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. […]
TI-gang programmer needs .int, .hex, .a43 file format.
By default, this mode is enabled for files with a .a90, .hex, .a43, or .ihx extension.
[…] 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)
[…] 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)
[…] 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 […]
[…] 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.)
[…] 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. […]
[…] 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.)
[…] 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)
[…] Nonprinting Carriage Return, line feed, and nulls determined by null count […](56 pages)
[…] (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)
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
$[…] 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.)
[…] 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.)
[…] I […] Intel Hex with comments on download and tolerance of checksum errors on upload […](66 pages)
[…] Frames 7,8: Record Type […] Two ASCII characters. Currently (1974), all records are type 0. This field is reserved for future expansion […][18]
[…] 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)
[…] 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.)
[…] 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.)
[…] 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.)
[…] 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.)