It's generally believed that the IBM/Xebec Fixed Disk adapters were hardware limited to only four different drive geometries - of which, only the last revision of the card was user configurable (without modification).

However, page 37 of the first version ROM source code states:


In other words the drive geometries were in fact dynamic using tables referenced via INT 41H (similar how INT 1EH was used for floppy disk controllers).

Obviously this was forward thinking, but had some clear shortcomings. The default drive tables in adapter ROM table is vectored to INT 41H at INT 19H (boostrap) time rather than at ROM initialization, so this would prevent the BIOS or another option ROM from being able to switch it out during POST. However it seem plausible that this could be done before any significant reads or writes occurred via a boot floppy disk or a modified MBR on the hard drive (similar to later drive overlay software).

Presumably there would be some electronic/adapter ROM limitations as to the range of parameters possible and if the custom MBR were to be overwritten on your drive, your data could be in peril. Of course, WD and others worked past this with their own ROM-based dynamic formatters, and replacing the slower IBM controllers to support a larger drive was accepted so this eventually became an obsolete issue.

My question is, was modifying the INT 41H table to enable the IBM/Xebec controllers to support additional drive geometries ever done and were there software titles at the time to do it?

  • 1
    I don't have an answer to your actual question, but even if the default table is set at INT 19H bootstrap, the disk BIOS is at address C8000H, which means it is the first expansion ROM to hook the INT 19H handler, and any other expansion ROMs are run later. So the other expansion ROMs or a modified main BIOS are free to change where INT 19H points to if they want to stop the original disk expansion ROM from setting the default parameters. Also the bootstrap reads in a single sector for execution so loaded boot code can also change the default parameters.
    – Justme
    Apr 22, 2022 at 20:05
  • @Justme what seems to be happening is that (at least the code rev I'm looking at) the IBM FD BIOS actually sets INT 41H back to it's own table at the start of INT 19H, meaning it happens after all of the other option ROMs got their chance. However, it's just about the first thing it does so it leaves the code in the MBR as a possible way to do it.
    – 640KB
    Apr 22, 2022 at 20:22
  • Yes, but as the FD BIOS init is first to set INT 19H, all the other ROMs get run after it and they can change INT 19H before anyone (main BIOS) actually calls INT 19H. So INT 19H is not run right after the init of FD BIOS.
    – Justme
    Apr 22, 2022 at 20:26
  • @Justme what I'm seeing though is that the FD BIOS's INT 19H sets back INT 41 to it's own table as the first thing it does at C800:018B (not during init, but actual IPL). So even if you re-vectored INT 19 or INT 41 after FD BIOS init, once the FD BIOS's INT 19 is eventually called to boot the HD, it's just going to revert it back to it's own. Unless you take over INT 19, then jump past that part of the FD BIOS's INT 19 that resets INT 41 back... but that's a bit hacky!
    – 640KB
    Apr 22, 2022 at 20:35
  • 1
    I once made a small DOS driver to be loaded from CONFIG.SYS that loaded the HD parameters with around 600 tracks to replace the 300 tracks table provided by the ROM. I wasn't good enough at that time to hack it into the MBR, so the DOS core, config.sys and that driver had to be inside the first 300 cylinders, but it made a 20MB drive work perfectly on a controller that didn't have a 600 cylinder entry in the ROM. Sep 4, 2022 at 10:43

1 Answer 1


Back in the 80's I modified the ROM on my IBM XT hard drive controller by changing the drive parameters encoded in the drive parameter table to match those of a non-IBM drive. It worked just fine (remember to alter the ROM checksum to match). You will of course need an 8K EPROM, EPROM eraser and EPROM programmer to do this.

The problem with implementing a 'custom' drive geometry is the matter of where you store the relevant parameters. As the pre-AT systems had no CMOS memory there is nowhere to store this data except possibly on the HDD itself, which creates a bit of a 'chicken and egg' scenario.

There was a piece of software created by Gold Bow Systems called 'Vfeature' which used a combination of custom code in the Master Boot Record and (I think) a DOS device driver which would allow you to override the BIOS table settings. This definitely worked, but I think it used some copy-protection features so finding a copy in the Internet works may be a bit of a challenge.

You must log in to answer this question.

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