Missing cylinder in DOS hard drive tools?

[Vin Digit]

I'm working through some old MFM HDDs (backing up, erasing, etc.) but I'm noticing that the reported geometry from tools I'm using (e.g. Active@ KillDisk) are reporting one cylinder less than the stated hard drive spec. For example, I'm currently working on an IBM Type 13 20MB HDD with a Xebec fixed disk controller, which should have the CHS values of: 306 Cylinders, 8 Heads, 17 Sectors. With the tools I'm using however only 305 cylinders are being reported as thus the maximum accessible sector is 41480 (C*H*S) when the actual sectors for a 306C disk should be 41616, so I'm concerned there's data being missed out and not erased. I'm using a 486 machine, as the Xebec fixed disk controller appears incompatible with later BIOSes (it hangs on POST). On a socket 7 machine I used for another MFM drive, this issue was also present. PC-Config 9.33 reports the correct geometry.

I'd wondered whether it's to do with formatted vs unformatted capacities but according to this information I don't think that's the case.

Are sectors being missed out here? Obviously really important if they are! Thanks

 

[Timo W.]

Are you sure it shows the number of cylinders and not just what is the last one? Counting starts at 0, so with 306 cylinders, the last one is 305.

 

[SomeGuy]

Track/cylinder numbering starts at zero, so you do need to make sure it it is saying "306 total" rather than "0-305".

Not surprising when a programs says one but means the other, because in the real world absolutely negative one people start counting from zero.

Also, keep in mind some hard drives may actually have a few extra cylinders than the official specs state, probably due to manufacturing variation.

 

[Vin Digit]

The size of the cloned image file generated from another drive is 21377024 bytes, divided by 512 gives 41752 sectors (which corresponds to 614*4*17). Additionally, when creating a 615c4h17s image file, with a total size of 21411840 bytes, in PCem I can see that the whole file is indeed not erased when using Active@ KillDisk (reporting 614 cylinders). Infact, 34816 bytes are left out, which is the difference between 21377024 and 21411840

I've found some further information:

The maximum cylinder number reported in CX is usually two less than the total cylinder count reported in the fixed disk parameter table (see INT 41h,INT 46h) because early hard disks used the last cylinder for testing purposes

This might explain why PC-Config 9.33 reports 615c if it gets the info from `int 41h` and `int 46h`. I presume then the other software is quering the drive info using `int 13h` and assuming the final cylinder is for testing.

For BIOSes which reserve the last cylinder for testing purposes, the cylinder count is automatically decremented.

The question then is how to know if the final cylinder is being used for testing? My IBM Type 13 HDD image seemingly has a file in the final sector, but I don't know whether the file just happens to stop at the final byte or whether it continues into the next sector I'll have a look to see what the FAT and partition data say

 

[Vin Digit]

Fortunately it looks like the partition does not cross into the final cylinder.

In PCem with a Xebec fixed disk adapter and a Type 13 HDD, I tested crudely an `int 13h` call using DEBUG and extracted the cylinder count. The value returned (304) was indeed two below the drive's cylinder count. Since the value is said to be the maximum cylinder number I presume that's the zero-indexed value (i.e. cylinders 0-304).

Does anyone know where more information can be found about this 'testing' area? I know security wasn't really a thing back then but having a (seemingly) undocumented area of the disk not being touched by the majority of tools doesn't seem like the best of ideas lol!

 

[modem7]

Does anyone know where more information can be found about this 'testing' area?

1. To park the heads on. Used by head parking utilities. Since the head is coming to rest on that cylinder, best that data not be stored in the cylinder.
2. Diagnostics wanting to do a read/write test can use the subject cylinder knowing that there is no data there to be concerned about. (It is a 'scratch' area.)

In PCem with a Xebec fixed disk adapter and a Type 13 HDD, I tested crudely an `int 13h` call using DEBUG and extracted the cylinder count.

Definitely not cylinder count.

The hard disk controller supplied by IBM in the IBM 5160 is made by Xebec. IBM names it the 'IBM Fixed Disk Adapter'. IBM's technical document for the adapter is in a link at [here]. Within that document is the source code for the BIOS ROM on the adapter. At the start of the source code is:

The value returned (304) was indeed two below the drive's cylinder count.

Yes; the BIOS ROM on the IBM Fixed Disk Adapter allows for both numbering starting at 0, and allows for the last cylinder reserved for parking and diagnostics.
We can see that in the INT13H FUNCTION 8 part of the aforementioned BIOS source code:

 

[modem7]

And per [here], if an MFM controller is operating in 'dynamic' mode, then we can expect another cylinder to be unavailable to the OS.

 

[doshea]

And per [here], if an MFM controller is operating in 'dynamic' mode, then we can expect another cylinder to be unavailable to the OS.

Interesting! What a horrible waste of very expensive storage.

That page says tracks are reserved, not cylinders, but I suppose a full cylinder does have to be reserved if the controller is going to present a geometry in cylinders, heads and sectors which is completely usable?

I suppose that if they reserved the last track in the last cylinder, they could allow access to that cylinder but tell you to partition your disk so as not to use that track and not allow writes to it, but that seems too painful for users, and I suppose they would have to reserve something at the start of the disk rather than the end anyway, due to this information telling the controller where the end is.

Hopefully what I said makes sense. I must admit that I needed to check the glossary in Upgrading and Repairing PC to make sure I really did understand the difference between a track and a cylinder properly, finally, after all these decades!

 

[modem7]

That page says tracks are reserved, not cylinders, but I suppose a full cylinder does have to be reserved if the controller is going to present a geometry in cylinders, heads and sectors ...

That is my page, and you are correct. In respect of what is reserved, the page should use "cylinder". I will change it.

Of interest to you might be the page at [here], another page authored by me. When I encountered the behaviour, I was puzzled. The behaviour indicates that the BIOS ROM (in dynamic mode) on the WD1002A-WX1 stores the dynamic geometry on track 0 of cylinder 0, but the question is, how is SpeedStor software able to get write access to the track where the BIOS is storing the dynamic geometry? Surely the WD1002A-WX1's BIOS ROM (when in dynamic mode), is doing a logical-to-physical cylinder translation. To me, the obvious one would be {add 1 to the requested cylinder}.

An answer might be that SpeedStor is bypassing the BIOS, communicating directly with the controller hardware. A way to find out would be for me to see the stored dynamic geometry is overwritten if I use an INT13H call to overwrite {cylinder=0, track=0}.

 

[vwestlife]

If you're using an MFM/RLL drive and are upset about losing that last cylinder or two, then you can simply specify a higher number of cylinders when formatting the drive to make up for it. For example, the ST-225 officially has 615 cylinders, but is physically capable of stepping to at least 663 or 664 cylinders before the heads actually reach the end stop. But that extra space is normally not used because the magnetic coating on the platters may not be reliable that close to the center.

 

[doshea]

That is my page, and you are correct. In respect of what is reserved, the page should use "cylinder". I will change it.

Thanks, and I did catch the clue in your avatar

Of interest to you might be the page at [here], another page authored by me. When I encountered the behaviour, I was puzzled. The behaviour indicates that the BIOS ROM (in dynamic mode) on the WD1002A-WX1 stores the dynamic geometry on track 0 of cylinder 0, but the question is, how is SpeedStor software able to get write access to the track where the BIOS is storing the dynamic geometry? Surely the WD1002A-WX1's BIOS ROM (when in dynamic mode), is doing a logical-to-physical cylinder translation. To me, the obvious one would be {add 1 to the requested cylinder}.

An answer might be that SpeedStor is bypassing the BIOS, communicating directly with the controller hardware. A way to find out would be for me to see the stored dynamic geometry is overwritten if I use an INT13H call to overwrite {cylinder=0, track=0}.

Ouch! Yes, let's hope your explanation is correct!

 

[Svenska]

Interesting! What a horrible waste of very expensive storage.

The controller needs to store the user-configured disk geometry somewhere, and the only cylinder guaranteed to exist on all disks is the first one. Storing it inside the controller would have made the controller far more expensive.

 

[doshea]

The controller needs to store the user-configured disk geometry somewhere, and the only cylinder guaranteed to exist on all disks is the first one. Storing it inside the controller would have made the controller far more expensive.

Oh yeah, I guess I was wrong, it wasn't really wasting that much storage anyway. This is a real cylinder, not something with inflated logical geometry, so there are only 8 heads and 17 sectors per track in the OP's HDD and hence a cylinder is only 68KiB.