VOGONS


First post, by videogamer555

User metadata
Rank Member
Rank
Member

I know that sectors are addressed using a CHS scheme.
C is the cylinder to read, and controls the positioning of the read-write head mechanism. Its lowest possible value is 0 (zero).
H is the head (or track) on a given cylinder, and it selects which read/write head should be used for the read or write operation. Its lowest possible value is also 0 (zero).
S is the sector on the current track and cylinder which is to be read. It tells the drive how properly time the read or write operation so that the rotation of the disk is at the exact correct spot on the current track for the read/write head to perform the read or write operation. Its lowest possible value is 1 for some reason.

What I really want to know here is what is the access order, for reading and writing sectors sequentially? The first sector has CHS address = 0,0,1. But what is the address of the second sector? Is that 0,0,2? Or maybe 0,1,1? Does anybody know this? Or is this lost knowledge from the days of old computers, that nobody even knows anymore? I know one thing, and that is I haven't found this info yet from any Google searches. So that's why I'm asking here.

Reply 3 of 11, by Jo22

User metadata
Rank l33t++
Rank
l33t++

Just like the others said.

On XT era hardware, low-level format and the interleave factor also come into play.

Then, there were special cylinders, like diagnostic cylinders, that held information for the drive controller firmware.

That was from a time before the BIOS could store drive parameter data (early systems didn't ship with real-time clocks with internal SRAM).

Attachments

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 4 of 11, by superfury

User metadata
Rank l33t++
Rank
l33t++
Jo22 wrote on 2022-02-14, 07:19:
Just like the others said. […]
Show full quote

Just like the others said.

On XT era hardware, low-level format and the interleave factor also come into play.

Then, there were special cylinders, like diagnostic cylinders, that held information for the drive controller firmware.

That was from a time before the BIOS could store drive parameter data (early systems didn't ship with real-time clocks with internal SRAM).

So it's basically the same way as with floppy disks? The read head must read and decode the entire track until it finds the sector to read/write (unless hard-sectored)?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 5 of 11, by TrashPanda

User metadata
Rank l33t
Rank
l33t
superfury wrote on 2022-02-14, 07:32:
Jo22 wrote on 2022-02-14, 07:19:
Just like the others said. […]
Show full quote

Just like the others said.

On XT era hardware, low-level format and the interleave factor also come into play.

Then, there were special cylinders, like diagnostic cylinders, that held information for the drive controller firmware.

That was from a time before the BIOS could store drive parameter data (early systems didn't ship with real-time clocks with internal SRAM).

So it's basically the same way as with floppy disks? The read head must read and decode the entire track until it finds the sector to read/write (unless hard-sectored)?

Doesn't need to decode the entire track, at boot the MBR or what ever the drive is using to store file location data is loaded into memory and the HDD uses this to quickly locate where files are on the drive. Floppies use a boot sector to do something similar, it contains a TOC of sorts that tells the drive where the files are located on the floppy. CD roms also use a TOC as do DVD and Blu-Rays.

Its more complicated than this obviously, far more complicated than you could get into here and if you really do want to know how this is done there is a ton of information about it on Google. Data recovery companies usually have in-depth information about how HDDs work and how some of their less secret recovery methods go about finding lost data.

You really dont want the drive to have to read entire tracks to find files, its too slow and modern recording methods require speed.

Reply 6 of 11, by Ringding

User metadata
Rank Member
Rank
Member
superfury wrote on 2022-02-14, 07:32:

So it's basically the same way as with floppy disks? The read head must read and decode the entire track until it finds the sector to read/write (unless hard-sectored)?

No, drives "know" where the sectors are located. If it’s not static, then at least they have a cache for that information so that they know it most of the time. But obviously they need to wait until the sector passes through under the head.

Reply 7 of 11, by Jo22

User metadata
Rank l33t++
Rank
l33t++

I'm speaking under correction, but I vaguely remember that "sector caches" were once considered a feature in computer magazines from the 80s.
Maybe the early fixed-disk drives didn't feature it, thus and PCs had "to race the platter"* ?

(* reference to "race the beam"; old video game consoles)

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 8 of 11, by TrashPanda

User metadata
Rank l33t
Rank
l33t
Jo22 wrote on 2022-02-14, 08:22:

I'm speaking under correction, but I vaguely remember that "sector caches" were once considered a feature in computer magazines from the 80s.
Maybe the early fixed-disk drives didn't feature it, thus and PCs had "to race the platter"* ?

(* reference to "race the beam"; old video game consoles)

Even MFM drives had to load the MBR to memory, they always know where the boot sector is and after that the OS and MBR handle everything else, I'm not even sure its that the drive knows where the boot sector is but the BIOS knows where it is and tells the HDD to load that into memory at which point the OS takes over using the MBR cached in memory to locate files/sectors as needed.

Its likely why old XT PCs needed the BIOS to know the HDD type to even be able to boot as without the type the BIOS has no idea where the boot sector is and well without a boot sector the HDD is pretty much a paper weight.

I could be wrong.

Reply 9 of 11, by superfury

User metadata
Rank l33t++
Rank
l33t++

What I meant is that the hard drive might need to read the track to find the starting position of the sector to load off a track. That could be the MBR or any other sector.
With hard sectoring the drive might know the exact location off the index hole, but when using formattable hard drives (by software), it would need to read the disk (which probably is much smaller than it would be with hard sectoring due to needing to keep positioning header/footer data for each sector, probably why it ran out of practice to do such a thing) until it finds/reads the matching sector header using the read head, then proceed to read/write the data of the sector once it does. That would have to be done somewhat comparable to the floppy disk sector reading mechanism, wouldn't it?

Of course, hard sectored disks (what they're all nowadays afaik) simply need to specify an position past the index hole (which the drive actually knows without reading). That would also be why it can't be formatted using software, since it won't know where the data of a sector starts anymore using that mechanism?

Stuff like the BIOS knowing about the physical location on the disk (in inches, cm or whatever) isn't used by any BIOS. They use CHS addressing or LBA, which is done by the hard drive anyways (doing all the sector lookup itself).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 10 of 11, by mkarcher

User metadata
Rank l33t
Rank
l33t
superfury wrote on 2022-02-14, 20:48:

What I meant is that the hard drive might need to read the track to find the starting position of the sector to load off a track. [...] until it finds/reads the matching sector header using the read head, then proceed to read/write the data of the sector once it does. That would have to be done somewhat comparable to the floppy disk sector reading mechanism, wouldn't it?

That's exactly how classic MFM drives work. Nonwithstanding the mechanical differences, MFM hard drives (as an example, I pick the ST412) just work like floppy drives (for period correctness, I cite the technical data of 360KB 5,25" PC drives), but with 7.5 times the cylinders (306 instead of 40), twice the sectors per track (17 instead of 8 or 9) and twice the count of disks (2 disks / 4 heads instead of 1 disk / 2 heads). This yields around 30 times the capacity (10MB compared to 360 KB). As a hard drive also spins 12 times faster (3600rpm compared to 300rpm), combined with twice as much sectors per revolution, the raw transfer rate is 20 times higher (5 Mbps instead of 250 kbps). The technology used to position the head (a stepper motor) and the encofing scheme (MFM) and idea of doing the encoding/decoding on a controller card that can be shared between multiple drives is the same both on floppy drives and early MFM drives.

From "being better floppies", hard drives did keep advancing in technology. One example is replacing a fixed stepping rate by an optimized accelleration/deceleration curve for the stepper motor controlled by the hard drive, with the controller still outputting step pulses at a fixed (albeit higher) rate. There is a feedback signal indicating that the seek process completed. This is called "buffered seek" and the ST412 mentioned above (as it is the prototypical 10MB XT drive) is one of the first adopters. That's why the classic hard disk status bits (which were sent from the drive to the controller the old days) has a "seek complete" signal. And guess who is mirroring those status bits? Well, IDE of course. The IDE / ATA status register has a "seek complete" bit which is completely pointless as all IDE commands use implied seeks anyway. That bit already was cargo cult and/or compatibility the days IDE was invented, and kept its spot in status registers in all ATA specifications (though the bit might be "reserved, always set for compatibility" in later editions).

Reply 11 of 11, by superfury

User metadata
Rank l33t++
Rank
l33t++
mkarcher wrote on 2022-02-14, 22:07:
superfury wrote on 2022-02-14, 20:48:

What I meant is that the hard drive might need to read the track to find the starting position of the sector to load off a track. [...] until it finds/reads the matching sector header using the read head, then proceed to read/write the data of the sector once it does. That would have to be done somewhat comparable to the floppy disk sector reading mechanism, wouldn't it?

That's exactly how classic MFM drives work. Nonwithstanding the mechanical differences, MFM hard drives (as an example, I pick the ST412) just work like floppy drives (for period correctness, I cite the technical data of 360KB 5,25" PC drives), but with 7.5 times the cylinders (306 instead of 40), twice the sectors per track (17 instead of 8 or 9) and twice the count of disks (2 disks / 4 heads instead of 1 disk / 2 heads). This yields around 30 times the capacity (10MB compared to 360 KB). As a hard drive also spins 12 times faster (3600rpm compared to 300rpm), combined with twice as much sectors per revolution, the raw transfer rate is 20 times higher (5 Mbps instead of 250 kbps). The technology used to position the head (a stepper motor) and the encofing scheme (MFM) and idea of doing the encoding/decoding on a controller card that can be shared between multiple drives is the same both on floppy drives and early MFM drives.

From "being better floppies", hard drives did keep advancing in technology. One example is replacing a fixed stepping rate by an optimized accelleration/deceleration curve for the stepper motor controlled by the hard drive, with the controller still outputting step pulses at a fixed (albeit higher) rate. There is a feedback signal indicating that the seek process completed. This is called "buffered seek" and the ST412 mentioned above (as it is the prototypical 10MB XT drive) is one of the first adopters. That's why the classic hard disk status bits (which were sent from the drive to the controller the old days) has a "seek complete" signal. And guess who is mirroring those status bits? Well, IDE of course. The IDE / ATA status register has a "seek complete" bit which is completely pointless as all IDE commands use implied seeks anyway. That bit already was cargo cult and/or compatibility the days IDE was invented, and kept its spot in status registers in all ATA specifications (though the bit might be "reserved, always set for compatibility" in later editions).

Yeah. You're right. ATAPI even reuses the seek complete bit for it's own purposes (releasing the bus if I remember the documentation correctly for parallel master/slave command execution on ATAPI devices).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io