|
New commands just for extended natives:
F-P
EC
EM
EU
MR
CR
When a direct access channel is opened, two adjacent buffers are assigned to the channel so that a 512 byte block of memory can be used. When a file is opened, four adjacent buffers are assigned. The first two buffers are used for a data buffer and the last two are used for a CAT buffer for the file or chain of blocks. When a file is opened, bufpnt+3,x always points to the second page of the 1024 block buffer. bufpnt+0 and bufpnt+1 will change as data is read or written to the 512 byte data buffer. bufpnt+2 points to either the first half of the 512 byte buffer or the seond half depending on where the last byte of the buffer is located. lastChnChar points to the last byte within the page. catptr always points within the third and fourth buffers. This holds the current CAT block for the channel. When a bam buffer is allocated for the partition, two adjacent 512 byte buffers in the bam buffer area are used. The first holds the current bam block and the second holds the master header and master bam block for the partition. Modify mode allows reading and writing to an existing file only in an extended native partition. In all other partitions, it only allows reading. When reading, the first byte is made ready to read. If writing, the F-P command should be used first to set the file pointer to the desired byte after opening the file in modify mode. Modify mode cannot be used to add additional data to a file. It can only be used to read or write the existing data bytes. If data needs to be added, the file should be closed and reopened in append mode. The F-P command only works in an extended native partition and only when using modify mode or read mode. Hidden files cannot be deleted using wildcard patterns. To delete a hidden file, the actual filename must be used. This prevents accidental deleting of a file you may have forgotten about. Notes on extended native partitions NOTICE: These notes are subject to change during the development of the new 'extended native' mode partitions. Block sizes are always 512 bytes. Partition size minimum is 32,768 blocks (16 megs) Partition size maximum is 8,388,608 blocks (4 gigs) Partitions can be sized in increments of 4096 blocks (2 megs) There are no tracks and sectors. Blocks are addressed according to their offset from the start of the partition. Three bytes are used to address any block. Everything in an extended native partition is composed of chains of blocks. A file is nothing more than a chain of blocks with directory entry describing where to begin finding the chain. The directory entry actually points to a CAT block, which is described in detail later. The CAT block describes the location of every block in the file. A directory, whether it be a root directory or a subdirectory is also a chain of blocks. As with other partition types, a directory also has a header block. The header block and directory blocks make up a chain of blocks just like a file. There is also a CAT block describing the location of the header block and all the directory blocks in the directory. Each root dir and subdir has its own CAT block and header block. Every directory has its CAT block, header block, and first directory block in a fixed location in relation to each other. The CAT block comes first. Then in the next two consecutive blocks are the header block and first directory block. This holds true for all root directories and subdirectories. The master directory is arranged in the same manner. The master CAT block is always at block 1. The master header block is always at block 2. And the first master directory block is always at block 3. Block 0 is reserved as a boot block. Block 0 ($000000) Reserved for C-128 boot block. Operating systems aside from BASIC may use this block provided they do not interfere with the bytes that are normally used by the C-128 boot operation. Block 1 ($000001) - Master directory CAT block This block describes the location of every block that makes up the master directory. The first block in the list points to the master header block and the second points to the first master directory block.
Block 2 ($000002) - Master directory header block
byte value description
0 Middle byte pointer to master directory CAT block
1 Low byte pointer to master directory CAT block
2 77 ASCII 'M' for format type
3 High byte pointer to master directory CAT block
4-21 Partition name padded with shifted spaces.
22-23 Disk ID (HD-DOS ignores this)
24 160 Shifted space for separator
25 49 ASCII '1' for DOS version
26 77 ASCII 'M' for format type
27-28 160 Shifted spaces for separators
29 High byte of partition size in blocks
30 Middle byte of partition size in blocks
31 0 Low byte of partition size (always zero)
size ranges from 32,768-8,388,608 ($008000-$800000)
blocks in 4,096 ($001000) block increments
32-38 0 Always 7 zeros in the Master directory header
39-41 0 Reserved
42 High byte of blocks free count
43 Middle byte of blocks free count
44 Low byte of blocks free count
(blocks free is updated whenever a block
is allocated or freed)
45 0-255 The default root directory
46 For HD-DOS use
47-255 0 Reserved
256-511 Master BAM bytes
Master BAM description Located in bytes 256-511 of the Master directory header block. Each Master BAM bit represents an actual BAM block. There are 2048 bits. With each bit representing one BAM block and each BAM block representing 4096 blocks, this means there can be a possible 2048*4096 blocks maximum. If all the blocks represented by a BAM block are used, its master BAM bit will be zero, otherwise the master BAM bit will be 1 even if only one block is still available within that 4096 block segment. byte description 256 Master bits for BAM blocks 0-7 257 Master bits for BAM blocks 8-15 ... ... 511 Master bits for BAM blocks 2040-2047 If a partition is less than the maximum allowable size, all unused Master BAM bits will be set to zero. This is done during formatting and validating. Block 3 ($000003) - First master directory block This block is the first block of the master directory. The master directory can be anywhere from 1 block to 32 blocks and can contain from 1 to 256 root directories. Only one root directory is visible to the user at any one time. Root directories can be treated almost like separate partitions. Each directory entry points to the first CAT block for a root directory. Additional master directory blocks can be located anywhere within the partition, but the first block will always be at block 3 in the partition. Block 4 ($000004) - Block 2051 ($000803) Bam blocks. There is always 2048 bam blocks. The first bam block is always at block 4. All the rest of the bam blocks follow. Each bam block represents 4096 data blocks. With a minimum partition size of 32768 blocks (16mb), at least 8 bam blocks will always be in use. With a maximum partition size of 8388608 blocks (4gb), all 2048 bam blocks will be used. BAM block description There will always be at least 8 BAM blocks in use. A BAM block is used for each increment of 4096 blocks. All 2048 bam blocks exist even though they may not all be in use. This facilitates easier copying of whole partitions between partitions of varying sizes. All DOS operations completely ignore the unused bam blocks. They are not written to when validating the partition. BAM byte description for the first BAM block byte description 0 BAM bits for blocks 0-7 (bit 7 is for block 0) 1 BAM bits for blocks 8-15 ... ... 511 BAM bits for blocks 4088-4095 The second BAM block is for blocks 4096-8191, the third is for blocks 8192-12287, etc. Block 2052 ($000804) and beyond The remainder of the partition is used for root directories, subdirectories, and files. The Master directory The Master directory is a new feature being introduced with the extended native partitions. Bytes 0,1, and 3 of the Master directory header indicate the location of the Master CAT block within the partition. The Master CAT block will always be at block 2, one block before the Master header block. Likewise, the first Master directory block is always one block after the Master header block. This Master directory is used for holding root directories. No user files should ever be placed in the Master directory. The Master directory is normally not visible to the user when using normal directory access methods. Instead, only the default root directory is visible. Access to additional root directories depends on the operating system in use and how it wants to use them. There are also special commands that can be issued from BASIC or a configuration application for creating new root directories and for accessing them as well as changing them to become the new default root directory. When an extended native partition is first created and formatted, or reformatted, it is always formatted with one root directory located within the Master directory. This root directory is always given the name that was used with the format command. This also becomes the default root directory that will be used whenever this partition is accessed. The default root directory is listed in bytes 4-21 of the Master directory header block. The user can simply use this one single root directory if desired, it is always open by default. To the user, this will work just like the original native partitions. Files can be added and subdirectories can be created within this root directory. Nothing new needs to be learned by the user. There are no subdirectories or other files in the Master directory. Only root directories are allowed in the Master directory. Any directory entry found that is not a root directory is removed during a partition validation. An operating system could have one small boot file located within the default root directory that the user can access from BASIC. This boot file would then access the Master directory to locate a particular root directory in order to access the needed files for booting up the operating system. Once booted, the operating system would then make one of the root directories visible to the user from its own desktop or command line interface. If desired, the operating system could also provide a means for switching to a different root directory, but this will most likely not be needed except for copying or moving files between root directories. Root Directories and Subdirectories We can have several root directories as already described but each one is similar to the single root directory found in the standard native partitions. Subdirectories in an extended native partition are just like subdirectories in a standard native partition as well. Subdirectories have a directory entry, just like any file, either within a root directory or within another subdirectory. Note: In native partitions, the first directory sector ALWAYS must begin at the next consecutive logical block after the header block. Likewise, in extended native partitions, the first CAT block for a directory must be followed by the directory header block and then by the first directory block. Directory header for a root directory
byte value description
0 Middle byte pointer to root directory CAT block
1 Low byte pointer to root directory CAT block
2 77 ASCII 'M' for format type
3 High byte pointer to root directory CAT block
4-21 160 Shifted spaces.
22-23 Disk ID (HD-DOS ignores this)
24 160 Shifted space for separator
25 49 ASCII '1' for DOS version
26 77 ASCII 'M' for format type
27-28 160 Shifted spaces for separators
29 High byte pointer to root dir CAT block (same as byte 3)
30 Middle byte pointer to root dir CAT block
(same as byte 0)
31 Low byte pointer to root dir CAT block (same as byte 1)
32-34 0 Always zeros in root directories
35 High byte of dir block in master directory for this entry
36 Middle byte of dir block in master directory
for this entry
37 Low byte of dir block in master directory for this entry
38 0-7 Index to dir entry within master directory block
39-41 0 Reserved
42-44 0 Always zeros in root directories
45 0-255 Root directory number. This is also the offset within
the master directory where this root dir entry
is located.
46 0 Always zero in root directories
47-63 0 Reserved
64-95 Root directory name padded with shifted spaces
96-168 0 Reserved
Note: If the directory contains a GEOS type system directory, bytes 169-189 are described below. A GEOS system directory does not contain a directory header, it consists only of a CAT block which will indicate the location of each directory block. In GEOS, this directory chain is seen as an extension to the directory it belongs to. The same chain of directory blocks can be made visible to other directories within the same partition by including the same CAT pointers in those other directory headers. 169 High byte pointer to system directory CAT block 170 Middle byte pointer to system directory CAT block 171 Low byte pointer to system directory CAT block 173-188 "GEOS format V2.0" GEOS ID string 189 0 Null terminator for ID string 190-255 Reserved 256-511 Reserved Directory header for a subdirectory
byte value description
0 Middle byte pointer to subdirectory CAT block
1 Low byte pointer to subdirectory CAT block
2 77 ASCII 'M' for format type
3 High byte pointer to subdirectory CAT block
4-21 160 Shifted spaces.
22-23 Disk ID (HD-DOS ignores this)
24 160 Shifted space for separator
25 49 ASCII '1' for DOS version
26 77 ASCII 'M' for format type
27-28 160 Shifted spaces for separators
29 High byte pointer to root dir CAT block
30 Middle byte pointer to root dir CAT block
31 Low byte pointer to root dir CAT block
32 High byte pointer to parent dir CAT block
33 Middle byte pointer to parent dir CAT block
34 Low byte pointer to parent dir CAT block
The block pointed at by bytes 32-34 will always be
greater than zero if this is a subdir.
Root dirs always have these three bytes set to zero.
This is how
to identify if the current directory is a root or
subdirectory.
35 High byte of dir block in parent chain for this entry
36 Middle byte of dir block in parent chain for this entry
37 Low byte of dir block in parent chain for this entry
38 0-7 Index to dir entry within parent's dir entry block
39-41 0 Reserved
42-44 0 Always zeros in subdirectories
45 0-255 Root directory number this subdir resides in.
This is also the offset within the master directory
where the root dir entry is located.
46 0 Always zero in subdirectories
47-63 0 Reserved
64-95 Subdirectory name padded with shifted spaces
96-168 0 Reserved
Note: If the directory contains a GEOS type system directory, bytes 169-189 are described below. A GEOS system directory does not contain a directory header, it consists only of a CAT block which will indicate the location of each directory block. In GEOS, this directory chain is seen as an extension to the directory it belongs to. The same chain of directory blocks can be made visible to other directories within the same partition by including the same CAT pointers in those other directory headers. 169 High byte pointer to system directory CAT block 170 Middle byte pointer to system directory CAT block 171 Low byte pointer to system directory CAT block 173-188 "GEOS format V2.0" GEOS ID string 189 0 Null terminator for ID string 190-255 Reserved 256-511 Reserved Directory entry description Each directory entry in an extended native partition consists of 64 bytes. All other partition types only use 30 bytes for a directory entry. In some cases, this may pose a compatibility problem for some applications and/or operating systems. New or upgraded operating systems and applications should be able to adapt without much problem. Likewise, with the larger directory entry, the filename size has also been increased from the previous 16 character limit to a 32 character limit. This also may pose a problem, but the user will learn when to limit a filename to 16 characters for compatibility reasons. The DOS will not attempt to truncate any long filename during any DOS access. Long filenames are designed into this system and will be used as such. Another compatibility problem that could arise has to do with filesizes. In all other partitions, the maximum size of a file is limited to the available space on the partition. Since the limit was 65280 blocks, only two bytes were needed to list a filesize in blocks. In an extended native partition, filesizes are listed in bytes instead of blocks. Since the largest possible filesize is nearly 4 gigabytes, 4 bytes are used for listing the filesize. There are also other new bytes in each directory entry for identifying the filetype, its usage, etc. Each directory block within a directory can hold up to 8 directory entries. Directory entry layout File status bytes
byte value description
0,1 0,0 Empty file entry or previously deleted.
1,128 Entry in use.
0,128 Trashed file - entry may not be reused until file is deleted
* If 64 is added to byte 0, the file is locked and cannot be deleted, trashed, or modified. * If 64 is added to byte 1, the file is a hidden file and will not appear in normal directory listings. Note: Hidden directories cannot be opened by HD-DOS. It is up to an operating system to manage a hidden directory. * A trashed file is similar to a deleted file except that it is not actually removed from the partition. A trashed file is merely hidden from a normal directory listing. It will never be overwritten by another file. When the user trashes a file, the DOS simply changes byte 0 of the directory entry to a 0. A trashed file can easily be recovered by simply changing byte 0 of the directory entry back to a 1. This can be done with an 'untrash' command if the user knows the name of the trashed file. Or a directory listing can be displayed showing only the trashed files in the current directory. When a file is deleted, only the first two bytes of the directory entry are cleared to zero. The remainder of the directory entry is left intact. However, further data saved to the partition will likely overwrite the data blocks previously occupied by the deleted file. Commodore Filetype byte
byte value description
2 0 DEL (not used)
1 SEQ (generally a data file)
2 PRG (file may or may not have a load address as its first
two bytes)
3 USR
4 REL (not used)
5 CBM (not used)
6 DIR (a directory entry)
* In other partitions and disk types, the filetype byte is always added to 128 to indicate that it was properly closed. If it was not properly closed, it's considered to be a splat file and the disk should be validated to eliminate the entry. There are no splat files in an extended native partition. Also, the filetype byte is not 128 or greater, but rather contains the values as listed above. As you can see, only 4 of the Commodore filetypes are used, SEQ, PRG, USR, and DIR.
Pointer in blocks to first chain allocation block for this file byte value description 3 High byte 4 Middle byte 5 Low byte Mount ID
6 0-254 If 0 - file not mounted to any partition
If 1-254 - partition file was last mounted to
HD-DOS checks this byte before deleting the file or before opening the file for modifying or for mounting to another partition. If 0, then it's OK to proceed. If non-zero, the partition will be checked to see if the file is still mounted to it. If not, then this byte is cleared to zero and the operation will continue. The byte is not cleared to zero when the file is unmounted. Filesize in bytes 7 Fourth byte (high byte) 8 Third byte 9 Second byte 10 First byte (low byte) Unused 11-13 Reserved for future use Time file or directory was created 14 20- Century byte of the year 15 0-99 Year within the century 16 1-12 Month 17 1-31 Date within the month 18 0-23 Hour in military time 19 0-59 Minutes 20 0-59 Seconds Operating system usage byte
21 0 Generic type. HD-DOS uses this value when creating a file
1-63 Reserved for other operating systems
64-127 Reserved by HD-DOS for future use
128-255 GEOS type operating systems
* Valid operating system designers should contact Click Here Software to register a value for byte 21 for your OS usage to prevent conflicts with other operating systems. These values will then be listed in official documentation. Byte 21 defines how the OS bytes at 22-30 are used. HD-DOS sets these bytes to zero when creating a file. GEOS usage of OS bytes
22-24 Currently undefined
25 0 GEOS sequential file structure
1 GEOS VLIR file structure (for GEOS kernal usage)
26 1-99 GEOS filetype
27-28 Reserved for future GEOS use
29-30 Reserved for application use
Generic usage of OS bytes 22-24 Currently undefined 25 0 Always zero, normal file structure 26 Reserved for future use 27-30 Reserved for application use The generic usage of bytes 22-30 are left for non-OS specific applications to use. These bytes are considered generic when byte 21 is set to 0. HD-DOS will then treat the bytes as listed above. HD-DOS normally ignores the OS bytes. If an operating system uses its own file structure unlike what is described here, it will also have to provide its own validating, file creating and deleting, and other file system operations. Shared byte
31 0 Shared by all operating systems - currently undefined.
HD-DOS sets this byte to zero when creating a file
and ignores it afterwards
Filename 32-63 filename padded with shifted spaces The Chain Allocation Table (CAT) Other partition types and disk types use logical blocks of 256 bytes in length with the first two bytes of each block either pointing to the next block in the chain or indicating which byte is the last byte in the current block if it's the last block in the chain. This leaves 254 bytes in each block for holding data for the file. In an extended native partition, blocks are 512 bytes in size and each byte is a data byte if the block is part of a file. The directory entry does not point to the actual data blocks for the file. Instead, it points to a block containing a compressed listing of bytes describing the location of all the data blocks that make up the file or directory. This sounds complex but is really quite simple once it's understood. This first block is referred to as a chain allocation table or CAT for short. It has nothing to do with reserving the blocks once a file has been created. It's merely a way of determining where each block in the file is located in the partition. The actual BAM blocks are updated as blocks are either allocated or freed as files are created, modified, or deleted. A CAT block contains pointers to an entire file or to various chunks of the file if the file is fragmented into several areas of the partition. So, a file can be contained in one complete chunk of data or scattered about in many chunks if the partition is badly fragmented. In any case, all the chunks that make up the file are contained within the CAT block or however many CAT blocks are needed to describe the location of the entire file. Chain Allocation Table usage
byte value description
0 High byte to next CAT block if bit 7 is set
If bit 7 clear, this is the last CAT block in the chain
1 Middle byte to next CAT block
2 Low byte to next CAT block
3 High byte to previous CAT block if bit 7 is set
If bit 7 clear, this is the first CAT block in the chain
4 Middle byte to previous CAT block
5 Low byte to previous CAT block
6 High byte to this CAT block if bit 7 is set
If bit 7 clear, no block assigned for this CAT block yet
(in reality, this will always have bit 7 set. If not, then the
CAT block is corrupt)
7 Middle byte to this CAT block
8 Low byte to this CAT block
The remainder of the block makes up the chunk descriptor bytes in groups of 6 bytes each. Each set of 6 bytes is as follows.
9 High byte to first block of this chunk if bit 7 is set
If Bit 7 is clear, there are no more blocks in the chain
If this happens in the first chunk of the first CAT block,
the file is empty
10 Middle byte to first block of this chunk
11 Low byte to first block of this chunk
12 High byte to last block of this chunk
If bit 7 is set, there are more chunks in the chain
If bit 7 is clear, this is the last block of the chain
13 Middle byte to last block of this chunk
14 Low byte to last block of this chunk
Following the last chunk in the chain, there will be two bytes indicating how many bytes are contained within the last block. If they exceed 512, there is an error.
15 High byte of number of bytes in last block 16 Low byte of number of bytes in last block As you can see from the above description, if a file is contained entirely within consecutive blocks in the partition, only 8 bytes are needed to describe the location of every byte of the file. This would be 3 bytes for the starting block, 3 bytes for the ending block, and 2 bytes for the number of bytes in the last block. Note: Bit 7 of the high byte in each set of three byte pointers is masked out when pointing to the block since the maximum number of blocks in a 4gb partition is $7fffff. Bit 7 of these bytes is used as described above. If a CAT block was completely filled with the maximum number of chunk descriptors, it would look like this: Bytes 0-2 pointers to next CAT block (if any) Bytes 3-5 pointers to previous CAT block (if any) Bytes 6-8 pointers to this CAT block Bytes 9-14 1st set of descriptor bytes Bytes 15-20 2nd set of descriptor bytes . . . Bytes 502-507 83rd set of descriptor bytes Bytes 508-509 number of bytes (msb,lsb) in final block of chain Bytes 510-511 unused If bytes 3-5 indicate there is another CAT block, then bytes 508-509 would be unused. So, a file can be fragmented into as many as 83 chunks and still be completely described within a single CAT block. An operating system can also determine the size of a file by examining the CAT block. It can count the number of blocks in each 6 byte description, subtract 1 for the final block, multiply the block count by 512, and then add the number of bytes in the final block to arrive at the total file size in bytes. This count can be compared to the filesize bytes in the directory entry. If there's a conflict, then the operating system needs to correct one or the other. During an HD-DOS validate, the values in the CAT blocks take precedence over the directory entry values. However, if the number of bytes contained within the final block are not listed as being between 0 and 512, the CAT block is considered corrupt. The filesize bytes from the directory entry will then be used to aid in determining the end of the file. A CAT block describing a directory chain will always show the last block in the chain as having 512 bytes. A directory block is always full even if it contains 8 empty directory entries. Note: In other partitions, the first two bytes in the last block 'point' to the last byte in the block. In an extended partition, the final two bytes in the CAT listing is the 'number' of bytes in the last block. CAT blocks are not included in the filesize, only the actual data bytes are counted. However, a CAT block that is created will get a bit allocated in the BAM and also will decrease the blocks free count of the partition by one. So, as files are created or deleted, the blocks free count won't change by the same amount as the filesize. GEOS OS features A chain of blocks in the HD-DOS extended native file system always begins with a CAT block. This is the same with any chain of blocks used in the GEOS file system when used in an extended native partition. In other partition types, there is a separate pointer to the GEOS info block in the directory entry. In an extended native partition, the GEOS info block is always the first block of the file. The actual data of the file begins with the second block. Therefore, a GEOS file is always a sequentially linked chain of blocks just like any ordinary file. This first block which is the info block will contain the same information in the first 256 bytes as found in a normal GEOS info block. The second 256 bytes of the block are normally empty. It's also possible for additional information to be found in the second half of the info block which might describe additional icons or other information for the GEOS file. There might also be a pointer to the actual start of the data if additional blocks are needed for the info portion of the file. The way GEOS will use the extended native partition is still to be developed. Direct access programming All of the direct access commands such as U1, U2, B-A, B-F, B-R, B-W, B-E, and B-P will work in an extended native or extended foreign partition. The major difference is the size of the blocks that are being accessed. With these partitions, each block contains 512 bytes. When you open a direct access channel in an extended partition, a 512 byte buffer will be assigned instead of a 256 byte buffer which is used for all other partition types. Accessing blocks in a partition the size that an Extended Native partition can be requires 3 bytes to describe the location of the block. Previously, this has always been done with just two bytes. However, there has always been a third unused byte in each of the direct access commands. As an example, look at the U1 command for reading a block: PRINT#lf,"U1";sa;n;t;s where: lf = the logical file number used for the command channel sa = the secondary address used for the direct access file n = partition number (always 0) t = the logical track of the block to be read or written s = the logical sector of the block to be read or written With an Extended Native partition, the meaning for n, t, and s are different but actually almost identical. Tracks and sectors are not used, instead addressing is done by blocks. The high byte of the 3 byte block address is n, the middle byte is t, and the low byte is s. The same method works with the B-A command. For instance, if we wanted to allocate block number 151,651 using the B-A command, we first convert 151651 to a three byte value. It's easy if we look at the hexadecimal equivalent which is $025063. The high byte is $02 (2), the middle byte is $50 (80), and the low byte is $63 (99). So, the command would look like this: PRINT#lf,"B-A:"CHR$(2)CHR$(80)CHR$(99) This is the same number of bytes used with the B-A command when using it with other partition types, except that the first number is always a zero, no matter what. Therefore, with other partition types, the limit to the B-A command is 16MB with block sizes of 256 bytes. In an Extended Native or Extended Foreign partition, with block sizes of 512 bytes and the first byte in the command being allowed to have a value larger than zero, the limit for the B-A command (as well as all of the direct access commands) is 8GB, which is the limit for an Extended Foreign partition.
|
Copyright © 2001-2007 Click Here Software Co.
Comments and questions regarding this site
should be directed to support@cmdrkey.com