5 ms·

What surprised me is that Commodore 64 had really "fragmentable" filesystem > Every file is stored as a linked list. Every block holds the track/sector tuple o

by ungzd 8y ago

What surprised me is that Commodore 64 had really "fragmentable" filesystem > Every file is stored as a linked list. Every block holds the track/sector tuple of the next block in its first two bytes, followed by 254 data bytes. On ZX Spectrum, TR-DOS, one of available disk OSes, didn't support file fragmentation at all: files occupied consecutive sectors, and new files could be written only to free space at the end of floppy. Once file is deleted, it continued to occupy space. Instead of defragmentation, there was "MOVE" command that packed files together by moving towards start of the disk to fill freed space. https://www.worldofspectrum.org/pub/sinclair/hardware-info/Beta128DiskInterface_Manual.txt https://www.worldofspectrum.org/pub/sinclair/hardware-info/B... (section 9.3) (I don't know, however, how ZX Spectrum +3 filesystem works (another disk system for ZX Spectrum) (http://www.worldofspectrum.org/ZXSpectrum128+3Manual/ http://www.worldofspectrum.org/ZXSpectrum128+3Manual/)

tom_ 8y ago
It surprised me too, especially as it means you now have a rather inconvenient 254 data bytes per sector. (The BBC Micro's ordinary disc filing system also stored contiguous files. I'd always assumed that this would be pretty standard for 8-bit systems... it simplifies reading and writing of files, and reduces the amount of metadata that needs storing.)
- nineteen999 8y ago
  CP/M, without a doubt the most popular OS for Z80 based systems with disk drives, and the main inspiration for MS-DOS, was an exception: "Files in CP/M can be thought of as a sequence of up to 65536 records of 128 bytes each, numbered from 0 through 65535, thus allowing a maximum of 8 megabytes per file. Note, however, that although the records may be considered logically contiguous, they may not be physically contiguous in the disk data area. Internally, all files are divided into 16K byte segments called logical extents, so that counters are easily maintained as 8-bit values. The division into extents is discussed in the paragraphs that follow: however, they are not particularly significant for the programmer, because each extent is automatically accessed in both sequential and random access modes". (http://www.gaby.de/cpm/manuals/archive/cpm22htm/ch5.htm http://www.gaby.de/cpm/manuals/archive/cpm22htm/ch5.htm)
- jhallenworld 8y ago
  Here are some other formats: CP/M: extent map made up of directory entries. The file size is in units of sectors, but text files end with ^Z. Ctrl-M Ctrl-J is end of line. TRSDOS (TRS-80), also used extents. This whole extent concept came from DOS/360 from IBM mainframes. Apple DOS: directory entry points to a linked-list of indirection sectors which hold pointers to the sectors that make up the file. The size of a file is in units of sectors, except that for text files, the end of the file is indicated with NUL. Ctrl-M is end of line. Atari DOS: just like the C64- a linked list of sectors, but with 3 bytes of overhead per 128 byte sector (the extra byte contains the number of valid data bytes in the sector). The file size is in units of bytes due to this. End of line for text files is 0x9b. (ESC with 7th bit set). MS-DOS: files are made of a linked-list of clusters, but the linked list for all the files are stored in one place- the FAT (nicely eliminating the need for a free-space bitmap). But if you overwrite the FAT, you lose everything! Early version of UNIX (SCO Xenix) didn't use a bitmap for the free blocks, instead it kept them a linked list. This was a really bad idea, files instantly became fragmented.

by ungzd 8y ago

tom_ 8y ago

It surprised me too, especially as it means you now have a rather inconvenient 254 data bytes per sector. (The BBC Micro's ordinary disc filing system also stored contiguous files. I'd always assumed that this would be pretty standard for 8-bit systems... it simplifies reading and writing of files, and reduces the amount of metadata that needs storing.)

nineteen999 8y ago
CP/M, without a doubt the most popular OS for Z80 based systems with disk drives, and the main inspiration for MS-DOS, was an exception: "Files in CP/M can be thought of as a sequence of up to 65536 records of 128 bytes each, numbered from 0 through 65535, thus allowing a maximum of 8 megabytes per file. Note, however, that although the records may be considered logically contiguous, they may not be physically contiguous in the disk data area. Internally, all files are divided into 16K byte segments called logical extents, so that counters are easily maintained as 8-bit values. The division into extents is discussed in the paragraphs that follow: however, they are not particularly significant for the programmer, because each extent is automatically accessed in both sequential and random access modes". (http://www.gaby.de/cpm/manuals/archive/cpm22htm/ch5.htm http://www.gaby.de/cpm/manuals/archive/cpm22htm/ch5.htm)
jhallenworld 8y ago
Here are some other formats: CP/M: extent map made up of directory entries. The file size is in units of sectors, but text files end with ^Z. Ctrl-M Ctrl-J is end of line. TRSDOS (TRS-80), also used extents. This whole extent concept came from DOS/360 from IBM mainframes. Apple DOS: directory entry points to a linked-list of indirection sectors which hold pointers to the sectors that make up the file. The size of a file is in units of sectors, except that for text files, the end of the file is indicated with NUL. Ctrl-M is end of line. Atari DOS: just like the C64- a linked list of sectors, but with 3 bytes of overhead per 128 byte sector (the extra byte contains the number of valid data bytes in the sector). The file size is in units of bytes due to this. End of line for text files is 0x9b. (ESC with 7th bit set). MS-DOS: files are made of a linked-list of clusters, but the linked list for all the files are stored in one place- the FAT (nicely eliminating the need for a free-space bitmap). But if you overwrite the FAT, you lose everything! Early version of UNIX (SCO Xenix) didn't use a bitmap for the free blocks, instead it kept them a linked list. This was a really bad idea, files instantly became fragmented.