How are blocks stacked on a floppy or older HD

Question

I tried to understand how to read a floppy image format (.sdk). The format is based on CP/M 2.2 filesystem. I've lost track, and I think it's my third attempt. Now I am looking more into what these different things are:

• sector
• tracks
• blocks?

I know what a sector is, its one of those pies, and a track is one of the concentric circles on a disk. Not sure if blocks are an actual physical thing on the surface of a disk or if they are only part of software. Thats what I am attempting to understand more about. Wether or not its physical, my question is how we can read those sectors (or how they are stacked) when the floppy or hd is reading data from it. I've drawn a krappie paint figure (or i think those circles wasnt that bad afterall):

So, which one of these four figures are most accurate?

I've read that there can be more than one sector per track. My question is wether or not one block is the upper right or upper left figure because the disk or surface is rotating so that the head-reader is reading more than one sector at a time and one block can be thought of as that.

Answer 1

A sector is the minimum amount of data you can read from a floppy disk or harddisk. As you've drawn correctly, a sector is part of a track (on a harddisk also called cylinder, because there are many platters with one track, so overall you get a cylinder).

One thing you are missing is that some floppy drives and nearly all harddrives have multiple heads, so for a double sided floppy, there are drives that can read from both sides.

Blocks are a logical abstraction on sectors. In general, one block can contain a constant number of sectors. Sometimes this constant is "one". (And I've never come across the case where there are several blocks in one sector, but who knows...)

To make things more interesting, the term "block" is used in many subsystems, and can have different sizes in each of those. So you can have a logical harddisk block that consists of exactly one sector, or a filesystem block ("allocation unit") that consists of, say, four sectors.

You can also stack these, so you can have a filesystem block that consists of two logical blocks which consists of two sectors each.

So to get through this mess, you have to be very specific which kind of disk you are dealing with, which kind of transport mechanism, and which kind of filesystem.

For CP/M, see e.g. here:

CP/M supports block sizes of 1024, 2048, 4096, 8192 and 16384 bytes. Unfortunately, this format specification is not stored on the disk and there are lots of formats. Accessing a block is performed by accessing its sectors, which are stored with the given software skew.

One way to figure this out is to look at a disk image where you know the contents of the file, and reconstruct the "magic" numbers for the format from that.

As for files that capture disk images, some also have an internal structure, which can add another complication. I am not familiar with the .SDK format, so I don't know if that is relevant for it.

Answer 2

There's a number of terms which partially overlap here, and of course some people use the wrong word for a particular concept due to incomplete understanding. I'll summarise all the terms I can think of.

Block: the data residing on a single sector of a single track. This is typically between 128 and 512 bytes for floppy drives, depending on the vintage of the format, but recent hard disks have increased it to 4096 bytes.

Track: the circle on a disk surface described by a single head in a single cylinder position.

Sector: a pie-shaped section of the disk, usually an integer subdivision of the total rotation, aligned to one or more reference marks (a physical hole in the disk on 8" and 5.25" floppies, some other means on other types). Some older disks are hard sectored with a reference mark per sector. It is possible (and usual nowadays) to have different sector counts at different cylinders, eg. on the Commodore 1541 and Apple ProDOS formats, provided the disk is soft sectored with only one reference mark.

Colloquially, sector may sometimes be used to refer to a block (see above) but this is technically incorrect.

Head or Side: generally there is one head per disk surface. Some old floppy drives have only one head, and it is necessary to flip the disk to use the other surface. Floppy drives can usually step the head to about 40 or 80 cylinders, hard drives to a larger number.

Cylinder: a logically-cylindrical grouping of all tracks at a given head position. The drive may not need to seek the heads in order to access any block/track/sector in the same cylinder.

In summary, a block can be described by its cylinder, head, and sector coordinates, often abbreviated CHS. Colloquially for floppy drives, the term track may be used interchangeably with cylinder, but strictly speaking track is the intersection of cylinder and head coordinates.

At the filesystem level, several consecutive disk blocks may be handled as a single entity. This is most often associated with FAT, in which it is called a cluster. This has been perpetuated in the Microsoft family, but in Linux the distinction is instead drawn between a filesystem block (ie. a cluster) and a disk block (as defined above).

Answer 3

"Block" has nothing to do with the physical layout of a CP/M disk. There are just tracks and sectors. Block refers to an allocation unit, which is a logical grouping of sectors.

For example, a single-density, single-sided 8" disk contains 77 tracks, each divided into 26 sectors, for a total of 2002 sectors. A sector is the smallest amount of data that can be read or written at a time. Each sector holds 128 bytes of data, so the whole disk holds a grand total of 256,256 bytes.

However, two entire tracks are reserved on every disk to hold system code (boot sector, bios, and CP/M itself). This leaves 75 tracks (1950 sectors, or 249,600 bytes) for the disk directory and file data.

Note that the total amount of data is just under 256k bytes. If space is allocated to files 1k (8 sectors) at a time, then each "allocation unit" or "block" can be described by a single byte. This was chosen as a reasonable compromise between the size of a directory entry and the total number of files that could be stored on a single disk.

A directory entry is 32 bytes, and contains 16 bytes of allocation information. (Files larger than 16k bytes require multiple directory entries, referred to as "extents".) The directory typically occupies the first two blocks (2k bytes), which is enough space for 64 entries. This leaves 241 blocks (241k bytes) for actual file data — 96.3% of the raw disk space.

So a single disk can hold up to 64 files of between 1k and 16k bytes each, or fewer larger files. Note that 1950 is not a multiple of 8, which means that the last 6 sectors of the disk cannot be accessed via CP/M — they are simply wasted as far as the filesystem is concerned. The only way to access them is via direct calls to the bios.

Answer 4

TL;DR:

So, which one of these four figures are most accurate?

Non - or all of them, depending on what controller/system/OS is used, but as well as the abstraction level one looks at. And, as usual with an evolving terminology, meaning got changed, overlaying terms were introduced and some turned them upside down.

---

A long story - made short:

In the beginning there was only a block, no sector (*1), and it existed on tape. Blocks had arbitrary length, much like the application liked (*2). When disk came, they were first just assigned on track level. A whole track got written at once. This was soon replaced by writing separate blocks instead. In the mainframe world, were it happened first, blocks were 2048 bytes or a half page (*3).

The term sector was used when viewing this from a media angle, while block was more about the logical view. Then again, at that time they were exchangeable. It changed when for one minis and more important micros 'redeveloped' disk storage bottom up, using sector as basic term on OS as well as application level.

This is were it gets really confusing. For various reasons, later operating systems did use disk drives with a certain physical sector size but superimposed their logical sector sie. In more lucky cases these logical sectors got again called block.

A nice example is the UCSD Pascal system for the Apple II. Since UCSD system was developed on machines with a 512 byte sector/block size, the Pascal file system for the apple II always combined two consecutive physical 256 byte sectors into one logical 512 byte block.

But this also happened the other way. The be device independent, CP/M operated with a logical sector(!) size of 128 bytes. It was the BIOS' job to turn them into disk sectors, which now got called blocks - essentially turning the terminology upside down - depending on whatever physical sector size was used. To make it even more confusing, later versions (3.0?) introduced larger sector sizes as well to cover larger storage media.

Bottom line: Sectors and blocks may or may not be the same and either may be used to describe a chunk on disk or a logical structure.

my question is how we can read those sectors (or how they are stacked) when the floppy or hd is reading data from it.

By positioning on the track, and reading the headers. Each sector is prefixed by a header with track and sector number (*4). After positioning the headers are read. If it's the wrong track, the head gets repositioned (*5), if it's the right one, headers get read until the desired sector is found.

Within a track, logical sectors can come in arbitrary order. While sectors are of course always sequential, their logical number can be ordered different. Basically any drive and OS can operate with any sequence. Though, depending on hard and software, a sector my need some time for post processing before being able to read the next. So after processing the first sector, the next header it 'sees' ma be the third, as the header of the second has already passed, forcing the OS to look for almost a full rotation.

This can be leveled by simply interleaving logical sectors on a track. So instead of putting the logical sectors 1, 2, 3, 4 into the physical (sequential) sectors 1, 2, 3, 4, They are put on the track as 1, 3, 2, 4. Now reading two (logically) consecutive sectors only need the time for 3 sectors, not a whole track time plus two. This technique is called sector skewing.

As a result, logical block made up of sectors like mentioned above may not be stored in consecutive physical sectors on a disk. Apple PASCAL for example stored the logical sectors as 0, 8, 1, 9 ... but a block was formed from sector 0 and 1, making them interleave (*6)

Bottom line: Sectors and blocks may come in any order in multiple layers of abstraction.

---

As said, all of your drawings may apply.

---

*1 - Well, in the real beginning there was the punch card :)

*2 - As assumed, some very early system did really use 80 byte blocks to make it look like punch cards!

*3 - A page is a memory page of 4096 bytes, used for virtual memory as well.

*4 - Track/sector number, or some other kind of unique ID for the block is always present. But there is/may be other meta data as well. It may include things like block keys, file numbers or alike. Presence depends much on the OS/machine used.

*5 - Yes, that is a thing. For one head position is usually tracked by counting steps, but they may get out of sync, so checking and repositoning is helpful. Also, with more and denser tracks, drive mechanics did run into mechanical issues of exact positioning, so (some) drives started to use a multi precicion aproach. The motor positioned the head roughly in the right direction, followed by a secondary mechanic for fine positioning, correcting any over or undershoot.

*6 - Let's not touch 13 sector format here :)

Answer 5

1. Track/cylinder

   its single circle on the surface or set of circles on each surface/head forming cylinder (one spin). Each containing several sectors. How many is chosen by physical format of the media and limited by data density.

2. Sector

   its predefined fixed size chunk of usable data. The size is chosen by physical format but is limited by used HW so you can not use any size and usually just one that is supported by the connected HW. For floppies the size stabilized at 512 Bytes. But beware the whole sector (sync and header info included) is bigger like ~598 Bytes ... but that stuff is usually not present in disc images.

3. Block/cluster

   this is related to used File System smallest usable data chunk usable (usually several sectors). Sometimes is called cluster size and usually is chosable during logical Format. It has nothing to do with physical representation of data on the surface its just logical addressing of storage data by File System (so no FAT just the data).

To know more about sector/track you should know how it is stored on the medium:

The tracks and sectors are lines (arcs) not areas like you do (the heads have very thing magnetic gap so the track can be as thin as possible).

Index Hole is to detect rotation speed and angular position (once the rotation speed is stable).

The track start is not defined by index hole and all the tracks might start at different angular positions (so no pie !!!).

The gaps are not empty space !!! they detect start of sector, sync data and sector header. They usually start with some repeating hexa number so the FDC can synchronize where the 8bit data starts and ends in the bit stream. After that is followed by different hex number to signalize sector will start soon and FDC have to store the incoming data into buffer. Then sector info is stored (number of sector, checksum, etc..) and only then 512 Bytes of data follows. The gaps are created during physical format and different controlles had different formats of the gap making not possible to read some floppies on different systems (like ZX MDOS on PC) without specifically preformated gaps that are readable on both systems ...

Sectors might also not be stored in order. They where usually interleaved so they could be loaded sequentially faster. I know its sound wrong but you must realize that on old systems you have to read sector, transfer it to memory and then process it and that took more time than the heads go to start of next sector so you would need to wait for next revolution. To speed this up the sectors where stored instead of

0,1,2,3,4...

in orders like:

0,2,4,...,1,3,5,...
0,3,6,...,1,4,7,...,2,5,8,...

the number of interleaving was chosable during physical format. And you interleave the more the slower your system is.

So your image should look more like set of concentric circles with highlighted arces not too closely aligned between neighboring tracks.

And do not forget that the binary bits are not stored on the flux directly but are encoded by specific patterns of flux change. There are several media formats out there also ...

For more info see:

• Finding byte boundaries in floppy disk MFM bitstreams