Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
srec_signetics(5)	      File Formats Manual	     srec_signetics(5)

NAME
       srec_signetics -	Signetics file format

DESCRIPTION
       The Signetics file format is not	often used.  The major disadvantage in
       modern applications is that the addressing range	 is  limited  to  only
       64kb.

   Records
       All data	lines are called records, and each record contains the follow-
       ing 5 fields:

			   +--+------+----+----+----+----+
			   |: |	aaaa | cc | as | dd | ss |
       The field are defined-as-follows:--+----+----+----+

       :       Every record starts with	this identifier.

       aaaa    The address field.  A four digit	(2 byte)  number  representing
	       the first address to be used by this record.

       cc      The  byte-count.	  A two	digit value (1 byte), counting the ac-
	       tual data bytes in the record.

       as      Address checksum.  Covers 2 address bytes and the byte count.

       dd      The actual data of this record.	There can be  1	 to  255  data
	       bytes per record	(see cc)

       ss      Data Checksum.  Covers only all the data	bytes of this record.

   Record Begin
       Every  record  begins  with  a colon ":[rq] character.  Records contain
       only ASCII characters.  No spaces or tabs are allowed in	a record.   In
       fact,  apart from the 1st colon,	no other characters than 0..9 and A..F
       are allowed in a	record.	 Interpretation	of a  record  should  be  case
       less, it	does not matter	if you use a..f	or A..F.

       Unfortunately the colon was chosen for the Signetics file format, simi-
       lar to the Intel	format (see srec_intel(5) for more information).  How-
       ever,  SRecord  is  able	to automatically detect	the dofference between
       the two format, when you	use the	-Guess format specifier.

   Address Field
       This is the address where the first data	byte of	the record  should  be
       stored.	 After storing that data byte, the address is incremented by 1
       to point	to the address for the next data byte of the record.   And  so
       on, until all data bytes	are stored.  The address is represented	by a 4
       digit hex number	(2 bytes), with	the MSD	first.	The order of addresses
       in  the	records	of a file is not important.  The file may also contain
       address gaps, to	skip a portion of unused memory.

   Byte	Count
       The byte	count cc counts	the actual data	bytes in the  current  record.
       Usually records have 32 data bytes, but any number between 1 and	255 is
       possible.

       A value of 0x00 for cc indicates	the end	of the file.  In this case not
       even  the address checksum will follow!	The record (and	file) are ter-
       minated immediately.

       It is not recommended to	send too many data bytes in a record for  that
       may increase the	transmission time in case of errors.  Also avoid send-
       ing only	a few data bytes per record, because the address overhead will
       be too heavy in comparison to the payload.

   Address Checksum
       This  is	 not really a checksum anymore,	it looks more like a CRC.  The
       checksum	can not	only detect errors in the values  of  the  bytes,  but
       also bytes out of order can be detected.

       The checksum is calculated by this algorithm:
	      checksum = 0
	      for i = 1	to 3
		checksum = checkum XOR byte
		ROL checksum
	      next i
       For  the	Address	Checksum we only need 2	Address	bytes and 1 Byte Count
       byte to be added.  That's why we	count to 3 in the loop.	 Every byte is
       XORed with the previous result.	Then the intermediate result is	rolled
       left (carry rolls back into b0).

       This results in a very reliable checksum, and that for only 3 bytes!

       The last	record of the file does	not contain  any  checksums!   So  the
       file ends right after the Byte Count of 0.

   Data	Field
       The  payload  of	the record is formed by	the Data field.	 The number of
       data bytes expected is given by the Byte	Count field.  The last	record
       of the file may not contain a Data field.

   Data	Checksum
       This checksum uses the same algorithm as	used for the Address Checksum.
       This time we calculate the checksum with	only the data  bytes  of  this
       record.
	      checksum = 0
	      for i = 1	to cc
		checksum = checksum XOR	byte
		ROL checksum
	      next i
       Note that we count to the Byte Count cc this time.

   Size	Multiplier
       In general, binary data will expand in sized by approximately 2.4 times
       when represented	with this format.

EXAMPLE
       Here is an example Signetics file
	      :B00010A5576F77212044696420796F75207265617B
	      :B01010E56C6C7920676F207468726F756768206136
	      :B02010256C6C20746861742074726F75626C652068
	      :B0300D5F746F207265616420746869733FD1
	      :B03D00
       In the example above you	can see	a piece	of code	in  Signetics  format.
       The  first 3 lines have 16 bytes	of data	each, which can	be seen	by the
       byte count.  The	4th line has only 13 bytes, because the	program	is  at
       it's end	there.

       Notice that the last record of the file contains	no data	bytes, and not
       even an Address Checksum.

SEE ALSO
       http://sbprojects.fol.nl/knowledge/fileformats/signetics.htm

AUTHOR
       This man	page was taken from the	above Web page.	 It was	written	by San
       Bergmans	<sanmail@bigfoot.com>

Reference Manual		    SRecord		     srec_signetics(5)

NAME | DESCRIPTION | EXAMPLE | SEE ALSO | AUTHOR

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=srec_signetics&sektion=5&manpath=FreeBSD+12.1-RELEASE+and+Ports>

home | help