July 27th, 2024

Lessons from Ancient File Systems

The article examines the evolution of Atari 8-bit file systems, focusing on Atari DOS versions, their limitations, and the emergence of alternatives like MyDOS and SpartaDOS, emphasizing the need for future-oriented design.

Read original articleLink Icon
Lessons from Ancient File Systems

The article discusses the evolution of various Atari 8-bit file systems, particularly focusing on the design decisions and limitations of different versions of Atari DOS. It begins with Atari DOS 1.0, introduced in 1979, which supported single-sided, single-density disks. Subsequent versions, such as DOS 2.0s and DOS 2.5, aimed to address bugs and improve functionality, including the introduction of features like sector chaining for file navigation. The author highlights the challenges faced by early DOS versions, such as the lack of support for zero-length files and the absence of timestamps, which were not prioritized due to hardware limitations.

The article also critiques Atari's failure to anticipate future needs, particularly with DOS 3, which did not accommodate emerging disk technologies. In contrast, MyDOS and SpartaDOS emerged as successful alternatives, offering greater scalability and support for larger drives. The author emphasizes the importance of designing software with future requirements in mind, suggesting that flexibility and foresight in engineering can lead to long-lasting solutions. The discussion serves as a reminder of the lessons learned from past file system designs, advocating for a proactive approach to software development that considers potential advancements and user needs.

Related

Creating New Installation Media for MS-DOS 4.0

Creating New Installation Media for MS-DOS 4.0

Microsoft released MS-DOS 4.00 source code in 2024, prompting the community to develop MS-DOS 4.01 due to missing official media. Challenges arose in recreating installation media, including creating stub executables and addressing missing files. Installation from floppies had mixed results, with various disk downloads provided for users. Feedback is welcomed on fabulous.community.

Programming Like It's 1977

Programming Like It's 1977

The article explores programming games on the Atari VCS, a pioneering hardware platform from the 1970s with constraints that inspired creativity. Coding in 6502 assembly language offers a retro experience. The Atari 2600+ release supports old hardware for modern gaming. Learning on the Atari VCS reveals early programmers' challenges and solutions, fostering creativity.

30 years later, FreeDOS is still keeping the dream of the command prompt alive

30 years later, FreeDOS is still keeping the dream of the command prompt alive

FreeDOS, a 30-year-old public domain DOS version, persists for legacy applications on modern systems. Creator Jim Hall notes sustained interest despite uncertain future, emphasizing its significance in MS-DOS-compatible systems.

A blast from the past: Disassembling DOS (2020)

A blast from the past: Disassembling DOS (2020)

The text explores disassembling MS-DOS, focusing on INT 21h functions and dissecting files like IO.SYS. It discusses reverse engineering, legal aspects, and the microkernel nature of DOS for deeper insights.

A look into Xenix, Microsoft's long forgotten Unix Operating System [video]

A look into Xenix, Microsoft's long forgotten Unix Operating System [video]

The video compares MS-DOS 2.0 and Xenix, highlighting disk space and hard drive requirements. The creator shares their experience installing SCO Xenix via floppy disks, setting up dual-boot on an old hard drive, and loading Xenix despite challenges. It also touches on limited OS choices in the 80s and Microsoft's link to Xenix, with plans to explore SCO vs. Microsoft Xenix differences.

Link Icon 5 comments
By @skissane - 6 months
> Instead, it was to support "note" and "point" commands. Atari believed people would use files as a database, and with the sector chaining, it was impossible to jump around in a file without reading it linearly. So a program could "note" its position in a file (sector and offset) and then return there later with the point command. This is where verifying that the file number in the user-supplied sector number matched the entry used when opening the file came in. Without that number, there would be no verification that a "point" would end up in the right file.

Interesting to hear this terminology used in the context of 8-bit Atari computers. The terms NOTE and POINT come from IBM mainframes, where there are OS/360 macros by those names. NOTE essentially does an fgetpos and POINT an fsetpos

By @mrandish - 6 months
Brings back fond memories of the Amiga DOS floppy disk structure which had some clever things I hadn't seen before (coming from 8-bit ROM-based floppy disk OSes). Such as having each file sector link to the next so if the file allocation table got corrupted, the files on the disk could be recovered by a utility that crawled every sector and rebuilt a new file allocation table.

IIRC, it also would occasionally write a backup copy of the file allocation table on another normally unused track as well as parking the disk head away from the track where the directory was after some default period of inactivity. Floppy drives were notorious for occasionally crashing the heads into whatever track they happen to be over if there was a power glitch or software crash - and of course, statistically, they spent most of their time over the directory track, thus greatly increasing to odds of blasting part of the file allocation table.

When I moved to PCs I remember being surprised that NTFS didn't seem to do any of this (at least early on) despite being more recent and supposedly advanced.

By @bediger4000 - 6 months
This is the type of analysis I always hope for about file systems, but almost never see. Looks like some of these file systems had linked list files, which is an interesting contrast to inode based file systems like the original UFS, or BSD FFS.
By @kristopolous - 6 months
How are the design intentionalities determined? Are they documented somewhere? I'm not disputing anything, I just want to know the provenance in case there's some really great book or code I should be reading.
By @jftuga - 6 months
Conclusion: "So the big lesson here is to always plan for the future. Listen to the requirements for the current product, but then design with the assumption that you'll be asked to expand the requirements in the future. If you don't, users may be cursing you when the code is released. But who knows? If you do it right, people may still be using your code in 40 years."