💾 Archived View for mirrors.apple2.org.za › archive › ground.icaen.uiowa.edu › Docs › NuFx.Format.tx… captured on 2023-04-26 at 17:21:35.
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
------------------------------------------------------------------------------- | The New Archive Standard for the Apple II -- "NuFX" -- NuFile eXchange | ------------------------------------------------------------------------------- NuFX Documentation - 12/2/88 by Andy Nicholas Final Revision Three - 2/3/89 Please distribute as widely as possible Send questions/comments to: Paper Bag Productions CSNET: nicholaA@moravian.edu c/o Andy Nicholas InterNET: nicholaA%batman.moravian.edu@relay.cs.net Box 435 nicholaA@batman.moravian.edu.csnet Moravian College ProLine: andyn@pro-sol.cts.com [619-670-5379] Bethlehem, PA 18018 AppleLink PE: ShrinkIt NuFX Documentation 2/3/89 - Page 2 - Preface ------- The first copy of this proposal that was circulated was preliminary revision 10. Since then I have had many requests for a more flexible solution to the archival problem. To do so meant the removal of such features as the alignment to 128-byte boundaries of all data blocks and so forth, and the re-definition of the header block so that it is less rigid in its format (extensible). To do this makes it at least a factor more complex for programs which can extract records from NuFX archives on-the-fly (such as telecommunications programs). While this may be seen as a hardship by some, I believe the additional power provided by all formats after revision 10 justifies the additional complexity. Standalone utility programs should have no problems adjusting to the new format. This final revision of the documentation fixes the master_header's size at 48 bytes, eliminates the archive_create_program and archive_mod_program fields, increases the size of the access field to a longword, and introduces a new name for the archive, NFX, or NuFX, for "NuFile eXchange." I am also almost finished an archive program which places files or disks into NuFX archives using dynamic LZW compression, ShrinkIt. Any reference to ShrinkIt in the text is a reference to this program. Final Rev 2 corrects the all the algorithms to include the length of the thread list in their calculations, includes some notes on how to properly include threads and directories, and standardizes on the use of "NuFX" to describe the archive name so as to distinguish it from Sun Microsystems' "NFS" network product. Final Rev 3 changes some of the terminology used, changes the date labels to xx_when instead of xxx_date_time, assigns the resource_fork of a file to be stored as a thread_kind in a data_thread instead of having it's own thread available. An attempt at further clarity has been undertaken. andy (2/3/89) NuFX Documentation 2/3/89 - Page 3 - History ------- The Apple II community has always been sorely lacking a well-defined method for archiving files. NuFX is an attempt to rectify the situation by providing for a flexible, consistent standard for archiving files, disks, and other computer medium. The Binary II standard, authored by Gary B. Little, for placing multiple files within a single file has been rendered obsolete by the (now) recent release of GS/OS(tm) which provides access to multiple filing systems. Since GS/OS can (or will) use HFS files, Binary II does NOT provide for: o filenames larger than 64 characters (GS/OS can create 8000 character filenames) o a convenient way to add to, remove from, and other ways work on an archive. o including HFS-style files which contain resource forks. o including of entire disk images. o including messages along with a file. o a convenient way to represent that a file is compressed or encrypted by a specific application. (an excess secondary header must be attached to the beginning of files, such is the case with SQueezed files) o a true archive standard. Binary II's original intent was to make transfer of Apple II files from local machines to large information services like The Source, Delphi, CompuServe, and GEnie, possible. Otherwise, a file's attribute information would be lost. Binary II is now being stretched beyond what it was originally meant to do. o no support for multiple data threads or structures. Adding all of these features to the existing Binary II standard would not only be nerve-racking, but nearly impossible without violating the existing standard and causing a great deal of confusion (ie, "did you say it was Binary II, first revision or the second one?") Although Binary II is flexible, it is simply unable to address all of these concerns without alienating existing Binary II extraction programs. So, to provide some differentiation between standards and provide a better functioning format, I have defined a new standard called "NuFX" (NuFile eXchange for the Apple II). NuFX fixes the problems that Apple IIgs(tm) users would soon be experiencing as other filing systems become available for GS/OS(tm). I am trying to stop a set of problems before they have a chance to develop. NuFX provides all of the features of Binary II, but doesn't stop there... it goes farther to allow the user the ultimate in flexibility, usefulness and performance. NuFX Documentation 2/3/89 - Page 4 - Implementation -------------- The basic structure of a NuFX archive is as follows: [First record] [Next Record] +---------------------------------------------------------------------------+ | Master Header | Header | Data . . . . . . . . | Header | Data . . . . | +---------------------------------------------------------------------------+ A single master header block contains values which describe the entire archive (those of you who are into structured programming can consider them archive globals). Each of the succeeding header blocks contain only information about the record they precede (consider them archive locals). Each header block may be followed by a series of "threads." Each thread may be a portion of data, a message, the resource part of an extended file, a control sequence for a NuFX utility program, or almost any sort of sequential data. The number of threads is described as a longword (32-bit word), so it is also possible to properly archive and store the data portions of sparse files. NuFX Documentation 2/3/89 - Page 5 - Master header block contents: All word and double-word values are byte-reversed. Offset Length Content ------ ------ --------------------------------------------------------------- +0 1 $4E Master ID Byte #1 +1 1 $F5 Master ID Byte #2 +2 1 $46 Master ID Byte #3 spells the word "NuFile" in +3 1 $E9 Master ID Byte #4 alternating ASCII (high, low) for +4 1 $6C Master ID Byte #5 uniqueness. +5 1 $E5 Master ID Byte #6 +6 2 master_crc 16-bit CRC of the remaining fields in this block. (bytes +8 through +47) Any programs which modify the master header block *MUST* recalculate the CRC for the master header. +8 4 total_records Total number of records in this archive file. It is possible to chain multiple records (Files or Disks) together. It is also possible to chain different types of records together (Files and Disks mixed). NuFX Documentation 2/3/89 - Page 6 - +12 8 archive_create_when The date and time on which this archive was initially created. This field should never be changed once initially written. The format of this field is as follows: +12 second - 0 through 59 +13 minute - 0 through 59 +14 hour - 0 through 23 +15 current Year minus 1900 +16 day - 0 through 30 +17 month - 0 through 11, with 0=January +18 filler byte - reserved must be null (00). +19 weekDay - 1 through 7, with 1=Sunday The format of this field is identical to that described in the _ReadTimeHex ($0D03) call described on page 14-14 of the Apple_IIgs_Toolbox_Reference:_Volume_1. If the date is not known, or is unable to be calculated, this field should be set to null (00). If the weekDay is not known, or is unable to be calculated, this field should be set to null (00). +20 8 archive_mod_when The date of the last modification to this archive. This field should be changed every time a change is made to any of the records in the archive. The format of this field is as follows: +20 second - 0 through 59 +21 minute - 0 through 59 +22 hour - 0 through 23 +23 current Year minus 1900 +24 day - 0 through 30 +25 month - 0 through 11, with 0=January +26 filler byte - reserved, must be null (00). +27 weekDay - 1 through 7, with 1=Sunday The format of this field is identical to that described in the _ReadTimeHex ($0D03) call described on page 14-14 of the Apple_IIgs_Toolbox_Reference:_Volume_1. If the date is not known, or is unable to be calculated, this field should be set to null (00). If the weekDay is not known, or is unable to be calculated, this field should be set to null (00). NuFX Documentation 2/3/89 - Page 7 - +28 . . *** RESERVED, MUST BE SET TO NULL (00) *** . Do NOT use any of these fields. . +47 NuFX Documentation 2/3/89 - Page 8 - The following header block must precede each record within the NuFX archive. The cyclic redundancy check (CRC) has been provided to detect archives which have possibly been corrupted. The only time the CRC should be included in in a block is for the master header and for each of the regular header blocks. The CRC functions to ensure reliability and record integrity. Header Block contents: All word and double-word values are byte-reversed. Offset Length Content ------ ------ --------------------------------------------------------------- +0 1 $4E - Header ID Byte #1 +1 1 $F5 - Header ID Byte #2 Spells "NuFX" in alternating ascii +2 1 $46 - Header ID Byte #3 (high/low) for uniqueness. +3 1 $D8 - Header ID Byte #4 +4 2 header_crc 16-bit CRC of the remaining fields of this block. (bytes 6 through the end of the attributes, filename, and any threads.) This field is used to verify the integrity of the rest of the block. Programs which make NuFX archives *MUST* include this in every header. It is up to the discretion of the extracting program to check the validity of these bytes. Any programs which might modify the header of a particular record *MUST* recalculate the CRC for the header block. +6 2 attrib_count This field describes the length of the attribute section of each header in bytes. This count measures the distance in bytes from the first field (offset +0) to and including the filename_length field. By convention, the filename_length field will always be the last 2 bytes of the attribute section regardless of what has preceded it. NuFX Documentation 2/3/89 - Page 9 - +8 2 version_number Minimum NuFX version number needed for extraction. (Currently $0000) This field is used to detect the possible existence of other as-of-yet undefined fields and features. Utility programs should check this value to be certain that they are capable of extracting a record with this minimum version. +10 4 total_threads The number of thread sub-records which should be expected immediately following the end of the file/path name. This field is extremely important because it contains the information about the length of the last 1/3 of the header. +14 2 file_sys_id Native file system identifier: $0000 reserved $0001 ProDOS/SOS $0002 DOS 3.3 $0003 DOS 3.2 $0004 Apple II Pascal $0005 Macintosh(tm) (HFS) $0006 Macintosh (MFS) $0007 LISA(tm) file system $0008 Apple CP/M $0009 reserved, do not use $000A MS-DOS $000B High-Sierra/ISO 9660 $000C . . reserved . $FFFF Disk: if the file system of a disk is not known, then this field should be set to null (0000). NuFX Documentation 2/3/89 - Page 10 - +16 2 file_sys_info Information about the current filing system: [$00xx] Native file system separator. Under Prodos, the "/" ($2F) character is used to separate paths. Under HFS, the ":" ($3A) character is used to separate paths. Under MS-DOS, the "\" ($5C) character is used to separate paths. The low byte of this word is used to store the file system's separator. The primary reason for including this field is that the receiving file system (say, to Prodos 8 from GS/OS running an HFS File System Translator) must know how to parse a valid file/path name from the filename field for the receiving file system. [$xx00] Sparse byte. If the high-byte of this word is $01, then the image which follows is a sparse file (and the threads should have been filled in properly to indicate this). If a more "normal" image follows, this byte will be null (00). NuFX Documentation 2/3/89 - Page 11 - +18 4 access [0000 0000 0000 0000 DRB00IWR] bits 31-8 reserved, must be zero bit 7 D=0, destroy disabled D=1, destroy enabled bit 6 R=0, rename disabled R=1, rename enabled bit 5 B=0, backup not needed B=1, backup needed bits 4-3 reserved, must be zero bit 2 I=0, file is visible I=1, file is invisible bit 1 W=0, write disabled W=1, write enabled bit 0 R=0, read disabled R=1, read enabled Disk: this field should be set to null (00). +22 4 file_type Disk: this field should be set to null (00). +26 4 extra_type ProDOS aux_type or HFS creator_type Disk: this field *MUST* be set to the total number of blocks on the device. This information must be present so that the extracting program can place the record on the proper type of device. +30 2 storage_type $0 - $3 = standard file $5 = extended (gs/os) file $d = subdirectory Disk: file_sys_block_size This should only be used if a disk is being archived. The block size used by the device should be placed in this field. For example, under Prodos, this field will be 512, while HFS would set it to 524. NuFX Documentation 2/3/89 - Page 12 - +32 8 create_when The date and time on which this record was initially created. If the creation date and time is available from a disk device, this information should be included. The format of this field is as follows: +32 second - 0 through 59 +33 minute - 0 through 59 +34 hour - 0 through 23 +35 current Year minus 1900 +36 day - 0 through 30 +37 month - 0 through 11, with 0=January +38 filler byte - reserved, must be set to null (00). +39 weekDay - 1 through 7, with 1=Sunday The format of this field is identical to that described in the _ReadTimeHex ($0D03) call described on page 14-14 of the Apple_IIgs_Toolbox_Reference:_Volume_1. If the date is not known, or is unable to be calculated, this field should be set to null (00). If the weekDay is not known, or is unable to be calculated, this field should be set to null (00). +40 8 mod_when The date and time on which this record was last modified. If the modification date is available from a disk device, this information should be included. The format of this field is as follows: +40 second - 0 through 59 +41 minute - 0 through 59 +42 hour - 0 through 23 +43 current Year minus 1900 +44 day - 0 through 30 +45 month - 0 through 11, with 0=January +46 filler byte - reserved, must be set to null (00). +47 weekDay - 1 through 7, with 1=Sunday The format of this field is identical to that described in the _ReadTimeHex ($0D03) call described on page 14-14 of the Apple_IIgs_Toolbox_Reference:_Volume_1. If the date is not known, or is unable to be calculated, this field should be set to null (00). If the weekDay is not known, or is unable to be calculated, this field should be set to null (00). NuFX Documentation 2/3/89 - Page 13 - +48 8 archive_when The date and time on which this record was placed in this archive. The format of this field is as follows: +48 second - 0 through 59 +49 minute - 0 through 59 +50 hour - 0 through 23 +51 current Year minus 1900 +52 day - 0 through 30 +53 month - 0 through 11, with 0=January +54 filler byte - reserved, must be set to null (00). +55 weekDay - 1 through 7, with 1=Sunday The format of this field is identical to that described in the _ReadTimeHex ($0D03) call described on page 14-14 of the Apple_IIgs_Toolbox_Reference:_Volume_1. If the date is not known, or is unable to be calculated, this field should be set to null (00). If the weekDay is not known, or is unable to be calculated, this field should be set to null (00). Any other attributes which are needed may be added at the discretion of the NuFX application programmer. The attrib_count field should be modified accordingly. NuFX Documentation 2/3/89 - Page 14 - attrib_count-2 filename_length (xx bytes) Length of filename. Under Prodos, this will not exceed 64 characters. If HFS or another filing system is used, this field may exceed 64 characters. This is the last field considered included in the attributes section. To allow the inclusion of future additional parameters in the attributes section, NuFX utility programs should rely on the attribs_count field to find the filename_length field. ------------------------- End of attributes section xx Bytes Filename or partial pathname if applicable. If this is a disk which is being archived, then the volume_name should be included in this field. If a volume name is included in this field, a separator ("/" or ":") should *NOT* be included in, or precede the name. If a volume name is not available, then this field should be set to nulls. (00's) If a partial pathname is specified, the directories to which the current pathname refers need not have preceded this particular record. The extraction program must test each referenced directory individually. If the directory in question does not exist, the extracting program should create it. Any utility which extracts files from a NuFX archive *MUST NOT* assume that this field will be in a format it is able to handle. In particular, extraction programs should check for mixed case text in a file/path name and do whatever conversions are necessary to parse a legal file/path name. In general, assume nothing. ----------------------- End of filename section NuFX Documentation 2/3/89 - Page 15 - Threads ------- Thread records are 16 byte records which immediately follow the filename and describe the types of data structures which are included with a given record. The number of thread records is described in the attribute section by a longword, total_threads. Each thread record should be checked for the type of information that a given utility program can extract. If a utility is incapable of extracting a particular thread, that thread should be skipped. If a utility finds a redundancy in a thread_record, it must decide whether to skip the record or to do something with that particular thread (ie, if a utility finds 2 message_threads it can either ignore the second thread or display it. Likewise, if a utility finds 2 resource threads, it can either overwrite the first thread which was extracted, or warn the user and skip the errant thread). A thread record can be represented as follows: Offset Length Content ------ ------ --------------------------------------------------------------- +0 2 thread_class +2 2 thread_format +4 2 thread_kind +6 2 reserved +8 4 thread_eof +12 4 comp_thread_eof "thread_class" describes the classification of the thread --------------------------------------------------------- $0000 = message_thread $0001 = control_thread $0002 = data_thread $0003 = sparse_thread NuFX Documentation 2/3/89 - Page 16 - "thread_format" is the format of the data within the thread. ------------------------------------------------------------ $0000 = Uncompressed [Not application specific] $0001 = SQueezed (SQ/USQ) [Not application specific] $0002 = Dynamic LZW [ShrinkIt] $0003 . . RESERVED, contact the author . $FFFF "thread_kind" describes the kind of data which is contained in the thread ------------------------------------------------------------------------- if thread_class $0000 = message_thread thread_kind $0000 = ASCII text $xxxx = all others undefined $0001 = control_thread thread_kind $0000 = create directory $xxxx = all others undefined $0002 = data_thread thread_kind $0000 = data_fork of file thread_kind $0001 = disk image thread_kind $0002 = resource_fork of file $xxxx = all others undefined "thread_eof" is the length of the uncompressed thread ----------------------------------------------------- "comp_thread_eof" is the length of the compressed thread -------------------------------------------------------- Current ideas for messages include static pictures, sounds, sound & pictures, animations, and possibly executable files. I encourage writers of NuFX utility programs to be able to handle messages of the lowest common denominator, ASCII text. NuFX Documentation 2/3/89 - Page 17 - Finding the start of the thread list ------------------------------------ The beginning of the thread records can be found by using the following algorithm: Threads := (mark at beginning of header) + (attrib_count) + (filename_length) Finding the end of the thread list ---------------------------------- The end of the thread records can be found by applying the following algorithm: endOfThreads := (mark at beginning of header) + (attrib_count) + (filename_length) + (16 * total_threads) Finding the start of a data_thread ---------------------------------- The beginning of a data_thread can be found using the following algorithm: Data Mark := (mark at beginning of header) + (attrib_count) + (filename_length) + (16 * total_threads) + (comp_thread_eof of all threads in the thread list which are not data prior to finding a data_thread) Finding the start of a resource_thread -------------------------------------- The beginning of a resource_thread can be found using the following algorithm: Resource Mark := (mark at beginning of header) + (attrib_count) + (filename_length) + (16 * total_threads) + (comp_thread_eof of all the threads in the thread list which are not resources prior to finding a resource_thread) Finding the next record ----------------------- The next record can be found using the following algorithm: Next Mark := (mark at beginning of header) + (attrib_count) + (filename_length) + (16 * total_threads) + (comp_thread_eof of each thread) NuFX Documentation 2/3/89 - Page 18 - Misc notes on threads --------------------- There must *ALWAYS* be at least 1 thread attached to each record, whether the thread has any physical length or not. Phantom files and directories will have both the thread_eof and comp_thread_eof fields set to null (00). If a control_thread indicates that a directory should be created on the destination device, the path to be created must take the form of a prodos partial pathname. That is, the path must *NOT* be preceded with a volume name. ie, /STUFF/SUBDIR is an invalid path, while SUBDIR/ANOTHERSUB is a legal path. If a control_thread indicates that a directory is to be created, *ALL* the subdirectories that are contained in the pathname must be created. Control_threads will be eventually used to control the execution of utility programs by allowing for directory creation, renaming, deleting, moving, or modifying files. A form of scripting language will eventually be available to allow utility programs to perform these actions automatically. Control_threads will allow extraction programs to perform operations akin to Apple's GS/OS installer program, allowing updates to program sets dependent upon such things as date of creation or modification, version number, etc. NuFX Documentation 2/3/89 - Page 19 - Normal Files ------------ Normal Prodos files (sub_types $01,$02,$03) should be handled in the following manner: the data portion of the file will occupy the first data_thread. Sample header block for a normal file record: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F +-------------------------------------------------+ created 01:10:00 00 | 4E F5 46 D8 55 34 3A 00 00 00 01 00 00 00 01 00 | 10/22/88 10 | 2f 00 00 00 c3 00 04 00 00 00 00 00 00 00 01 00 | saturday 20 | 00 0a 01 58 16 0a 00 07 00 10 0b 58 11 0b 00 05 | 30 | 00 0c 01 28 16 0a 00 07 05 00 53 54 55 46 46 02 | last mod 11:16:00 40 | 00 02 00 00 00 00 00 00 20 00 00 00 10 00 00 | 11/17/88 +-------------------------------------------------+ thursday archived 01:12:00 header_id = "NuFX" 10/22/88 header_crc = $3455 saturday attrib_count = $003A (58 bytes in attrib section) version = $0000 total_threads = $00000001 file_sys_id = $0001 (Prodos) file_sys_info = $002f (not sparse, / = separator) access = $000000C3 (full access, not invis) filetype = $00000004 (Prodos BIN) aux_type = $00000000 storage_type = $0001 (Prodos sapling file) create_when = 00 0a 01 58 16 0a 00 07 mod_when = 00 10 0b 58 11 0b 00 05 archive_when = 00 0c 01 58 16 0a 00 07 filename_length = $0005 filename = "STUFF" thread_class = $0002 (data_thread) thread_format = $0002 (compressed with ShrinkIt) thread_kind = $0000 (file) reserved = $0000 thread_eof = $00002000 comp_thread_eof = $00001000 (file is 50% of original size) NuFX Documentation 2/3/89 - Page 20 - Extended Files -------------- Sample header block for an extended file record: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F +-------------------------------------------------+ created 01:10:00 00 | 4E F5 46 D8 65 78 3A 00 00 00 02 00 00 00 01 00 | 10/22/88 10 | 2f 00 00 00 c3 00 b3 00 00 00 00 00 00 00 05 00 | saturday 20 | 00 0a 01 58 16 0a 00 07 00 10 0b 58 11 0b 00 05 | 30 | 00 0c 01 58 16 0a 00 07 09 00 45 58 54 2e 53 54 | last mod 11:16:00 40 | 55 46 46 02 00 02 00 00 00 00 00 00 20 00 00 00 | 11/17/88 50 | 08 00 00 02 00 02 00 00 00 00 00 00 10 00 00 00 | thursday 60 | 08 00 00 | +-------------------------------------------------+ archived 01:12:00 10/22/88 header_id = "NuFX" saturday header_crc = $7865 attrib_count = $003A (58 bytes in attrib section) version = $0000 total_threads = $00000002 file_sys_id = $0001 (Prodos) file_sys_info = $002f (not sparse, / = separator) access = $000000C3 (full access, not invis) filetype = $000000B3 (Prodos S16) aux_type = $00000000 storage_type = $0005 (extended file) create_when = 00 0a 01 58 16 0a 00 07 mod_when = 00 10 0b 58 11 0b 00 05 archive_when = 00 0c 01 58 16 0a 00 07 filename_length = $0009 filename = "EXT.STUFF" thread_class = $0002 (data_thread) thread_format = $0002 (compressed by ShrinkIt) thread_kind = $0000 (file) reserved = $0000 thread_length = $00002000 comp_thread_length = $00000800 (data_fork is 25% of original size) thread_class = $0002 (data_thread) thread_format = $0002 (compressed by ShrinkIt) thread_kind = $0002 (resource_fork) reserved = $0000 thread_eof = $00001000 comp_thread_eof = $00000800 (resource is 50% of original size) NuFX Documentation 2/3/89 - Page 21 - Disks ----- If the file system of a particular disk is not known, the file_sys_id field should be set to null, the volume name should also be set to null, and all the other fields pertaining only to files should be set to null. If the file system of a particular disk *IS* known, as many of the fields as possible should be filled with the correct information. Fields which do not pertain to an archived disk should remain set to null. If an entire disk is added to the archive without some form of compression (ie, record_format = uncompressed), then the blocks which comprise the disk image *MUST* be added sequentially from the first through the last block. Since there will be no character included in the data stream to mark the end/beginning of a block, extraction programs should rely on the file_sys_block_size field to determine how many bytes to read from the record to properly fill a block. NuFX Documentation 2/3/89 - Page 22 - Sample header block for a disk record: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F +-------------------------------------------------+ created 01:10:00 00 | 4E F5 46 D8 67 05 3A 00 00 00 01 00 00 00 01 00 | 10/22/88 10 | 2f 00 00 00 00 00 00 00 00 00 40 06 00 00 00 02 | saturday 20 | 00 0a 01 58 16 0a 00 07 00 10 0b 58 11 0b 00 05 | 30 | 00 0c 01 58 16 0a 00 07 04 00 44 49 53 4B 02 00 | last mod 11:16:00 40 | 02 00 01 00 00 00 00 00 00 00 51 45 07 00 | 11/17/88 +-------------------------------------------------+ thursday archived 01:12:00 header_id = "NuFX" 10/22/88 header_crc = $0567 saturday attrib_count = $003A (58 bytes in attrib section) version = $0000 total_threads = $00000001 (one thread) file_sys_id = $0001 (Prodos) file_sys_info = $002f (not sparse, / = separator) access = $00000000 (none) filetype = $00000000 (none) aux_type/creator_type = $00000640 (1600 blocks on device -- 3.5" disk) storage_type = $0200 (block size = 512 bytes) create_when = 00 0a 01 58 16 0a 00 07 mod_when = 00 10 0b 58 11 0b 00 05 archive_when = 00 0c 01 58 16 0a 00 07 filename_length = $0004 filename = "DISK" thread_class = $0002 (data_thread) thread_format = $0002 (compressed with ShrinkIt) thread_kind = $0001 (disk image) reserved = $0000 thread_eof = $00000000 (unknown size before compressing) comp_thread_eof = $00074551 (size after compression) NuFX Documentation 2/3/89 - Page 23 - Directories ----------- Directories are handled almost the same way that normal files are handled with the exception that there will be no data in the thread which follows the entry. A thread_record *MUST* exist to inform a utility that a directory is to be created through the use of the proper control_thread value. Directories do not necessarily have to precede a record which references a directory. ie, if a record contains STUFF/MY.STUFF, the directory "STUFF" need not exist for the extracting program to properly extract the record. The extracting program must check to see if each of the directories referenced exist, and if they do not exist, create them. While this method places a great burden on the abilities of the extraction program, it avoids the anomalies associated with the deletion of directories within an archive. NuFX Documentation 2/3/89 - Page 24 - Cyclic Redundancy Checks (CRC's) -------------------------------- Many people are not aware of how to calculate a CRC, so to provide this function, I am providing source code to a very fast routine which does the crc calculation. The routine "makeLookup" needs to be called only once. After this, the routine "doByte" should be called repeatedly with each new byte in succession to generate the cumulative CRC for the block. The CRC word should be reset to null (0000) before beginning each new CRC. This is the same CRC calculation which is done for CRC/Xmodem, and Ymodem. The code is easily portable to a 16-bit environment like the Apple IIgs. The only detrimental factor with this routine is that it requires 512 bytes of main memory to operate. If you can spare the space, this is one of the fastest routines I know to generate a CRC-16 on a 6502-type machine. *------------------------------- * fast crc routine based on table lookups by * Andy Nicholas - 03/30/88 - merlin 'c02 - easily portable to nmos 6502 also. * easily portable into orca/m format, just snip and save. xc turn 65c02 opcodes on *------------------------------- * routine to make the lookup tables *------------------------------- makeLookup LDX #0 zero first page zeroLoop STZ crclo,x zero crc lo bytes STZ crchi,x zero crc hi bytes INX BNE zeroLoop *------------------------------- * the following is the normal bitwise computation * tweeked a little to work in the table-maker docrc LDX #0 number to do crc for fetch TXA EOR crchi,x add byte into high STA crchi,x of crc LDY #8 do 8 bits loop ASL crclo,x shift current crc-16 left ROL crchi,x BCC loop1 NuFX Documentation 2/3/89 - Page 25 - * if previous high bit wasn't set, then don't add crc * polynomial ($1021) into the cumulative crc. else add it. LDA crchi,x add hi part of crc poly into EOR #$10 cumulative crc hi STA crchi,x LDA crclo,x add lo part of crc poly into EOR #$21 cumulative crc lo STA crclo,x loop1 DEY do next bit BNE loop done? nope, loop INX do next number in series (0-255) BNE fetch didn't roll over, so fetch more RTS done crclo ds 256 space for low byte of crc table crchi ds 256 space for high bytes of crc table *------------------------------- * do a crc on 1 byte/fast * on initial entry, CRC should be initialized to 0000 * on entry, A = byte to be included in CRC * on exit, CRC = new CRC *------------------------------- doByte EOR crc+1 add byte into crc hi byte TAX to make offset into tables LDA crc get previous lo byte back EOR crchi,x add it to the proper table entry STA crc+1 save it LDA crclo,x get new lo byte STA crc save it back RTS all done crc dw 0000 cumulative crc for all data NuFX Documentation 2/3/89 - Page 26 - Possible Block Combinations --------------------------- The blocks *MUST* occur in the following fashion: Master Header block containing N entries Header block threads (message, control, data, or resource) . . . Next Header block (notice no second Master Header block) threads (message, control, data, or resource) . . . Nth Header Block threads (message, control, data, or resource) NuFX Documentation 2/3/89 - Page 27 - Known NuFX utility programs: --------------------------- Name Author Description Current Ver ------------- -------------- ------------------------------------ ----------- ShrinkIt Andy Nicholas Compresses files/disks, provides 0.95 archive and file utilities. NuList Andy Nicholas Lists contents of NuFX files for 1.1 the GBBS "Pro" (tm) BBS, online. NuFX Documentation 2/3/89 - Page 28 - Legal Stuff ----------- Apple, Apple IIGS, AppleLink, GS/OS, Macintosh, and Lisa are registered trademarks of Apple Computer, Inc. GBBS "Pro" is a registered trademark of L&L Productions. About the Author ---------------- I am currently a Junior attending Moravian College in Bethlehem, Pennsylvania, majoring in Computer Science. Any comments or suggestions you have about NuFX are more than welcome, or if you wish to request that any of the fields be assigned your own value, or if you would like to inform me of a NuFX utility you have written, you can contact me at: Paper Bag Productions c/o Andy Nicholas Box 435 Moravian College Bethlehem, PA 18018 CSNET : nicholaA@moravian.edu InterNET : nicholaA%batman.moravian.edu@relay.cs.net nicholaA@batman.moravian.edu.csnet ProLine : andyn@pro-sol.cts.com [619-670-5379] AppleLink PE: ShrinkIt I would like to thank the following people for their help and input during the design phase of the NuFX proposal: Jason Blochowiak, Morgan Davis, Don Elton, Dave Lyons, Jon Davidson, Vince Cooper, Lance Taylor-Warren, Floyd Zink, Kent Dickey, John Brooks, Doug Brandon, Todd South, Larry Hawkins, Kevin Keller