Windows 98 hard drive limit 127 GB

Partition size doesn't matter, if your drive is larger than 127 GB you'll get data corruption under Win9x. I think RLoew had a patch for this though.

I've been looking into this further, to try and clarify what this limit actually means. From what I understand, the issue is that the native disk controller driver for all DOS/9x only support up to 28-bit LBA (128GB). But in theory, a drive controller with its own drive driver (Windows device driver, not just its BIOS), could work around this. This seems to be why many people have said that the BOOT drive needs to be on a smaller drive. I think what this means is simply that the bootable partition can't exceed the 28-bit LBA boundary, otherwise the native disk controller for booting might be unable to read from the disk.

The motherboard controller and BIOS I am certainly already has support for 48-bit LBA. It's a much more modern board than would otherwise normally run Windows 98.

Can anyone confirm?

Joseph_Joestar wrote on 2022-07-12, 03:24:

Windows 98 hard drive limit 127 GB

Partition size doesn't matter, if your drive is larger than 127 GB you'll get data corruption under Win9x. I think RLoew had a patch for this though.

Both partition size and disk size can be issues.

I stick with partition sizes <127GB to avoid that issue, but there are patches, AFAICR .

The issue with drives bigger than 127GB is due to a limitation in ESDI_506.PDR bundled with Windows . This file is used by the default Windows IDE controller driver . This can either be addressed by a patched ESDI_506.PDR driver (there are several options there, including by RLOEW) or by using a controller driver that does not use ESDI_506.PDR and supports 127GB and bigger HDD (Promise, Silicon Image, SCSI controller, etc).

Finally, if you want to avoid issues with big drives and the bundled version of scandisk, fdisk, etc , I suggest https://web.archive.org/web/20210505030944/ht … iles/BHDD31.ZIP which includes a patched version of ESDI_506.PDR .

See also Re: Formating and partitioning disk for MSDOS 6.22 for more information .

Kahenraz wrote on 2022-07-12, 03:45:

I've been looking into this further, to try and clarify what this limit actually means. From what I understand, the issue is that the native disk controller driver for all DOS/9x only support up to 28-bit LBA (128GB). But in theory, a drive controller with its own drive driver (Windows device driver, not just its BIOS), could work around this.

RLoew goes into more detail about this in the manual for his patch:

HIGH CAPACITY DISK PATCH manual wrote:

The High Capacity Disk Patch Program patches Windows 98/98SE/ME to provide direct support for Hard Drives larger than 137GB without requiring a controller card or the Intel Application Accelerator which can only be used with some Intel Chipset Motherboards. The Patch installs support for the 48-Bit LBA addressing mode required for Hard Drives larger than 137GB.

This patch updates the standard IDE controller (ESDI_506.PDR in the Windows SYSTEM\IOSUBSYS Directory). If you are using a controller card such as the Promise Card included with some Maxtor or Western Digital drives, this Patch will not affect drives connected to the Card(s). If you have installed the Intel Application Accelerator, this driver may no longer be used and the Patch is not needed and may not have any effect. SATA drives may or may not be supported depending on configuration.

Personally, I stick with drives smaller than 128 GB for Win9x, so I haven't used this patch myself.

Kahenraz wrote on 2022-07-12, 03:45:

I've been looking into this further, to try and clarify what this limit actually means. From what I understand, the issue is that the native disk controller driver for all DOS/9x only support up to 28-bit LBA (128GB). But in theory, a drive controller with its own drive driver (Windows device driver, not just its BIOS), could work around this. This seems to be why many people have said that the BOOT drive needs to be on a smaller drive. I think what this means is simply that the bootable partition can't exceed the 28-bit LBA boundary, otherwise the native disk controller for booting might be unable to read from the disk.

The motherboard controller and BIOS I am certainly already has support for 48-bit LBA. It's a much more modern board than would otherwise normally run Windows 98.

Can anyone confirm?

Having an LBA48 capable IDE BIOS (either for the native IDE on the motherboard, if using that) or in the form of a disk controller with a BIOS supporting LBA48 is highly recommend if you don't want to corrupt your >127G B drive under real-mode DOS which use INT13h (i.e. outside of Windows) . This applies to any physical drive that will be accessed under DOS, not just the boot drive . If the motherboard's native IDE BIOS does not support LBA48, XTIDE BIOS can be used as well . One reason why this is important to have is to avoid Windows corrupting data before the protected mode driver kicks in (see below), namely during early boot AND when Windows decides to run Scandisk at boot in real-mode DOS .

When running Windows, a protected mode driver is used, like ESDI_506.PDR or one for a given PCI IDE/SATA/SCSI controller (Promise, Silicon Image, etc). This driver must support LBA-48 or there will be problems . One alternative is to force Windows to use DOS compatibility mode for disk access, in which case it fall back to accessing the disk using BIOS INT13h (assuming it supports LBA48, see above) which will also work (at the expense of performance) if the previously mentioned BIOS supports LBA48 .

EDIT : Here is my successful experience with Windows 98 SE on an Asus P3B-F using its native IDE controller with XTIDE BIOS and Intel Application Accelerator and 1TB hard drive (which I filled almost to capacity to 360GB to check for corruption) : Adding XT-IDE option ROM to Asus P3B-F BIOS [Thanks to DenizOezmen, it actually works!!!]

darry wrote on 2022-07-12, 03:56:

Both partition size and disk size can be issues.

I stick with partition sizes <127GB to avoid that issue, but there are patches, AFAICR .

What I meant was, simply creating a 127 GB partition on a 500 GB drive won't stop data corruption under Win9x.

As you say, a third-party patch or a separate controller card with its own driver is needed to solve the problem.

Joseph_Joestar wrote on 2022-07-12, 04:18:

darry wrote on 2022-07-12, 03:56:

Both partition size and disk size can be issues.

I stick with partition sizes <127GB to avoid that issue, but there are patches, AFAICR .

What I meant was, simply creating a 127 GB partition on a 500 GB drive won't stop data corruption under Win9x.

As you say, a third-party patch or a separate controller card with its own driver is needed to solve the problem.

I agree .

To be clear, you need a separate patch for each issue (one for partition size and one for disk size), unless you stick to <127GB partitions, in which case you only need to worry about the controller driver that supports LAB48 (either patched ESDI_506.PDR or an LBA48 capable driver for the specific controller being used).

Having BIOS 13h LBA48 support for any Windows 9x install with a >127GB drive is also highly recommended (possibly essential) for any physical drive that might be accessed under DOS before the protected mode driver kicks in. If the boot drive is smaller than 127GB and none of the other physical drives that may be bigger than 127GB are ever accessed outside of Windows, it may be enough to have an LBA48 capable driver EVEN WITHOUT LBA48 BIOS support . However, if Windows decides to run the real mode DOS version of scandisk on one of those non boot drives that are bigger than 127GB, you may be in for a bad day .

EDIT: Corrected multiple typos and ambiguities

Joseph_Joestar wrote on 2022-07-12, 04:07:

RLoew goes into more detail about this in the manual for his patch:

To confirm, this patch fixed my problem perfectly. I am now able to access all folders and files that were giving me problems before and was able to stress test this reliably by running Doom 3 off of this partition. This is exactly what I was hoping for. Not just a fix, but to confirm with certainty what the problem actually was.

From what I can tell, Windows ME defrag and scandisk should work with this patch:

https://www.mdgx.com/98-5.htm#WDIW

And DOS 7.1 format and scandisk should be using BIOS INT13h and be fine. I would also use the latest FreeDOS fdisk for safety.

Does anyone know if there are any other issues to be aware of after this patch?

For reference, here is a screenshot of the error that I was receiving while trying to access certain folders prior to applying this patch.

Kahenraz wrote on 2022-07-12, 05:24:

To confirm, this patch fixed my problem perfectly. I am now able to access all folders and files that were giving me problems be […]
Show full quote

Joseph_Joestar wrote on 2022-07-12, 04:07:

RLoew goes into more detail about this in the manual for his patch:

To confirm, this patch fixed my problem perfectly. I am now able to access all folders and files that were giving me problems before and was able to stress test this reliably by running Doom 3 off of this partition. This is exactly what I was hoping for. Not just a fix, but to confirm with certainty what the problem actually was.

From what I can tell, Windows ME defrag and scandisk should work with this patch:

https://www.mdgx.com/98-5.htm#WDIW

And DOS 7.1 format and scandisk should be using BIOS INT13h and be fine. I would also use the latest FreeDOS fdisk for safety.

Does anyone know if there are any other issues to be aware of after this patch?

You may still have issues with >127GB partitions. Though I can't locate a reliable source of info on that right now .

I strongly recommend that you DO NOT try to use RLOEW's FAT32 TRIM utility for DOS on an SSD drive partitioned with FreeDOS' version of fdisk . See Corruption issue when using rloew's TRIM.EXE (TRIM utility for DOS) with FreeDOS FDISK 1.2.1/1.3.1 partitioned DISK

Reason for this :

darry wrote on 2020-05-07, 14:57:

Well this is interesting. […]
Show full quote

Well this is interesting.

If I create a second partition, whether primary or extended with a logical volume, using FreeDOS' FDISK 1.2.1 command , TRIM.EXE corrupts it when run on the first partition .
BUT
When I create a second primary partition extended partition with a logical volume using Windows 10 disk management tool (formatted to FAT32 using Easeus Partition Master, but I do not think the formatting tool matters), or create an extended partition with a FAT32 logical volume using EASEUS Partition Master, I am unable to corrupt anything with TRIM.EXE .

So FreeDOS FDISK does something in a way that TRIM.EXE does not like . Whether that's a bug in FreeDOS FDISK 1.2.1 and 1.3.1 BETA (tried both) or TRIM.EXE, I do not know .

EDIT: Creating a second FAT32 primary partition using Easeus Partition Master also works with TRIM.EXE without corruption .

Moral of the story : make sure you have backups when using TRIM.EXE (especially for the first time) .

EDIT2 : For the fun of it, I tried using Easeus Partition Master to FAT32 format partitions created with FreeDOS FDISK 1.3.1 . Easeus Partition Master said there were partition errors or anomalies (forgot exact wording) . Partition Master is by no means a reference in this matter, but still .

EDIT 3: Tried Freedos XFDISK . It's a BETA and it shows : it won't let me enter 6 digits in the partition size field (field is pre-populated with max value and leftmost digit cannot be changed) .

EDIT 4 : Linux fdisk (lubuntu-16.04.3) works well too . TRIM.EXE has no issues . I also just noticed that Primary partitions 2 and greater, when created in Windows 10 disk management console or Easeus Partition Master, are only visible in Windows 98 SE , not in DOS 7.1 (hidden flag is set) . All primary partitions created by Linux fdisk are visible in both DOS 7.1 and Windows 98SE and properly aligned as well .

I partitioned all disks using fdisk from a Fedora LiveCD. This system will also be configured with a GRUB bootloader to boot into Linux, so I can trim there as necessary.

Thank you for the warning. Was there any consensus on what the issue was?

Kahenraz wrote on 2022-07-12, 07:13:

I partitioned all disks using fdisk from a Fedora LiveCD. This system will also be configured with a GRUB bootloader to boot into Linux, so I can trim there as necessary.

Thank you for the warning. Was there any consensus on what the issue was?

AFAIK, Linux will not TRIM FAT32 filesystems (unless this has changed recently), nor will Windows 10 Re: Planning to install SSD in my Windows 98 machine. Help, advice, suggestions, etc.?

As for the root cause, I have no idea, TBH . AFAIK, I am the only one who has ever reported that issue, so maybe this is specific to my system, but considering the fact that I can only reproduce the issue with FreeDOS' fdisk but cannot with the 3 other partitioning utilities I have tried. I have not dug deeper to try to see what FreeDOS fdisk seems to do differently versus the other . If you have a spare SSD and some free time, maybe you could try it . Maybe I'm crying wolf for a bug that nobody else will ever experience .

I noted that Partition Magic 8 always reported correctable issues with the partition table after installing FreeDOS. It mentioned something about the CHS and LBA values being out of sync. It's possible that this is responsible for the data corruption.

I have since moved to a 500GB SSD and this causes problems for PM8 that I wasn't able to work around, which I assume is probably also due to the LBA being out of range.

Kahenraz wrote on 2022-07-12, 07:45:

I noted that Partition Magic 8 always reported correctable issues with the partition table after installing FreeDOS. It mentioned something about the CHS and LBA values being out of sync. It's possible that this is responsible for the data corruption.

I have since moved to a 500GB SSD and this causes problems for PM8 that I wasn't able to work around, which I assume is probably also due to the LBA being out of range.

I stopped using Partition Magic a long time ago (I still have my last retail bought copy somewhere). Once bootable Linux distros on CD/DVD/flash drive became a thing, it just made sense to use those, IMHO .

On the modern Windows front, I bought Easus Partition Master . IMHO, it works very well and essentially does what Partition Magic did and more .

I'm just now realizing that this logical partition also isn't visible from DOS. Is there any way to fix this as well?

Kahenraz wrote on 2022-07-18, 13:25:

I'm just now realizing that this logical partition also isn't visible from DOS. Is there any way to fix this as well?

I only ever use primary partitions under DOS/Windows 9x (you can have up to 4). I don't even remember if I have ever created an extended partition and logical drives since I started using Linux fdisk to partition for DOS/Windows 9x systems .
Anyway, I would check if the partition type you are using is not one the hidden types .

00 Empty 24 NEC DOS 81 Minix / old Lin bf Solaris
01 FAT12 27 Hidden NTFS Win 82 Linux swap / So c1 DRDOS/sec (FAT-
02 XENIX root 39 Plan 9 83 Linux c4 DRDOS/sec (FAT-
03 XENIX usr 3c PartitionMagic 84 OS/2 hidden or c6 DRDOS/sec (FAT-
04 FAT16 <32M 40 Venix 80286 85 Linux extended c7 Syrinx
05 Extended 41 PPC PReP Boot 86 NTFS volume set da Non-FS data
06 FAT16 42 SFS 87 NTFS volume set db CP/M / CTOS / .
07 HPFS/NTFS/exFAT 4d QNX4.x 88 Linux plaintext de Dell Utility
08 AIX 4e QNX4.x 2nd part 8e Linux LVM df BootIt
09 AIX bootable 4f QNX4.x 3rd part 93 Amoeba e1 DOS access
0a OS/2 Boot Manag 50 OnTrack DM 94 Amoeba BBT e3 DOS R/O
0b W95 FAT32 51 OnTrack DM6 Aux 9f BSD/OS e4 SpeedStor
0c W95 FAT32 (LBA) 52 CP/M a0 IBM Thinkpad hi ea Linux extended
0e W95 FAT16 (LBA) 53 OnTrack DM6 Aux a5 FreeBSD eb BeOS fs
0f W95 Ext'd (LBA) 54 OnTrackDM6 a6 OpenBSD ee GPT
10 OPUS 55 EZ-Drive a7 NeXTSTEP ef EFI (FAT-12/16/
11 Hidden FAT12 56 Golden Bow a8 Darwin UFS f0 Linux/PA-RISC b
12 Compaq diagnost 5c Priam Edisk a9 NetBSD f1 SpeedStor
14 Hidden FAT16 <3 61 SpeedStor ab Darwin boot f4 SpeedStor
16 Hidden FAT16 63 GNU HURD or Sys af HFS / HFS+ f2 DOS secondary
17 Hidden HPFS/NTF 64 Novell Netware b7 BSDI fs fb VMware VMFS
18 AST SmartSleep 65 Novell Netware b8 BSDI swap fc VMware VMKCORE
1b Hidden W95 FAT3 70 DiskSecure Mult bb Boot Wizard hid fd Linux raid auto
1c Hidden W95 FAT3 75 PC/IX bc Acronis FAT32 L fe LANstep
1e Hidden W95 FAT1 80 Old Minix be Solaris boot ff BBT

I used Linux to partition it as well, to align the partitions properly since it's a 4k sector drive. I ended up using FreeDOS 1.3 instead of MS-DOS 7.10, and that fixed the problem. It's possible that it's unable to cope with the partition extending beyond of the 137GB boundary. It appears just fine in Windows 98 and ME, but requires a 48-bit LBA patch to be accessible there. I don't think it should be needed in DOS though, since uses BIOS calls instead.

http://web.allensmith.net/Storage/HDDlimit/Int13h.htm

http://web.allensmith.net/Storage/HDDlimit/Li … s.htm#Tech5p014

https://thestarman.pcministry.com/asm/mbr/Limits.htm

https://thestarman.pcministry.com/index.html

https://thestarman.pcministry.com/asm/bios/index.html

https://handwiki.org/wiki/INT_13H

https://www.informit.com/articles/article.asp … 31238&seqNum=14

http://web.inter.nl.net/hcc/J.Steunebrink/bioslim.htm

darry wrote on 2022-07-12, 07:32:

AFAIK, Linux will not TRIM FAT32 filesystems (unless this has changed recently)

It has, FITRIM for FAT32 was implemented and was released with Linux 4.19 back in October 2018.