VOGONS


Reply 20 of 20, by CharlieFoxtrot

User metadata
Rank Member
Rank
Member
wierd_w wrote on 2023-09-14, 12:59:
It's from the CHS geometry schema-- https://en.wikipedia.org/wiki/Cylinder-head-sector […]
Show full quote
CharlieFoxtrot wrote on 2023-09-14, 10:17:
digistorm wrote on 2023-09-14, 09:37:

I would try using a smaller HDD. A lot of older BIOSes don't like drives larger then 528 MB. Others don't like going above 2 GB. Autodetect can go all kinds of wrong if you exceed that size. Some drives support a jumper setting to limit it's size to 2GB, sometimes that helps. Or you can manually reduce the number of cylinders reported by the drive (sometimes it is put on the label on top) to 1024 to prevent an overflow from happening in the BIOS code. But generally, using drives > 512 MB can cause trouble with those (older) 486 systems and was not period correct anyways.

These limitations are indeed strange sometimes. I have been putting together late 486 system which is based on Zida 4DPS 2.11 with latest stable bios. I slapped a 1083MB HDD in it and BIOS detects drive parameters 100% correctly like the drive sticker says. Even better, everything works correctly. Except maximum space I have available is the famous 503MB, so I can't even make another partition. It feels almost like completely artificial limitation in BIOS.

It's from the CHS geometry schema--
https://en.wikipedia.org/wiki/Cylinder-head-sector

colluding with the INT13 CHS limits--
https://www.win.tue.nl/~aeb/linux/Large-Disk-4.html

this results in a maximum allowable geometry (for DOS), being (1024 cyls)(16 heads)(63 sectors per track)(512 bytes per sector) == 528482304 bytes.

This was addressed with improvements in the number of bits used by INT13, and later by ECHS, before finally being retired entirely for direct LBA.

This is where DDOs, (and better BIOSes) come into play.

A dynamic disk overlay is a small program that lives on the boot sector of the hard drive, rather than the boot sector for an OS. It loads BEFORE the OS, and take over the disk controller, loads a handler into RAM to handle software interrupt 13, then populates it with data it collects from interrogating the hard drive itself. To prevent itself being deleted/overwritten, it subtracts the first sector from the total sector count, and then lies afterward, presenting the **NEXT** logical sector as if it were the boot sector, so that disk utilities never touch its code.

There are 2 currently available from the days of Yore, that work with basically anything, and have been gifted to the masses for general non-commercial use. EZ-Drive and Ontrack Disk Manager.
https://www.philscomputerlab.com/western-digital.html

https://www.philscomputerlab.com/ontrack-disk-manager.html

Better BIOS is where XT-IDE comes into play. This is a small BIOS ROM routine that gets started by AT class computers before the OS loading routine starts. It can either be integrated onto an IDE controller, or be placed on a network card that has a socket for a PXE bios. (You place XT-IDE's bios there instead!) When the system tries to boot, this ROM routine executes, Takes over from the native BIOS's INT13 handler by altering the vector table, autodetects the connected drives, populates the INT13 variables, then passes on to OS load.

Interesting info about the bios!

Yeah, I network every DOS system in any case, so my plan is to use XTIDE bootrom with NIC like I did with my IBM PS/2. Actually I have already programmed the eeprom, but I have had other projects recently so this system has been in the back burner in the recent weeks, so I haven’t finished the setup.

IMO XTIDE bootrom is more elegant solution that overlay programs, but both are fine options.