Initial import1.0

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 */

+}

+

+

+