How to determine BIOS-provided (INT 13h) hard disk geometry, and how to fix the MBR partition table to agree with it?

Question

When transferring a hard drive from one computer to another, sometimes a situation can occur where the BIOS-provided CHS hard disk geometry (interrupt 13h without extensions) is different from the CHS geometry it presented as on the computer that it came from. In my case one computer seems to have been using 240 heads for interrupt 13h access. If you have an operating system such as DOS, or a Windows NT boot sector (up to at least XP), or any other partition boot sector that is operating in legacy interrupt 13h mode instead of extended interrupt 13h, where it communicates legacy ~8.4 GB-limited CHS values to the BIOS, your operating system will not correctly access the hard drive and will be unable to boot. Furthermore, many more modern computers from the 90s and thereafter have fairly basic BIOS hard drive configurations that don't let you see or change anything related to cylinders, heads or sectors.

How does someone find out what number of cylinders, heads, and sectors a BIOS is presenting for a particular hard drive? Is there some kind of DOS utility that will tell you? Also, is there a utility to change the CHS values in the MBR partition table and partition start and end entries to correspond to a different BIOS-provided geometry on a different computer?

It is important to good understanding of INT 13h, extended 64-bit INT 13h, what operating systems use INT 13h only, the 528MB limit, the 8.4GB limit, 255 or 256 heads, and LBA before attempting this kind of fix during a hard drive swap. Here is a link to a Stack Exchange information on the topic: https://retrocomputing.stackexchange.com/tags/chs/info

To read more background on the history of CHS, int 13h, and BIOS translations, you can read my summary of it here.

Since this is a very confusing topic, here is some background: In the early days, IDE hard drives were accessed using cylinders, heads, and sectors. SCSI hard drives have always used an LBA like linear addressing method, but the SCSI BIOS still presented an int 13h CHS interface for DOS to access the SCSI hard drive using cylinders, heads, and sectors. These CHS values were manually entered in to the CMOS setup. The DOS operating system would access the hard drive through the BIOS int 13h interface using these CHS values. Everything worked fine. If you moved the hard drive to a different computer, you just entered the same CHS values in to the CMOS setup on the new computer. If you had a SCSI HDD, your SCSI controller BIOS would provide consistent CHS values for DOS to use.

The IDE hard drive CHS is limited to 65536 cylinders, 16 heads, and 256 sectors, which is the 128GB limit or "LBA28". The BIOS (or SCSI BIOS) int 13h interface is limited to 1024 cylinders, 256 heads (or 255 for DOS compatabilty), and 63 sectors making the 8.4GB limit. These two limits combined result in 1024 cylinders, 16 heads, and 63 sectors, making the 528MB limit for an IDE hard drive with a non translating BIOS.

To get around this, BIOSes started providing int 13h extensions which is a 64-bit LBA like number used by the operating system to access the hard drive. But before that became standard, a workaround was created where the BIOS would provide fake int 13h geometry and translate it in to real hard drive CHS geometry or use LBA to access the hard drive. If you have a BIOS that does not support int 13h extensions, or an operating system that is using the legacy int 13h CHS mode (even the Windows XP boot sectors will sometimes operate in the CHS int 13h mode), this is where the problems arise. The CHS value of the hard drive is no longer determined by the hard drive, but by the BIOS of the computer that the hard drive is put in to. Putting the hard drive in to a different computer can change the BIOS provided int 13h CHS values of the hard drive. There is sort of a standard way of creating virtual CHS values for a hard drive, but there is more than one standard way of doing it, which makes it not really standard.

It would have been better if extended int13h had been the solution from the beginning, and the whole translation thing had been skipped. It used to not matter if the CHS values in the BIOS were correct when a hard drive was transferred to another computer, because the true CHS values are stored in the DOS partition table, and software uses that. DOS would use that and the BIOS would send it directly to the hard drive, so the BIOS values were ignored. The only time it mattered would be if a utility like fdisk used the incorrect CHS values from the BIOS when making a new partition. Ever since translation became a thing, and the BIOS had to modify the CHS values, having mismatched CHS values will make the drive inaccessible to any software that uses INT 13h CHS access. Even Windows XP uses CHS if a partition is within 1024 cylinders.

When thinking about this, be sure to not confuse the IDE hard drive CHS or LBA access modes with the DOS (or other OS) to BIOS int 13h or extended int 13h interface. They are two completely different things. The BIOS presented to DOS and BIOS to HDD CHS values haven't been the same since hard drives went over 528MB.

Answer 1

If you can manage to boot the computer from a DOS floppy or some other device, you should be able to use the classic partitioning tool, Ranish Partition Manager. (I recommend version 2.40 or 2.44; neither unfortunately comes with source code, but they are considerably more flexible than 2.37, which does.) When you start the program, you will be presented with an interactive low-level(-ish) editor of the Master Boot Record, with the disk’s logical geometry (the one used with interrupt 0x13 services) displayed at the top. Any discrepancies the program detects will be highlighted in red.

You may remember that the MBR defines partition boundaries using both CHS and LBA coordinates. As it happens, Ranish Partition Manager prefers using the LBA fields, and derives CHS coordinates from those. This means that, assuming the LBA fields are correctly filled, all you need to do to adjust the MBR for the new geometry is start RPM, immediately press F2 to write the MBR to disk, and exit. RPM will re-calculate the CHS coordinates from the LBA offsets stored in the partition table and the geometry it received from the BIOS.

If the disk contains FAT partitions you want to be able to boot from, you will additionally need to fix the geometry found within the boot sector’s BIOS Parameter Block⁰, and possibly the “hidden sectors” value as well, which is simply the LBA partition offset. With RPM, this is also easy: press F4 to switch to LBA view, then select the partition entry and press ↵ Return to enter the BPB editor. If the “Starting” value is highlighted in red, adjust it so that it agree with the partition table. Then press F2 to write the BPB, then Esc to go back to the partition list. RPM will write the new geometry information into that partition’s BPB.

NTFS partitions also store the disk geometry in a very similar structure, but RPM is not able to correct it as easily. What you may try doing is: press Insert to temporarily change partition type to FAT (e.g. 0x06), then ↵ Return to enter the BPB editor, adjust the “Starting” value if necessary, then, without changing anything else, save the BPB with F2, exit the BPB editor with Esc and change the partition type back to NTFS (0x07). This works because the layout of NTFS’s BPB is largely the same as FAT’s⁰; at least its initial fields, which contain the geometry information. In my quick experiment in a VM, nothing other than the geometry fields was modified in the boot sector, so I expect it to be relatively safe. But if you want to be absolutely sure, you can use a hex editor instead.

Extended partitions (type 0x05) may pose more problems. The main difficulty with them is that MS‑DOS expects Extended Boot Records to be aligned on a cylinder boundary (The Large Disk HOWTO warns about this.). If the EBR is not so aligned under the new geometry, MS‑DOS will not be able to access the logical drives correctly. The simplest way to address this, if you don’t mind the fact that it will make the logical drives unreadable under an OS older than MS‑DOS 7.0 (the one bundled with Windows 9x; equivalently, a clone like FreeDOS that happens to support the same feature), is to change the EBR’s partition type from 0x05 (‘Extended’ in RPM) to 0x0f (confusingly labelled ‘VFAT Extended LBA’, despite not having anything to do with FAT). Other than that, you might not be able to access the disk without re-partitioning it entirely.

---

⁰ I have rather mixed feelings about recommending this source. The description of the BPB structures found there is largely correct, although the author of that page imposes a few bizarre interpretations upon them, like insisting that decimal values 40 and 41 in the signature byte correspond to MS-DOS version 4.0 (which may or may not be true: there are no sources to confirm one way or another), lamenting that the BPB variant introduced with FAT32 uses the wrong value (up to writing a whole fanfiction standard correcting this)… and then going to say that hexadecimal value 0x80 found in NTFS BPBs somehow corresponds to a supposedly non-existent “MS-DOS version 8.0” (which does actually exist, kind of – it’s the DOS version number reported by Windows Me). Why not 12.8 instead, since hexadecimal 0x80 is decimal 128? So beware of that author’s strange pedantic fixations; they have led him astray before.

Answer 2

There are various different methods of converting the drive physical geometry to logical BIOS geometry.

It sounds like the drive was originally been used with "ECHS" or "Large" method, or more specifically, it might use the "Revised ECHS" method, because it uses 240 heads for large enough drives, or the drive originally reported 15 heads to begin with. The original, unrevised ECHS method, would have resulted in 256 heads if drive originally had 16 heads, and DOS and Win95 were incompatible with 256 heads. Also note that the ECHS method does not change the value of how many sectors per track there is.

So if the computer has different geometry translation methods available, try them if it ends up with same geometry. Most likely setting is "Large", as "LBA" would end up with 255 heads and 63 sectors per track.

As the drive is usually partitioned with the translated logical geometry using standard int 13h functions, you pretty much must use the original geometry for partitions to access the drive and to boot from it properly.

If drive logical geometry is different in two different computers, it might be best to just repartition the drive and reinstall everything.

Editing the new geometry into MBR and into all partitions and/or moving the partitions to match the new cylinder block alignment may prove to be difficult.

At least you can take an image of the drive contents for backup purposes so you can always restore the drive or try the process using the drive image in virtual machines.