Dear Mr. Brase, thanks for the detailed report... I wasn't paying attention back in March, so I don't recall what motherboard and BIOS you have there... but in general that probably doesn't make too much of a difference :-) What you're complaining about (boot sequence / ordering of disk controller channels and drives) is primarily a BIOS issue, with MS-DOS adding a handful of quirks of its own...
I'd like to praise you for coping so well (scouting by way of fighting). And, "Linux" is indeed the king of the hill, when it comes to disk partitioning - or rather, the tools such as fdisk, gdisk and others, coming in modern distroes (these tools keep evolving). Thumbs up for learning about the underlying principles. Your SATA controller does have a BIOS option ROM baked in, which fortunately is somewhat compatible with the BIOS on your motherboard. There are several ways (some of them "feral", plus the BBS API) of engaging the SATA option ROM or individual drives in the BIOS boot sequence. Generally the SATA controller's OPROM can hook maybe two different "software interrupts" (if memory serves) to force itself before or after the onboard BIOS boot sequence, or it can offer the disk drives detected as individual BIOS disk drives to the host BIOS for its own boot sequence (thus leaving the ordering of individual drives at the discretion of the host BIOS and its SETUP). I recall seeing some disk controller OPROM that would give you a choice, what method of hooking the boot sequence to use (INT18h, INT19h, PnP BBS). On top of that, different brands, generations, versions, and mobo-maker-flavours of BIOSes have different user-visible approaches to boot device ordering. This alone would warrant a howto of its own. Unfortunately some BIOSes were/are just stupid and limited in what they allow you to do. If you don't like the way these issues are handled by your particular combination of motherboard BIOS and the SATA controller's option ROM, you should check for a BIOS update especially for the motherboard's BIOS - if you haven't done that yet, chances are, that a more modern BIOS, if available, has added some intelligence in that area. I recall trying some Russian hacker tools for vintage Award BIOSes, that were able to improve support for large disk drives http://www.rom.by/articles/BP/index_english.htm Beware, this could brick your motherboard. I had a HW programmer as a retreat path. And, that project is really old now. It added support for disk drives up to 137 GB - this particular boundary has long been exceeeded, we are now past another boundary at 2 TB. And, it probably does nothing about the way the BIOS Boot Sequence is approached and manipulated by the SETUP of your BIOS (and its runtime logic). Unless you install a device driver, DOS uses disk drives it learns about from the BIOS - and accesses them via the BIOS Int 13h services. Accepts them in the order as supplied by the BIOS. Windows 95 and 98 would do the same for disks from controllers where they don't have their own 32bit driver. What *drive* gets selected for loading the 1st-stage bootloader (in the drive's MBR), that's strictly a choice on part of the BIOS including any OPROMs hooking it. MS-DOS does not have a say. What *partition* on that drive (or some other drive?) gets chain-loaded next, that's the bootloader's choice. Actually it may be a second boot-loader stage in the "active" partition's boot sector (MS-DOS style), or it can be a file from a file system, or whatever... depends on what bootloader starts in the first stage and how capable it is. I recall noticing some shenanigans with primary vs. extended partitions on disk drives... MS-DOS would give the letter C: to the first primary partition it would find, following up with *primary* partitions on other drives, and then any extended partitions would follow. I seem to recall that multiple "primary" partitions per drive were not supported at all? I.e. MS-DOS would not "see" primary partitions other than the first one in the drive's partition table. FreeDOS seems more liberal in those respects. Not paying attention to the secondary IDE channel, if the primary channel is unoccupied, that sounds like a pretty dumb BIOS to me... DOS cannot see disks on the SATA controller, yet Linux is able to boot from the SATA card? How large are your SATA drives? What particular version is "MS-DOS 6" are you using - is that a "6.22", or rather "6.0" ? Isn't this merely a matter of partition size? I'm wondering if loading some driver such as UHDD / UIDE / udma2 would improve something about large disk support. Won't help you with the boot disk, but could improve accessibility of the non-boot drives: https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/udma/deve l/ https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions /1.2/repos/drivers/uide.zip https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions /1.2/repos/drivers/uhdd.zip But I wouldn't expect too much. A nice informative README in the udma2_27 package says that the BIOS OPROM on your SATA board does support large drives and effectively circumvents the motherboard BIOS by hooking the INT 13h BIOS services. And, the Silicon Image chip is not supported by the UDMA2 driver. Which makes good sense. The UIDE/UHDD caching drivers apparently intercept INT 13h for drives that they do not natively support... which might change something about how DOS sees the drives? Not sure... I'd give this a better chance in FreeDOS, rather than ancient MS-DOS. If you're stuck with old hardware, for practical reasons or just for the sport, you have my respect and sympathy. More modern hardware would probably allow you to run DOS too, and might rid you of some of the ancient quirks that you have reported :-) Frank On 23 Jun 2021 at 4:37, Jon Brase wrote: > Continuing a conversation from back in March, I took Liam's suggestion > of using a PCI SATA adapter. I ended up getting a card with a SiI3114 > chipset. I actually got the card a while ago, but took my sweet time > getting around to installing it. > > The good: The card is bootable, and with only a SATA drive on it the > machine will boot Linux and FreeDOS. Linux will recognize both SATA and > IDE drives in any combination and configuration. > > The bad: My configuration includes MS-DOS 6, which will not see any > drives on the SATA card at all, so a mixed configuration is required, > despite Liam's warnings. This does have consequences: > > The ugly: If the IDE drive is mounted on the secondary IDE channel, > neither MS nor FreeDOS will see the IDE drive. If the IDE drive is > mounted on the primary IDE channel, the SATA card is not bootable (the > BIOS seems to try booting from the primary IDE channel and then gives up > without passing boot off to the SATA card, so Grub has to be on the IDE > disk), but at least both MS and FreeDOS will see the IDE disk. FreeDOS > itself will still see the SATA disk. However, in this configuration > FreeDOS fdisk claims to find no fixed disks. MS fdisk claims a bogus HDD > size, so only Linux tools can be used to reliably partition the disk > (despite giving dire warnings about messing with FAT volumes containing > bootable MS-DOS systems). My configuration includes Win95 (though I can > run most of what I'd run there on other machines, so it's not as > critical). Win95 has no drivers for the SATA card (earliest drivers are > WDM drivers, so Win98 at the earliest). Win98 is supposed to support the > card, but its installer seems to run completely under DOS, and doesn't > give an opportunity to load drivers before installing, so it only sees > the IDE disk. Because of my BIOS's limitations in dealing with large > drives, it will take some finagling of partition sizes and locations to > allow both DOS 6 and Win98 to boot from the IDE disk whilst giving both > a decent amount of space (though hopefully Win98 will be able to use a > FAT32 partition on the SATA disk as a data/program disk once the drivers > are installed). > > Still, despite everything under "the ugly", the most crucial elements of > my configuration are up and running with a lot more space than they used > to have. > > Jon Brase > > On 3/11/21 4:37 AM, Liam Proven wrote: > > I do not see any info about what the host machine is. If it is new > > enough to have PCI slots, then a SATA controller with a BIOS of its > > own should, in theory, bypass all this nightmare. Citation with model > > recommendations: > > https://www.vogons.org/viewtopic.php?t=62958 > > > > A firmware-equipped SATA controller (i.e. not some cheap thing that > > just adds additional ports and is not bootable) will appear to the PC > > as a SCSI controller and its firmware will take over the INT13 BIOS > > calls for disk access completely. > > > > If you do decide to go that route, though, I advise _against_ mixing > > SATA and EIDE/PATA disks. Let the SATA controllers' firmware take over > > completely and do not use the motherboard's EIDE channels at all. > > > _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
