Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!husc6!bloom-beacon!athena.mit.edu!dcw From: dcw@athena.mit.edu (David C. Whitney) Newsgroups: comp.sys.apple Subject: Re: binscii file format Message-ID: <9469@bloom-beacon.MIT.EDU> Date: 26 Feb 89 18:39:02 GMT References: <464@duteca2.UUCP> <9455@bloom-beacon.MIT.EDU> <9722@smoke.BRL.MIL> Sender: daemon@bloom-beacon.MIT.EDU Reply-To: dcw@athena.mit.edu (David C. Whitney) Organization: Massachusetts Institute of Technology Lines: 98 In article <9722@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) 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 > >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 > >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 > >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."