Thanks for clarifying. This means my last test would have been sufficient.

In any event, I have now filled the entire drive and rebooted/scandisked. It's quite apparent that this fix works exactly as intended.

I hope no one asks me to keep filling it

Excellent.

Not necessarily, I know a few other people [besides myself] that use 98SE and XP in dual-boot setups, and [like myself] own legal licenses for all their M$ OSes.

On the other hand, use of certain OS files by people who don't own a particular OS license, is debatable.
IMHO:
From what I've seen, use of isolated files that fix problems with your [legally owned] OS should theoretically be ok, but then again, I haven't read all types of M$ EULA, so I could be wrong.

HTH

My bios is Award Modular Bios v4.51PG on an Asus P2B-LS mobo. I have the 1014 Beta 003 bios patch installed. Works fine but doesn't include 48bitLBA. There seems to be a commercial upgrade to version 6.00 or something but I think it's not necessary (see below).
I guess that the missing bios support is why just about all partitioning tools don't work. I've tried Free FDISK, SuperFdisk and some other mentioned in this thread. At best they showed big partitions correctly but they were not able to create them. None of them showed the harddisk size correctly.

Anyway, I've installed the patch and tools from the BigHDD2.0 setup from post #56 (on my system drive which is small and scsi, so no problems there). Then used a Knoppix CD (live linux booting from cdrom) to create partitions on the 250GB Samsung disk (model SP2514N) and create a FAT32 filesystem in them.
After some experiments I found why windows sometimes shows two driveletters for the same partition, one formatted and one seemingly unformatted. It turns out that windows likes just about any set of partitions as long as there are no primary partitions that start above the 128GiB limit.
Extended/logical partitions can start anywhere, primaries that start below the limit can stretch across the limit and be bigger that 128GiB. For any primary starting beyond the limit windows will show a ghost driveletter.

With that sorted I filled the drive (then one big primary partition) to the rim by copying some big files over and over again. There was no corruption at all. All data verified 100%.
The copying was done partly by the normal explorer copy&paste functions, partly by an ancient version of FileSync and partly with xcopy calls in a batch file. No problems with any of them.
Note that I haven't tried any copying in dosmode!

So, once again thanx to LLXX for developing the patch!!!

If anybody wants some input on how to partition/format with linux, let me know. It's just a few (relatively) simple commands but I don't want to fill this thread with off-topic info if nobody is interested.

p.s. Scandskw and defrag from the BigHDD2.0 install work fine where the originals wouldn't even start because the disk was too big for them. To avoid problems I've disabled (renamed) all older versions of scandskw, defrag and don't forget chkdsk. Hopefully that will prevent windows from messing things up on a boot-time scan after a bad shutdown.

but isnt the bad shutdown scan with the dos scandisk which doesnt have any problems.

What was your BIOS setup for this disk? My experience is that it is necessary to set it to "NONE" but then there is problem with the transfer speed because the IDE disk controller (PIIX4 in this case) is not programmed correctly.

Have you tried to test the transfer speed, for example by HDTach 2.7? The transfer speed should be around 30 MB/s.

Petr

I'm no expert in this field, but I suspect that the dos version (I'm not sure which version is used during a bad-shutdown scan) is more likely to depend on the bios than the windows version.
However, the bad-shutdown scan used to be able to scan the drive whereas the windows version complained about having too little memory. So you might be right afterall.


As far as I know I have the disk set to auto and LBA (normal is for smaller disks and "large" is a seldom used setting, at least that's what I read somewhere).

I tested the disk by copying files generated by h2test, a small tool that came with a computer magazine over here. It writes pseudo-random data into a bunch of files and can read it back and verify that it's correct. This read back and verify processed the data at about 15MB/s (the P2 400MHz could be a bottleneck).
I'll check out that HdTach tool and get back when I have some numbers.

CORRECTION
The disk is set to AUTO mode in the bios, not LBA.
The website of HdTach mentions that it's going to install lowlevel drivers. Since my system is working correctly now I don't want to risk messing it up. Another benchmark (h2bench for those who read c't magazine) showed read speeds of around 9MB/s in dos mode.
I'm happy with it since I bought the drive for size, not speed.

4.51PG does not support 48-bit LBA so you may encounter many problems working in DOS mode. You may be able to upgrade to a custom build of 6.00PG but unless you have a separate BIOS flasher it is very risky and not recommended.

9MB/s, that's decent...

You are right MDGx. But my point was rather adressing the inflation of posts lately saying that, as MS does not support the 9x OSes anymore, everything is permitted, including redistributing the entire setup files to anyone.

You're right, as long as M$ doesn't post the source code or releases these OSes as open source [or similar], nobody should treat them as such.
M$ files are still copyrighted + trademarked.

True, they have copyright, but the question is not whether they have copyright or not, but whether they're going to enforce that.

An interesting article about copyrights:http://www.templetons.com/brad/copymyths.html

I tried the patch and there might be a problem. I unplugged my VIA PATA/SATA/RAID card, uninstalled all the related drivers and gave the patched driver a try.

Problem is this: When testing the drive (trying to fill up a 160GB PATA HD) once it reaches around 130GB-140GB or so, the file transfer stops, and it immediately my mouse/system freeze for 3-4 seconds. Then the system unfreezes for 3-4 seconds, after that it again freezes for 3-4 seconds, and it keeps doing that (freezing/unfreezing) until I stop the transfer.

There was no damage of any kind to my data or system, so far. I tried breaking the limit several times, it would always end up doing the same old freezing/unfreezing loop once it reaches a certain point. (around 130GB-140GB)

No data corruption though.

Any idea, anyone?

(By the way I'm using driver ver. 4.10.2225)

What chipset are you using, and does it come with its own IDE driver?

The chipset has a native driver, but it's only for Win2k/XP. You already know the manufacturer (I already told you about it in a PM I sent you week ago, before posting in this thread) I think I know what you're aiming at though: the system is using your modified driver, I checked.

As far as I can tell, the modified driver is a failure, on my system at least. Quite probably the only reason my data is intact is because I have heckuva motherboard with built in virus protection and plenty of security features (on-chip). It just happens that one of the BIOS options is MBR protection (from viruses) as well as other data loss prevention features. So, the modified driver would probably ^&*$-up my system if it wasn't for the BIOS security features.

I suspect the stalling during the transfer is probably because BIOS firmware is halting it. Only reason my BIOS firmware would halt the transfer is because something on my system was up to no good. Since the stalling occurs at a pretty specific time/period during the transfer (once it reaches around 130GB-140GB ), its pretty obvious what is happening, no?


Any ideas, anyone?

Try disabling all those protection options and see what happens.

Ensure LBA access mode in BIOS is enabled.

Backup data before proceeding.

You could try some of the other fileversions I've fixed as well.

I have Win98SE (4.10.2222A) so I assumed I needed the 2.10.2222F) update as you confirm in your reply above... BUT....


then I go to MGDxx's great site and it says this:




So from that I take it I should use 4.10.2225 fix.

Now I'm confused? What's the pros and cons of each version for my situation?




Oh And love your work!

Pretty good for a Sheila





EDIT:
After re-reading this entire Thread I think I understand it now. 2225 was an update of 2222 to fix support for Scandisk or something. So using it would indeed be an OK option.

So using the 2225 update should be fine?

Moin,

the 4.10.2222 can be quite dangerous.
See http://www.pcreview.co.uk/forums/thread-1944044-2.php and http://www.partitionsupport.com/gb32-13.zip for explanation.

In short: Microsoft chose to not admit version 2225 fixes not just the Phoenix BitShift bug but also a bug where certain mappings can cause the driver to have a wraparound at 32GB.

Last week, a friend lost his system partition due to this bug when he filled the second partition over the (absolute) 32GB mark, overwriting the start of the system partition of the harddisk, completely trashing partition root sector and FAT (it is quite surprising how long 98SE kept running until it finally crashed ...). Also above mentioned gb32.exe showed 1000 identical sectors before and 0 after installing KB243450. This was on a Compaq Armada E700 (with latest BIOS 6h_0315.02) which unfortunately decided to use a 240 heads mapping on a 40GB disk.

LLXX, as you stated earlier in this thread that your patch only jumps to the new code when a LBA48 harddisk is encountered, this would leave patched systems vulnerable to the wraparound bug if a drive between (slightly less than) 32GB and 128GB was used. If a user just plugged in another harddisk and start losing data, the problem could be very hard to detect as it is really counter-intuitive that a >128GB patched driver could have problems with drives between 32 and 128GB, so I'd recommend pulling the patch to .2222 completely or at least add a big fat-a** warning. Every system that can use .2222 should be able to run .2225 anyway.

MfG MOW

Wrong. It switches over to 48-bit LBA commands when accesses are made to and beyond the 256th billion physical sector.
The data loss would be noticed much beyond the 128Gb barrier. Also, if you read the previous posts I have made in this thread, that data loss is statistically a rare occurrence and only applies to specific BIOSae and hardware configurations which are not very prominent.

Regarding the warning, re-read the OP again.

I provide fixed versions of drivers for the replacement of an existing driver with one of exactly the same version. The newer ones are actually slightly *slower* than the original 2222 and if your disk/BIOS combination worked fine with 2222 then there is no reason to switch to a newer version to "fix" bugs which don't exist in your system.

So are you saying you don't recommend the 2225 update if everything is working ok with 2222?

Moin,



Hmm, what happens if a multi-sectors transfer starts just below and ends beyond 128GB? If this leads to the harddisk producing an error, would the original code be able to handle it?



Well, not that rare. And it might even happen to bigger than 128GB disk if the BIOS decides to map them into something with 240 heads. Thus it is important to test not only for correct function around 128GB but also around 32GB.

I just see a general warning, not a specific one about .2222 vs. .2225.



Except in the cases where the user is in for an unpleasant surprise because (s)he
1) wasn't even aware that a 32GB problem existed on the drives already in the system
2) has not used a HD >32GB yet and happens to trigger the problem with the new >128GB HD
3) later on adds a HD whose mapping triggers the problem, not even aware that another HD, even smaller than 128GB, could lead to trouble when a working big HD already is present in the system - how long would it take said user to identify the .2222 code as the source of the problem?

I'd rather be on the safe side. Especially if it's only a *slight* slowdown it's not worth taking the risk, and does anyone know what other fixes Microsoft built into the .2225?

MOW

Actually the first sector on which 48-bit LBA is used is 256 sectors below 128Gb. This is because the maximum number of sectors which the original driver can transfer at once is 256, and while this may lead to problems with hard drives of a size between 128GB-128KB and 128GB-512y that do not support 48-bit LBA, I have yet to find a hard drive within this (tiny) size range - not to mention that the size produced below this is 120Gb, and the size above 150Gb.
LBA mode is used so CHS values are unimportant. CHS code still resides within the driver to handle legacy drives that do not support LBA commands (and thus are likely to be far below any limits).

That's how it should be, but when .2222 encounters certain mappings with e.g. 240 heads the wraparound occurs, hence .2225. I don't know what moronic code causes the CHS mapping to have such a strange side effect on the LBA access, but I know it does not happen in .2225. For further details please see the forum link above.

Update: There is no off option for DataGuard (only on or auto). I tried both, no difference. I turned off the built in anti-virus stuff, also no difference. Could the driver be misbehaving because of my perhaps unusual partitioning (multiple Win98 installations on a single disk)? Two of them to be exact, and both have the updated driver.

Tried a different version? There's several Win98SE versions to choose from there...

LLXX:

It's been a few months since your original postings of your fix ... I've read thru the postings here, but I'm sure you've also had other direct feedback. What has been the over-all sucess? Do you feel confident now that these patches completely solve the 137GB limitation? And do you have any reservations at this time based on comments submitted to you?

There are certain chipsets it doesn't seem to work properly on, but then again it might just be because the original chipset hardware was not 48-bit LBA capable, and there's nothing I can do about that.

Other than that I can't really give an estimate of success, since I think most of the users just download the files and it works for them, but they don't bother to post. The ones which it doesn't work on are more likely to post...

I've been using it with no problems.

Do you really think that there is something like "48-bit LBA capable chipset"?

Petr

Most of them implement passthrough, so reads/writes are passed directly through the IDE bus and to the device, but I wouldn't be surprised if some of them do something with the requests besides directly giving them to the devices.

well if the mobo has a 48bit LBA enabled BIOS [like the refurbished DFI CM33-TL mobo I have], then 137gb HDs or bigger should work ok

OR

get a 48bit LBA enabled IDE controller card as mentioned here.

hello

i have installed the 48lba esdr.pdr to windows me
and tested it on a seagate 160 mb hard drive and also on a 200gb maxtor hard drive....

it seems to be fine...

yes,yes i did fill the drives to the brim by
coping/pasting files using 2,4,8,16,32 method...i.e doubling a file then pasting it again and again...


next week i will try with a 250 gb samsung drive.....


once again thanks for your hard work for these patches
which i have burned to dvd and copied for safe keeping.....

the next thing is to fix the memory problem in winme.....so that we dont need to keep rebooting after running lots of programs.....


also another thing is to zip or winrar files within the windows directory...
eg
fonts
cursers
themes
games,
etc,

this makes windows faster
by reducing the number of files in the windows directory....

i compress them and make them into self extracting exe files
using winrar or winzip....

then delete the originals....

if i need anything i just double click the exe file.....


i suggest you do the same....or try it yourself....








QUOTE(LLXX @ Nov 26 2006, 06:08 AM) *

QUOTE(Petr @ Nov 26 2006, 05:15 AM) *

QUOTE(LLXX @ Nov 26 2006, 12:25 AM) *

There are certain chipsets it doesn't seem to work properly on, but then again it might just be because the original chipset hardware was not 48-bit LBA capable, and there's nothing I can do about that.


Do you really think that there is something like "48-bit LBA capable chipset"?

Petr
Most of them implement passthrough, so reads/writes are passed directly through the IDE bus and to the device, but I wouldn't be surprised if some of them do something with the requests besides directly giving them to the devices.


hello

i have installed the 48lba esdr.pdr to windows me
and tested it on a seagate 160 mb hard drive and also on a 200gb maxtor hard drive....

it seems to be fine...

yes,yes i did fill the drives to the brim by
coping/pasting files using 2,4,8,16,32 method...i.e doubling a file then pasting it again and again...


next week i will try with a 250 gb samsung drive.....


once again thanks for your hard work for these patches
which i have burned to dvd and copied for safe keeping.....

the next thing is to fix the memory problem in winme.....so that we dont need to keep rebooting after running lots of programs.....


also another thing is to zip or winrar files within the windows directory...
eg
fonts
cursers
themes
games,
etc,

this makes windows faster
by reducing the number of files in the windows directory....

i compress them and make them into self extracting exe files
using winrar or winzip....

then delete the originals....

if i need anything i just double click the exe file.....


i suggest you do the same....or try it yourself..

If I'm lucky, by Christmas we may obtain a 4-way RAID adapter (4 IDE -> 1 IDE) and 4 500Gb hard drives.

If so, testing will definitely occur

Hi all

I only just came across this site today, after having purchased a Seagate 250GB harddrive, which, obviously, wasn't going to play nicely under my Version of Win98se.

I installed the patch in short order, and I must say LLXX, it is really bloody brilliant

I haven't had the chance to test much (Nor will I probably, to be truthful), though I am currently dumping a large portion of data onto the created partitions (The drive is replacing one of my 120's, I haven't gotten around to buying an IDE card )

I haven't suffered any apparent data corruption, performance appears to be fine, Partition Magic worked like a charm (As opposed to giving me Error#49 - Write Error each time).

I had been deeply afraid that I was going to have to bite the bullet and migrate to XP, but now, I can hold onto the past for a bit longer. This current install is going on 4 years old, and it's faced multiple virus', a couple of drive crashes, a plethora of software being installed and uninstalled, and she's still going strong.

Thanks for having produced such a great little patch. It's really made my night

HELLO

i use windows me and i have installed the patch and tested it....

it works fine...

i suggest u test it by copy/pasting large data flies...using 1 2 4 8 16 32 method


i.e u double the data and copy/paste it ad repeat...


then check the files
by playing them if its dvd vob files...etc....

BUT U MUST REPORT BACK...



i too am very grateful to LLEX doing this......

i am amazed microsoft never wrote the upgrade patch...i guess they just want your money for the dreadful xp....

I am lost...

Months ago i installed esdi_506.pdr and a single 300 GB HDD on my old Pentium system running Win 98 SE. Yesterday i bought another 300 GB HDD. (hd300ld)

This fokin HDD won't work. I used various tools from this thread. I can't remember how i installed the first HDD. I used Partition Magic 6 to see the size of my drives. First HDD is 286, second HDD is 131. I used FDISK any many other tools.

I remember, perhaps i used Win XP with my first HDD.

Any suggestions for win98se?

1. Partition with Free FDISK
2. Format with WinME format (look for it somewhere in this thread along with WinME FDISK)
3. Install Enable48BitLBA ESDI_506.PDR

I got two machines:
(1) Intel Pentium 233 MMX running Win 98 SE with PhoenixBios 4.06
(2) AMD Duron 1200 running Win 98 SE with AMIBIOS 1.24g

Left image was made on (1). Bios setting for HDD is set to "auto" and "enable 32 bit translation".
Right image was made on (2). Bios setting for HDD is set to "auto".

I wasn't able to create partition on (1) which is larger than 131077 MB.
I was able to created partition on (2) and use it on (1) with more than 131077 MB.

What FDISK are you using?

I used Free FDISK in DOS-Box under Win 98 SE on (2) to create extended partition with single drive.

Even if (1) wasn't able to create such partition, Win 98 SE on (1) is able to use this HDD and also shows correct size as on (2). It's also possible to format such big HDD on (1) under Win 98 SE.

Left image shows results after formatting it on (1).
Right image shows results after formatting it on (2).

Not a problem. Fill it past the 128Gb mark just to be sure.

Is it possible to combine my two 300 GB HDD's to get a single drive with 600 GB capacity under Windows 98 SE without special hardware? Is it possible to modify esdi_506.pdr to get some type of Software-RAID? Is there already some kind of software who works like this?

Drive D (300GB ) and E (300 GB) will be virtual drive F (600 GB) and should have read/write access. If there is no more space on drive D it will automatically write to E without user action and the other way round.

It's possible in my mind but is it possible in real. It should some kind of SUBST.

XSUBST <virtual drive> <space delimited list of real drives>

software can easily check available free space and move any overflow to the next desired drive without needing SUBST and without user interaction, I must admit I have never tried this out on such large hard drives but I can see no reason why it would fail. Free available ram might also be handy

If you want to mod esdi_506.pdr yourself or write your own disk access driver, go ahead.

I'm definitely not going to do it, for several reasons:

- Hardware RAID is much safer and already available on many mobos.
- Modifying the driver to do it would be extremely difficult.
- Disk access from DOS would be impossible.

Edit: Those 4 500Gb disks and the RAID controller are coming. Soon, I hope.

It would not be hard to modify ESDI_506.PDR to combine a Master and Slave Drive into a single drive. I have already done the reverse (split one large hard drive into smaller drives) in the experimental versions of my High Capacity Disk Patch for Hard Drives larger than 2200GB. The D and E drives would have to be inaccessible, or at least not mount any parititions, as they would conflict with the partition on the virtual F drive. A matching DOS DDO, similar to my BOOTMAN packages, will be required for DOS support and to pass the protected mode validation precedure in the IOS.VXD and ESDI_506.PDR code.

Do you... have one of these?

Not yet. Should be available before the end of the decade. But I have an ESDI_506.PDR Patch for it. Most of the new code has already been tested using a smaller hard drive.

It will be one of a number of Patches I am working on for the future, building upon my original High Capacity Disk Patch and an Encrypting Disk Patch I released recently.

Can some tell me how check the version of my existing ESDI_506.PDR and how replace it with the exact same fixed version which can be downloaded from this website. I'm a noob here so be easy on me thanks in advance for your help. Oh i forgot to mention i'm using Windows ME for my operating system. Thanks

Right click the file, choose Properties, and it's either right on the first page or on a tab labeled Version.

Windows ME has only 1 version of ESDI_506.PDR and that is 4.90.3000 . The original one [unpatched] can be extracted from the Windows ME Setup CD-ROM or CABs by using this DOS command from any DOS prompt box/session/window:

EXTRACT /Y WIN_19.CAB /L %windir%\SYSTEM\IOSUBSYS ESDI_506.PDR

%windir% = usually C:\WINDOWS .
This driver must exist into the %windir%\SYSTEM\IOSUBSYS subfolder.

The patched one can be installed by running the executable called ME48BLBA.EXE [see link below]:

* Unofficial Windows ME 48-bit LBA (Logical Block Addressing) > 137 GB (E)IDE/ATAPI Hard Disk Driver ESDI_506.PDR 4.90.3000 Fix:
http://www.msfn.org/board/?showtopic=78592
Direct download [143 KB, English]:
http://www.mdgx.com/files/ME48BLBA.EXE

Patched driver listed here:
http://www.mdgx.com/web.htm#MEU

One way to check a Windows file version [only if the version function is built into the file] is to download and use getver.exe [free GPL], a DOS box [Windows console] command line tool:
http://lbrisar.htmlplanet.com/e_cmd32.html#getver

HTH

WTF? I read LLXX is banned?
What's going on here?