VOGONS


First post, by unix_junkie

User metadata
Rank Newbie
Rank
Newbie

Hi everyone.

Over the years, I've been able to successfully triple-boot

  • MS-DOS 6.22,
  • Windows 98, and
  • Windows 2000

from the same IDE hard drive, having the following disk geometry:

  • a primary 2047.3 MB FAT16B (0x6) partition for MS-DOS, defined in CHS, cylinder-aligned, and spanning no more than 1024 cylinders (the "DOS limit");
  • an extended LBA container (0xf), spanning the rest of the disk and, again, cylinder-aligned,
    • 50% of the space within the extended partition dedicated to Windows 98 (W95 FAT32 (LBA), 0xc),
    • 50% of the space within the extended partition dedicated to Windows 2000 (HPFS/NTFS/exFAT, 0x7).

The motherboard is ABIT BX133-RAID with an iBX440 chipset and AWARD BIOS (v6.00PG). When a 128 GB SATA disk is plugged into the onboard IDE controller (using an IDE/SATA DOF B76NX1041 adapter), AWARD BIOS offers three CHS geometry options:

  • Normal or Auto: 61291 x 16 x 255 (with the 1024 cylinder limit, DOS will see up to 1.99 GB, whole CHS-addressable size is 119.2 GB)
  • Large: 7661 x 128 x 255 (DOS-addressable size 15.9 GB, whole CHS-addressable size is 119.2 GB)
  • LBA: 15565 x 255 x 63 (DOS-addressable size 7.8 GB, whole CHS-addressable size is 119.2 GB). This is, by the way, the choice of geometry always reported by Linux (with the only difference that it sees 15566 cylinders and not 15565).

Now, I'm trying to achieve the same goal using a Silicon Image SiI3114 controller, which can be plugged into a PCI slot and has 4 SATA ports. The controller itself is a SiI3114r5 (RAID5) downgraded to SiI3114 (non-RAID) by flashing a pure-IDE BIOS. And I'm facing a problem with the way how SiI3114 reports CHS disk geometry, even to OSes that are fully LBA-capable. Here's a screenshot of Linux fdisk reporting the drive geometry (LBA mode, 15566 cylinders, 255 heads). As you can see, 261 cylinders are more than enough to allow a 2047.3 MB FAT16B DOS partition. This is the expected behavior:

geometry-255heads-cylinders.jpg
Filename
geometry-255heads-cylinders.jpg
File size
1.26 MiB
Views
398 views
File comment
15565 x 255 x 63, LBA mode
File license
CC-BY-4.0

Yet, at some point (I personally did no changes to the hardware or BIOS, except for re-partitioning and OS re-installation), the SATA controller started reporting the number of heads as 16 and not 255 (this is no longer an LBA geometry, nor is it a Normal one). There're a couple of problems with this new weird geometry:

  • It comes and goes for no reason, preventing CHS-dependent OSes (MS-DOS) from booting (right now, I have my controller reporting the correct LBA CHS geometry, but I'm not sure how long this will last).
  • CHS-addressable size is only 7.5 GB (and no longer the whole disk). Even from within Linux.
  • With the 1024 cylinder limit, the maximum partition size MS-DOS can use now is only 504 MB. Pretty much useless.
  • Windows 98 can boot in the command-line mode (DOS 7.0, scandisk.exe reports no errors), but apparently observes the change in geometry when transferring control from DOS 7.0 to the 32-bit LBA-capable kernel, goes schizophrenic, and hangs with all kinds of error messages before reaching the GUI mode.
geometry-16heads-cylinders.jpg
Filename
geometry-16heads-cylinders.jpg
File size
1.26 MiB
Views
398 views
File comment
15565 x 16 x 63, ??? mode
File license
CC-BY-4.0

Conclusion

Apparently, the controller's own BIOS is either too buggy or too "clever", presenting either

  • LBA-specific emulated CHS geometry to the OS, or
  • the Normal CHS geometry,

depending on something I haven't yet figured out (the boot record content?).

Questions

  • What may be going on with the SATA controller?
  • How can I further diagnose the problem?
  • Has anyone had any success booting Windows 98 from a 128 GB SATA SDD (size matters) attached to a SiI3114 controller?

Reply 1 of 4, by hyoenmadan

User metadata
Rank Member
Rank
Member

With schizo controller BIOSes like this one, your best bet (if you will not do any RAID or strange stuff) is just zero fill the mbr and the first megabyte on your storage with some tool, and then repartition the disk on a board with SATA support. Be careful to choose the geometry you need for your purposes (Normal for old machines, LBA for machines which support it, Large for Compaq/HP/IBM/AST and sh*t propietary boads with Phoenix BIOSes) in the BIOS if it supports it (Award boards are the most suitable for this, but some AMI BIOSes allow to select the geometry), BEFORE PARTITIONING THE DISK. The geometry will be written once to the MBR tables, and that's what your BIOS will use later (and ever if you don't zero fill your drive again) when autodetecting the disk, as your SIL controller was doing before you decided to repartition it.

Use Partition Magic or Ontrack v9.57. These create very compatible tables with old configs, and handle these 3 geometries quirks (Normal, LBA, Large translations). Don't use gparted nor windows diskpart. These do some things which aren't compatible with older bioses and OSs.

Reply 2 of 4, by unix_junkie

User metadata
Rank Newbie
Rank
Newbie
hyoenmadan wrote on 2021-10-13, 15:08:

With schizo controller BIOSes like this one, your best bet (if you will not do any RAID or strange stuff) is just zero fill the mbr and the first megabyte on your storage with some tool, and then repartition the disk on a board with SATA support. Be careful to choose the geometry you need for your purposes (Normal for old machines, LBA for machines which support it, Large for Compaq/HP/IBM/AST and sh*t propietary boads with Phoenix BIOSes) in the BIOS if it supports it (Award boards are the most suitable for this, but some AMI BIOSes allow to select the geometry), BEFORE PARTITIONING THE DISK. The geometry will be written once to the MBR tables, and that's what your BIOS will use later (and ever if you don't zero fill your drive again) when autodetecting the disk, as your SIL controller was doing before you decided to repartition it.

Thank you for your response!

Forgot about zero-filling the beginning of the disk.
I recall doing this a couple of times, but haven't made this my regular practice.

Speaking of zero-filling the MBR, Linux fdisk seems to never write any bootloader code when partitioning, so the only way to do this is to run fdisk /mbr from MS-DOS 7.0. So, speaking of writing the right geometry into the MBR, how destructive fdisk /mbr is?

hyoenmadan wrote on 2021-10-13, 15:08:

Use Partition Magic or Ontrack v9.57. These create very compatible tables with old configs, and handle these 3 geometries quirks (Normal, LBA, Large translations). Don't use gparted nor windows diskpart. These do some things which aren't compatible with older bioses and OSs.

I generally partition the disk from Linux using fdisk (the lowest level possible), switching units (u) from sectors to cylinders, and enabling DOS compatibility mode (c). Seems to be compatible enough.

Later on, I generally do run Partition Magic and/or VCOM System Commander to verify the geometry and see whether there are no errors. Unfortunately, those can only be executed if the disk is attached to an onboard IDE controller (or is a SATA disk in IDE compatibility mode attached to a modern system). Unfortunately, they don't see any drives attached to a SiI3114 controller.

Attachments

Reply 3 of 4, by hyoenmadan

User metadata
Rank Member
Rank
Member
unix_junkie wrote on 2021-10-13, 19:55:

Forgot about zero-filling the beginning of the disk.
I recall doing this a couple of times, but haven't made this my regular practice.

If you do this from linux, you can just dd the first megabyte of your storage as well.

unix_junkie wrote on 2021-10-13, 19:55:

Speaking of zero-filling the MBR, Linux fdisk seems to never write any bootloader code when partitioning, so the only way to do this is to run fdisk /mbr from MS-DOS 7.0. So, speaking of writing the right geometry into the MBR, how destructive fdisk /mbr is?

DOS fdisk /mbr command doesn't write new device geometry values to the MBR if there are any partitions on the device. Nor partition magic does. Ontrack v9.57 only writes new device geometry values to the table, if you generate a new partition table from the partitioning tool menu (which destroys any partition existing in your drive), and that one is only available if you run Ontrack in advanced mode with /x switch.

unix_junkie wrote on 2021-10-13, 19:55:

I generally partition the disk from Linux using fdisk (the lowest level possible), switching units (u) from sectors to cylinders, and enabling DOS compatibility mode (c). Seems to be compatible enough.

Later on, I generally do run Partition Magic and/or VCOM System Commander to verify the geometry and see whether there are no errors. Unfortunately, those can only be executed if the disk is attached to an onboard IDE controller (or is a SATA disk in IDE compatibility mode attached to a modern system). Unfortunately, they don't see any drives attached to a SiI3114 controller.

Problem with linux is that all is done through linux drivers, instead using firmware to generate the translation values. What is right for the driver, may be wrong for the firmware, thus rendering the disk unbootable, or with a wonky behavior. Too many obscure compatibility problems from doing partitioning stuff from linux (or windows by the matters with Diskpart) vs zero problems just doing it from DOS with Ontrack, PM or even DOS7 FDISK, specially with older configurations. And these tools will automatically use whatever translation scheme your firmware got selected (Normal/Large/LBA) and apply the need fixes to them.

My advice remains. Plug your drive to the built in board ports (if you have a sata drive, you would need a board with compatibility mode SATA ports), configure the desired geometry scheme (Normal, Large, LBA), zero fill the drive first MB, shutdown and reboot, and then partition it from DOS with any mentioned tool (DM, PQmagic, DOS FDISK). After that, you can connect your drive again to your PCI controller. Its firmware will use your MBR written disk geometry scheme and values.

Reply 4 of 4, by canthearu

User metadata
Rank Oldbie
Rank
Oldbie

If you want to use the linux fdisk, you NEED to use:

fdisk -c=dos /dev/sd[x]

To enable DOS compatibility mode. Otherwise I have trouble with it trying to run DOS systems.

https://man7.org/linux/man-pages/man8/fdisk.8.html