Enable48BitLBA | Break the 137Gb barrier!

[LLXX]

I've decided to go ahead with 4.10.2226, it is now available for download. However, it is not for all machines - use it only to replace an existing 4.10.2226 without Enable48bitLBA.

As such, work on Win95 versions 4.00.1111 and 4.00.1119 will now proceed.

Edited July 30, 2006 by LLXX

[Acheron]

As of HDD corruption might be possible with high PCI bus speed I can do some experimental tests with PCI bus speeds up to 42 MHz. Sorry no tests results yet, I spent most time translating Revolutions Pack Lite to Dutch.

[Petr]

It was full. And I have .SFV files for most of the data.

You still don't think it's possible?? At Micro$oft, "not supported" doesn't mean "not possible". It means "we don't want you to do it".

I have created 137 GB disk as disk D, then filled it (Win95 OSR2.1 ESDI_506.PDR 4.00.1111) to 100 GB by some files with known MD5 sum, and then calculated the MD5 sums in Windows 95 environment - and everything was good.

It would be very good to know any examples of problems above 32 GiB barrier, I still believe that Mictosoft had some reason to write that KB article.

Petr

[jaclaz]

it's just like mixing apples and oranges which does NOT make any sense!

Actually, as scientifically proven here:

http://www.improb.com/airchives/paperair/v...1-3-apples.html

apples and oranges are NOT much different.

...and generally calling another person "fool" is not very nice, I guess you can disagree with LLXX opinions and ideas without calling him her names, just take it easy

jaclaz

Edited July 30, 2006 by jaclaz

[LLXX]

I have created 137 GB disk as disk D, then filled it (Win95 OSR2.1 ESDI_506.PDR 4.00.1111) to 100 GB by some files with known MD5 sum, and then calculated the MD5 sums in Windows 95 environment - and everything was good.

It would be very good to know any examples of problems above 32 GiB barrier, I still believe that Mictosoft had some reason to write that KB article.

Petr

Again, excellent. It looks like the original Win95 ESDI_506.PDR is good up to 137Gb. Win95 also internally uses a 32-bit linear sector address (while 2K/XP+ use 64-bit if I remember correctly).

I have stated this in my past posts, but I don't think I made it clear enough.

First, the infamous KB: http://support.microsoft.com/kb/246818/EN-US/

Hard disks and other media larger than 32 GB in size were not available at the time Windows 95 and subsequent Windows 95 OEM Service Releases were developed. The changes required to support media larger than 32 GB in Windows 95 would require architectural changes that cannot be supported on these platforms. Microsoft Windows 98 does support IDE hard disks larger than 32 GB in size, if the hotfix documented in the following Microsoft Knowledge Base article is applied:

243450 (http://support.microsoft.com/kb/243450/EN-US/) ScanDisk Errors on IDE Hard Disks Larger Than 32 GB

Notice the emphasized wording. It is implied that Windows 98 does *not* support IDE hard disks larger than 32 GB in size unless KB243450 fix is applied, which updates ESDI_506.PDR to 4.10.2186 (FE) or 4.10.2225 (SE). However, once again notice the wording:

This problem may occur on computers that use a Phoenix BIOS and use the Phoenix BitShift translation algorithm to report the geometry of large IDE hard disks. On such computers, the Windows protected-mode IDE disk driver (Esdi_506.pdr) may not correctly recognize the translation mode for the drive, resulting in an inability to access areas of the drive beyond the first 32 GB.

I have two 120GB drives, one of which has nearly 90GB of data on it. I scandisk them regularly and nothing odd is noticed (the occasional lost clusters following a bad shutdown, wrong freespace count, all quite common and non-threatening errors). I am using ESDI_506.PDR 4.10.2222 - the Original file of 98SE release. So it seems, I do NOT need 4.10.2225 to utilise HDDs of greater than 32 gigabytes and the problem is localised to "computers that use a Phoenix BIOS and use the Phoenix BitShift translation algorithm." Furthermore,

IMPORTANT: There is no fix available for any version of Windows 95. The reason for this is explained in the following article in the Microsoft Knowledge Base:

246818 (http://support.microsoft.com/kb/246818/EN-US/) Windows 95 Does Not Support Hard Disks Larger Than 32 GB

Thus it would appear that Micro$oft is lying. "The changes required to support media larger than 32 GB in Windows 95 would require architectural changes that cannot be supported on these platforms" is a totally Null and Void statement. They just didn't want to. The ESDI_506.PDRs are very similar between 98FE and 95b. They just didn't want to add the extra code they added in 4.10.2186 to 4.00.1111/9, instead they decided to kill the whole problem by discontinuing support! In this way, KB246818 should've been better named "Windows 95 Does Not Support Hard Disks Larger Than 32 GB If Using Phoenix BIOS And BitShift Translation", although that was probably a bit too long for their liking

The truth: Windows 95 supports hard disks of up to 137 GB in size, except on systems with a Phoenix BIOS using BitShift translation.

I just got an email response from someone from the 48bitLba.com site and this is what the person told me about Win95 & 48bit LBA:

Because Windows 95 operating system is not designed to support it. Simple as that

Perhaps someone should email them again, pointing to this thread. Getting something from here listed under http://www.48bitlba.com/tools.htm should also be a good idea, as Loew's own patch seems to have gotten listed there, and also http://www.48bitlba.com/faq.htm#FAQ7 should be ameliorated appropriately

...and generally calling another person "fool" is not very nice, I guess you can disagree with LLXX opinions and ideas without calling her names, just take it easy

Edited July 30, 2006 by LLXX

[Kelsenellenelvian]

You're a GIRL?

[LLXX]

You're a GIRL?

Yes, you find that surprising?

Anyway a Validation screenshot would be much appreciated

[randiroo76073]

You're a GIRL?

Yes, you find that surprising?

LOL!, I find that quite refreshing, people are often surprised that programing is gender neutral, amongst other things.

[jaclaz]

@LLXX

corrected original post, sorry for the misleading gender assumption.

jaclaz

[Petr]

Just for reference - 180GB disk in rather old PC with GA-586HX motherboard with AMD K6-2/400 and Windows 95 OSR2.1, DDO installed but the disk is controlled by ESDI_506.PDR:

Of course, after 128GiB/137GB data corruption would occur but it is just because the ESDI_506.PDR does not support 48-bit LBA yet. But the systems seem to have no problem with this size. We will see when LLXX release the patched 4.00.1119 driver.

Petr

EDIT: Even without DDO and BIOS set to NONE it works the same way.

Just the correct timing of the PIIX3 controller should be checked, I suppose it is set to the slowest one because the transfer speed is approx 1800 kbytes/s only. The other slower disk shows about 8000 kbytes/s. But this is problem of any OS that does not set timing registry of the disk controller - 95/98/Me.

Petr

Edited August 2, 2006 by Petr

[MDGx]

eidenk wrote (July 27 2006, 12:55 PM):

He could have elaborated just a little a bit at this point IMO by saying

where he believes a problem could occur with LLXX patch or what the other

code, he thinks needs to be also patched, does.

... And this is the answer:

The anonymous author of these 2 unofficial patches:

http://www.msfn.org/board/?showtopic=77218

http://www.msfn.org/board/?showtopic=58780

& VOLTRACK.VXD & KRNL386.EXE & other patches could not have elaborated!!!

I wrote my patch by trying to find *all* instances in ESDI_506.PDR where a

relevant command is sent to the HD controller and used the ATA-6 standards

and a manual from one of the largest HDD manufactures (Toshiba, Seagate or

WD, I forget which) to figure out how to patch. All I was looking for in

LLXX's patched file was whether *I* had *missed* code she found and patched.

However, I noticed from her patches (in a well-known location!) that she had

definitely patched *less* code than I did, that's all. If such unpatched

code is executed for a HDD that needs 48-bit LBA, data corruption is pretty

much guaranteed.

I am on business travel and do not have access to the computers that either

have the information I need to comment further or could possibly be used to

test any patch.

I firmly believe that running SCANDSKW alone is *not* sufficient to confirm

that a particular patch is working. I nearly filled a 160-Gbyte HDD with

large files using Windows Explorer and verified that *all* files, in

particular those located above 137 GByte, were correct and, most importantly,

that writing data to a location > 137 GByte did *not* overwrite data in a

location < 137 GByte and vice versa.

[LLXX]

4.00.1111 for Windows 95 OSR2+ is now available for download. 4.00.1119 should be ready soon.

I wrote my patch by trying to find *all* instances in ESDI_506.PDR where a

relevant command is sent to the HD controller and used the ATA-6 standards

and a manual from one of the largest HDD manufactures (Toshiba, Seagate or

WD, I forget which) to figure out how to patch. All I was looking for in

LLXX's patched file was whether *I* had *missed* code she found and patched.

However, I noticed from her patches (in a well-known location!) that she had

definitely patched *less* code than I did, that's all. If such unpatched

code is executed for a HDD that needs 48-bit LBA, data corruption is pretty

much guaranteed.

Maybe my new code is just more efficient... Edited August 2, 2006 by LLXX

[JLJ]

Two questions:

First, the README for v 4.10.2225 seems to be missing the complete statement regarding supported partition sizes -- can anyone supply the info?

Second, regarding data corruption above 137GB (please note I may be making fundamental wrong assumptions about how hard disk space is used, as a midlevel user, I'm assuming the space is at least sonewhat based on the physical layout of formatted partitions on a disk) -- is it a "safe" method to avoid this by partitioning a >137GB drive such that the total usable formatted portion of the drive is <137GB? Eg, I have a new 160GB drive, but since I don't need the space I have not installed any 46bit LBA patches/file versions, and it's currently configured (PartitionMagic 4.01) with three partitions, 32/32/62GB for a total of 126GB -- would this type of setup avoid >137 barrier corruption by making any "higher" space unusable?

THX JLJ

Edited August 2, 2006 by JLJ

[erpdude8]

4.00.1111 for Windows 95 OSR2+ is now available for download. 4.00.1119 should be ready soon.

I wrote my patch by trying to find *all* instances in ESDI_506.PDR where a

relevant command is sent to the HD controller and used the ATA-6 standards

and a manual from one of the largest HDD manufactures (Toshiba, Seagate or

WD, I forget which) to figure out how to patch. All I was looking for in

LLXX's patched file was whether *I* had *missed* code she found and patched.

However, I noticed from her patches (in a well-known location!) that she had

definitely patched *less* code than I did, that's all. If such unpatched

code is executed for a HDD that needs 48-bit LBA, data corruption is pretty

much guaranteed.

Maybe my new code is just more efficient...

REMOVE V4.00.1111 OF ESDI_506.PDR file, IMMEDIATELY! IT is FLAWED with power management bugs, UDMA bugs and other problems that are fixed with version 4.00.1116 of esdi_506.pdr from Q273468 & remideup.exe. Please patch ESDI_506.PDR files versions 4.00.1116 from Q273468 and 4.00.1118 from amdk6upd.exe and REMOVE 4.00.1111 of patched esdi_506.pdr OFF THIS SITE RIGHT AWAY.

<I will delete this post when ESDI_506.PDR 4.00.1111 48Bit LBA driver for Win95 OSR2 has been removed from this thread>

Edited August 2, 2006 by erpdude8

[eidenk]

Two questions:

First, the README for v 4.10.2225 seems to be missing the complete statement regarding supported partition sizes -- can anyone supply the info?

Second, regarding data corruption above 137GB (please note I may be making fundamental wrong assumptions about how hard disk space is used, as a midlevel user, I'm assuming the space is at least sonewhat based on the physical layout of formatted partitions on a disk) -- is it a "safe" method to avoid this by partitioning a >137GB drive such that the total usable formatted portion of the drive is <137GB? Eg, I have a new 160GB drive, but since I don't need the space I have not installed any 46bit LBA patches/file versions, and it's currently configured (PartitionMagic 4.01) with three partitions, 32/32/62GB for a total of 126GB -- would this type of setup avoid >137 barrier corruption by making any "higher" space unusable?

THX JLJ

1) Theoretically up to a total of 2 TB of partitions per disk but as there is the 48bit LBA adressing bug in it, only 128 GB.

2) Yes.