UNLOAD23

Here is a BRIEF description of the format of an INTEL (8 bit) HEX file.

Each line in the file is a stand-alone unit called a "paragraph".
The paragraphs are built with upper case ascii-hex (0-F) characters.
Each character represents 1 nybble.

The format of each paragraph is as follows :

COLON  Data   Address of   Type of      pairs of nybbles    CRC
       Count  First data   paragraph

  :    10     10F0           00           00 01 02 03 ....   FF

The characters all go together, not separate as shown above. The
paragraph is terminated with a carrage return (0DH) and line
feed (0AH). The colon is mandatory.

The paragraph type is either 00, (not the end yet), or 01, (last
paragraph.)

The CRC is the two's complement of the 8 bit addition of all the
characters following the COLON, AFTER they have been converted to
real binary-hex.

   TAH (above taken from a remote BBS message response)


     UNLOAD23 is derived from UNLOAD21, a venerable P.D. program that
converts .COM files to .HEX files, the opposite of Digital Research's
LOAD.COM.  This is useful if you want to send the data to a PROM
programmer, send it to a 7 bit device like a paper tape punch, (in
1987?) or down a serial link where the .HEX file's built in checksum
gives some degree of confidence in an ASCII transfer.

     Having used UNLOAD21 on a regular basis, I quickly found some
deficiencies.  The most annoying was the fact that UNLOAD21 forced the
input file to be a .COM file.  Not defaulted, FORCED.  As I was often
UNLOADing files that weren't even 8080/Z-80 code, I didn't want these
non-executable files called .COM files on my CP/M disk.  Makes for
confusion, I prefer to call these files .CIM for Core IMage.  The next
problem I found was in the EOF record.  UNLOAD21 output an EOF record
(End Of File record) consisting of ten (10) ASCII zeros.  This is also
the EOF record output by ASM.COM, MAC.COM, & maybe others.  This type of
EOF record does not meet the Intel specification, and caused at least
one PROM programmer I was working with to "choke".  The third problem
was mainly one of preference.  A previous programmer had changed
UNLOAD21 to output 32 byte data records, to conserve disk space.  This
is perfectly legal, however it does reduce the reliability of the
checksum.  I prefer the more standard 16 byte data record.

     All the above problems have been fixed with UNLOAD23!  The program
defaults to a .COM filetype for the input file, but allows .CIM or other
input filetypes as well.  The EOF record now meets the Intel
specification.  The user now has the option of setting the output data
record size.  (Defaults to 16)


        Invoke as follows:

UNLOAD23 FILENAME<.EXT> <ADDR></X>


        Where:


         FILENAME  is the name of the file you wish to convert

         <.EXT>  is the extension, if not given, assumes .COM

         <ADDR>  is the load address, if not given defaults to 0100H

         </X>  is the data record size, if given after an address

         parameter, there must be no spaces!  Where X:


        /S   Small, 8 bytes per data record, for max reliability

             (Within reason) of checksum.


        /M   Medium, 16 bytes per data record, the old standby.


        /L   Large, 32 bytes per data record, some prefer it because

             the resultant file is smaller.


        /E   Extra large, 64 bytes per data record.  Produces even

             smaller files.

Notes by Mark D. Pickerill, SYSOP Hacker Heaven BBS, (408) 375-5455
9/5/87