The DOS 2.0/2.5 Filesystem in a nutshell

Entry posted by Atari_Ace July 27, 2018

499 views

I started this blog by fixing up a relatively obscure Atari title (The ABC of CPR). I could fix it because there were several different archives containing purportedly the same data, and since the most common problem with old disks is a bad sector which translates to an empty/dropped sector in an ATR archive, we could see the blank sectors and conclude fixes were needed.

So how do we find some (ideally all) disks with dropped sectors in a large archive. Well, it falls out of trying to build a comprehensive directory of all the files on those disk images.

The most common disk format for the Atari is the one used by DOS 2/2.5. It places its metadata in sectors 360-368 on the disk, plus sector 1024 in the case of enhanced density disks. For single density disks, sector 360 starts with the DOS code in the first byte (the value 2 in both cases), the amount of data sectors on the disk (usually 707), and then the amount of free sectors. Starting at offset 10 is the VTOC, 720 bits of data where each bit represent whether a sector is free (1) or used (0). Sector 361-368 then follows with individual directory entries, 16 bytes per entry. The first byte is the status byte, the next two bytes the sector count, then two bytes for the first sector of the file, with the remaining 11 bytes used for the filename.

So to find the contents of a file, you read from the directory entry the sector count and first sector, then read the first sector and decrement the sector count. That (and all subsequent sectors) contains 125 bytes of data, followed by 3 bytes (24 bits) containing the file entry number (the first 6 bits), the next sector number (the next 10 bits), and then finally the data byte count for that sector (the last 8 bits). If the sector count is non-zero, the byte count should be 125, and all 125 bytes of data belongs to the file. If the sector count is zero, the next sector field should be zero, and the byte count could be smaller than 125.

Given that description, detecting a dropped sector usually happens as a side-effect. As you walk all the sectors in a file, if one of them is empty, the next sector will be zero but the sector count will likely still be non-zero. If you're on the last sector, the byte count should be non-zero (otherwise you would have ended the file in the previous sector).

If you think about this design, you realize it's awful for random access to the data, but it's great for quickly detecting integrity issues. The more common FAT (file allocation table) design doesn't mix the file metadata with the file data, so if some of the data in the file is zeroed, the file maintains integrity and you might not realize the file is damaged. With the DOS design, the attempt to load the file itself will fail.

So one algorithm for finding damaged single density disks is to examine the first five bytes of sector 360, and if it starts with 2, 707, and a number less than 707, assume it's a DOS 2.0/2.5 disk and walk the directory entries validating that the length of the chain of sectors matches the sector count in the directory.

I've written (in Perl of course) that algorithm (actually a slightly more permissive version) and started applying it to various archives to spot damaged disks that need repairs. So we'll pick up the discussion next time with the results on a large collection of disks, specifically the Bellcom public domain archive.