summaryrefslogtreecommitdiff
path: root/tools/hex2bin-2.0/doc
diff options
context:
space:
mode:
authorJuan J. Martinez <jjm@usebox.net>2020-12-30 19:07:31 +0000
committerJuan J. Martinez <jjm@usebox.net>2020-12-30 19:23:41 +0000
commit2682bc5d1d864341aaeb42a449db73c3ecd16d70 (patch)
tree9116764364b4ee0ce7f6037305077807b57776de /tools/hex2bin-2.0/doc
downloadubox-msx-lib-2682bc5d1d864341aaeb42a449db73c3ecd16d70.tar.gz
ubox-msx-lib-2682bc5d1d864341aaeb42a449db73c3ecd16d70.zip
Initial import1.0
Diffstat (limited to 'tools/hex2bin-2.0/doc')
-rw-r--r--tools/hex2bin-2.0/doc/CRC list.txt542
-rw-r--r--tools/hex2bin-2.0/doc/ChangeLog_hex2bin57
-rw-r--r--tools/hex2bin-2.0/doc/ChangeLog_mot2bin49
-rw-r--r--tools/hex2bin-2.0/doc/README225
-rw-r--r--tools/hex2bin-2.0/doc/S-record.txt361
-rw-r--r--tools/hex2bin-2.0/doc/formats.txt72
-rw-r--r--tools/hex2bin-2.0/doc/intelhex.spc409
-rw-r--r--tools/hex2bin-2.0/doc/srec.txt447
8 files changed, 2162 insertions, 0 deletions
diff --git a/tools/hex2bin-2.0/doc/CRC list.txt b/tools/hex2bin-2.0/doc/CRC list.txt
new file mode 100644
index 0000000..8549799
--- /dev/null
+++ b/tools/hex2bin-2.0/doc/CRC list.txt
@@ -0,0 +1,542 @@
+http://regregex.bbcmicro.net/crc-catalogue.htm
+
+CRC-8
+07
+<crc-8-atm>
+ Name : "CRC-8"
+ Width : 8
+ Poly : 07
+ Init : 00
+ RefIn : False
+ RefOut : False
+ XorOut : 00
+ Check : F4
+
+<crc-8-itu>
+ Name : "CRC-8/ITU"
+ Width : 8
+ Poly : 07
+ Init : 00
+ RefIn : False
+ RefOut : False
+ XorOut : 55
+ Check : A1
+
+<crc-8-rohc>
+ Name : "CRC-8/ROHC"
+ Width : 8
+ Poly : 07
+ Init : FF
+ RefIn : True
+ RefOut : True
+ XorOut : 0
+ Check : D0
+
+39
+<crc-8-darc>
+ Name : "CRC-8/DARC"
+ Width : 8
+ Poly : 39
+ Init : 00
+ RefIn : True
+ RefOut : True
+ XorOut : 00
+ Check : 15
+
+1D
+<crc-8-icode>
+ Name : "CRC-8/I-CODE"
+ Width : 8
+ Poly : 1D
+ Init : FD
+ RefIn : False
+ RefOut : False
+ XorOut : 00
+ Check : 7E
+
+<crc-8-j1850>
+ Name : "CRC-8/J1850" (new entry)
+ Width : 8
+ Poly : 1D
+ Init : FF
+ RefIn : False
+ RefOut : False
+ XorOut : FF
+ Check : 4B
+
+31
+<crc-8-maxim>
+ Name : "CRC-8/MAXIM"
+ Alias : "DOW-CRC"
+ Width : 8
+ Poly : 31
+ Init : 00
+ RefIn : True
+ RefOut : True
+ XorOut : 00
+ Check : A1
+
+9B
+<crc-8-wcdma>
+ Name : "CRC-8/WCDMA"
+ Width : 8
+ Poly : 9B
+ Init : 00
+ RefIn : True
+ RefOut : True
+ XorOut : 00
+ Check : 25
+
+8D
+<crc-8-ccitt>
+ Name : "CRC-8/CCITT" (new entry) 1-Wire?
+ Width : 8
+ Poly : 8D
+ Init : 00?
+ RefIn : False?
+ RefOut : False?
+ XorOut : 00?
+ Check : D2
+
+D5
+<crc-8>
+ Name : "CRC-8" (new entry)
+ Width : 8
+ Poly : D5
+ Init : 00?
+ RefIn : False?
+ RefOut : False?
+ XorOut : 00?
+ Check : BC
+
+CRC-16
+8005
+<crc-16>
+ Name : "ARC"
+ Alias : "CRC-16"
+ Alias : "CRC-IBM"
+ Alias : "CRC-16/ARC"
+ Alias : "CRC-16/LHA"
+ Width : 16
+ Poly : 8005
+ Init : 0000
+ RefIn : True
+ RefOut : True
+ XorOut : 0000
+ Check : BB3D
+
+<crc-16-buypass>
+ Name : "CRC-16/BUYPASS"
+ Alias : "CRC-16/VERIFONE"
+ Width : 16
+ Poly : 8005
+ Init : 0000
+ RefIn : False
+ RefOut : False
+ XorOut : 0000
+ Check : FEE8
+
+<crc-dds-110>
+ Name : "CRC-16/DDS-110"
+ Width : 16
+ Poly : 8005
+ Init : 800D
+ RefIn : False
+ RefOut : False
+ XorOut : 0000
+ Check : 9ECF
+ XCheck : CFE9
+
+<crc-16-maxim>
+ Name : "CRC-16/MAXIM"
+ Width : 16
+ Poly : 8005
+ Init : 0000
+ RefIn : True
+ RefOut : True
+ XorOut : FFFF
+ Check : 44C2
+
+<crc-usb>
+ Name : "CRC-16/USB"
+ Width : 16
+ Poly : 8005
+ Init : FFFF
+ RefIn : True
+ RefOut : True
+ XorOut : FFFF
+ Check : B4C8
+
+<crc-modbus>
+ Name : "MODBUS"
+ Width : 16
+ Poly : 8005
+ Init : FFFF
+ RefIn : True
+ RefOut : True
+ XorOut : 0000
+ Check : 4B37
+
+1021
+<crc-ccitt-1d0f>
+ Name : "CRC-16/AUG-CCITT"
+ Alias : "CRC-16/SPI-FUJITSU"
+ Width : 16
+ Poly : 1021
+ Init : 1D0F
+ RefIn : False
+ RefOut : False
+ XorOut : 0000
+ Check : E5CC
+
+<crc-ccitt-ffff>
+ Name : "CRC-16/CCITT-FALSE"
+ Width : 16
+ Poly : 1021
+ Init : FFFF
+ RefIn : False
+ RefOut : False
+ XorOut : 0000
+ Check : 29B1
+
+<crc-genibus>
+ Name : "CRC-16/GENIBUS"
+ Alias : "CRC-16/I-CODE"
+ Alias : "CRC-16/DARC"
+ Width : 16
+ Poly : 1021
+ Init : FFFF
+ RefIn : False
+ RefOut : False
+ XorOut : FFFF
+ Check : D64E
+
+<crc-ccitt-xmodem>
+ Name : "XMODEM"
+ Alias : "ZMODEM"
+ Alias : "CRC-16/ACORN"
+ Width : 16
+ Poly : 1021
+ Init : 0000
+ RefIn : False
+ RefOut : False
+ XorOut : 0000
+ Check : 31C3
+
+<crc-mcrf4xx>
+ Name : "CRC-16/MCRF4XX"
+ Width : 16
+ Poly : 1021
+ Init : FFFF
+ RefIn : True
+ RefOut : True
+ XorOut : 0000
+ Check : 6F91
+
+<crc-riello>
+ Name : "CRC-16/RIELLO"
+ Width : 16
+ Poly : 1021
+ Init : B2AA
+ RefIn : True
+ RefOut : True
+ XorOut : 0000
+ Check : 63D0
+
+ <crc-ccitt-kermit>
+ Name : "KERMIT"
+ Alias : "CRC-16/CCITT"
+ Alias : "CRC-16/CCITT-TRUE"
+ Alias : "CRC-CCITT"
+ Width : 16
+ Poly : 1021
+ Init : 0000
+ RefIn : True
+ RefOut : True
+ XorOut : 0000
+ Check : 2189
+ XCheck : 8921
+
+<crc-x25>
+ Name : "X-25"
+ Alias : "CRC-16/IBM-SDLC"
+ Alias : "CRC-16/ISO-HDLC"
+ Width : 16
+ Poly : 1021
+ Init : FFFF
+ RefIn : True
+ RefOut : True
+ XorOut : FFFF
+ Check : 906E
+ XCheck : 6E90
+
+0589
+<crc-dect-r>
+ Name : "CRC-16/DECT-R"
+ Alias : "R-CRC-16"
+ Width : 16
+ Poly : 0589
+ Init : 0000
+ RefIn : False
+ RefOut : False
+ XorOut : 0001
+ Check : 007E
+
+<crc-dect-x>
+ Name : "CRC-16/DECT-X"
+ Alias : "X-CRC-16"
+ Width : 16
+ Poly : 0589
+ Init : 0000
+ RefIn : False
+ RefOut : False
+ XorOut : 0000
+ Check : 007F
+
+3D65
+<crc-dnp>
+ Name : "CRC-16/DNP"
+ Width : 16
+ Poly : 3D65
+ Init : 0000
+ RefIn : True
+ RefOut : True
+ XorOut : FFFF
+ Check : EA82
+ XCheck : 82EA
+
+<crc-en-13757>
+ Name : "CRC-16/EN-13757"
+ Width : 16
+ Poly : 3D65
+ Init : 0000
+ RefIn : False
+ RefOut : False
+ XorOut : FFFF
+ Check : C2B7
+
+8BB7
+<crc-t10-dif>
+ Name : "CRC-16/T10-DIF"
+ Width : 16
+ Poly : 8BB7
+ Init : 0000
+ RefIn : False
+ RefOut : False
+ XorOut : 0000
+ Check : D0DB
+
+A097
+<crc-teledisk>
+ Name : "CRC-16/TELEDISK"
+ Width : 16
+ Poly : A097
+ Init : 0000
+ RefIn : False
+ RefOut : False
+ XorOut : 0000
+ Check : 0FB3
+
+CRC-24
+864CFB
+<crc-24>
+ Name : "CRC-24"
+ Alias : "CRC-24/OPENPGP"
+ Width : 24
+ Poly : 864CFB
+ Init : B704CE
+ RefIn : False
+ RefOut : False
+ XorOut : 000000
+ Check : 21CF02
+
+5D6DCB
+<crc-24-flexray-a>
+ Name : "CRC-24/FLEXRAY-A"
+ Width : 24
+ Poly : 5D6DCB
+ Init : FEDCBA
+ RefIn : False
+ RefOut : False
+ XorOut : 000000
+ Check : 7979BD
+
+<crc-24-flexray-b>
+ Name : "CRC-24/FLEXRAY-B"
+ Width : 24
+ Poly : 5D6DCB
+ Init : ABCDEF
+ RefIn : False
+ RefOut : False
+ XorOut : 000000
+ Check : 1F23B8
+
+CRC-32
+04C11DB7
+<crc-32>
+ Name : "CRC-32"
+ Alias : "CRC-32/ADCCP"
+ Alias : "PKZIP"
+ Width : 32
+ Poly : 04C11DB7
+ Init : FFFFFFFF
+ RefIn : True
+ RefOut : True
+ XorOut : FFFFFFFF
+ Check : CBF43926
+
+<crc-32-bzip2>
+ Name : "CRC-32/BZIP2"
+ Alias : "B-CRC-32"
+ Width : 32
+ Poly : 04C11DB7
+ Init : FFFFFFFF
+ RefIn : False
+ RefOut : False
+ XorOut : FFFFFFFF
+ Check : FC891918
+
+<crc-32-mpeg-2>
+ Name : "CRC-32/MPEG-2"
+ Width : 32
+ Poly : 04C11DB7
+ Init : FFFFFFFF
+ RefIn : False
+ RefOut : False
+ XorOut : 00000000
+ Check : 0376E6E7
+
+<crc-32-posix>
+ Name : "CRC-32/POSIX"
+ Alias : "CKSUM"
+ Width : 32
+ Poly : 04C11DB7
+ Init : 00000000
+ RefIn : False
+ RefOut : False
+ XorOut : FFFFFFFF
+ Check : 765E7680
+ LCheck : 377A6011
+
+<crc-32-jamcrc>
+ Name : "JAMCRC"
+ Width : 32
+ Poly : 04C11DB7
+ Init : FFFFFFFF
+ RefIn : True
+ RefOut : True
+ XorOut : 00000000
+ Check : 340BC6D9
+
+1EDC6F41
+<crc-32-C>
+ Name : "CRC-32C"
+ Alias : "CRC-32/ISCSI"
+ Alias : "CRC-32/CASTAGNOLI"
+ Width : 32
+ Poly : 1EDC6F41
+ Init : FFFFFFFF
+ RefIn : True
+ RefOut : True
+ XorOut : FFFFFFFF
+ Check : E3069283
+
+A833982B
+<crc-32-D>
+ Name : "CRC-32D"
+ Width : 32
+ Poly : A833982B
+ Init : FFFFFFFF
+ RefIn : True
+ RefOut : True
+ XorOut : FFFFFFFF
+ Check : 87315576
+
+741B8CD7
+<crc-32-K> (new entry)
+ Name : "CRC-32K"
+ Alias : "CRC-32/KOOPMAN"
+ Width : 32
+ Poly : 741B8CD7
+ Init : 00000000?
+ RefIn : False?
+ RefOut : False?
+ XorOut : 00000000?
+ Check : 085A3197 ?
+
+814141AB
+<crc-32-Q>
+ Name : "CRC-32Q"
+ Width : 32
+ Poly : 814141AB
+ Init : 00000000
+ RefIn : False
+ RefOut : False
+ XorOut : 00000000
+ Check : 3010BF7F
+
+000000AF
+<crc-32-xfer>
+ Name : "XFER"
+ Width : 32
+ Poly : 000000AF
+ Init : 00000000
+ RefIn : False
+ RefOut : False
+ XorOut : 00000000
+ Check : BD0BE338
+
+CRC-40
+<crc-40-gsm>
+ Name : "CRC-40/GSM"
+ Width : 40
+ Poly : 0004820009
+ Init : 0000000000
+ RefIn : False
+ RefOut : False
+ XorOut : 0000000000
+ Check : 2BE9B039B9
+
+CRC-64
+42F0E1EBA9EA3693
+<crc-64>
+ Name : "CRC-64"
+ Width : 64
+ Poly : 42F0E1EBA9EA3693
+ Init : 0000000000000000
+ RefIn : False
+ RefOut : False
+ XorOut : 0000000000000000
+ Check : 6C40DF5F0B497347
+
+<crc-64-we>
+ Name : "CRC-64/WE"
+ Width : 64
+ Poly : 42F0E1EBA9EA3693
+ Init : FFFFFFFFFFFFFFFF
+ RefIn : False
+ RefOut : False
+ XorOut : FFFFFFFFFFFFFFFF
+ Check : 62EC59E3F1A4F00A
+
+000000000000001B
+<crc-64-1b>
+ Name : "CRC-64/1B" (New entry)
+ Width : 64
+ Poly : 000000000000001B
+ Init : 0000000000000000
+ RefIn : True
+ RefOut : True
+ XorOut : 0000000000000000
+ Check : 46A5A9388A5BEFFE
+
+AD93D23594C935A9
+<crc-64-jones>
+ Name : "CRC-64/Jones" (New entry)
+ Width : 64
+ Poly : AD93D23594C935A9
+ Init : FFFFFFFFFFFFFFFF
+ RefIn : True
+ RefOut : True
+ XorOut : 0000000000000000
+ Check : CAA717168609F281
diff --git a/tools/hex2bin-2.0/doc/ChangeLog_hex2bin b/tools/hex2bin-2.0/doc/ChangeLog_hex2bin
new file mode 100644
index 0000000..3339250
--- /dev/null
+++ b/tools/hex2bin-2.0/doc/ChangeLog_hex2bin
@@ -0,0 +1,57 @@
+(UTF8 encoding)
+
+- hex2bin 1.0.12 - 20141122 Simone Fratini
+ small feature added
+ 20141121 Slucx
+ added line for removing extra CR when entering file name at run time.
+ 20141008 JP
+ removed junk code
+
+- hex2bin 1.0.11 - 20141005 Jacques Pelletier
+ added option to support byte-swapped hex used by Microchip's MPLAB IDE
+ corrected bug caused by extra LF at end or within file
+
+- hex2bin 1.0.10 - 20120509 Yoshimasa Nakane
+ modified error checking (also for output file, JP)
+ modified option parser (JP)
+
+- hex2bin 1.0.9 - 20120125 - Danny Schneider
+ Added code for filling a binary file to a given Max_Length relative to
+ Starting Address if Max-Address is larger than Highest-Address
+
+- hex2bin 1.0.8 - 20100402 - Jacques Pelletier
+ Fixed a bug with physical address calculation with extended linear address records
+ ADDRESS_MASK is now calculated from MEMORY_SIZE
+
+- hex2bin 1.0.7 - 20091212 - Jacques Pelletier
+ Fixed the crash on 0 byte length data records
+
+- hex2bin 1.0.6 - 20080103 - Jacques Pelletier
+ Fixed a bug when generating binary files near the end of the buffer
+
+- hex2bin 1.0.5 - 20071005 - Paweł Grabski -
+ Improved parsing of options.
+
+- hex2bin 1.0.4 - 20050126 - Jacques Pelletier -
+ Corrected the conversion LF -> CR+LF bug
+ applied patch for correcting the incorrect handling of
+ extended segment address record
+ added the Rockwell checksum extensions, and modified them a bit to allow
+ other types later.
+
+- hex2bin 1.0.3 - 20040617 - Alf Lacis -
+ Added pad byte (may not always want FF).
+ Added 'break;' to remove GNU compiler warning about label at
+ end of compound statement
+ Added PROGRAM & VERSION strings.
+
+- hex2bin 1.0.2 -
+ Corrected Bug in checksum verification
+
+- hex2bin 1.0.1 -
+ Added checking for memory indexing out of bound.
+ Added segmented and linear extended addressing in hex2bin.
+ Corrected an error: & were interverted with && (and bitwise, logical and).
+
+- hex2bin 1.0.0 -
+ Initial release
diff --git a/tools/hex2bin-2.0/doc/ChangeLog_mot2bin b/tools/hex2bin-2.0/doc/ChangeLog_mot2bin
new file mode 100644
index 0000000..4e3c7b3
--- /dev/null
+++ b/tools/hex2bin-2.0/doc/ChangeLog_mot2bin
@@ -0,0 +1,49 @@
+(UTF8 encoding tab = 4)
+- mot2bin 1.0.12 - 20141122 Simone Fratini
+ small feature added
+ 20141121 Slucx
+ added line for removing extra CR when entering file name at run time.
+
+- mot2bin 1.0.11 - 20141005 Jacques Pelletier
+ added option to support byte-swapped hex used by Microchip's MPLAB IDE
+ corrected bug caused by extra LF at end or within file
+
+- mot2bin 1.0.10 - 20120509 Yoshimasa Nakane
+ modified error checking (also for output file, JP)
+
+- mot2bin 1.0.9 - 20120125 - Danny Schneider
+ Added code for filling a binary file to a given Max_Length relative to
+ Starting Address if Max-Address is larger than Highest-Address
+ (JP) corrected a bug in the checksum checking
+ (JP) added code for record types 0,5,7,8,9
+
+- mot2bin 1.0.8 - 20100402 - Jacques Pelletier
+ ADDRESS_MASK is now calculated from MEMORY_SIZE
+
+- mot2bin 1.0.7 - 20091212 - Jacques Pelletier
+ Fixed the crash on 0 byte length data records
+
+- mot2bin 1.0.6 - 20080103 - Jacques Pelletier
+ Corrected a bug when generating a binary file near the end of the buffer.
+
+- mot2bin 1.0.5 - 20071005 - Paweł Grabski -
+ Improved parsing of options (same code as hex2bin).
+
+- mot2bin 1.0.4 - 20050128 - Jacques Pelletier -
+ Modified the checksum code to be able to generate other checksum types
+ later (ex. CRC).
+
+- mot2bin 1.0.3 - 20041026 - Scott A. Mintz -
+ Modified the MOT2BIN file to compute a checksum over a range using
+ 8bit, 16bit little endian, or 16bit big endian and optionally forcing
+ the checksum to a specific value by modifying a memory location.
+
+- mot2bin 1.0.2 - 20040617 - Alf Lacis -
+ Added pad byte (may not always want FF).
+ Added initialisation to Checksum to remove GNU
+ compiler warning about possible uninitialised usage
+ Added 2x'break;' to remove GNU compiler warning about label at
+ end of compound statement
+ Added PROGRAM & VERSION strings.
+
+- no previous ChangeLog -
diff --git a/tools/hex2bin-2.0/doc/README b/tools/hex2bin-2.0/doc/README
new file mode 100644
index 0000000..78ee7e7
--- /dev/null
+++ b/tools/hex2bin-2.0/doc/README
@@ -0,0 +1,225 @@
+Yet Another Hex to bin converter
+
+It can handle the extended Intel hex format in segmented and linear address
+modes. Records need not be sorted and there can be gaps between records.
+
+Some hex files are produced by compilers. They generate objects files for each
+module in a project, and when the linker generates the final hex file, the
+object files are stored within the hex files, but modules can appear not
+necessary in order of address.
+
+How does it work?
+
+Hex2bin/mot2bin allocates a 4 MBytes buffer and just place the converted bytes
+in its buffer. At the end, the buffer is written to disk. Using a buffer elimi-
+nates the need to sort records. If the option l is used (3), the buffer will be
+allocated with the maximum size specified if over 4Mbytes.
+
+Before reading the hex file, the buffer is filled with a default value. These
+padding bytes are all FF by default so an EPROM programmer can skip these bytes
+when programming. The padding value can be changed with the -p option.
+
+1. Compiling on Linux or other unix platforms
+
+ make
+
+ then
+
+ make install
+
+ This will install the program to /usr/local/bin.
+
+1a. Compiling for Windows on Msys, Cygwin or DOS prompt
+
+ The programs can be compiled as follows:
+ gcc -O2 -Wall -o hex2bin.exe hex2bin.c common.c libcrc.c binary.c
+ gcc -O2 -Wall -o mot2bin.exe mot2bin.c common.c libcrc.c binary.c
+
+2. Using hex2bin
+
+ hex2bin example.hex
+
+ hex2bin will generate a binary file example.bin starting at the
+ lowest address in the hex file.
+
+3. Binary file starting address and length
+
+ If the lowest address isn't 0000,
+ ex: 0100: (the first record begins with :nn010000xxx )
+
+ there will be problems when using the binary file to program a EPROM
+ since the first byte supposed to be at 0100 is stored in the binary file
+ at 0000.
+
+ you can specify a starting address for the binary file on the command line:
+
+ hex2bin -s 0000 start_at_0100.hex
+
+ This start address is not the same thing as the start address record in
+ the hex file. The start address record is used to specify the starting
+ address for execution of the binary code.
+
+ The bytes will be stored in the binary file with a padding from 0000
+ to the lowest address minus 1 (00FF in this case).
+
+ Similarly, the binary file can be padded up to Length -1 with FF or another byte.
+
+ Here, the space between the last byte and 07FF will be filled with FF.
+ hex2bin -l 0800 ends_before_07FF.hex
+
+ EPROM, EEPROM and Flash memories contain all FF when erased.
+
+ This program does minimal error checking since many hex files are
+ generated by known good assemblers.
+
+ When the source file name is
+ for-example.test.hex
+ the binary created will have the name
+ for-example.bin
+ the ".test" part will be dropped.
+
+ Hex2bin/mot2bin assume the source file doesn't contain overlapping records,
+ if so, overlaps will be reported.
+
+4. Checksum of source file
+
+ By default, it ignores record checksum errors, so that someone can change
+ by hand some bytes allowing quick and dirty changes.
+ If you want checksum error reporting, specify the option -c.
+
+ hex2bin -c example.hex
+
+ If there is a record checksum error somewhere, the program will continue the
+ conversion anyway.
+
+ The example file example.hex contains some records with checksum errors.
+
+5. Check value inserted inside binary file
+
+ A check value can be inserted in the resulting binary file.
+
+ hex2bin -k [0-4] -r [start] [end] -f [address] -C [Poly] [Init] [RefIn] [RefOut] [XorOut]
+
+ -k Select the check method:
+ 0: Checksum 8-bit
+ 1: Checksum 16-bit
+ 2: CRC8
+ 3: CRC16
+ 4: CRC32
+
+ -r Range to compute checksum over (default is min and max addresses)
+
+ -f Address of the result to write
+
+ -C Parameters for CRC
+ Parameters for common CRCs are listed in doc/CRC list.txt. They appear in
+ the same order. Feed them as is and use t for TRUE, f for FALSE.
+
+ See also the test/Makefile for these common CRCs; since they're tested,
+ you'll have the command line figured out.
+
+ -E Endian for storing the check result or forcing it
+ 0: little
+ 1: big
+
+ Change from previous versions of hex2bin/mot2bin:
+ Replace former options to this version
+ -k 1 -> -k 1 -E 0
+ -k 2 -> -k 1 -E 1
+
+6. Value inserted directly inside binary file
+ Instead of calculating a value, it can be inserted directly into the file at a specified address.
+
+ hex2bin -k [0|1|2] -F [address] [value]
+
+ -k Select the value format:
+
+ 0 = 8-bit
+ 1 = 16-bit
+ 2 = 32-bit
+
+ -F Address and value of checksum to force
+
+ -E Endian for storing the check result or forcing it
+ 0: little
+ 1: big
+
+7. Motorola S files
+
+ mot2bin example.s19
+
+ Options for mot2bin are the same as hex2bin. Executing the program
+ without argument will display available options. Some are specific to
+ Motorola files.
+
+ This program will handle S19 files generated for Motorola micropro-
+ cessors. Since I use this program for an EPROM programmer, I will
+ rarely need to have more than 4M, I limited the source program for
+ 24 bits or 16 bits address records.
+
+ 32 bits records are now supported, but obviously I can't allocate all
+ the memory for the binary target. What I did is simply assume that the
+ binary file will occupy less than 4M. For binary files greater than 4M,
+ see length option (section 3).
+
+8. Support for byte-swapped hex/S19 files
+
+ -w Wordwise swap: for each pair of bytes, exchange the low and high part.
+ If a checksum needs to be generated to insert in the binary file, select
+ one of the 16-bit checksums.
+
+ hex2bin -w test-byte-swap.hex
+
+9. Goodies
+
+ Description of the file formats is included.
+ Added examples files for extended addressing.
+
+ Check for overlapping records. The check is rather basic: supposing
+ that the buffer is filled with pad bytes, when a record overlaps a
+ previous one, value in the buffer will be different from the pad bytes.
+ This will not detect the case when the previous value equals the pad byte,
+ but it's more likely that more than one byte will be overlapped.
+
+
+10. Error messages
+
+ "Can't allocate memory."
+
+ Can't do anything in this case, so the program simply exits.
+
+ "Error occurred while reading from file"
+
+ Problem with fgets.
+
+ "Input/Output file %s cannot be opened. Enter new filename: "
+
+ The user may not have permissions to open the file.
+
+ "0 byte length data record ignored"
+
+ This means that an empty data record was read. Since it's empty, it's simply
+ ignored and should have no impact on the binary file.
+
+ "Data record skipped at ..."
+
+ This means that the records are falling outside the memory buffer.
+
+ "Overlapped record detected"
+
+ A record is overwritten by a subsequent record. If you're using SDCC, check
+ if more than one area is specified with a starting address. Checking the map
+ file generated by the linker can help.
+
+ "Some error occurred when parsing options."
+
+
+
+11. History
+
+ See ChangeLog
+
+12. Other hex tool
+
+ There is a program that supports more formats and has more features.
+ See SRecord at http://srecord.sourceforge.net/
diff --git a/tools/hex2bin-2.0/doc/S-record.txt b/tools/hex2bin-2.0/doc/S-record.txt
new file mode 100644
index 0000000..ba4abc1
--- /dev/null
+++ b/tools/hex2bin-2.0/doc/S-record.txt
@@ -0,0 +1,361 @@
+S-Record Format
+
+ A file in Motorola S-record format is an ASCII file. There are three different
+ formats:
+
+ S19 for 16-bit address
+ S2 for 24-bit address
+ S3 for 32-bit address
+
+
+ The files consist of optional symbol table information, data specifications
+ for loading memory, and a terminator record.
+
+ [ $$ {module_record}
+ symbol records
+ $$ [ module_record ]
+ symbol_records
+ $$]
+ header_record
+ data_records
+ record_count_record
+ terminator_record
+
+
+Module Record (Optional)
+
+ Each object file contains one record for each module that is a component of it. This
+ record contains the name of the module. There is one module record for each relocatable
+ object created by the assembler. The name of the relocatable object module
+ contained in the record comes from the IDNT directive. For absolute objects created
+ by the linker, there is one module record for each relocatable object file linked,
+ plus an additional record whose name comes from the NAME command for the
+ linker.
+
+ Example:
+
+ $$ MODNAME
+
+
+Symbol Record (Optional)
+
+ As many symbol records as needed can be contained in the object module. Up to 4
+ symbols per line can be used, but it is not mandatory that each line contain 4
+ symbols. A module can contain only symbol records.
+
+ Example:
+
+ APPLE $00000 LABEL1 $ODOC3
+ MEM $OFFFF ZEEK $01947
+
+ The module name associated with the symbols can be specified in the
+ module_record preceding the symbol records.
+
+ Example:
+
+ $$MAIN
+
+ Symbols are assumed to be in the module named in the preceding module_record
+ until another module is specified with another module_record. Symbols defined by
+ the linker's PUBLIC command appear following the first module record, which
+ indicates the name of the output object module specified by the linker's NAME
+ command.
+
+
+*****************************************************************************************
+
+Header Record (SO)
+
+ Each object module has exactly one header record with the following format:
+
+ S00600004844521B
+
+ Description:
+
+ S0 Identifies the record as a header record
+ 06 The number of bytes following this one
+ 0000 The address field, which is ignored
+ 484452 The string HDR in ASCII
+ 1B The checksum
+
+
+
+*****************************************************************************************
+
+Data Record (S1)
+
+ A data record specifies data bytes that are to be loaded into memory. Figure 1
+ shows the format for such a record. The columns shown in the figure represent half
+ of a byte (4 bits).
+
+ ---------------------------------------------
+ | 1 2 3 4 5 6 7 8 9 ... 40 41 42 |
+ | |
+ | S ID byte load data...data checksum |
+ | count address 1 n |
+ ---------------------------------------------
+ Figure 1: Data Record Formatter 16-Bit Load Address
+
+
+ Column Description
+
+ 1 Contains the ASCII character S, which indicates the start of
+ a record in Motorola S-record format.
+
+ 2 Contains the ASCII character identifying the record type.
+ For data records, this character is 1.
+
+ 3 to 4 Contain the count of the number of bytes following this one
+ within the record. The count includes the checksum and the
+ load address bytes but not the byte count itself.
+
+ 5 to 8 Contain the load address. The first data byte is to be loaded
+ into this address and subsequent bytes into the next sequential
+ address. Columns 5 and 6 contain the high-order address
+ byte, and columns 7 and 8 contain the low-order address byte.
+
+ 9 to 40 Contain the specifications for up to 16 bytes of data.
+
+ 41 to 42 Contain a checksum for the record. To calculate this, take the
+ sum of the values of all bytes from the byte count up to the
+ last data byte, inclusive, modulo 256. Subtract this result
+ from 255.
+
+
+*****************************************************************************************
+
+Data Record (S2)
+
+
+ A data record specifies data bytes that are to be loaded into memory. Figure 2
+ shows the format for such a record. The columns shown in the figure represent half
+ of a byte (4 bits).
+
+
+ ----------------------------------------------------
+ | 1 2 3 4 5 6 7 8 9 10 11 ... 42 43 44 |
+ | |
+ | S ID byte load data...data checksum |
+ | count address 1 n |
+ ----------------------------------------------------
+ Figure 2: Data Record Format for 24-Bit Load Address
+
+ Column Description
+
+ 1 Contains the ASCII character S, which indicates the start of
+ a record in Motorola S-record format.
+
+ 2 Contains the ASCII character identifying the record type.
+ For data records, this character is 2.
+
+ 3 to 4 Contain the count of the number of bytes following this one
+ within the record. The count includes the checksum and the
+ load address bytes but not the byte count itself.
+
+ 5 to 10 Contain the load address. The first data byte is to be loaded
+ into this address and subsequent bytes into the next sequential
+ address. Columns 5 and 6 contain the high-order address
+ byte, and columns 9 and 10 contain the low-order address byte.
+
+ 11 to 42 Contain the specifications for up to 16 bytes of data.
+
+ 43 to 44 Contain a checksum for the record. To calculate this, take the
+ sum of the values of all bytes from the byte count up to the
+ last data byte, inclusive, modulo 256. Subtract this result
+ from 255.
+
+
+*****************************************************************************************
+
+Data Record (S3)
+
+
+ A data record specifies data bytes that are to be loaded into memory. Figure 3
+ shows the format for such a record. The columns shown in the figure represent half
+ of a byte (4 bits).
+
+ ----------------------------------------------------------
+ | 1 2 3 4 5 6 7 8 9 10 11 12 13 ... 44 45 46 |
+ | |
+ | S ID byte load data...data checksum |
+ | count address 1 n |
+ ----------------------------------------------------------
+ Figure 3: Data Record Format for 32-Bit Load Address
+
+ Column Description
+
+ 1 Contains the ASCII character S, which indicates the start of
+ a record in Motorola S-record format.
+
+ 2 Contains the ASCII character identifying the record type.
+ For data records, this digit is 3 for 32-bit addresses.
+
+ 3 to 4 Contain the count of the number of bytes following this one
+ within the record. The count includes the checksum and the
+ load address bytes but not the byte count itself.
+
+ 5 to 12 Contain the load address. The first data byte is to be loaded
+ into this address and subsequent bytes into the next sequential
+ address. Columns 5 and 6 contain the high-order address
+ byte, and columns 11 and 12 contain the low-order address byte.
+
+ 13 to 44 Contain the specifications for up to 15 bytes of data.
+
+ 45 to 46 Contain a checksum for the record. To calculate this, take the
+ sum of the values of all bytes from the byte count up to the
+ last data byte, inclusive, modulo 256. Subtract this result
+ from 255.
+
+
+*****************************************************************************************
+
+Record Count Record (S5)
+
+
+ The record count record verifies the number of data records preceding it. Figure 4
+ shows the format for such a record. The columns shown in the figure represent half
+ of a byte (4 bits).
+
+ --------------------------------------
+ | 1 2 3 4 5 6 7 8 9 10 |
+ | |
+ | S ID byte # of data checksum |
+ | count records |
+ --------------------------------------
+ Figure 4: Record Count Record Format
+
+ Column Description
+
+ 1 Contains the ASCII character S, which indicates the start of
+ a record in Motorola S-record format.
+
+ 2 Contains the ASCII character 5, which indicates a record
+ count record.
+
+ 3 to 4 Contain the byte count, ASCII string 03.
+
+ 5 to 8 Contain the number of data records in this file. The high-
+ order byte is in columns 5 and 6.
+
+ 9 to 10 Contain the checksum for the record.
+
+ Example:
+
+ S503010DEE
+
+ The example above shows a record count record indicating a total of 269 records
+ (0x010D) and a checksum of 0xEE.
+
+
+
+*****************************************************************************************
+
+Terminator Record for 32-bit address (S7)
+
+ A terminator record specifies the end of the data records. Figure 5 shows the
+ format for such a record. The columns shown in the figure represent half of a byte
+ (4 bits).
+
+ -------------------------------------
+ | 1 2 3 4 5...12 13 14 |
+ | |
+ | S ID byte load checksum |
+ | count address |
+ -------------------------------------
+ Figure5: Terminator Record Format for 32-Bit Load Address
+
+ Column Description
+
+ 1 Contains the ASCII character S, which indicates the start of
+ a record in Motorola S-record format.
+
+ 2 Contains the ASCII character 7, which indicates a 32-bit
+ load address.
+
+ 3 to 4 Contain the byte count, ASCII string 04.
+
+ 5 to 12 Contain the load address that is either set to zero or to the
+ starting address specified in the END directive or START
+ command (there are no data bytes).
+
+ 13 to 14 Contain the checksum for the record.
+
+*****************************************************************************************
+
+Terminator Record for 24-bit address (S8)
+
+
+ A terminator record specifies the end of the data records. Figure 6 shows the
+ format for such a record. The columns shown in the figure represent half of a byte
+ (4 bits).
+
+ ----------------------------------------
+ | 1 2 3 4 5 6 7 8 9 10 11 12 |
+ | |
+ | S ID byte load checksum |
+ | count address |
+ ----------------------------------------
+ Figure 6: Terminator Record Format for 24-Bit Load Address
+
+ Column Description
+
+ 1 Contains the ASCII character S, which indicates the start of
+ a record in Motorola S-record format.
+
+ 2 Contains the ASCII character 8, which indicates a 24-bit
+ load address.
+
+ 3 to 4 Contain the byte count, ASCII string 04.
+
+ 5 to 10 Contain the load address, which is either set to zero or to the
+ starting address specified in the END directive or START
+ command. There are no data bytes.
+
+ 11 to 12 Contain the checksum for the record.
+
+ Example:
+
+ S804000AF0001
+
+ The previous example shows a terminator record with a 24-bit load address of
+ 0x000AF0 and a checksum of 0x01.
+
+
+*****************************************************************************************
+
+Terminator Record for 16-bit address (S9)
+
+
+ A terminator record specifies the end of the data records. Figure 7 shows the
+ format for such a record. The columns shown in the figure represent half of a byte
+ (4 bits).
+
+ -------------------------------------
+ | 1 2 3 4 5 6 7 8 9 10 |
+ | |
+ | S ID byte load checksum |
+ | count address |
+ -------------------------------------
+ Figure 7: Terminator Record Format for 16-Bit Load Address
+
+
+ Column Description
+
+ 1 Contains the ASCII character S, which indicates the start of
+ a record in Motorola S-record format.
+
+ 2 Contains the ASCII character 9, which indicates a 16-bit
+ load address.
+
+ 3 to 4 Contain the byte count, ASCII string 04.
+
+ 5 to 8 Contain the load address, which is either set to zero or to the
+ starting address specified in the END directive or START
+ command (there are no data bytes).
+
+ 9 to 10 Contain the checksum for the record.
+
+
+
+*****************************************************************************************
+ hagen.v.tronje@on-line.de
diff --git a/tools/hex2bin-2.0/doc/formats.txt b/tools/hex2bin-2.0/doc/formats.txt
new file mode 100644
index 0000000..25e5e37
--- /dev/null
+++ b/tools/hex2bin-2.0/doc/formats.txt
@@ -0,0 +1,72 @@
+Hex formats
+
+Intel
+=====
+
+Hexadecimal values are always in uppercase. Each line is a record.
+The sum of all the bytes in each record should be 00 (modulo 256).
+
+Record types:
+
+00: data records
+01: end-of-file record
+02: extended address record
+
+Data record
+-----------
+
+ :0D011C0000000000C3E0FF0000000000C30F
+
+: 0D 011C 00 00000000C3E0FF0000000000C3 0F
+| | | | -------------+------------ |
+| | | | | +--- Checksum
+| | | | +------------------ Data bytes
+| | | +--------------------------------- Record type
+| | +------------------------------------- Address
+| +----------------------------------------- Number of data bytes
++-------------------------------------------- Start of record
+
+
+End of file record
+------------------
+
+ :00000001FE
+
+: 00 0000 01 FE
+| | | | |
+| | | | +--- Checksum
+| | | +------ Record type
+| | +---------- Address
+| +-------------- Number of data bytes
++----------------- Start of record
+
+
+
+Extended address record
+-----------------------
+
+ :02010002E0001B
+
+: 02 0100 02 E000 1B
+| | | | | |
+| | | | | +--- Checksum
+| | | | +-------- Segment address
+| | | +----------- Record type
+| | +--------------- Address
+| +------------------- Number of data bytes
++---------------------- Start of record
+
+Following data records will start at E000:0100 or E0100
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/tools/hex2bin-2.0/doc/intelhex.spc b/tools/hex2bin-2.0/doc/intelhex.spc
new file mode 100644
index 0000000..946d586
--- /dev/null
+++ b/tools/hex2bin-2.0/doc/intelhex.spc
@@ -0,0 +1,409 @@
+
+======================================================================
+
+Intel
+Hexadecimal Object File
+Format Specification
+Revision A, 1/6/88
+
+
+
+DISCLAIMER
+
+Intel makes no representation or warranties with respect to the contents
+hereof and specifically disclaims any implied warranties of
+merchantability or fitness for any particular purpose. Further, Intel
+reserves the right to revise this publication from time to time in the
+content hereof without obligation of Intel to notify any person of such
+revision or changes. The publication of this specification should not
+be construed as a commitment on Intel's part to implement any product.
+
+
+1. Introduction
+This document describes the hexadecimal object file format for the Intel
+8- bit, 16-bit, and 32-bit microprocessors. The hexadecimal format is
+suitable as input to PROM programmers or hardware emulators.
+Hexadecimal object file format is a way of representing an absolute
+binary object file in ASCII. Because the file is in ASCII instead of
+binary, it is possible to store the file is non-binary medium such as
+paper-tape, punch cards, etc.; and the file can also be displayed on CRT
+terminals, line printers, etc.. The 8-bit hexadecimal object file
+format allows for the placement of code and data within the 16-bit
+linear address space of the Intel 8-bit processors. The 16-bit
+hexadecimal format allows for the 20-bit segmented address space of the
+Intel 16-bit processors. And the 32-bit format allows for the 32-bit
+linear address space of the Intel 32-bit processors.
+The hexadecimal representation of binary is coded in ASCII alphanumeric
+characters. For example, the 8-bit binary value 0011-1111 is 3F in
+hexadecimal. To code this in ASCII, one 8-bit byte containing the ASCII
+code for the character '3' (0011-0011 or 033H) and one 8-bit byte
+containing the ASCII code for the character 'F' (0100-0110 or 046H) are
+required. For each byte value, the high-order hexadecimal digit is
+always the first digit of the pair of hexadecimal digits. This
+representation (ASCII hexadecimal) requires twice as ma ny bytes as the
+binary representation.
+A hexadecimal object file is blocked into records, each of which
+contains the record type, length, memory load address and checksum in
+addition to the data. There are currently six (6) different types of
+records that are defined, not all combinations of these records are
+meaningful, however. The records are:
+
+Data Record (8-, 16-, or 32-bit formats)
+End of File Record (8-, 16-, or 32-bit formats)
+Extended Segment Address Record (16- or 32-bit formats)
+Start Segment Address Record (16- or 32-bit formats)
+Extended Linear Address Record (32-bit format only)
+Start Linear Address Record (32-bit format only)
+
+
+2. General Record Format
+| RECORD | LOAD | | | INFO | |
+| MARK | RECLEN | OFFSET | RECTYP | or | CHKSUM |
+| ':' | | | | DATA | |
+ 1-byte 1-byte 2-bytes 1-byte n-bytes 1-byte
+
+Each record begins with a RECORD MARK field containing 03AH, the ASCII
+code for the colon (':') character.
+Each record has a RECLEN field which specifies the number of bytes of
+information or data which follows the RECTYP field of the record. Note
+that one data byte is represented by two ASCII characters. The maximum
+value of the RECLEN field is hexadecimal 'FF' or 255.
+Each record has a LOAD OFFSET field which specifies the 16-bit starting
+load offset of the data bytes, therefore this field is only used for
+Data Records. In other records where this field is not used, it should
+be coded as four ASCII zero characters ('0000' or 030303030H).
+Each record has a RECTYP field which specifies the record type of this
+record. The RECTYP field is used to interpret the remaining information
+within the record. The encoding for all the current record types are:
+
+'00' Data Record
+'01' End of File Record
+'02' Extended Segment Address Record
+'03' Start Segment Address Record
+'04' Extended Linear Address Record
+'05' Start Linear Address Record
+
+Each record has a variable length INFO/DATA field, it consists of zero
+or more bytes encoded as pairs of hexadecimal digits. The
+interpretation of this field depends on the RECTYP field.
+Each record ends with a CHKSUM field that contains the ASCII hexadecimal
+representation of the two's complement of the 8-bit bytes that result
+from converting each pair of ASCII hexadecimal digits to one byte of
+binary, from and including the RECLEN field to and including the last
+byte of the INFO/DATA field. Therefore, the sum of all the ASCII pairs
+in a record after converting to binary, from the RECLEN field to and
+including the CHKSUM field, is zero.
+
+
+3. Extended Linear Address Record (32-bit format only)
+| RECORD | LOAD | | | | |
+| MARK | RECLEN | OFFSET | RECTYP | ULBA | CHKSUM |
+| ':' | '02' | '0000' | '04' | | |
+ 1-byte 1-byte 2-bytes 1-byte 2-bytes 1-byte
+
+The 32-bit Extended Linear Address Record is used to specify bits 16-31
+of the Linear Base Address (LBA), where bits 0-15 of the LBA are zero.
+Bits 16-31 of the LBA are referred to as the Upper Linear Base Address
+(ULBA). The absolute memory address of a content byte in a subsequent
+Data Record is obtained by adding the LBA to an offset calculated by
+adding the LOAD OFFSET field of the containing Data Record to the index
+of the byte in the Data Record (0, 1, 2, ... n). This offset addition
+is done modulo 4G (i.e., 32-bits), ignoring any carry, so that offset
+wrap-around loading (from OFFFFFFFFH to OOOOOOOOOH) results in wrapping
+around from the end to the beginning of the 4G linear address defined by
+the LBA. The linear address at which a particular byte is loaded is
+calculated as:
+(LBA + DRLO + DRI) MOD 4G
+where:
+DRLO is the LOAD OFFSET field of a Data Record.
+DRI is the data byte index within the Data Record.
+
+When an Extended Linear Address Record defines the value of LBA, it may
+appear anywhere within a 32-bit hexadecimal object file. This value
+remains in effect until another Extended Linear Address Record is
+encountered. The LBA defaults to zero until an Extended Linear Address
+Record is encountered.
+The contents of the individual fields within the record are:
+
+RECORD MARK
+This field contains 03AH, the hexadecimal encoding of the ASCII colon
+(':') character.
+
+RECLEN
+The field contains 03032H, the hexadecimal encoding of the ASCII
+characters '02', which is the length, in bytes, of the ULBA data
+information within this record.
+
+LOAD OFFSET
+This field contains 030303030H, the hexadecimal encoding of the ASCII
+characters '0000', since this field is not used for this record.
+
+RECTYP
+This field contains 03034H, the hexadecimal encoding of the ASCII
+character '04', which specifies the record type to be an Extended Linear
+Address Record.
+
+ULBA
+This field contains four ASCII hexadecimal digits that specify the
+16-bit Upper Linear Base Address value. The high-order byte is the
+10th/llth character pair of the record. The low-order byte is the
+12th/13th character pair of the record.
+
+CHKSUM
+This field contains the check sum on the RECLEN, LOAD OFFSET, RECTYP,
+and ULBA fields.
+
+
+4. Extended Segment Address Record (16- or 32-bit formats)
+| RECORD | LOAD | | | | |
+| MARK | RECLEN | OFFSET | RECTYP | USBA | CHKSUM |
+| ':' | '02' | '0000' | '02' | | |
+ 1-byte 1-byte 2-bytes 1-byte 2-bytes 1-byte
+
+The 16-bit Extended Segment Address Record is used to specify bits 4-19
+of the Segment Base Address (SBA), where bits 0-3 of the SBA are zero.
+Bits 4-19 of the SBA are referred to as the Upper Segment Base Address
+(USBA). The absolute memory address of a content byte in a subsequent
+Data Record is obtained by adding the SBA to an offset calculated by
+adding the LOAD OFFSET field of the containing Data Record to the index
+of the byte in the Data Record (0, 1, 2, ... n). This offset addition
+is done modulo 64K (i.e., 16-bits), ignoring any carry, so that offset
+wraparound loading (from OFFFFH to OOOOOH) results in wrapping around
+from the end to the beginning of the 64K segment defined by the SBA.
+The address at which a particular byte is loaded is calculated as:
+
+ SBA + ([DRLO + DRI] MOD 64K)
+
+where:
+ DRLO is the LOAD OFFSET field of a Data Record.
+ DRI is the data byte index within the Data Record.
+
+When an Extended Segment Address Record defines the value of SBA, it
+may appear anywhere within a 16-bit hexadecimal object file. This
+value remains in effect until another Extended Segment Address
+Record is encountered. The SBA defaults to zero until an Extended
+Segment Address Record is encountered.
+
+The contents of the individual fields within the record are:
+
+RECORD MARK
+This field contains 03AH, the hexadecimal encoding of the ASCII
+colon (':') character.
+
+RECLEN
+The field contains 03032H, the hexadecimal encoding of the ASCII
+characters '02', which is the length, in bytes, of the USBA data
+information within this record.
+
+LOAD OFFSET
+This field contains 030303030H, the hexadecimal encoding of the
+ASCII characters '0000', since this field is not used for this
+record.
+
+RECTYP
+This field contains 03032H, the hexadecimal encoding of the ASCII
+character '02', which specifies the record type to be an Extended
+Segment Address Record.
+
+USBA
+This field contains four ASCII hexadecimal digits that specify the
+16-bit Upper Segment Base Address value. The high-order byte is the
+10th/1lth character pair of the record. The low-order byte is the
+12th/13th character pair of the record.
+
+CHKSUM
+This field contains the check sum on the RECLEN, LOAD OFFSET,
+RECTYP, and USBA fields.
+
+5. Data Record (8-, 16-, or 32-bit formats)
+
+| RECORD | LOAD | | | | |
+| MARK | RECLEN | OFFSET | RECTYP | DATA | CHKSUM |
+| ':' | | | '00' | | |
+ 1-byte 1-byte 2-bytes 1-byte n-bytes 1-byte
+
+
+The Data Record provides a set of hexadecimal digits that represent
+the ASCII code for data bytes that make up a portion of a memory
+image. The method for calculating the absolute address (linear in
+the 8-bit and 32-bit case and segmented in the 16-bit case) for each
+byte of data is described in the discussions of the Extended Linear
+Address Record and the Extended Segment Address Record.
+
+The contents of the individual fields within the record are:
+
+RECORD MARK
+This field contains 03AH, the hexadecimal encoding of the ASCII
+colon (':') character.
+
+RECLEN
+The field contains two ASCII hexadecimal digits that specify the
+number of data bytes in the record. The maximum value is 'FF' or
+04646H (255 decimal).
+
+LOAD OFFSET
+This field contains four ASCII hexadecimal digits representing the
+offset from the LBA (see Extended Linear Address Record) or SBA (see
+Extended Segment Address Record) defining the address which the
+first byte of the data is to be placed.
+
+RECTYP
+This field contains 03030H, the hexadecimal encoding of the ASCII
+character '00', which specifies the record type to be a Data Record.
+
+DATA
+This field contains pairs of ASCII hexadecimal digits, one pair for
+each data byte.
+
+CHKSUM
+This field contains the check sum on the RECLEN, LOAD OFFSET,
+RECTYP, and DATA fields.
+
+
+6. Start Linear Address Record (32-bit format only)
+
+| RECORD | LOAD | | | | |
+| MARK | RECLEN | OFFSET | RECTYP | EIP | CHKSUM |
+| ':' | '04' | '0000' | '05' | | |
+ 1-byte 1-byte 2-bytes 1-byte 4-bytes 1-byte
+
+
+The Start Linear Address Record is used to specify the execution
+start address for the object file. The value given is the 32-bit
+linear address for the EIP register. Note that this record only
+specifies the code address within the 32-bit linear address space of
+the 80386. If the code is to start execution in the real mode of
+the 80386, then the Start Segment Address Record should be used
+instead, since that record specifies both the CS and IP register
+contents necessary for real mode.
+
+The Start Linear Address Record can appear anywhere in a 32-bit
+hexadecimal object file. If such a record is not present in a
+hexadecimal object file, a loader is free to assign a default start
+address.
+
+The contents of the individual fields within the record are:
+
+RECORD MARK
+This field contains 03AH, the hexadecimal encoding of the ASCII
+colon (':') character.
+
+RECLEN
+The field contains 03034H, the hexadecimal encoding of the ASCII
+characters '04', which is the length, in bytes, of the EIP register
+content within this record.
+
+LOAD OFFSET
+This field contains 030303030H, the hexadecimal encoding of the
+ASCII characters '0000', since this field is not used for this
+record.
+
+RECTYP
+This field contains 03035H, the hexadecimal encoding of the ASCII
+character '05', which specifies the record type to be a Start Linear
+Address Record.
+
+EIP
+This field contains eight ASCII hexadecimal digits that specify the
+32-bit EIP register contents. The high-order byte is the 10th/1lth
+character pair.
+
+CHKSUM
+This field contains the check sum on the RECLEN, LOAD OFFSET,
+RECTYP, and EIP fields.
+
+
+7. Start Segment Address Record (16- or 32-bit formats)
+
+| RECORD | LOAD | | | | |
+| MARK | RECLEN | OFFSET | RECTYP | CS/IP | CHKSUM |
+| ':' | '04' | '0000' | '03' | | |
+ 1-byte 1-byte 2-bytes 1-byte 4-bytes 1-byte
+
+
+The Start Segment Address Record is used to specify the execution
+start address for the object file. The value given is the 20-bit
+segment address for the CS and IP registers. Note that this record
+only specifies the code address within the 20-bit segmented address
+space of the 8086/80186.
+
+The Start Segment Address Record can appear anywhere in a 16-bit
+hexadecimal object file. If such a record is not present in a
+hexadecimal object file, a loader is free to assign a default start
+address.
+
+The contents of the individual fields within the record are:
+
+RECORD MARK
+This field contains 03AH, the hexadecimal encoding of the ASCII
+colon (':') character.
+
+RECLEN
+The field contains 03034H, the hexadecimal encoding of the ASCII
+characters '04', which is the length, in bytes, of the CS/IP
+register contents within this record.
+
+LOAD OFFSET
+This field contains 030303030H, the hexadecimal encoding of the
+ASCII characters '0000', since this field is not used for this
+record.
+
+RECTYP
+This field contains 03033H, the hexadecimal encoding of the ASCII
+character '03', which specifies the record type to be a Start
+Segment Address Record.
+
+CS/IP
+This field contains eight ASCII hexadecimal digits that specify the
+16-bit CS register and 16-bit IP register contents. The high-order
+byte of the CS register content is the 10th/llth character pair, the
+low-order byte is the 12th/13th character pair of the record. The
+high-order byte of the IP register content is the 14th/15th
+character pair, the low-order byte is the 16th/17th character pair
+of the record.
+
+CHKSUM
+This field contains the check sum on the RECLEN, LOAD OFFSET,
+RECTYP, and CS/IP fields.
+
+
+
+8. End of File Record (8-, 16-, or 32-bit formats)
+
+| RECORD | LOAD | | | |
+| MARK | RECLEN | OFFSET | RECTYP | CHKSUM |
+| ':' | '00' | '0000' | '01' | |
+ 1-byte 1-byte 2-bytes 1-byte 1-byte
+
+The End of File Record specifies the end of the hexadecimal object
+file.
+
+The contents of the individual fields within the record are:
+
+RECORD MARK
+This field contains 03AH, the hexadecimal encoding of the ASCII
+colon (':') character.
+
+RECLEN
+The field contains 03030H, the hexadecimal encoding of the ASCII
+characters '00'. Since this record does not contain any INFO/DATA
+bytes, the length is zero.
+
+LOAD OFFSET
+This field contains 030303030H, the hexadecimal encoding of the
+ASCII characters '0000', since this field is not used for this
+record.
+
+RECTYP
+This field contains 03031H, the hexadecimal encoding of the ASCII
+character '01', which specifies the record type to be an End of File
+Record.
+
+CHKSUM
+This field contains the check sum an the RECLEN, LOAD OFFSET, and
+RECTYP fields. Since all the fields are static, the check sum can
+also be calculated statically, and the value is 04646H, the
+hexadecimal encoding of the ASCII characters 'FF'.
+
+========================================================================
+END
diff --git a/tools/hex2bin-2.0/doc/srec.txt b/tools/hex2bin-2.0/doc/srec.txt
new file mode 100644
index 0000000..ea63d31
--- /dev/null
+++ b/tools/hex2bin-2.0/doc/srec.txt
@@ -0,0 +1,447 @@
+S-Records
+
+
+ -S-Record Format-
+
+ Chaplin@keinstr.uucp (Roger Chaplin) reposted an article written
+ by mcdchg!motmpl!ron (Ron Widell) that explained how Motorola
+ S-Records are formatted. This comes from a unix man page. No
+ mention of which version of Unix is specified. This section
+ of the FAQ is a bit long. An anonymous ftp archive is currently
+ being sought. When one is found, the section will be placed in
+ the archive.
+
+
+ SREC(4) UNIX 5.0 (03/21/84) SREC(4)
+
+
+ An S-record file consists of a sequence of specially formatted
+ ASCII character strings. An S-record will be less than or equal to
+ 78 bytes in length.
+
+ The order of S-records within a file is of no significance and no
+ particular order may be assumed.
+
+ The general format of an S-record follow:
+
+ +------------------//-------------------//-----------------------+
+ | type | count | address | data | checksum |
+ +------------------//-------------------//-----------------------+
+
+ type A char-2- field. These characters describe the
+ type of record (S0, S1, S2, S3, S5, S7, S8, or
+ S9).
+ count A char-2- field. These characters when paired and
+ interpreted as a hexadecimal value, display the
+ count of remaining character pairs in the record.
+
+ address A char-4,6, or 8- field. These characters grouped
+ and interpreted as a hexadecimal value, display
+ the address at which the data field is to be
+ loaded into memory. The length of the field
+ depends on the number of bytes necessary to hold
+ the address. A 2-byte address uses 4 characters,
+ a 3-byte address uses 6 characters, and a 4-byte
+ address uses 8 characters.
+ data A char -0-64- field. These characters when paired
+ and interpreted as hexadecimal values represent
+ the memory loadable data or descriptive
+ information.
+
+ checksum A char-2- field. These characters when paired and
+ interpreted as a hexadecimal value display the
+ least significant byte of the ones complement of
+ the sum of the byte values represented by the
+ pairs of characters making up the count, the
+ address, and the data fields.
+
+ Each record is terminated with a line feed. If any
+ additional or different record terminator(s) or delay
+ characters are needed during transmission to the target
+ system it is the responsibility of the transmitting program
+ to provide them.
+
+ S0 Record The type of record is 'S0' (0x5330). The address
+
+
+ field is unused and will be filled with zeros
+ (0x0000). The header information within the data
+ field is divided into the following subfields.
+
+ mname is char-20- and is the
+ module name.
+ ver is char-2- and is the
+ version number.
+
+ rev is char-2- and is the
+ revision number.
+ description is char-0-36- and is a
+ text comment.
+
+ Each of the subfields is composed of ASCII bytes
+ whose associated characters, when paired,
+ represent one byte hexadecimal values in the case
+ of the version and revision numbers, or represent
+ the hexadecimal values of the ASCII characters
+ comprising the module name and description.
+
+ S1 Record The type of record field is 'S1' (0x5331). The
+ address field is interpreted as a 2-byte address.
+ The data field is composed of memory loadable
+ data.
+ S2 Record The type of record field is 'S2' (0x5332). The
+ address field is interpreted as a 3-byte address.
+ The data field is composed of memory loadable
+ data.
+
+ S3 Record The type of record field is 'S3' (0x5333). The
+ address field is interpreted as a 4-byte address.
+ The data field is composed of memory loadable
+ data.
+ S5 Record The type of record field is 'S5' (0x5335). The
+ address field is interpreted as a 2-byte value
+ and contains the count of S1, S2, and S3 records
+ previously transmitted. There is no data field.
+
+ S7 Record The type of record field is 'S7' (0x5337). The
+ address field contains the starting execution
+ address and is interpreted as 4-byte address.
+ There is no data field.
+ S8 Record The type of record field is 'S8' (0x5338). The
+ address field contains the starting execution
+ address and is interpreted as 3-byte address.
+ There is no data field.
+
+ S9 Record The type of record field is 'S9' (0x5339). The
+ address field contains the starting execution
+ address and is interpreted as 2-byte address.
+ There is no data field.
+
+ EXAMPLE
+
+ Shown below is a typical S-record format file.
+
+ S00600004844521B
+ S1130000285F245F2212226A000424290008237C2A
+ S11300100002000800082629001853812341001813
+ S113002041E900084E42234300182342000824A952
+ S107003000144ED492
+ S5030004F8
+ S9030000FC
+
+ The file consists of one S0 record, four S1 records, one S5
+ record and an S9 record.
+
+ The S0 record is comprised as follows:
+
+ S0 S-record type S0, indicating it is a header
+ record.
+ 06 Hexadecimal 06 (decimal 6), indicating that six
+ character pairs (or ASCII bytes) follow.
+
+ 00 00 Four character 2-byte address field, zeroes in
+ this example.
+ 48 ASCII H, D, and R - "HDR".
+
+ 1B The checksum.
+
+ The first S1 record is comprised as follows:
+ S1 S-record type S1, indicating it is a data record
+ to be loaded at a 2-byte address.
+
+ 13 Hexadecimal 13 (decimal 19), indicating that
+ nineteen character pairs, representing a 2 byte
+ address, 16 bytes of binary data, and a 1 byte
+ checksum, follow.
+ 00 00 Four character 2-byte address field; hexadecimal
+ address 0x0000, where the data which follows is to
+ be loaded.
+
+ 28 5F 24 5F 22 12 22 6A 00 04 24 29 00 08 23 7C Sixteen
+ character pairs representing the actual binary
+ data.
+ 2A The checksum.
+
+ The second and third S1 records each contain 0x13 (19)
+ character pairs and are ended with checksums of 13 and 52,
+ respectively. The fourth S1 record contains 07 character
+ pairs and has a checksum of 92.
+
+ The S5 record is comprised as follows:
+
+ S5 S-record type S5, indicating it is a count record
+ indicating the number of S1 records.
+
+
+
+ 03 Hexadecimal 03 (decimal 3), indicating that three
+ character pairs follow.
+
+ 00 04 Hexadecimal 0004 (decimal 4), indicating that
+ there are four data records previous to this
+ record.
+ F8 The checksum.
+
+ The S9 record is comprised as follows:
+
+ S9 S-record type S9, indicating it is a termination
+ record.
+ 03 Hexadecimal 03 (decimal 3), indicating that three
+ character pairs follow.
+
+ 00 00 The address field, hexadecimal 0 (decimal 0)
+ indicating the starting execution address.
+ FC The checksum.
+
+
+ -Intel Hex ASCII Format-
+
+ Intel HEX-ASCII format takes the form:
+
+ +----------------------------------- Start Character
+ |
+ | +-------------------------------- Byte Count
+ | | (# of data bytes)
+ | |
+ | | +-------------------------- Address of first data.
+ | | |
+ | | | +-------------------- Record Type (00 data,
+ | | | | 01 end of record)
+ | | | |
+ | | | | +------------ Data Bytes
+ | | | | |
+ | | | | | +---- Checksum
+ | | | | | |
+ | / \ / \ / \ / \ / \
+ : B C A A A A T T H H ... H H C C
+
+ An examples:
+
+ :10000000DB00E60F5F1600211100197ED300C3004C
+ :1000100000000101030307070F0F1F1F3F3F7F7FF2
+ :01002000FFE0
+ :00000001FF
+
+ This information comes from _Microprocessors and Programmed
+ Logic_, Second Edition, Kenneth L. Short, 1987, Prentice-Hall,
+ ISBN 0-13-580606-2.
+
+ Provisions have been made for data spaces larger than 64 kBytes.
+ The above reference does not discuss them. I suspect there is
+ a start of segment type record, but I do not know how it is
+ implemented.
+
+----------------------------------------------------------------------------
+
+/* This file contains source code to read a Motorola S-record file into
+** a memory image. The size of the file cannot exceed BUFSIZE of data.
+** The image is then written to disk either as binary data starting at
+** address 0 with no data gaps, or as a C array of unsigned longs.
+** Input lines must be no longer than MAXLINE. No check is made!
+**
+** Author: Eric McRae, Electro-Logic Machines, Inc.
+** Date: Copyright 1994
+**
+** This source code is made available to the public "as is". No
+** warranty is given or implied for it's proper operation. This source
+** code may be used in whole or in part as long as this copyright is
+** included.
+*/
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+
+/* Comment the following line for non PC applications */
+#define PCDOS
+
+/* Uncomment the following line if you want a binary output instead of
+** a structure
+*/
+/* #define BINARY */
+
+#ifdef PCDOS /* Intel x86 architecture */
+#define BUFSIZE 49152 /* 48K to avoid segment hopping */
+#else /* Any reasonable (non-segmented) arch... */
+#define BUFSIZE 65536 /* As big as you want */
+#endif
+
+#define MAXLINE 256 /* Length of longest input line + 1 */
+/* Globals */
+FILE *infilePH, *outfilePH; /* Handles for input and output files */
+unsigned char *bufAC, /* Allocated image buffer */
+ *highestPC = NULL; /* Highest buffer address written */
+
+/* Change this string to reflect the name of the output array */
+char headerAC[] = "unsigned long sRec[] =\n{\n";
+
+/* Predeclarations */
+int parsebufN( char * ); /* Does the actual parsing */
+
+void main(int argc, const char * argv[])
+{
+ int c, /* Temp char storage */
+ resN; /* result status */
+ char *lbufPC, lbufAC[MAXLINE];
+ int linectrN = 0; /* Used to correlate parse fail to input line */
+
+#ifndef BINARY
+ int i;
+ unsigned long *codePL;
+ unsigned char *codePC;
+#endif
+
+ /* Check the argument count */
+ if( argc != 3 ) /* If didn't specify input and output files */
+ {
+ printf("Usage: %s: infile outfile\n", argv[0] );
+ exit(1);
+ }
+
+ /* OK, let's open some files */
+ if( ( infilePH = fopen( argv[1], "r" ) )== NULL )
+ {
+ printf("%s: Couldn't open input file %s\n", argv[0], argv[1] );
+ exit(2);
+ }
+
+ if( ( outfilePH = fopen( argv[2], "w" ) ) == NULL )
+ {
+ printf("%s: Couldn't open output file %s\n", argv[0], argv[3] );
+ exit(3);
+ }
+
+ /* OK, get a buffer and clear it. */
+ if( (bufAC = calloc( (size_t)BUFSIZE, (size_t)1 )) == NULL )
+ {
+ printf("%s: Couldn't malloc memory for buffer\n", argv[0] );
+ exit(4);
+ }
+
+ lbufPC = lbufAC; /* Point at beginning of line buffer */
+ while( c = fgetc( infilePH ))
+ {
+ if( (c == '\n') || (c == EOF) ) /* If found end of line or file */
+ { /* Parse the Line */
+ if( ( c == EOF ) && ( ferror( infilePH ) ) )
+ {
+ printf("%s: Error reading input file\n", argv[0] );
+ exit(5);
+ }
+ else
+ { /* OK, have a complete line in buffer */
+ linectrN++; /* Increment line counter */
+ if( lbufPC == lbufAC )
+ break; /* ignore blank lines */
+ *lbufPC = 0; /* Terminate the line string */
+ if( resN = parsebufN( lbufAC ) ) /* Parse data record to mem */
+ {
+ printf("%s: Error reading input file at line %d, return code = %d\n",
+ argv[0], linectrN, resN );
+ exit( resN );
+ }
+ lbufPC = lbufAC; /* Repoint line buffer pointer */
+ } /* End of have a complete line */
+ }
+ else
+ *lbufPC++ = c; /* Place char into line buffer */
+ }
+
+ /* At this point, the input file has been emptied. Now dispose of the
+ ** output data according to compilation mode.
+ */
+
+#ifdef BINARY
+
+ /* Write the buffer back to disk as a binary image */
+ resN = fwrite( bufAC, 1, (size_t)((highestPC - bufAC) + 1), outfilePH );
+ if( resN != (int)( (highestPC - bufAC) + 1) )
+ {
+ printf("%s: Error writing output file\n", argv[0] );
+ exit( 6 );
+ }
+
+#else
+ /* Produce a file that can be included in a C program. Data is read
+ ** from buffer as bytes to avoid portability/endian problems with
+ ** this program.
+ */
+ /* Output header first, then 1 long per line */
+ fwrite( (void *)headerAC, 1, (size_t)(sizeof( headerAC )-1), outfilePH );
+
+ codePL = (unsigned long *)bufAC;
+ for( i = (highestPC - bufAC + 1) / 4; i; i-- ) /* for each long */
+ {
+ codePC = (unsigned char *)codePL++;
+ sprintf(lbufAC, "0x%02x%02x%02x%02x%s",
+ *codePC, *(codePC + 1), *(codePC + 2), *(codePC + 3),
+ i == 1 ? "\n" : ",\n" ); /* No comma after final long */
+ fwrite( lbufAC, 1, (size_t)(strlen( lbufAC )), outfilePH );
+ }
+ /* OK, data has been written out, close end of array */
+ fwrite( "};\n", 1, (size_t)3, outfilePH );
+#endif
+}
+
+/* Function: parsebufV
+** Parses an S-record in the buffer and writes it into the buffer
+** if it is has a valid checksum.
+**
+** Args: pointer to character buffer for null terminated line
+** Returns: int result code: 0 = success, else failure
+*/
+int parsebufN( char *lbufPC )
+{
+ unsigned long addrL;
+ unsigned char cksmB, /* checksum of addr, count, & data length */
+ *bufPC; /* Pointer into memory array */
+ int i, countN, /* Number of bytes represented in record */
+ oheadN, /* Number of overhead (addr + chksum) bytes */
+ tvalN; /* Temp for check checksum */
+
+ switch( *(lbufPC+1) ) /* examine 2nd character on the line */
+ {
+ case '1': /* 16 bit address field */
+ if( sscanf(lbufPC, "S1%2x%4lx", &countN, &addrL ) != 2 )
+ return( 10 ); /* Flag error in S1 record */
+ oheadN = 3; /* 2 address + 1 checksum */
+ break;
+
+ case '2': /* 24 bit address field */
+ if( sscanf(lbufPC, "S2%2x%6lx", &countN, &addrL ) != 2 )
+ return( 11 ); /* Flag error in S2 record */
+ oheadN = 4; /* 3 address + 1 checksum */
+ break;
+
+ case '3': /* 32 bit address field */
+ if( sscanf(lbufPC, "S3%2x%8lx", &countN, &addrL ) != 2 )
+ return( 12 ); /* Flag error in S3 record */
+ oheadN = 5; /* 4 address + 1 checksum */
+ break;
+
+ default: /* ignore all but S1,2,3 records. */
+ return( 0 );
+ }
+
+ if( addrL > BUFSIZE ) return( 13 ); /* if address exceeds buffer size */
+ bufPC = bufAC + addrL; /* otherwise, point to right spot in buffer */
+
+ /* OK now see if checksum is OK, while reading data to buffer */
+ cksmB = 0;
+ countN++; /* Bump counter to read final checksum too */
+ for( i = 1; i <= countN; i++ )
+ {
+ sscanf( lbufPC + i*2, "%2x", &tvalN ); /* Scan a 2 hex digit byte */
+ cksmB += (unsigned char)tvalN;
+ if( ( i > oheadN ) && ( i < countN ) ) /* If scanned a data byte */
+ *bufPC++ = (unsigned char) tvalN; /* write it to the buffer */
+ }
+ if( cksmB += 1 ) return( 14 ); /* flag checksum error */
+
+ if( (bufPC - 1) > highestPC )
+ highestPC = bufPC - 1; /* track highest address loaded */
+
+ return( 0 ); /* Successful return */
+}
+
+
+