Atari File Management Subsystem

From Just Solve the File Format Problem
(Difference between revisions)
Jump to: navigation, search
(See also)
Line 3: Line 3:
 
|subcat=Filesystem
 
|subcat=Filesystem
 
}}
 
}}
 
+
The '''[[Atari File Management Subsystem]]''' (FMS) is the filesystem on an [[Atari 810]] floppy disk.
The '''Atari File Management Subsystem''' (FMS) is the filesystem on an [[Atari 810]] floppy disk.
+
  
 
The 720 sectors of the disk were numbered from 1 to 720, but (perhaps due to poor communication between the different development teams at Atari) the FMS filesystem was designed to support sector addresses in the range from 0 to 719, which meant that sector 720 was not addressable but a nonexistent sector 0 was. This resulted in the filesystem only using the 719 sectors in the overlap between what is addressable and what actually exists, so sector 720 is unused (a waste of a perfectly good 128 bytes).
 
The 720 sectors of the disk were numbered from 1 to 720, but (perhaps due to poor communication between the different development teams at Atari) the FMS filesystem was designed to support sector addresses in the range from 0 to 719, which meant that sector 720 was not addressable but a nonexistent sector 0 was. This resulted in the filesystem only using the 719 sectors in the overlap between what is addressable and what actually exists, so sector 720 is unused (a waste of a perfectly good 128 bytes).

Revision as of 21:30, 29 December 2013

File Format
Name Atari File Management Subsystem
Ontology

The Atari File Management Subsystem (FMS) is the filesystem on an Atari 810 floppy disk.

The 720 sectors of the disk were numbered from 1 to 720, but (perhaps due to poor communication between the different development teams at Atari) the FMS filesystem was designed to support sector addresses in the range from 0 to 719, which meant that sector 720 was not addressable but a nonexistent sector 0 was. This resulted in the filesystem only using the 719 sectors in the overlap between what is addressable and what actually exists, so sector 720 is unused (a waste of a perfectly good 128 bytes).

(Note to self: Is there a way to hack the system to stick hidden messages in that 720th sector?)

The bytes within a sector are numbered from 0 to 127, because at least the development teams managed to agree on zero-based numbering there.

Multi-byte numbers in these formats are little-endian (except for a special case noted below).

Contents

Sector map

This filesystem is pretty narrowly tailored to the particular type of disk used by the Atari 810 drive, with various hard-coded sector positions.

  • Sector 1: Boot record
  • Sector 2-n: DOS.SYS file (on system disks)
  • Sector n+1-359: User file space
  • Sector 360: VTOC (Volume Table of Contents)
  • Sector 361-368: Directory
  • Sector 369-719: User file space
  • Sector 720: Unused

Boot record

Sector 1 is the boot record. It has this structure:

  • Byte 0: 0 (representing boot flag)
  • Byte 1: 1 (representing the number of sectors the boot record takes)
  • Byte 2-3: Boot address (0700)
  • Byte 4-5: Init address
  • Byte 6: 4B (JMP command used with address in following 2 bytes)
  • Byte 7-8: Boot read continuation address
  • Byte 9: Max # of files open concurrently (1-8)
  • Byte 10: Specific drive numbers supported (bitmap where low-order bit means drive 1, next bit drive 2, and so on up to 4)
  • Byte 11: Buffer allocation direction (set to 0)
  • Byte 12-13: Boot image end address + 1
  • Byte 14: Boot flag (must be nonzero if DOS.SYS is on disk)
  • Byte 15: Sector count (not used)
  • Byte 16-17: DOS.SYS starting sector number
  • Byte 18-127: Code for second phase of boot

Volume table of contents (VTOC)

Sector 360 is the VTOC. It has this structure:

  • Byte 0: Directory type (always 0)
  • Byte 1-2: Maximum sector number (always 02C5, which is incorrect given that this equals 709 and the actual maximum sector number used by the FMS is 719. Due to this error, this value is ignored.)
  • Byte 3-4: Number of sectors available (starts at 709 and changes as sectors are allocated or deallocated)
  • Byte 10-99: Bitmap showing allocation of sectors. The high-order bit of byte 10 corresponds to (the nonexistent) sector 0 (so it is unused), the next-lower bit corresponds to sector 1, and so on through sector 7 for the low-order bit of byte 10, then sector 8 for the high-order bit of byte 11, and so on. These are set to 1 if the sector is available, and 0 if it is in use.

File directory

Sectors 361-368 comprise the directory, with 8 file entries in each sector, making a maximum of 64 files on the disk. Each file entry has this structure:

  • Byte 0: Flag byte (High bit [bit 7] set if file deleted. Bit 6 set if file in use. Bit 5 set if file locked. Bit 0 set if file open for output.)
  • Byte 1-2: Sector count (number of sectors in file)
  • Byte 3-4: Starting sector number
  • Byte 5-12: Filename (8 characters)
  • Byte 13-15: File extension (3 characters)

Filenames are similar to MS-DOS and CP/M in that they consist of (up to) 8 characters in the main filename plus an extension of up to 3 characters.

Data sector

A sector within a file has its first 125 bytes (0-124) used for raw data.

Bytes 125-126 contain the number of the next sector in the file, or 0 if this is the last sector, but since not all 16 bits are needed for sector numbers, this is combined with 6 bits of file integrity check information (the highest 6 bits of byte 125); this equals the value of the position number of the file in the directory. If this doesn't match the actual position, error A4 is generated. The remaining 2 bits of that byte are used as the high bits in the sector number, combined with the 8 bits of byte 126 (which makes this quantity big-endian for a change).

Byte 127 uses its high bit to indicate a "short sector" (one not entirely filled with data), setting it to 1 if it is such a sector. The remaining bits indicate the number of data bytes stored in this sector.

See also

Links

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox