Yet Another Hex to bin converter

It can handle the extended Intel hex format.
Records need not be sorted and there can be gaps between records.

How does it work?

It allocates a one meg buffer and just place the converted bytes in its
buffer. At the end, the buffer is written to disk. Using a buffer eliminates
the need to sort records.


1. Compiling on Linux

	make
	
	then 
	
	make install
	
	This will install the program to /usr/local/bin.
	
2. Using hex2bin

	hex2bin example.hex
	
	hex2bin will generate a binary file example.bin starting at the 
	lowest address in the hex file.
	
	If the lowest address isn't 0000, ex: 0100, there will be problems 
	when using the binary file to program a EPROM since the first byte
	that should be at 0100 will be programmed at address 0000 (with my
	homemade EPROM programmer for example).
	If you can't specify the starting address to your EPROM programmer,
	you can specify a starting address on the command line:
		
	hex2bin -s 0000 start_at_0100.hex
	
	The bytes will be stored in the binary file with a padding from 0000
	to the lowest addess (00FF in this case). Padding bytes are all FF
	so an EPROM programmer can skip these bytes when programming.
	
3. Notes

	This program does minimal error checking since many hex files are
	generated by known good assemblers.


4. Checksum

	By default, it ignores 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 checksum error somewhere, the program will continue the
	conversion anyway.
	
	The example file example.hex contains some records with checksum errors.

5. Motorola S files
	
	mot2bin example.s19

	Options for mot2bin are the same as hex2bin. Executing the program
	without argument will display available options.

	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 1 Meg, I limited the source program for
	24 bits or 16 bits address records.
	
	Supporting 32 bits records would imply a redesign
	of the program because the buffer for storing bytes should be bigger
	than 1 Meg, but the conversion part is already done.


6. Compiling on DOS
	I didn't check this, but it should be relatively easy. The only problem
	may be to allocate a 1 Meg memory block. On recent DOS c compilers
	this should not be a problem anymore.

7. Goodies
	Description of the file formats is included.
