The FYS OS code named Konan: The File System

The FYS OS: code named 'Konan'

The File System

( Get a MS Word 97 version of this spec. Get a MS Word 97 viewer. )

If you have any questions and/or suggestions plus any feedback, please let me know
at fys [at sign] frontiernet [period] net.

The FYSOS File System (version 1.32) (dated: 16 June 2008)
by Benjamin David Lunt
Copyright (C) 1984-2008

You may distribute this document in its entirety and/or use this information for non-
commercial or education use without the author’s permission. This document and the
implementation of this file system may not be used commercially unless you obtain
prior written consent from the author.

This is a small attempt at a file system. This FS won’t break any new records, but
at least it is something that may help you with your FS creation.

A brief summary:
The FYSOS FS contains a root directory and a FAT similar to the MS FAT FS. However,
the FYSOS FS differs in that the directory entry and the FAT entry(s) are stored in
the same place. No need to read multiple locations just to get the directory and the
fat entry of a file.

The FYSOS FS allows for a filename of unlimited chars in length, though the host may
limit it to 255 chars, a 64-bit file size, and 64-bit FAT entries. This allows for
very large files and volume sizes.

An overlook of a typical FYSOS FS partition:
There are a few items in a FYSOS FS volume that must be set to fixed values. The
boot sector and location as well as the size and location of the SuperBlock.

The Boot Sector is always at Linear Sector Number zero, or LSN 0. The FYSOS FS
leaves the first 16 sectors free for the boot. These 16 sectors are reserved for the
boot and loader code, if needed. There is an optional copy of the boot sector in the
last sector of this block, LSN 15. To check if there is a valid copy at LSN 15,
check the copy_valid member in the BPB. If it is non zero then check the boot sig at
offset 0x1FE in the copy. If this sig is a word sum of the first 510 bytes of the
sector, then this is a valid boot sector copy and can replace the current boot
sector. Remember to make sure the sig is changed to 0xAA55 before replacing at LSN 0.

The Boot Sector must contain a valid BIOS Parameter Block (BPB) at the beginning of
the sector. Its format is as such:

struct S_FYSFS_BPB {
bit8u jmp[3]; //
char oem_name[8]; //
bit16u bytes_per_sect; // power of 2 from 512->4096
bit8u sect_per_clust; // power of 2 from 1 ->512
bit16u sect_reserved; // always 16
bit8u resv0; // must be zero
bit16u root_entrys; // number of root entries
bit8u resv1; // must be zero
bit16u sect_per_trk; //
bit16u heads; //
bit32u resv2; // must be zero
bit64u base_lba; // zero based LBA of this sector
bit8u drive_num; // must be set to the DL value given by the BIOS at boot
bit8u copy_valid; // “copy” at lsn 15 is valid (must check check_sum also)
bit8u sig; // currently not used.
bit32u serial; //
char label[11]; //
char sys_type[8]; // "FYSFSv10"
};

A definition of the fields:
jmp[3] The typical Intel jmp short instruction to jump over the BPB.
The third byte must be the NOP instruction: 0x90.
oem_name[8] Typically FYSFSv10, but can be modified per a format utility.
bytes_per_sect Must be a power of 2 from 512 to 4096. Usually always 512.
sect_per_clust Sectors per cluster from 1 to 512.
sect_reserved *Always 16*
root_entrys Number of 128 byte entry’s in the root directory block.
must be a minimum of 128 and a max of 65532 and a multiple of
the cluster size. If cluster size is 8 sectors, then this must
be a multiple of (8*4) or 32.
resv1 *must be zero’s*
sect_per_track sectors per track.
heads number of heads
base_lba zero based sector number on physical disk
drive_num must be set to DL value given by BIOS at boot time.
copy_valid the sector at LSN 15 is an exact copy of LSN 0 if this value is
not zero. See below for more on this member item.
sig not used.
serial 32-bit number of seconds since 1 Jan 1980, 00:00:00am.
label[11] volume label.
sys_type[8] file system type. Typically: FYSFSv10.

Any field not mentioned or is marked reserved must be set to zero.

LSN 16 contains the SuperBlock and has the following format:
struct S_FYSFS_SUPER {
bit32u sig[2]; // signature ‘FYSF’ ‘SUPR’ (0x46595346 0x53555052)
bit16u ver; // version (0x0131 = 1.31)
bit8u bitmaps; // number of bitmaps (1 or 2)
bit8u bitmap_flag; // flags describing the bitmaps
bit64u root; // LSN pointer to root. Must be in data block
bit64u data; // LSN pointer to the first sector of the data block
bit64u data_sectors; // count of sectors in data block
bit64u sectors; // total sectors in volume
bit64u bitmap; // LSN of list of bitmap sectors
bit64u bitmapspare; // LSN of list of bitmap sectors (second copy)
bit32u chkdsk; // Seconds since 0:00 1-1-1980 when last chkdsk was ran
bit32u lastopt; // Seconds since 0:00 1-1-1980 when last optimized
bit32u flags; // volume flags
bit8u filler[440]; // filler (to pad to 512 bytes)
};

All LSN pointers in the SuperBlock are zero based from the start of the volume. All
LSN pointers within the data block are zero based from the start of the data block.
i.e.: all starting sectors and fat entries for any file within the data block are
zero based within that data block, not the start of the volume. All values are
written and read in little-endian format, with least significant byte read/written
first and most significant byte last.

The flags field in the super block only has bit 0 used while the remaining 31 bits
must remain reserved. As with any reserved fields, any value read from a reserved
field must be written back as the same value. Bit 0 is use to indicate if the
volumes filenames are case sensitive. If set, they are case sensitive. This flag
should only be modified at format time. It can be set to use case sensitivity at any
time during the life of the volume, however it *must not* be cleared after a volume
has been used unless only after a complete check of the volume to make sure there are
no conflicts with case sensitivity, can it be cleared.

From this point on, the rest of the items on the volume are not located in fixed
locations. Each item is pointed to by the SuperBlock.

On a typical FYSOS FS partition, the bitmap(s) would be next. These bitmaps are
single bit representations of the use of each cluster in the partition. If the bit
is set, it is occupied. The high bit (bit 7) in the first byte of the bitmap
represents Cluster 0, while the low bit (bit 0) represents Cluster 7. The high bit
in the second byte of the bitmap represents Cluster 8, and so on. There are
typically two bitmaps, though the SuperBlock contains a field stating how many there
are. There can be 1 or 2, no more, no less. Bits 1:0 in the bitmap_flag field in
the SuperBlock denote which bitmap is to be used and if the inactive is to be updated
as the active bitmap is updated.

If bit 0 is clear, then the first bitmap is the active bitmap. If it is set, the
second, if present, is active. If this bit is set and the bitmaps entry in the bpb
is 1, then the OS should return an error at mount time.

If bit 1 is clear, the active bitmap is used, while the inactive bitmap is not
touched. If this bit is set, the inactive bitmap needs to be updated to match the
active bitmap at a time when the system is in a stable state. The time and state to
update the inactive bitmap is to be determined by the host. However, no more than
128 modifications should be made to the active bitmap before the inactive bitmap is
updated. A modification in this sense is a single write to the bitmap. If multiple
bits will be modified, but there is only one read/write sequence, this is considered
a single modification. No more than 128 of these modifications should be made before
the second bitmap is updated to match the active bitmap.

On a typical FYSOS FS partition, the Data Area follows the bitmap(s) and contains the
Root Directory within the Data Area. The Root Directory block can be anywhere within
the Data Area. The root_entrys field in the BPB determines the size of the Root
Directory. The Root Directory must be continuous and not fragmented. The Root
Directory can be resized as long as it remains continuous on the disk and the
root_entrys field is updated. Each entry, or slot, is 128 bytes fixed and there are
four (4) types of data blocks that can occupy each slot.

The first being the actual directory entry of the file:
struct S_FYSFS_ROOT {
bit32u sig; // signature of this slot type
bit32u attribute; // file attributes
bit8u resv[5]; //
bit8u fat_entries; // fat entries in this directory entry
bit8u crc; // crc of this slot. 8-bit sum
bit8u scratch; // OS scratch byte. Should be zero when written to disk.
bit32u created; // seconds since 00:00:00 1-1-80
bit32u lastaccess; // seconds since 00:00:00 1-1-80 (read or written)
bit64u fsize; // file size
bit32u fat_continue; // next entry that continues the FAT (0 if none)
bit32u name_continue; // next entry that continues the name (0 if none)
bit16u flags; // file flags (encryption, etc)
bit8u namelen; // length of name in this slot
bit8u resv1; //
bit32u slot; // slot number. Only used in subdirectories.
bit8u name_fat[80]; // name/fat buffer of this entry
};

A definition of the fields:
sig set to ‘SLOT’ (0x534C4F54) to denote the first slot in chain.
attribute the attributes of the file.
resv[5] must be zeros.
fat_entries the count of FAT entries in *this* slot.
crc 8 bit crc sum of all bytes in slot not including this byte,
so that including this byte, all 128 bytes will have a sum of
zero. If this field is zero, no check is used.
scratch OS may use this byte as it likes when in memory, however, it
should be written as zeros to the disk, though is not
mandatory. (See note below)
created Seconds since 00:00:00 1 Jan 1980.
lastaccess Seconds since 00:00:00 1 Jan 1980, when last read or written.
fsize the file size in bytes.
fat_continue the number of the next slot that contains more FAT entries
for this filename. Set to zero if no more slots are needed.
name_continue the number of the next slot that contains more chars of the
filename. Set to zero if no more slots are needed.
flags file flags used by the OS
namelen Length of the filename in *this* slot.
slot slot number. This is the slot number of the directory entry
of this subdirectory’s parent. Currently, only used in the
“..” entry of each subdirectory. Must be zero for all others.
See the section on directories for more information.
resv1 reserved and must be zero.
name_fat[80] remaining 80 bytes of the slot used for the filename and/or FAT
entries. See below for more information on what is in this field.

A directory entry (slot) can contain both the name and/or the FAT for a specified
file. Since the FYSOS FS allows a filename to be many chars in length, a slot must
contain a link to the next slot that contains the remainder of the name if the name
will not fit in the current slot. The same goes for the FAT.

The name and the FAT entries are located in the name_fat field. The name must be
first and must have at least 1 char included in the first slot. The name must also
be end padded with nulls to the next 32-bit alignment. However, the name does not
have to end in a null if the last char is the byte before a 32-bit aligned byte. The
namelen field does not include any null padding in its length.

If the name occupies the whole name_fat field and needs more room, the host must
allocate another unused slot, place this zero-based slot number in the name_continue
field and then continue placing the name in the new slot (not allowing slot 0 to be a
continued slot). See below for the format of this new slot. The 32-bit FAT entries
follow the same format as the name does. The only difference is that there can not
be any FAT entries before any filename chars in the same slot. All FAT entries must
proceed filename chars. To know where the first FAT entry is located in the name_fat
field, you simply skip namelen bytes and start on the next dword aligned entry. If
the namelen field contains a value of 77 or greater, then the FAT entries start at
the slot pointed to by the fat_continue field.

Please note that when calculating the offset of the first FAT entry, you can not
assume that name_fat will be dword aligned in memory. When you calculate using

dword_offset = ((x + 3) & ~0x03)

make sure that the offset of name_fat is not included in the calculation above. If I
were going to use the C language for my driver, my source would be similar to:

ptr = (bit32u *) (root[i].name_fat + ((root[i].namelen + 3) & ~0x03));

Notice that the offset of name_fat was not included in the rounding calculation.

The first FAT entry in the slot chain is the starting cluster number of the file.
With this in mind, there must always be at least one FAT entry, whether in this slot
or a fat_continue slot, unless this is a zero sized file. The cluster number is zero
based from the start of the data LSN given in the super_block.

The starting slot does not have to contain any FAT entries as long as there is at
least one fat_continue slot.

Since the starting slot (a slot with a sig of ‘SLOT’) may use only 32-bit fat
entries, this slot may only contain fat entries if the files’ cluster’s are 2^32 from
the start of the volumes data block. However, this sets a limit on the volume size
used. If you use a cluster size of 128 sectors, this still gives you a volume size
of 128 * 512 * 2^32 bytes, or a 256 terabyte volume. However, with drives starting
to exceed this size, and with smaller cluster sizes, you may want to have a volume
larger than this limit. To do so, simply place all FAT entries in a fat_continue
slot, set the large flag, and use 64-bit FAT entries. This has a max volume size
limit of 128 * 512 * 2^64, or 2^80, or a one yottabyte volume size. A yotta is a 1
with 24 digits after it, or a terabyte of terabytes.

The valid attributes of a file are:
#define FYSFAT_ATTR_ARCHIVE 0x00000001
#define FYSFAT_ATTR_SUB_DIR 0x00000002
#define FYSFAT_ATTR_VOLUME 0x00000004
#define FYSFAT_ATTR_SYSTEM 0x00000008
#define FYSFAT_ATTR_HIDDEN 0x00000010
#define FYSFAT_ATTR_READ_ONLY 0x00000020

Other bits in this field are reserved for future use. See further in this document
for use of the Volume attribute.

The created field contains the seconds since 00:00:00 1-1-1980 to the date this file
was created. The lastaccess field contains the seconds since 00:00:00 1-1-1980 when
the file was last read or written to. When a file is first created, these two fields
should be identical.

The scratch field may be used by the FS driver as a scratch byte, it should be
written to the disk as zeros, though it is not mandatory. However, due to multiple
hosts using this partition, this field, if read from the disk as non zero, should not
be assumed valid. FYSOS uses bit 0 in this field to indicate if this slot has been
modified before the commit to disk has taken place. The continue slots defined below
also have this field. This field must remain as byte 15 in all types of slots.

The valid flags of a file are:
Currently there are no flags specified. This field should contain 0x0000.

The crc field contains the 8-bit sum of all bytes in this 128-byte slot not counting
this field. This field can be left zero and no calculation will be made. When
adding, use 8-bit addition so that the carry is lost.
i.e.: 0x82 + 0x84 = 0x06. 0x10 + 0x12 = 0x22. 0xFF + 0x01 = 0x00.

The format of the name_continue and fat_continue slot is as follows:
struct S_FYSFS_CONT {
bit32u sig; // ‘NAME’ for name, ‘FAT ’ for FAT
bit32u previous; // pointer to the previous slot in this slot chain
bit32u continue; // next slot that continues the remainder (0 if none)
bit8u count; // length of name or FAT entries in *this* slot
bit8u flags; // see below
bit8u crc; // crc of this slot. 8-bit sum
bit8u scratch; // scratch byte
bit8u name_fat[112]; //
};

A definition of the fields:
sig set to ‘NAME’ (0x4E414D45) for a name_continue slot
set to ‘FAT ’ (0x46415420) for a fat_continue slot
previous points to the previous slot number in this slot chain.
next points to the next slot number in this slot chain.
zero if no more.
count is the amount of chars in this slot not counting the null char
or
is the count of FAT entries in this slot
flags name_continue:
this field is ignored and should be zero.
Fat_continue:
only bit 0 is used. Bits 7:1 should remain zero.
Bit 0: if not zero, the fat entries in this slot are 64-bit.
crc an 8-bit sum of all 128 bytes not counting this field.
scratch see the description above for this field.
name_fat contains the chars for the name, or
up to 28 32-bit or 14 64-bit FAT entries.

The last type of the four types of 128 byte slots is the empty slot. It simply
contains zeros in all fields if a truly empty slot or contains ‘DLTD’ (0x444C5444) in
the sig field denoting that this slot chain has been deleted. When deleting slot
chains, you must mark all slots in that slot chain with this id.

If the sig field contains anything other than these four types, it is considered a
used slot. With this version of the FS, this is a bad slot and will be deleted with
the next “Check Disk” or “Optimize” performed. Since a later version of this FS may
contain other valid slot sig values, you should not modify any slot that does not
have the four defined values above, or a value of zero. Typically, all empty slots
should have a value of zero in the sig field.

The following rules apply when deleting or adding slots to a slot chain:
- You may move the current FAT entries further down the slot to make room for a
longer name as long as there is room in this slot to do so. If there is not
room to move all FAT entries down, you can do one of two things:
- you can create a new slot for the remaining chars in the name
or
- you can “scroll” the existing FAT entries through to the next fat_continue
slot, creating a new slot if necessary.
- You may make room in this slot by moving all or some of the FAT entries to
another new (or occupied by this slot chain) slot. You may use multiple partial
slots, but this would fragment the slot chain and use unnecessary space.
Typically, you would never have more than two partial slots in each slot chain,
one partial for the name and one for the FAT. If the host operating system
supports the optional optimization of FYSFS systems, the user can optimize all
fragmented/partial slots to have at most two partials.
- A slot may not contain FAT entries that do not start directly on the next dword
aligned location after the filename.
- When the OS calls to rename the filename and the new name is shorter than the
current name, you must move the FAT entries in this slot to align after the new
shorter name. You can leave “blanks” at the end of the slot if so desired.
i.e.: you do not have to append the newly moved FAT entries with FAT entries from
an existing fat continue slot.
- The first slot in the slot chain is the only slot in this slot chain that can have
both name and FAT entries. Every other slot in the slot chain must contain a
valid NAME or FAT slot header and contain only that type of item.

When allocating a new slot for a new file, you must mark the sig entry as 0x534C4F54.
This denotes the first slot of this slot chain. When allocating a new slot to
continue the name and/or FAT, you must mark the sig entry as 0x4E414D45 for
continuing the name, and 0x46415420 for continuing the FAT.

Remember that the namelen field contains the length of the name in the current slot
only. Not the total length of the name used by the whole slot chain. Same goes for
the fat_entries field. It contains the count of fat entries in this slot only.

Please note that if you place the Bitmap(s) before the Data Area and don’t place them
on consecutive sectors, the sectors in-between will be lost and can not be accessed
by a typical FYSFS host driver. However, there is an advantage to leaving a few
sectors “behind”. This allows a host to use these sectors for encryption or any
other data storage desired. You should not, however, assume that these sectors would
remain untouched if a different Host were used on the volume. Only assume these
sectors would remain untouched if you can guarantee that you will be the only host
accessing this volume. Leaving a checksum and/or id field in your data would be
advised.

The Volume Attribute:
There should be only one slot in the complete volume that has its’ volume attribute
set, and this slot must be in the root directory and is advised to be in slot 0, the
first slot. A slot that has the volume attribute is simply a slot that uses the
name_fat field to denote the name of the volume. No FAT entries or fat continuations
are used. If the volume name is to exceed the space in the first slot, a
name_continuation slot may be used. Please note that this should be the only use of
this slot or slot chain and should not typically be listed in a directory listing.

Directories:
Please note that the first slot in any directory must be a starting slot, a sig value
of ‘SLOT’. This must be so, since zero is used to denote that there are no more
continue_slots in slot chain. When implementing this FS, a “find empty slot” routine
should ignore the first slot in the directory block when looking for an empty slot
when creating a continue_slot for a slot chain.

FYSFS directories are implemented similar to the FAT12/16 FS. A directory entry
(slot) simply points to a data block containing another set of directory entries
(slots). A sub-directory can grow just like a file does. It is up to the host to
decide on how many clusters to allocation on sub-directory creation, however at least
one (1) must be allocated at creation time. When the host requests a new slot to be
created in this sub-directory and there is no more room, at least one more cluster
can be allocated and added to the fat entry list of the parent’s slot. In other
words, the sub-directory can grow to use as much of the volume as desired (see note
below).

When a sub-directory is created, the first two slots must be filled with two
directory entries. The first must have a name of “.” (a single period) and have a
starting cluster number of the current directory. The second entry must have a name
of “..” (two periods) and have a starting cluster number of the parent directory, or
zero if the parent is the root. The fat_entries field must contain a 1 for each
entry, but no clusters should be allocated. The second entry must contain a slot
entry that has the slot number of the parent’s directory entry in the parent’s
directory block. The root directory does not contain these two slot entries.

These two entries must be the first two entries of the sub-directory and can not be
renamed or moved.

Please note about the size of a sub directory. Since the slot continue and slot next
entries, along with the corresponding slot entries in the parent slot, a sub
directory can not grow beyond 2^32 * slot_length and can only have 2^32 slots.
However, this allows a sub directory to occupy one gigabyte of the drive, and have
four billion directory entries, with the exception of the root directory which as a
limit of 2^16 * slot_length and 2^16 slots. Please note that this limit is only the
limit for the slots, not the files themselves.

The Root Directory may grow as long as it does not exceed the limit above *and* it
uses consecutive clusters. To grow the root directory, you may use unused
consecutive clusters at the end of the current root directory or you may copy the
current root directory to another location in the volume, then marking the old
location and free. You may also move clusters at the end of the root directory to
other locations updating the corresponding slot chains to make room for a larger root
directory. If you move the root directory to a larger consecutive block of clusters,
do remember to update the super block on the volume.

Notes on optimizing/defragmenting the volume.
A typical optimized volume would have as much of the name in the first slot (‘SLOT’)
as possible, with any needed name_continue slots (‘NAME’) following this slot, and
with any fat_continue slots (‘FAT ’) following the name_continue slots. Since a
decent host, on opening the file, will load and cache the whole FAT chain in memory,
the FAT chain will be read and then written only once per opening/closing of the
file, file sharing aside. However, the name of the file may be needed multiple times
when looking for filenames, due to many find_first/find_next function calls.

Defragmentation of the volume is typical of most volume types. Simply place all file
clusters in consecutive placement on the volume.

Here are a few examples of a typical FYSFS root directory.

First is an example of a slot that needs no continuation.
i.e.: The name and the FAT entries fit in this slot.

slot 0: (128 bytes)
00000000 54 4F 4C 53 01 00 00 00-00 00 00 00 00 00 01 00 TOLS............
00000010 78 56 34 12 12 34 56 78-EF CD AB 89 67 45 34 12 ................
00000020 00 00 00 00 00 00 00 00-00 00 11 00 00 00 00 00 ................
00000030 52 65 61 64 20 6D 65 20-66 69 72 73 74 2E 74 78 Read.me.first.tx
00000040 74 00 00 00 55 AA 55 AA-00 00 00 00 00 00 00 00 t...U.U.........
00000050 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00000060 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00000070 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

offset contents description
00000000 0x534C4F54 the New Slot id: ‘SLOT’
00000004 0x00000001 attribute of the file: FYSFAT_ATTR_ARCHIVE
00000008 0x000000000000 reserved
0000000E 0x01 number of 32-bit FAT entries in this slot
0000000F 0x00 scratch
00000010 0x12345678 file creation date: seconds since 00:00 1-1-80
00000014 0x78563412 file last closed date: seconds since 00:00 1-1-80
00000018 0x0123456789ABCDEF File size
00000020 0x00000000 FAT continue slot. 0 = no continue
00000024 0x00000000 Name continue slot. 0 = no continue
00000028 0x0000 File flags: none
0000002A 0x11 Name length: Length in chars of the file name in this slot.
0000002B 0x00 crc of file. 0x00 = not used.
0000002C 0x00000000 slot number. Used in child directories.
00000030 name The filename starts here. It does not have to end in null
unless we need padding to next dword aligned position.
00000044 0xAA55AA55 The first FAT entry. This is the cluster number of the
starting cluster of the file.
remaining bytes are zeros since there is not enough name chars and/or fat entries to
fill the slot.

Second is an example of a slot that needs name continuation due to a renaming of the
filename to a length that no longer fits in the slot. This example chose to select a
new slot for the continuation of the name instead of “scrolling” the FAT entries
through to the next slot or to a new slot.

slot 0: (128 bytes)
00000000 54 4F 4C 53 01 00 00 00-00 00 00 00 00 00 0E 00 TOLS............
00000010 78 56 34 12 12 34 56 78-EF CD AB 89 67 45 23 01 ................
00000020 00 00 00 00 01 00 00 00-00 00 18 00 00 00 00 00 ................
00000030 54 68 69 73 20 69 73 20-61 20 76 65 72 79 20 6C This.is.a.very.l
00000040 61 72 67 65 20 66 69 6C-55 AA 55 AA 55 AA 55 AB arge.filU.U.U.U.
00000050 55 AA 55 AC 55 AA 55 AD-55 AA 55 AE 55 AA 55 AF U.U.U.U.U.U.U.U.
00000060 55 AA 55 B0 55 AA 55 B1-55 AA 55 B2 55 AA 55 B3 U.U.U.U.U.U.U.U.
00000070 55 AA 55 B4 55 AA 55 B5-55 AA 55 B6 55 AA 55 B7 U.U.U.U.U.U.U.U.

00000010 0x12345678 file creation date: seconds since 00:00 1-1-80
00000014 0x78563412 file last closed date: seconds since 00:00 1-1-80
00000018 0x0123456789ABCDEF File size
00000020 0x00000000 FAT continue slot. If 0 = no continue
00000024 0x00000001 Name continue slot. If 0 = no continue
00000028 0x0000 File flags: none
0000002A 0x18 Name length: Length in chars of the file name in this slot.
0000002B 0x00 crc of file. 0x00 = not used.
0000002C 0x00000000 slot number. Used in child directories.
00000030 name The filename starts here. It occupies 24 bytes.
00000048 FAT The FAT Entries occupy the remainder of the slot.

slot 1: (128 bytes)
00000000 45 4D 41 4E 00 00 00 00-00 00 00 00 09 00 00 00 EMAN............
00000010 65 6E 61 6D 65 2E 74 78-74 00 00 00 00 00 00 00 ename.txt.......
00000020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00000040 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00000050 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00000060 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00000070 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

offset contents description
00000000 0x4E414D45 the Continue Name id: ‘NAME’
00000004 0x00000000 The previous slot number (parent)
00000008 0x00000000 The next slot number (0 = not used)
0000000C 0x09 number of chars in this slot
0000000D 0x00 crc
0000000E 0x00 flags
0000000F 0x00 scratch
00000010 continuation of the filename

An example of a FAT continuation slot chain would be identical to the above, except
that a few of the id’s would be changed, and slot 1 would contain FAT entries. The
only difference in slot 0, other than the name modification (for example purposes),
is the two continuation fields. The name_continue field is now zero, and the
fat_continue field is now one. No other field was changed.

slot 0: (128 bytes)
00000000 54 4F 4C 53 01 00 00 00-00 00 00 00 00 00 0E 00 TOLS............
00000010 78 56 34 12 12 34 56 78-EF CD AB 89 67 45 23 01 ................
00000020 01 00 00 00 00 00 00 00-00 00 18 00 00 00 00 00 ................
00000030 54 68 69 73 20 69 73 20-61 20 76 65 72 79 20 6C This.is.a.very.l
00000040 61 72 67 65 20 66 69 6C-55 AA 55 AA 55 AA 55 AB arge.filU.U.U.U.
00000050 55 AA 55 AC 55 AA 55 AD-55 AA 55 AE 55 AA 55 AF U.U.U.U.U.U.U.U.
00000060 55 AA 55 B0 55 AA 55 B1-55 AA 55 B2 55 AA 55 B3 U.U.U.U.U.U.U.U.
00000070 55 AA 55 B4 55 AA 55 B5-55 AA 55 B6 55 AA 55 B7 U.U.U.U.U.U.U.U.

offset contents description
00000000 0x534C4F54 the New Slot id: ‘SLOT’
00000004 0x00000001 attribute of the file: FYSFAT_ATTR_ARCHIVE
00000008 0x000000000000 reserved
0000000E 0x0E number of 32-bit FAT entries in this slot
0000000F 0x00 scratch
00000008 0x12345678 file creation date: seconds since 00:00 1-1-80
0000000C 0x78563412 file last closed date: seconds since 00:00 1-1-80
00000010 0x0123456789ABCDEF File size
0000001C 0x00000001 FAT continue slot. 0 = no continue
00000020 0x00000000 Name continue slot. 0 = no continue
00000024 0x0000 File flags: none
00000026 0x18 Name length: Length in chars of the file name in this slot.
00000027 0x00 crc of file. 0x00 = not used.
00000028 0x00000000 slot number. Used in child directories.
00000030 name The filename starts here. It occupies 24 bytes.
00000048 FAT The FAT Entries occupy the remainder of the slot.

slot 1: (128 bytes)
00000000 20 54 41 46 00 00 00 00-00 00 00 00 03 00 00 00 .TAF............
00000010 55 AA 55 B3 55 AA 55 B4-55 AA 55 B5 00 00 00 00 U.U.U.U.U.U.....
00000020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00000040 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00000050 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00000060 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00000070 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

offset contents description
00000000 0x46415420 the Continue Name id: ‘FAT ’
00000004 0x00000000 The previous slot number (parent)
00000008 0x00000000 The next slot number (0 = not used)
0000000C 0x03 number of FATS in this slot
0000000D 0x00 crc
0000000E 0x00 bit 0: 32-bit or 64-bit entries?
0000000F 0x00 scratch
00000010 continuation of the FAT entries

16 June 2008
- Minor grammar changes and additions.
- A few more details
- Increased sectors per cluster limit to 512

15 June 2008
- Changed the sectors field in the BPB to reserved.

14 June 2008
- Moved the crc fields in the slots to byte 14, so that they will be in the same
place in all types of slots.

7 June 2008
- Added the case sensitive information.
- moved the scratch byte in the SLOT’s to be the same position no matter the slot
type. This way it doesn’t matter the slot type, one can read/write the scratch
register at will. Makes it much better for the “dirty” flag. Unfortunately this
breaks any existing images. But, as far as I know, I am the only one using this
FS anyway. (smile)

5 June 2008
- Added the scratch field to the slot(s) structure.
- Specified that the BPB->Serial number should be a 32-bit value of seconds since
00:00:00am on 1 Jan 1980.
- just a few small typo’s, grammar issues.

7 Oct 2006
- made S_FYSFS_BPB.base_lba 64-bit, and made .resv1 a byte instead of 5 bytes.

1 Oct 2006
- removed five of the six reserved dwords in the Root Slot field. This
gives room for 20 more chars in the name, or 5 more fat entries in the
first slot
*Unfortunately* this will break any previous versions of this spec. Please
rebuild your images. If absolutely needed, I could write a small app to
modify the slots to adjust for this. Let me know.
- changed the large field in the continuation slot to use bit 0 instead of
the whole byte.
- the root_entrys field in the bpb now allows 128 entires as the minimum.
- the bpb.drivenum member needs to be set to the DL value given by the BIOS
- added information about the Volume attribute usage.
- other modifications to the text for clarity and detail.

8 April 2006
- removed “descriptor” from the BPB and combined the reserved fields.
However, this did not move or change the structure of the BPB.
- added details on optimizing/defragmenting the volume.

7 April 2006
- Added more details and cleared up a few description to the specs.
- No format changes were made to the specs.

19 June 2005
- Moved the bitmaps field from the BPB to the SuperBlock
- Added the data_sectors field in the SuperBlock
- Changed the size of the bitmap flags
- Added a few small details

24 June 2005
- Added the copy_valid member in the BPB and a little more
info about the validity of this copy.

25 Sept 2005
- Added a few comments to the documentation. No actual format
of the file system was modified.

27 Sept 2005
- Added documentation about directory’s and modified a member of
the Root Directory slot structure.

9 Oct 2005
- changed the size of some of the entries in the super to 64-bit entries.
- added a field in a fat continue slot to denote whether the FAT entries are
32-bit or 64-bit.