rloew

Device Drivers such as IOS.VXD and ESDI_506.PDR use 64-Bit Sector Arguments. The Interrupt 13 Extensions (DOS) also use 64-Bit Sector Numbers. The existing ESDI_506.PDR files, including LLXX's version and my High Capacity Disk Patch, ignore the upper 32 Bits. I created versions of my High Capacity Disk Patch and BOOTMAN Overlay to use the additional 16 Bits supported by the 48-Bit LBA Protocol. The IO.SYS and VFAT.VXD Filesystem Drivers use 32 Bits. I altered the way Logical Sector Numbers are mapped to Physical Sector Numbers. This allowed me to create Partitions of up to 2TB starting above the 2TB limit. 24 Partitions can be defined to provide a total space of 48TB. It may be possible to redo Cluster mapping. If so, the size of a single Partition could be increased to at least 32TB using 256 Sectors per Cluster. I have already developed Patches for IO.SYS and VFAT.VXD that support 256 Sectors per Cluster.

I tested Fast Defrag 2.3.1 (reports 2.3) with my Patch to see if the problem was memory or the MaxPhysPage workaround. I did not get error messages but the Cleaning Command would not display it's wait message and would never complete when there was too much memory. Between 1280MB and 1664MB it would work once. With 1664MB or more RAM, it would never work. This indicates that Fast Defrag has a problem handling large amounts of RAM. The other two Programs have problems when used as a workaround. These problems do not exist when using my Patch instead of a workaround. The problems are not related to the amount of memory. My Patch enables all RAM to be used so MaxPhysPage is not needed. This eliminates the issue with MSCONFIG.EXE Since the Patch enables all RAM to be used, there is no reason to use XMSDSK for Swap since better performance would be obtained by disabling Swap entirely.

That might have been OK if I had a lot of business customers. So far all of my customers have been home users. Maybe, but then there would be no point in developing Windows 9x Patches. I could work on the 2TB limit in Windows XP and Vista instead.

SATA uses nearly the same commands as PATA so it is subject to the same issues as PATA. Most SATA controllers come with their own drivers so 48-Bit LBA support depeds on the driver used. Being a newer standard, it is more likely that a SATA driver would support 48-Bit LBA but there are no guarantees expecially with older drivers. Some motherboards with SATA built into their chipsets are compatable with the ESDI_506.PDR driver. If ESDI_506.PDR is used then there will be no support for 48-Bit LBA. In addition, the MSHDC.INF file will incorrectly configure some of these SATA drivers causing problems especially when IDE and SATA drives are used together. In anticipation of the 2TB limit being reached, I have developed true 48 Bit versions of my Patches and a couple of workarounds to enable Windows 98 to utilize up to 52TB.

I haven't experimented with it so I don't know if the power management handler causes any problems. In normal operation it should have no effect. It might make a difference when suspending or hibernating. Of course it is larger and uses slightly more resources. It is an update. All changes made between 2222 and 2225 are present.

The difference between the 2225 and 2226 versions is as follows: Several routines were moved from the PCOD Segment to the LCOD Segment so they would be preloaded. A Power Handler is registered that allows the Virtual Power Management Device to flush the Driver.

The ECS GEFORCE 6100SM-M Motherboard is a nVidia MCP61S Based system for the AMD CPU. The manual say it can support up to 16GB of RAM using two slots. I have 2x2GB of RAM installed totalling 4GB. The BIOS has a setting that determines the limit of 32-Bit RAM. Additional RAM is shifted above 4GB into the 64-Bit Address Space. The setting is a 8-Bit HEX value that sets the limit in 16MB increments. The default is C0 which provides 3GB of 32-Bit RAM. With the on-board video disabled, I was able to set the value to E4. This provides 3648MB. 1MB and 64K are reserved by the BIOS leaving just under 3647MB. I was able to run my modified Windows 9X using this setting.

With the proper Patches, Windows 98/SE/ME can run as close to 4GB as your Motherboard will map to the 32-Bit Address Space. Most Motherboards will only map 3GB to the 32-Bit Address Space pushing any additional memory above the 4GB boundary. I found an ECS Motherboard that allowed me to tweak this limit, allowing me to run Windows 98/SE/ME with 3647MB of RAM.

The unpatched ESDI_506.PDR driver checks if the sector number is within the 28-Bit range. Whoever designed the driver never wrote the code to handle higher sector numbers, or reject them. The code falls through to the older CHS algorithm. The CHS code does the math using unintialized geometry and 16-Bit cylinders to come up with settings that are sent to a drive which has never been initialized for CHS. The end result is a complex pattern of accesses over a portion of the 137GB range, intermixed with disk errors.

Just because you don't INTENTIONALLY write to a Partition does not mean writes don't occur. Win 9X creates RECYCLE bins, WinME creates restore points, and Win XP writes Disk Management info, without user interaction. This type of damage can be very localized and not show up unless you test every byte of every file in every Partition. The unpatched ESDI_506.PDR does not simply wraparound when crossing the 137GB boundary but jumps around to different areas in a complex pattern.

Motherboard chipsets that have SATA integrated into them, rather than a separate chip, often appear to Windows 98SE as additional IDE controllers. Windows 98SE does not correctly configure these additional controllers causing lockup during boot. So far I have only resolved the problem for the MCP61S Chipset.

Even a Patched Windows 9X System is not safe if the BIOS does not support 48-Bit LBA. During Startup, Windows 9X uses DOS and the BIOS to load software and update system files (WININIT). It also uses the BIOS in Safe Mode or Compatability mode. Windows XP and Vista also have to use the BIOS to load their Kernels and Disk Drivers during Startup. This leaves a window of vulnerability in which any Writes to the higher partitions could corrupt data in the lower ones. Since the damage could be just a few bytes, as occurs when Windows XP tags an extended partition table entry, the damage may not be obvious Neither LLXX's Patches nor my High Capacity Disk Patch solve this problem. I wrote a separate package called BOOTMAN for my customers to provide an overlay to the BIOS to provide the necessary support.

The problem is not in Windows, when it is Patched, it has no problem even when the BIOS does not support 48 Bit-LBA. The problem occurs in the early boot phase when Windows loads itself, runs SCANDISK or does Real Mode tasks such as WININIT. Safe Mode or running in Compatability Mode will also fail since it uses the BIOS code. Programs run in Real Mode, such as DOS, FDISK and the Windows Install CD will also fail. Most Disk Management tools use System Calls to access Hard Drives. They do not know anything about 48-Bit LBA mode, so they should work. Some may simply overflow from working with drives larger than they were tested with. Partition oriented tools such as SCANDISK and DEFRAG are affected by Partition size rather than Physical Hard Drive size. My Patch works in a similar manner to LLXX's. The difference is that I do not provide the Drivers but Patch whatever is there. This avoids any issue of Microsoft Copyright problems. Ontrack does not appear to support 48-Bit LBA properly and may disable BIOS support, if present. As mentioned above, BIOS or DDO support is required for safe operation with large Hard Drives. Ontrack does not appear to do sector shifting as some older DDOs did. These older DDOs caused serious problems since the Drives became unreadable if moved or if the DDO was removed or damaged. Being unable to get any of the Hard Disk Vendor DDOs to work and wanting to work with my own Multi-Boot Manager, I wrote my own DDO called BOOTMAN. It only provides 48-Bit LBA support, without a lot of bells and whistles, and comes in different versions for different needs. One version is loaded from a Floppy Disk so it can work with any Boot Manager since nothing is changed on the Hard Drive.

I ran some experiments on OnTrack and was unable to get it properly support 48-Bit LBA. As you found out the hard way, it is not safe to test 48-Bit LBA support on a Hard Drive by writing test files above the 137GB Limit while having important files below the limit. BIOS issues, bad DDOs and Windows XP RTM, and to a lesser extent Windows 9X, will write data intended to go above the 137GB limit to other locations below the limit destroying the data you thought was safe. The new files are probably mostly still OK. You would have to read them with the same bad driver and get around the probably corrupted partition table. You will need the help of the CIA to get back any of your old data. I wrote my BOOTMAN Package to provide the necessary support that older BIOSes, and some buggy newer BIOSes, lack. It is compatable with LLXX's files and should work with the Autopatcher. I have no problem with new threads for these subjects. Links to them would of course be appreciated. It was a recent posting about my BOOTMAN Package that appears to have triggered these discussions when people saw my new RAM Limitation Patch on my website.

I have written a set of Programs that add to or replace the BIOS Hard Disk Drivers, providing 48-Bit LBA Support. If your BIOS does not support 48-Bit LBA and a BIOS update is not available, one of these programs will provide the necessary support. Although designed to work with my High Capacity Disk Patch, they will work with the LLXX files. Rudolph Loew rloew@hotmail.com