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.

  • I think the whole lengthy primer about CHS translation belongs more in the chs tag wiki rather than this specific question. Will you mind if I move it there? Commented Apr 3, 2022 at 5:57
  • @user3840170 Why not copy it there? I specifically put it here so that readers understand what is going on and don't say incorrect things like "this is irrelevant because modern hard drives use LBA". Commented Apr 3, 2022 at 17:02
  • Because by that token such lengthy explanation should be everywhere a question is asked about hard drive geometry. And don’t worry, I don’t think people saying ‘this is irrelevant because modern hard drives use LBA’ is a problem; if anything, it’s just the opposite, people often jump the gun to say ‘too modern, off-topic’. This is a Retrocomputing site after all. Commented Apr 3, 2022 at 17:06
  • @user3840170 Can it at least be directly linked here? There is already one comment asking something that was answered in my explanation about how CHS geometry and the Windows NT boot loader works. Commented Apr 3, 2022 at 17:10
  • It was posted before I even edited out this passage. But sure, a link to <retrocomputing.stackexchange.com/tags/chs/info> can’t hurt. Commented Apr 3, 2022 at 17:13

2 Answers 2


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.

Screenshot of RPM 2.40

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. With RPM, this is also easy: select the partition entry and press ↵ Return to enter the BPB editor. As before, immediately press F2, 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, then as before, without changing anything, immediately 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. 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.

  • Do NTFS-using operating systems actually care about CHS at all?
    – grawity
    Commented Apr 3, 2022 at 9:37
  • 2
    I would imagine early versions of Windows NT use the BPB geometry for booting, just like DOS does. NT 3.1 would certainly need to know the correct geometry; I am not sure if later versions switched to LBA. Commented Apr 3, 2022 at 9:49
  • 1
  • 2
    So does the Windows XP partition sector, which contains the classic "A disk read error occurred Press Ctrl + Alt + Del to restart" message when it can't correctly access the NTFS partition due to the CHS values being wrong. I mentioned this Win XP behavior in my explanation that got moved to the wiki. Commented Apr 3, 2022 at 17:29
  • 2
    I put 0xFE in the 0x1A offset thinking that was 255 but that is 254. I changed it to 0xFF and now it works! You have to change the backup sector at the end of the partition too or else the fixmbr utility will restore the backup sector with the wrong geometry. I created another 8ish GB partition after this one with Windows diskpart to experiment with and the hidden sectors value is still 0x3F which is 63, which should only be correct for the 1st partition. I'll have to examine it some more I guess. Commented Apr 28, 2022 at 5:03

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.

  • In this case it's Windows XP so it may not be necessary to keep the partitions aligned to cylinder boundaries, which as you say, won't be possible with the new BIOS provided interrupt 13h (int13h) geometry. To maintain DOS compatibility, which requires partitions to line up with cylinder boundaries, changing the geometry in the BIOS or repartitioning may be necessary as you said. Commented Apr 3, 2022 at 17:33
  • 2
    @AlexCannon Even better, only Extended Boot Records need to be aligned to cylinder boundaries, and even then, switching to LBA EBR partition type (0x0f) removes that requirement (at the cost of requiring MS-DOS 7/8, i.e. Windows 9x). DOS does not require any cylinder-alignment otherwise. Commented Apr 3, 2022 at 17:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .