Path: news.uiowa.edu!news.physics.uiowa.edu!math.ohio-state.edu!howland.reston.ans.net!newsfeed.internetmci.com!usenet.eel.ufl.edu!news.uoregon.edu!cie-2.uoregon.edu!nparker From: nparker@cie-2.uoregon.edu (Neil Parker) Newsgroups: comp.sys.apple2 Subject: Re: Binscii on PC? Date: 28 Feb 1996 10:22:51 GMT Organization: University of Oregon Campus Information Exchange Lines: 152 Message-ID: <4h1adr$2r2@pith.uoregon.edu> References: <4glmdp$i@nnrp1.news.primenet.com> <4gsv1h$ne7@maverick.tad.eds.com> <4h02dc$n88@cello.gina.calstate.edu> NNTP-Posting-Host: cie-2.uoregon.edu In article <4h02dc$n88@cello.gina.calstate.edu> jpowell@cello.gina.calstate.edu (Larry Powell) writes: >[...] > As alternative to getting some of the software >(descii and bsc) already mentioned, >would it be possible for someone to post (or email) binscii's >specifications. In particular, info on the encoding system, >file spec(s), and file segment (address range) information would >be appreciated. (I figure it probably would not be too difficult >to write a simple decoding utility-I hope.) My "bsc" program (a BinSCII encoder for UNIX) includes a UNIX man page that describes the BinSCII file format. You can find bsc on the Apple II FTP sites...for example, apple2.caltech.edu:/pub/apple2/source/bsc.aaf. For those without access UNIX or nroff, a human-readable version of the manual is attached below. - Neil Parker Neil Parker | No cute quote, no cute ASCII art, no cute nparker@cie-2.uoregon.edu | disclaimer, no deposit, no return.... nparker@cie.uoregon.edu | (This space intentionally left blank: http://cie-2.uoregon.edu/~nparker | ) ----------(beginning of attached file)---------- BINSCII(5) FILE FORMATS BINSCII(5) NAME bsc - format of a BinSCII file CAVEAT The information below is based almost entirely on my own analysis of Marcel J. E. Mol's sciibin source code. I can make no guarantees about its accuracy. Use at your own risk. DESCRIPTION Files encoded in the BinSCII format are broken into 12K (12288-byte) segments, and each segment is encoded separately. All segments except the last are 12K long; the final segment may be shorter than 12K if the length of the original file was not an exact multiple of 12K. Each segment of a BinSCII-encoded file contains 3 parts: the header, the body, and the checksum. The header consists of three lines. The first line is a "sentinal" line used to locate the start of the segment. It consists of the following text: FiLeStArTfIlEsTaRt The second line is the alphabet used in the encoding. In all current incarnations of BinSCII, it looks like this: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789() The third line contains the file name and characteristics, and information that tells the decoder which piece of the file this segment represents. The first 16 characters are the ProDOS filename - the first character indicates the length of the filename (A=1, B=2, C=3, etc.), and the remaining 15 characters are the actual filename, padded on the right with blanks. The final 36 chracters of the third line are an encoded representation of the following data structure: struct binscii_header { byte filesize[3]; /* Total size of original file */ byte segstart[3]; /* Offset into original file of start of this seg */ byte acmode; /* ProDOS file access mode */ byte filetype; /* ProDOS file type */ byte auxtype[2]; /* ProDOS auxiliary file type */ byte storetype; /* ProDOS file storage type */ byte blksize[2]; /* Number of 512-byte blocks in original file */ byte credate[2]; /* File creation date, in ProDOS 8 format */ byte cretime[2]; /* File creation time, in ProDOS 8 format */ byte moddate[2]; /* File modification date */ byte modtime[2]; /* File modification time */ Sun Release 4.1 Last change: June 7, 1994 1 BINSCII(5) FILE FORMATS BINSCII(5) byte seglen[3]; /* Length in bytes of this segment */ byte crc[2]; /* CRC checksum of preceding fields */ byte filler; /* Unused filler byte */ }; All multibyte fields of this structure are stored in Apple II byte order (low-order byte first). This structure is encoded in the same manner as the data lines, as described below. Immediately following the header lines come the data lines. Each data line is exactly 64 characters long, representing 48 bytes of the original file (if the file length is not an exact multiple of 48 bytes, the last line is padded with enough binary zeroes to fill out the line). Immediately following the last data line of the segment comes the checksum. The checksum is a 2-byte CRC of the data in the current segment. It is encoded by attaching a binary zero to the end to increase the length of the field to three bytes, which are then encoded in the same fashion as the data lines. The encoding scheme used by BinSCII takes data three bytes at a time, and converts them to four 6-bit bytes, each of which is translated into an ASCII character. If the bits of the three input bytes are as follows, abcdefgh ijklmnop qrstuvwx, then the four output bytes will be as follows: 00stuvwx 00mnopqr 00ghijkl 00abcdef. Each of these bytes is translated into an ASCII character by indexing into the encoding alphabet (from the second line of the header of the BinSCII segment). An example: Suppose the file being encoded includes the three bytes $D5, $AA, $96, or (written in binary), 11010101 10101010 10010110. We transform these three bytes into four as follows: 00010110 00101010 00011010 00110101, or (in decimal) 22, 42, 26, 53. We then look up the 22nd, 42nd, 26th, and 53rd characters in the encoding alphabet, and write them to the output file: Wqa1. Sun Release 4.1 Last change: June 7, 1994 2 BINSCII(5) FILE FORMATS BINSCII(5) (The first character of the encoding alphabet is character number zero, not character number one.) The CRC checksums in BinSCII are calculated using the CRC polynomial X^16 + X^12 + X^5 + 1. SEE ALSO bsc(1), uuencode(1), uuencode(5) Sun Release 4.1 Last change: June 7, 1994 3