[eidenk]

Successfully tested on WinMe with a 200GB Western Digital Caviar disk and multiple partitions :



Thumbs up LLXX !

[Marius '95]

erpdude8, on Jul 26 2006, 07:43 PM, said:

[...]
But you were using RAID controllers. Can you use your HDs WITHOUT RAID controllers under Win95? that's the big question!
Also can you use your big HDs without even using ANY Ultra ATA PCI adapters that have their own 48bit LBA BIOSes & drivers.
[...]

Yes I can, and I did use one of those two HDs until I bought the other one. It was connected to the IDE controller as primary master. RAID controller was disabled. No driver other than the default one was installed.
I only mentioned the RAID controller because the two HDs made a 240 GB (>127GB) virtual drive and I wanted to tell you about Scandisk and drives that large.

[LLXX]

Marius, on Jul 28 2006, 06:10 PM, said:

erpdude8, on Jul 26 2006, 07:43 PM, said:

[...]
But you were using RAID controllers. Can you use your HDs WITHOUT RAID controllers under Win95? that's the big question!
Also can you use your big HDs without even using ANY Ultra ATA PCI adapters that have their own 48bit LBA BIOSes & drivers.
[...]

Yes I can, and I did use one of those two HDs until I bought the other one. It was connected to the IDE controller as primary master. RAID controller was disabled. No driver other than the default one was installed.
I only mentioned the RAID controller because the two HDs made a 240 GB (>127GB) virtual drive and I wanted to tell you about Scandisk and drives that large.

But, did you fill up more than 32Gb of that drive? The >32Gb problem may be just as the >128Gb one, i.e. it doesn't show up until you actually fill the drive past the limit.

[Marius '95]

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".

[LLXX]

Excellent

Now we can try to take it past 137Gb

I'll patch the latest version of ESDI_506.PDR for Windows 95 (4.00.1119 I think) after I'm done with 4.10.2226

[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.

This post has been edited by LLXX: 30 July 2006 - 05:11 AM

[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]

Marius, on Jul 29 2006, 04:38 AM, said:

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]

erpdude8, on Jul 26 2006, 04:09 PM, said:

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

This post has been edited by jaclaz: 30 July 2006 - 09:28 AM

[LLXX]

Petr, on Jul 29 2006, 06:20 AM, said:

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.micro...b/246818/EN-US/

Quote

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.micro...b/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:

Quote

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,

Quote

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.micro...b/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.

erpdude8 said:

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:

Quote

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

jaclaz said:

...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

This post has been edited by LLXX: 30 July 2006 - 03:56 AM

[Kelsenellenelvian]

You're a GIRL?

[LLXX]

Kelsenellenelvian, on Jul 30 2006, 05:24 AM, said:

You're a GIRL?

Yes, you find that surprising?

Anyway a Validation screenshot would be much appreciated

[randiroo76073]

LLXX, on Jul 30 2006, 06:05 AM, said:

Kelsenellenelvian, on Jul 30 2006, 05:24 AM, said:

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:
 w95_180g.gif (8.54K)
Number of downloads: 40
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

This post has been edited by Petr: 01 August 2006 - 06:30 PM

[MDGx]

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

Quote

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:

Quote

The anonymous author of these 2 unofficial patches:
http://www.msfn.org/...showtopic=77218
http://www.msfn.org/...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.

Quote

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...

This post has been edited by LLXX: 02 August 2006 - 01:14 AM

[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

This post has been edited by JLJ: 02 August 2006 - 09:51 AM

[erpdude8]

LLXX, on Aug 2 2006, 02:10 AM, said:

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

Quote

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>

This post has been edited by erpdude8: 02 August 2006 - 01:03 PM

[eidenk]

JLJ, on Aug 2 2006, 09:41 AM, said:

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.