Sectors and Tracks and Bytes (Oh my!)

This is an overly-simplified but still pretty technical explanation about how (I'm pretty sure, at least -- correct me if I made any mistakes) floppy disks and disk drives work, using an extremely early computer as an example. If this is all too technical for you, don't worry; it's some really close-to-the-metal stuff, and you don't have to know it to enjoy Sector Disk.

If you want to learn more, though, about computers and data close to the metal, I highly recommend checking out Ben Eater's videos on YouTube. Also, The 8-Bit Guy probably gives a better explanation of this than I do, so I recommend watching his video on the topic, but perhaps someone will find this valuable, so I'll try my best.

Floppy disks (and basically all vintage storage mediums) have more bytes on them than 8-bit and 16-bit computers could reasonably address in just one or two bytes. An 8" Altair Disk had 330K worth of data on every disk, but the Altair 8800, being an 8-bit machine at heart with a 16-bit address bus, could only address 64K of memory (RAM or ROM) at once, and could only read or write a value between 0 and 255 (8-bits of data) to/from a device (like a floppy disk controller) at once. To read a value from RAM or ROM into the CPU's internal memory (registers), the Altair simply sets the 16-bits on the address bus to whatever address (0-65535) it wants to read and, at the same time, sends out a 'read' signal, and the RAM and ROM chips send 8-bits of data back out on the data bus. The Altair gives a 16-bit word, it gets back an 8-bit word (a byte). It's one for one, for the most part (I did say I was over-simplifying).

This works fine for on-board memory, and 64K of RAM was a whole lot for any home user at the time (and was much more than many people who actually owned an Altair would have had), but it's no good at all for a (literally) giant storage medium like an 8" disk with 330K to write to and read from. After all, since you'd have to talk to the floppy disk controller first, you'd be limited to 8 bits of bus-space to communicate, and you'd have to send it all kinds of information just to read and write a single byte from the disk! You'd need, at minimum, 3 bits (out of one byte) to tell it a) whether to read to or write from the disk and b) which disk drive (0-3) to use, and then 19 more bits for a large enough address to support 330K. Even shrunk down, that's 3 bytes (with two bits to spare) just to read a SINGLE byte of data from the disk! The disk controller would then have to translate that into some sort of position where that bit might be on the drive, which would add delay, and then would have to do that for every single byte requested, so even with a blazing fast 2MHz CPU and 360RPM floppy disk drive, that's just maddeningly slow. It would just be a tremendously terrible idea. (It might be worth nothing that, again, this is dramatically over-simplified. The CPU requires several instructions to get the ready status of the disk drive, wait if it's not ready, and then read the byte into the appropriate location in memory. Either way it would be dramatically slower if we were simply telling the drive "I want this byte, this byte, that byte" one by one rather than in a batch (keep reading)).

Instead, it's smarter to think about how the drive might find the data to begin with. After all, there's a magnetic head that has to move in one axis, back and forth, to certain positions where the data might be. The disk then spins underneath the head, meaning for whatever position the head could be at in one plane, it could read/write a circular track around the circumference of wherever the head is positioned (and is therefore called a "track"). Each track can hold a certain amount of data, but since tracks towards the inside of the disk would have less distance (and therefore less data capacity) than those toward the outside of the disk, we can do something smart and divide each track into sectors, where each sector holds the same amount of data as any other sector. For the sake of simplicity, each track should also contain the same amount of sectors (note that not every disk format did this). This does mean that, in general, the disk isn't storing the maximum data it possibly could per track on the outer tracks, but either way, at 330K storage for a literal plastic envelope, it didn't matter, and you had an easier disk format to work with.

On the Altair 8" disks, there were 77 tracks, each with 32 sectors, with each sector containing 137 bytes. With all that in mind, it'd be MUCH easier to tell the floppy controller a disk drive (0-3, 2 bits), a track number (0-76, 7 bits), and a sector number (0-31, 5 bits), and whether to read or write (we could say 1 bit). Of course, this isn't exactly how it would work in real life. You'd instead tell the floppy disk controller you want to set the track, and what track you want. Then you'd tell it to set the sector and what sector you want. Then you wait until the drive is ready and in-position, and you tell the CPU to read in data from or write out data to the drive. You'd have a counter for the number of bytes you're reading (137), and decrement it with every byte you read in until it reaches zero (0) and you know you're done with the sector. Of course this isn't even CONSIDERING file system information nor any of that other higher-level software junk. This is just a basic example of how it might communicate with the floppy disk controller and ultimately send/receive data to/from the disk. For an 8" floppy on an Altair 8800, it actually reads in about 2 bytes per every 107 cycles (53.5 microseconds).

"But if we're only reading two bytes at a time with all those other instructions, isn't that just about as bad as only reading 1 byte at a time?" I hear you cry, and perhaps that's due to my trying to simplify and the fact that this is the first time I'm trying to explain how this works, in theory and in reality. Basically, absolutely not. In the first example, the Altair expends a whole lot of data and instructions just to get a single byte, and the theoretical drive controller would still have to figure out where the byte the Altair is trying to address physically is (because data storage is physical after all; all those bytes exist in real-world space, just with wibbly-wobbly magnetic flux). After it does that, it does it all over again for every single byte. It would be like if instead of simply readying yourself some chopsticks and eating from a bowl of rice one chopstick-full at a time, you were to pick up your chopsticks, pick up a single grain of rice, eat it, put down your chopsticks, and repeat the process over and over again until it was done. It would take significantly more time and effort than simply starting and eating until you're done, and then moving on to another bowl if you're still hungry.

I'm not sure if that was helpful at all (if at all), or if all of it is quite right, but I hope perhaps it was enjoyable for some of you! (Please do let me know if you found it useful or if you hated it and think I should go find another thing to spend my time on lol).

From the time of the 8" 330K floppy for the Altair 8800 to the 3.5" 1.44MB diskette that's at the core of sector disk, a lot of improvements in data density and storage capacity were made. The 3.5" 2HD/DSHD (double-sided, high-density) format disk first came out in 1986, just twelve years after the release of the Altair 8800. The format has two sides, each with 80 tracks, each with 18 sectors per track, each with 512 bytes per sector, making for a total of 1.44MB*, or 1440KiB, or 1474560 bytes per disk. This is the beautifully engineered heart of Sector Disk, and I hope that you can enjoy it even more so knowing what it is up close.

Read more: Double Sided Disks and Cylinders

*1.44MB is a LIE! (bits, bytes, and bibytes)

This turned out longer than I expected.

Actually, you've been lied to. A 2HD floppy disk does not have 1.44 megabytes of storage, any way you look at it. Instead, it has 1.44 * 1000 kibibytes of storage. Technically, that is not 1.44 megabytes (MB), nor is it 1.44 mebibytes (MiB). It's 1.44 kilokibibytes (KKiB?).

A common (and incorrect) myth is that storage media is advertised in tera/giga/mega/kiloBITS instead of BYTES, but this is incorrect. A *BIT is 1/8th of a *BYTE (because there are 8 bits in a byte (an 8-bit word)). For example, your internet connection is most likely sold to you measured in megaBITS per second because the number is both larger (easier to sell) and modems from the olden days of the internet were advertised in their capacity for bits-per-second (baud rate). If I have an 80 megabit per second (80 Mbps, 80 * 10^6 bps) connection, that is only 10 megabytes per second (10MB/s, 10 * 10^6 bps). However, since both this sales strategy would not fly with storage mediums and they were not traditionally measured by the bit, the capacity is instead almost always measured in tera/giga/mega/kiloBYTEs (10^n bytes) of storage. Still, though, this number is often just a close estimation. For example, the SSD in my computer has an actual capacity of 240.057409536 gigabytes, but is sold as a 240GB drive.

However, metric doesn't paint the whole story because computers work with twos, not tens. A sector being 512 bytes makes more sense as a data structure because a computer can count 512 steps by simply counting to 2^7 (8-bits) twice. There's not a particular reason why a sector couldn't be 500 bytes, or 50 bytes, or 137 bytes, but in general I'm sure it was to simply maximize the balance between the capabilities of the medium and the capabilities of the machine.

As a result, you may have heard that 1 kilobyte is equal to 1024 bytes or 1 megabyte is equal to 1024 kilobytes. This is not true, as kilo and mega are metrix prefixes, meaning they are always going to be a round measure of 10 to some power. 1 kilobyte is 1000 bytes. 1 megabyte is 1000 kilobytes.

Enter the *bibyte.

Windows and most other operating systems generally actually measure in the often unknown and unsung *bibytes (gibibytes/mebibytes/kibibytes/bytes), which instead of being multiples of ten (10^(n*3), where n is kilo(1), mega(2), giga(3), and so forth), they are multiples of two (2^10n) since binary bases are also multiples of 2. One kibibyte is 2^10 (1024) bytes, a mebibyte is (2^10 * 2^10 = 2^20, 1024 * 1024) bytes, and so on and so forth. It is why we can say that two sectors (each 512 bytes, because that number is again more natural to a computer-centric bases like base-2 (binary)) make up 1K instead of 1.024K. It can get confusing, but know if you buy a 500GB hard disk, it is generally about 500 gigabytes. It will show up on a Windows computer as ~465GB (Windows, confused as it is, calls them gigabytes, where it should be calling them gibibytes (GiB)) -- maybe slightly less depending on file system information, partitioning, etc. Linux is a bit more transparent about this, at least using the correct abbreviations (most of the time), and to my knowledge macOS (previously OS X) is the only operating system to truly measure in the metric bases. There's a big ol' load of mixups and misinformation, but hopefully this sets the record straight for you. For the love of all that is good, let's at LEAST stop the gigabits rumor.

So, finally, how much is on a 2HD floppy disk then? Well, there are 2880 sectors, each at 512 bytes a piece, meaning there are precisely 1474560 bytes on a disk. That equates to 1474.56 kilobytes, or 1.47456 megabytes. There are 1440 kibibytes (a nicer number), or 1.40625 mebibytes. There are 1.44 kilo-kibibytes (not megabytes!) per disk.

Of course, this is advertised as 1.44MB, so for the sake of simplicity and to minimize confusion, that's probably what I'll call it everywhere else on this site and the system. You're welcome to do the same, of course, but hopefully you enjoy knowing more about the measurement of our dearest medium - the floppy disk.