Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!bloom-beacon!oberon!cit-vax!ucla-cs!zen!ucbvax!WALKER-EMH.ARPA!InfoMail-Mailer From: InfoMail-Mailer@WALKER-EMH.ARPA.UUCP Newsgroups: comp.sys.atari.8bit Subject: Undeliverable Mail Message-ID: <8710010425.AA05243@ucbvax.Berkeley.EDU> Date: Thu, 1-Oct-87 00:03:00 EDT Article-I.D.: ucbvax.8710010425.AA05243 Posted: Thu Oct 1 00:03:00 1987 Date-Received: Sat, 3-Oct-87 02:17:21 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 526 Mail was not delivered to the following users because there were bad address(es) in TO and/or CC field(s): info-atari UNDELIVERED-MESSAGE: ---------------------------------------------------------------- Received: from BBN.COM by WALKER-EMH.ARPA ; 1 Oct 87 03:52:47 GMT Received-2: from score.stanford.edu by BBN.COM id aa24043; 30 Sep 87 17:32 EDT Date: Wed 30 Sep 87 10:21:38 PDT Subject: Info-Atari8 Digest V87 #86 From: Info-Atari8 @ SCORE.STANFORD.EDU Errors-to: Info-Atari8-request@Score.Stanford.EDU Maint-Path: Info-Atari8-request@Score.Stanford.EDU To: Info-Atari8 Distribution List: Reply-to: Info-Atari8@SCORE.STANFORD.EDU Text: Info-Atari8 Digest Wednesday, September 30, 1987 Volume 87 : Issue 86 This weeks Editor: Bill Westfield Today's Topics: Welcome message information new welcome message Re: ARC file format? ---------------------------------------------------------------------- Mail-From: G.ABRAMS created at 29-Sep-87 18:59:04 Date: Tue 29 Sep 87 18:59:04-PDT From: Info-Atari Moderator Subject: Welcome message information To: info-atari8@Score.Stanford.EDU, info-atari16@Score.Stanford.EDU From time to time I am reminded by a message asking the operation of the lists that it is necessary to periodically send out the welcome message. It contains valuable information about the location of information. I would appreciate receiving updates to this information (sent to abrams@mitre.arpa) and offers to help fix whatever is broken. At present I have some doubts about certain items; I hope I am wrong. Marshall Abrams 1. Welcome _ _______ Welcome to info-atari. 2. Sending Messages _ _______ ________ You may send messages to all "subscribers" by address- ing it to info-atari8@score.stanford.edu and/or info-atari16@score.stanford.edu Administrative messages should be sent to info-atari{8,16}-request. Please do NOT send general messages to this address. Your moderators get enough mail as it is! 3. Ground Rules _ ______ _____ All messages should be in good taste. Commercial mes- sages and advertisements are not permitted. When answering a question, please consider carefully whether the answer should go to the whole list, or just to the person who asked the question. The following ground rules should make the use of this (or of any other) mailing list much easier: * never send a message that a totally irrelevant to the mailing list's purpose to a mailing list. This especially includes any expressions of irritation at another list member. * never forward a message that is totally irrelevant to the mailing list's purpose to a mailing list. * when replying to a message on a mailing list, reply only to the sender of the message unless the reply is of interest to the entire mailing list. * avoid inserting the message being replied to in a reply, especially in a message going to a mailing list. The context of the reply should be clear from *your* reply and from various mailer functionalities such as Message-ID. * when replying to an earlier reply that violates the previous rule, ABSOLUTELY DO NOT make matters worse by adding your own violation. 4. LISTSERV _ ________ LISTSERV provides a number of features which you can access by sending mail (note) to LISTSERV. Only the barest minimum are described herein. On Bitnet messages should be sent to your nearest LISTSERV (the one from which you receive the info-atari digests). (If your address is not on Bitnet, an address for file servers is given below.) All mail sent to LISTSERV contains command lines. LISTSERV will respond by return mail. No subject is necessary in such mail. For more information send the command INFO 4.1. List Names _ _ ____ _____ The list_name for 16-bit Ataris is INFO-A16. The list_name for 8-bit Ataris is INFO-A8. These list names are used by Bitnet addressees for subscribing and unsubscribing and by everyone for obtaining back copies of news digests. The list_names for programs stored in the archives are PROG-A16 and PROG-A8. 4.2. (Un)Subscribing _ _ __ ___________ If you are on Bitnet you may add or remove yourself from the distribution list. It would greatly convenience the moderators if you would do so when you no longer wish to receive digests. The command to join the list is SUBSCRIBE list_name User_name The command to remove yourself from the list is UNSUBSCRIBE list_name Note that the list was established with all user_names unknown. To enter your name, send a SUBSCRIBE command. It would be most convenient if users took care of their own subscribing and unsubscribing, but messages to INFO- ATARI-REQUEST{8,16}@SCORE.STANFORD.EDU will still be accepted. 4.3. File Server (Archives) _ _ ____ ______ ________ The following service is being installed beginning February 1987; we will announce when everything is in place and "known" to be working. All messages are in the archives. In addition, some contributed programs are also there. You can obtain copies of files from LISTSERV by sending a message in the specified format. If you are on ARPAnet (or gatewayed to it), your mail should be addressed to LISTSERV%CANADA01.BITNET@WISCVM.WISC.EDU To obtain a list of files in the file server, the com- mand is INDEX list_name The command to obtain a specific file is GET list_name file_name for example, GET INFO-A16 87-00076 If you want to learn more, send the message HELP ------------------------------ Date: Sun, 9 Aug 87 17:00:37 EDT From: abrams%community-chest.mitre.org@gateway.mitre.org To: g.abrams@score.stanford.edu Subject: new welcome message 1. Welcome _ _______ Welcome to info-atari. 2. Sending Messages _ _______ ________ You may send messages to all "subscribers" by address- ing it to info-atari8@score.stanford.edu and/or info-atari16@score.stanford.edu Administrative messages should be sent to info-atari{8,16}-request. Please do NOT send general messages to this address. Your moderators get enough mail as it is! 3. Ground Rules _ ______ _____ All messages should be in good taste. Commercial mes- sages and advertisements are not permitted. When answering a question, please consider carefully whether the answer should go to the whole list, or just to the person who asked the question. The following ground rules should make the use of this (or of any other) mailing list much easier: * never send a message that a totally irrelevant to the mailing list's purpose to a mailing list. This especially includes any expressions of irritation at another list member. * never forward a message that is totally irrelevant to the mailing list's purpose to a mailing list. * when replying to a message on a mailing list, reply only to the sender of the message unless the reply is of interest to the entire mailing list. * avoid inserting the message being replied to in a reply, especially in a message going to a mailing list. The context of the reply should be clear from *your* reply and from various mailer functionalities such as Message-ID. * when replying to an earlier reply that violates the previous rule, ABSOLUTELY DO NOT make matters worse by adding your own violation. 4. Archives _ ________ Archives are kept in several places in formats avail- able to everyone. As described below, if you are on ARPANET/DDN you will probably find it more convenient to retrieve files from the archive on radc-softvax.arpa using FTP. If you are not on ARPANET/DDN, or are unable to use FTP, you will be able to retrieve files from archives dis- tributed over several Bitnet hosts by sending mail (notes) to a program called LISTSERV. 4.1. Archives on radc-softvax.arpa _ _ ________ __ ____ _______ ____ Files from radc-softvax.arpa are available by FTP. FTP will work only for hosts directly connected to ARPANET/DDN. Please obtain local documentation and advice for the FTP user programming running on your host. There are two direc- tories under the anonymous account. One for atari8 and one for atari16. FTP to radc-softvax using login:guest and password:guest. To get the current list of available atari16 files do a 'get atari16/files.doc'. All of the atari16 files are stored in the atari16 subdirectory. If you need any other information, contact Marc Poulin. The archive is maintained by Rodney Peck (Peck@radc- multics.arpa) and Marc Poulin (Poulin@radc-multics.arpa or Archives@radc-softvax.arpa). 4.2. LISTSERV _ _ ________ LISTSERV provides access to files for everyone who can send mail, independent of their location. Note, however, that intermediate notes have been known to refuse to handle long messages or have damaged them in transit. LISTSERV provides a number of features which you can access by send- ing mail (note) to LISTSERV. Only the barest minimum are described herein. On Bitnet messages should be sent to your nearest LISTSERV (the one from which you receive the info- atari digests). (If your address is not on Bitnet, an address for file servers is given below.) All mail sent to LISTSERV contains command lines. LISTSERV will respond by return mail. No subject is necessary in such mail. For more information send the command INFO 4.2.1. List Names _ _ _ ____ _____ The list_name for 16-bit Ataris is INFO-A16. The list_name for 8-bit Ataris is INFO-A8. These list names are used by Bitnet addressees for subscribing and unsubscribing and by everyone for obtaining back copies of news digests. The list_names for programs stored in the archives are PROG-A16 and PROG-A8. 4.2.2. (Un)Subscribing _ _ _ __ ___________ If you are on Bitnet you may add or remove yourself from the distribution list. It would greatly convenience the moderators if you would do so when you no longer wish to receive digests. The command to join the list is SUBSCRIBE list_name User_name The command to remove yourself from the list is UNSUBSCRIBE list_name It would be most convenient if users took care of their own subscribing and unsubscribing, but messages to INFO- ATARI-REQUEST{8,16}@SCORE.STANFORD.EDU will still be accepted. 4.2.3. Accessing Program & Digest Archives _ _ _ _________ _______ ______ ________ All digests are in the archives. There is a separate program library. You can obtain copies of files from LIST- SERV by sending a message in the specified format. If you are on ARPAnet (or gatewayed to it), your mail concernin 16-bit Atari information should be addressed to LISTSERV%CANADA01.BITNET@WISCVM.WISC.EDU Mail concernin 8-bit Atari information should be addressed to LISTSERV%TCSVM.BITNET@WISCVM.WISC.EDU To obtain a list of files in the file server, the com- mand is INDEX list_name The command to obtain a specific file is GET list_name file_name for example, GET INFO-A16 87-00076 If you want to learn more, send the message HELP 4.2.4. LISTSERV Moderators _ _ _ ________ __________ The person to contact if you are having problems (un)subscribing is Harry Williams (harry@marist.bitnet). The moderator of the 16-bit digest archives is Peter Jasper-Fayer (sofpjf@uoguelph.bitnet). The moderator of the 16-bit program archives is Richard Werezak (carson@mcmaster.bitnet). The moderator of the 8-bit archives is John Voigt (sysbjav@tcsvm.bitnet). The modera- tor of the 8-bit program archives is Arnold de Leon (adeleon@hmcvax.bitnet). 4.2.5. Information Concerning 16-bit Archive Organization _ _ _ ___________ __________ __ ___ _______ ____________ The digests are numbered sequentially as they come in. Sometimes the files arrive here out of order, or with miss- ing ones, or with extra ones or with mail from BITNET users requesting information. Often the moderator has to logon to LISTSERV and re-name the files according to the "Subject:" line within it. Those "Subject:" lines are what end up in the indexes (in both "-A16" lists) The program files are largely extracts from the digests (INFO-A16). As far as possible, they are numbered the same as the digests they came from. Other programs were inserted somewhere in the list. The numbers of these "inserted" files were selected so that they would appear in the index at about the correct CHRONOLOGICAL sequence. If no programs were included in the digests, and nocontributions were received, then those spaces in the index numbers were left blank. ------------------------------ Date: 29 Sep 87 21:11:30 GMT From: super.upenn.edu!eecae!nancy!umix!hyc@rutgers.edu (Howard Chu) Subject: Re: ARC file format? To: info-atari8@score.stanford.edu A long time ago I said I'd port ARC in Action!, but I never finished, and my 800XL has since bit the dust. However, I have full docs and source code in C if you want them. I'm currently porting ARC 5.20 to my ST. A description of the ARC header follows.... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ARC-FILE.INF, created by Keith Petersen, W8SDZ, 21-Sep-86, extracted from UNARC.INF by Robert A. Freed. From: Robert A. Freed Subject: Technical Information for ARC files Date: June 24, 1986 Note: In the following discussion, UNARC refers to my CP/M-80 program for extracting files from MSDOS ARCs. The definitions of the ARC file format are based on MSDOS ARC512.EXE. ARCHIVE FILE FORMAT ------------------- Component files are stored sequentially within an archive. Each entry is preceded by a 29-byte header, which contains the directory information. There is no wasted space between entries. (This is in contrast to the centralized directory used by Novosielski libraries. Although random access to subfiles within an archive can be noticeably slower than with libraries, archives do have the advantage of not requiring pre-allocation of directory space.) Archive entries are normally maintained in sorted name order. The format of the 29-byte archive header is as follows: Byte 1: 1A Hex. This marks the start of an archive header. If this byte is not found when expected, UNARC will scan forward in the file (up to 64K bytes) in an attempt to find it (followed by a valid compression version). If a valid header is found in this manner, a warning message is issued and archive file processing continues. Otherwise, the file is assumed to be an invalid archive and processing is aborted. (This is compatible with MS-DOS ARC version 5.12). Note that a special exception is made at the beginning of an archive file, to accomodate "self-unpacking" archives (see below). Byte 2: Compression version, as follows: 0 = end of file marker (remaining bytes not present) 1 = unpacked (obsolete) 2 = unpacked 3 = packed 4 = squeezed (after packing) 5 = crunched (obsolete) 6 = crunched (after packing) (obsolete) 7 = crunched (after packing, using faster hash algorithm) (obsolete) 8 = crunched (after packing, using dynamic LZW variations) Bytes 3-15: ASCII file name, nul-terminated. (All of the following numeric values are stored low-byte first.) Bytes 16-19: Compressed file size in bytes. Bytes 20-21: File date, in 16-bit MS-DOS format: Bits 15:9 = year - 1980 Bits 8:5 = month of year Bits 4:0 = day of month (All zero means no date.) Bytes 22-23: File time, in 16-bit MS-DOS format: Bits 15:11 = hour (24-hour clock) Bits 10:5 = minute Bits 4:0 = second/2 (not displayed by UNARC) Bytes 24-25: Cyclic redundancy check (CRC) value (see below). Bytes 26-29: Original (uncompressed) file length in bytes. (This field is not present for version 1 entries, byte 2 = 1. I.e., in this case the header is only 25 bytes long. Because version 1 files are uncompressed, the value normally found in this field may be obtained from bytes 16-19.) SELF-UNPACKING ARCHIVES ----------------------- A "self-unpacking" archive is one which can be renamed to a .COM file and executed as a program. An example of such a file is the MS-DOS program ARC512.COM, which is a standard archive file preceded by a three-byte jump instruction. The first entry in this file is a simple "bootstrap" program in uncompressed form, which loads the subfile ARC.EXE (also uncompressed) into memory and passes control to it. In anticipation of a similar scheme for future distribution of UNARC, the program permits up to three bytes to precede the first header in an archive file (with no error message). CRC COMPUTATION --------------- Archive files use a 16-bit cyclic redundancy check (CRC) for error control. The particular CRC polynomial used is x^16 + x^15 + x^2 + 1, which is commonly known as "CRC-16" and is used in many data transmission protocols (e.g. DEC DDCMP and IBM BSC), as well as by most floppy disk controllers. Note that this differs from the CCITT polynomial (x^16 + x^12 + x^5 + 1), which is used by the XMODEM-CRC protocol and the public domain CHEK program (although these do not adhere strictly to the CCITT standard). The MS-DOS ARC program does perform a mathematically sound and accurate CRC calculation. (We mention this because it contrasts with some unfortunately popular public domain programs we have witnessed, which from time immemorial have based their calculation on an obscure magazine article which contained a typographical error!) Additional note (while we are on the subject of CRC's): The validity of using a 16-bit CRC for checking an entire file is somewhat questionable. Many people quote the statistics related to these functions (e.g. "all two-bit errors, all single burst errors of 16 or fewer bits, 99.997% of all single 17-bit burst errors, etc."), without realizing that these claims are valid only if the total number of bits checked is less than 32767 (which is why they are used in small-packet data transmission protocols). I.e., for file sizes in excess of about 4K bytes, a 16-bit CRC is not really as good as what is often claimed. This is not to say that it is bad, but there are more reliable methods available (e.g. the 32-bit AUTODIN-II polynomial). (End of lecture!) Bob Freed 62 Miller Road Newton Centre, MA 02159 Telephone (617) 332-3533 -- -- Howard Chu "Of *course* it's portable. It's written in C, isn't it?" ------------------------------ End of Info-Atari8 Digest ************************** ------- -------------------END OF UNDELIVERED MESSAGE-------------------