BSC is a program which creates BinSCII files on VMS systems. COMPILING & INSTALLING ---------------------- After unpacking the BSC source files, type "@VMSMAKE". Then sit back and wait for the compile to finish. When BSC is finished compiling, move the file BSC.EXE to the location where you finally want it to run from. (This can be done with the RENAME command.) Finally, execute a command of the following form: BSC :== $device:[directory]BSC where "device:[directory]" is the location where you stored BSC.EXE. (The above command should be put into your LOGIN.COM if you want to have access to BSC whenever you log on.) NOTE: I tested BSC on VMS 5.2. I have no idea whether it will work on earlier versions of VMS. EXECUTING --------- To run BSC, use: BSC [] The following options are available: -t type Sets the ProDOS filetype stored in the BinSCII header to "type". The type may be specified in any of several ways: Type Meaning ---- ----------- LLL 3-letter abbreviation dd decimal 0xdd hexadecimal $dd hexadecimal 0dd octal The 3-letter abbreviations recognized are the standard ones described in "About File Type Notes" from Apple Computer, Inc. For the complete list of abbreviations recognized by the current version of BSC, see the file PFTYPES.H. If no "-t" option is present, the filetype will default to 6 (BIN). -a auxtype Sets the stored ProDOS auxiliary filetype to "auxtype". The auxiliary type may specified in any of the following forms: Syntax Base ------ ----------- dd decimal $dd hexadecimal 0xdd hexadecimal 0dd octal If no "-a" options is present, the auxiliary filetype will default to 0. -m mode Sets the stored ProDOS access mode to "mode" The mode may be one or more of the following: Mode Meaning ---- --------- d destroy n rename b backup-needed i invisible w write r read If no "-m" option is present, the access mode defaults to "dnwr", which corresponds to an "unlocked" ProDOS file. To create a "locked" file, use "-m r". -n name Sets the ProDOS filename stored in the BinSCII header. If the "-n" option is omitted, the ProDOS filename will be the same as the VMS filename. -s num Sets the number of BinSCII segments per output file to "num". As above, the number may be specified in decimal, hex, or octal. If no "-s" option is present, or if "num" is 0, then all BinSCII segments will be written to a single output file. To cause each segment to go into its own output file (like the Apple II BINSCII program), use "-s 1". See below for an explanation of output files. -b Normally, BSC treats its input file as an ASCII file. If the "-b" flag is specified, the input file will be treated as binary instead. This flag is essential for getting a sensible conversion of a non-ASCII file. See below for more information on VMS files and the "-b" option. -h Print a short summary of bsc's options on the standard output. These options, if present, may appear in any order, provided that they appear before the filename. Spaces may appear between an option letter and its value, but are not necessary. The filename is the name of the VMS file to be BinSCII'd. The stored ProDOS filename will be taken from the VMS name, or from the -n option if one was supplied, with lowercase letters converted to uppercase. Additionally, characters that are not valid in ProDOS filenames will be translated into periods (unless the invalid character is the first character in the name, in which case it gets translated into an "X"). The ProDOS name will be truncated to 15 characters if necessary. The stored ProDOS creation and modification times will be taken from the VMS input file. The output of bsc is a set of one or more files, each containing one or more BinSCII segments. By default, all BinSCII segments are written to a single output file, which has the same name as the input file with a "-0" appended to the end. If the "-s" option is given on the command line with a value greater than zero, then the number of segments per output file will be limited to the specified value, and if more than one output file is needed, the second file will have "-1" appended to the name, the third will have "-2" appended, and so forth. For example, if "FOO.DAT" is a large VMS file, the command "bsc -s3 foo.dat" will create files "FOO.DAT-0", "FOO.DAT-1", "FOO.DAT-2", etc., each containing 3 BinSCII segments. Unfortunately, certain features of the VMS file system seem to be specifically designed to make life as difficult as possible for programs like BSC. Files on VMS may be sequential, relative, or indexed, and of the three, only sequential files can be handled by BSC in a sensible manner. Additionally, all files are divided into records, which may be any one of several types, and may have any one of several carriage-return-handling conventions. The VAX C I/O functions do their best to make sense of this chaos by making everything look like a UNIX (i.e. structureless) file. This works great for text files, but it turns non-ASCII files into garbage (since there's no completely reliable way to tell whether a given newline character was really part of the file or was inserted by VAX C to mark the end of a record). The (partial) solution to this problem is BSC's "-b" flag. This causes BSC to open the file in binary mode, which turns off the special end-of-record character insertion. Alas, this isn't the end of the story. If the records of a binary file are of any type other than FIXED, then the file-length counter includes record-separator information that isn't part of the actual data (and therefore isn't seen by BSC, which then thinks the file is longer than it actually is). And if the records ARE of type FIXED, then the last record will be padded with enough extra bytes to raise the file length to a multiple of of the record length. Either way, the result may be a file with extra garbage at the end. * If you have an ASCII file, omit the -b option. * If you have a non-ASCII file, use the -b option, and pray that the application that finally has to deal with the file isn't bothered by extra garbage at the end. * For some weird cases, you may need to use CONVERT/FDL first. Mercifully, Shrinkit seems to be able to handle extra garbage at the end of an archive without problems. BSC will refuse to BinSCII a file larger than 16777216 bytes (16 meg), since that is the maximum size of a ProDOS file. An example: Suppose a VMS file called "PIC.DAT" contains a standard Apple IIGS super-hires screen image. The command bsc -b -tpic pic.dat will create the file "PIC.DAT-0" in a format suitable for downloading to an Apple II and un-BinSCIIing, or for posting to comp.binaries.apple2. When un-BinSCII'd on an Apple II, it will automatically be converted to a PIC ($C1) file. INFORMATION ----------- This program is freeware. It comes with no warranty of any kind--in particular, I cannot guarantee that it is free of bugs. Use it at your own risk. When the inevitable bugs DO appear, send e-mail to one of the addresses below. I welcome bug reports, comments, complaints, and suggestions for improvement. Thanks to Marcel J. E. Mol, whose sciibin program was a valuable source of technical information on BinSCII. - Neil Parker parker@corona.uoregon.edu nparker@cie.uoregon.edu parkern@jacobs.cs.orst.edu Version 1.1