[comp.sys.apple] binscii file format

marcel@duteca (Marcel Mol) (02/24/89)

Is there someone who can describe the format and/or layout of
binscii files.
I have no trouble sending binary files from my unix system to my apple,
and Therefore want to write a program to rebuild the binary file on unix.
(I someone has such a program in C, please mail it to me or post it to the net.)

I also wrote an unpack program for blu files, so I can extract and print
doc files without kermitting the blu file to the apple first.
(to do this I also needed an unsqueeze utility, which I also wrote.)
If there is interest in these programs just drop a note.

- Marcel
-- 
#########################################
# Marcel J.E. Mol                       # They hate you if your're clever
# Delft, University of Technology       # And they despise the fool
# The Netherlands                       # Till you're so fucking crazy
# UUCP: marcel@duteca.UUCP              # You can't follow the rules.
#       duteca!marcel                  	#
#########################################			 - Lennon

dcw@athena.mit.edu (David C. Whitney) (02/26/89)

In article <464@duteca2.UUCP> marcel@duteca.UUCP (Marcel J.E. Mol) writes:
>
>Is there someone who can describe the format and/or layout of
>binscii files.
>I have no trouble sending binary files from my unix system to my apple,
>and Therefore want to write a program to rebuild the binary file on unix.
>(I someone has such a program in C, please mail it to me or post it to the net.)

I don't recommend doing this as file information (such as type, size, create
date, etc) will be forever lost. In some cases it won't matter, but most of the
time it would be a bad thing.

At any rate, here's what a BinSCII file looks like:

A text file which BinSCII will decode has one or more segments in it.

A segment is identified by it's start marker: FiLeStArTfIlEsTaRt <NL>
immediately following is the translation alphabet (for those cases when
some mailer accidentally changes all open parens to single quotes..) <NL>
Then on one line:
	filename preceded by the filename length - eg SAMPLE is written
		FSAMPLE followed by blanks to fill out 15 chars
	then CRC checked:
		File size (eof marker)
		Start byte in output file of this segment
		File info (date, #blocks, type, etc)
		# of bytes in this segment (size<=12K)
		CRC <NL>

Then one or more lines follow which are then encoding of the file. Each
line is 64 chars long followed by <NL>
the last line is the CRC check of the file.

Bytes are coded 3 at a time into 4 characters (6-bit encoding).

Any questions?

Dave Whitney	A junior in Computer Science at MIT
dcw@athena.mit.edu  ...!bloom-beacon!athena.mit.edu!dcw  dcw@goldilocks.mit.edu
I wrote Z-Link. Send me bug reports.           I use a //GS. Send me Tech Info.
"This is MIT. Collect and 3rd party calls will not be accepted at this number."

gwyn@smoke.BRL.MIL (Doug Gwyn ) (02/26/89)

In article <9455@bloom-beacon.MIT.EDU> dcw@athena.mit.edu (David C. Whitney) writes:
>Any questions?

YES!

>immediately following is the translation alphabet <NL>

What is this alphabet, normally?  (I could look in some posted file
but then I'd have to wonder whether some mailer has already messed
it up.)

>	FSAMPLE followed by blanks to fill out 15 chars

Why isn't this 	6SAMPLE  (with no padding) instead?  It seems that
you're requiring the filename to contain spaces, which ProDOS does
not allow (but DOS 3.3 did, and perhaps some GS/OS file systems
might).

>	then CRC checked:

Why isn't the filename included in the CRC?

>		File info (date, #blocks, type, etc)

What format?  Also, are the sizes etc. in ASCII decimal or are they
binary (little-endian? how many bytes?)

>		CRC <NL>

How is this CRC computed?

>Each line is 64 chars long followed by <NL>

What if the file size is not an integral multipel of 64 bytes?

>the last line is the CRC check of the file.

How is this CRC computed?

>Bytes are coded 3 at a time into 4 characters (6-bit encoding).

What is the specific encoding scheme?

Also, how do you handle the resource fork, different file system
types, etc.?

I'd appreciate enough information so that I can write a program
to turn these files back into reasonable ones on my UNIX system
before transfer to my Apple.  I don't want to have to do this on
my Apple, and I don't want the added file transfer time that the
encoding forces.

dcw@athena.mit.edu (David C. Whitney) (02/27/89)

In article <9722@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>In article <9455@bloom-beacon.MIT.EDU> dcw@athena.mit.edu (David C. Whitney) writes:
>>Any questions?
>
>YES!
>
>>immediately following is the translation alphabet <NL>
>
>What is this alphabet, normally?

It is the alphabet in UPPERCASE followed by the alphabet in lowercase, then
10 digits and open and close paren - 64 chars total.

>
>>	FSAMPLE followed by blanks to fill out 15 chars
>
>Why isn't this 6SAMPLE (with no padding) instead?

I don't use a digit because then my code to deal with filenames longer
than 9 chars would get complex (space is of the essence). I just take
the length and add 'A' to it. I pad with spaces just so I have regular
code. I know exactly how many bytes to read from the file to get all
the file info.

>
>>	then CRC checked:
>
>Why isn't the filename included in the CRC?

I decided to leave the filename flexible. The user can have the file unpack
to any name he likes and BinSCII won't crap out because the CRC is bad.

>
>>		File info (date, #blocks, type, etc)
>
>What format?  Also, are the sizes etc. in ASCII decimal or are they
>binary (little-endian? how many bytes?)

This field is in the same format as the ProDOS call to get the info. I just
code the table up after doing the MLI call.

>
>>		CRC <NL>
>
>How is this CRC computed?

I forget the polynomial used, but it is the same algorithm used in
XMODEM/CRC calculation (in fact, I took the CRC code from Z-Link for
this). It is originally seeded with 0.

>>Each line is 64 chars long followed by <NL>
>
>What if the file size is not an integral multipel of 64 bytes?

It gets padded by 0's out to the next 64 chars - although the restored file
is exactly the same as the original file (no extra bytes added).

>>the last line is the CRC check of the file.
>
>How is this CRC computed?

Same as above - seeded with 0.

>>Bytes are coded 3 at a time into 4 characters (6-bit encoding).

>What is the specific encoding scheme?

the bits are rotated to the left 6 at a time. The six-bit number from
each set of shifts is used as an index into the xlation alphabet.
restoration goes the other way.

>Also, how do you handle the resource fork, different file system
>types, etc.?  

ProDOS 8 doesn't and won't be able to deal with future filesystem
options.  GS/OS will (we'll see what Apple comes up with), but P8 is
locked into the one there is. BinSCII was designed to be used under
P8, and I therefore didn't deal with those options (I know, not very
smart, but I hacked this out in 1 week because it needed to be done.)

>I'd appreciate enough information so that I can write a program 
>to turn these files back into reasonable ones on my UNIX system 
>before transfer to my Apple.  I don't want to have to do this on 
>my Apple, and I don't want the added file transfer time that the 
>encoding forces.

As I said earlier, I don't recommend it as file info will get lost (unless
you plan on dumping the file into a BNY file or something). Also, xfer time
is only about 30% greater. Also, if you wait a bit, Jason Blochowiak is writing
a version in C and 65816 assembly to run from thw APW shell. It will be pretty
easy to port it to UNIX I'm sure. Talk to him and see what he says.



Dave Whitney	A junior in Computer Science at MIT
dcw@athena.mit.edu  ...!bloom-beacon!athena.mit.edu!dcw  dcw@goldilocks.mit.edu
I wrote Z-Link. Send me bug reports.           I use a //GS. Send me Tech Info.
"This is MIT. Collect and 3rd party calls will not be accepted at this number."

asd@mentor.cc.purdue.edu (Kareth) (03/01/89)

In article <464@duteca2.UUCP> marcel@duteca.UUCP (Marcel J.E. Mol) writes:
>I also wrote an unpack program for blu files, so I can extract and print
>doc files without kermitting the blu file to the apple first.
>(to do this I also needed an unsqueeze utility, which I also wrote.)
>If there is interest in these programs just drop a note.

YES, YES there's interest!  I have Mousetalk which allows me to download
to any file type.  I would very much like to have a program that could un-blu
programs so I didn't have to perform a three step dl. (dl, exec, unblu)

Questions:
- Does your program extract from an exec file? or just blu files?
- Can it handle files that have been split?

If if can do this stuff, I WANT IT!!!  You wouldn't believe how much stuff
I got stored on UNIX.  Bout as much, if not more than Apple2-L.

I wudda mailed this but our mailer kept barfing at me.  Wasn't a pretty site.

kareth.