Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


Petr

137GB limit - ESDI_506.PDR and other limits

Recommended Posts

I had found Mr Loew's patch to enable 48 bit LBA in Windows 98 but I had a suspicion that Mr Loew was not a person I would want anything to do with. Mr Loew's hostile posts here affirm my suspicion and I anxiously await an independant solution from a more amicable author. I eventually solved the 48 bit LBA problem in my own crude way. All I did was to remove ESDI_506.PDR from IOSUBSYS which puts C: into compatibility mode paging then 48 bit LBA support gets inherited from the BIOS. The performance is low but I get long file name support on 48 bit LBA drives. I wasn't trying to win any speed races, I just wanted the ability to move, rename, and perform minimal data recovery on big FAT32 drives from Windows 98.

USB drives are not limited by Windows 9x to 137GB. >137GB drives will not function properly in in older non 48 bit LBA compatible enclosures. Enclosures that are 48 bit LBA compatible are usually labeled as compatible with the largest shipping drive size at the time the advertizing is printed, some size far above 137GB.

48 bit LBA detection has not been perfected between drive manufacturers and chipsets. In rare cases, the enclosure or motherboard chipset will fail to detect more than 137GB. When this occurs you'll expect to see some folders and files scrambled. Any use of SCANDISK or AUTOCHK or CHKDSK in this condition will promptly trash much data. This has been noted with:

Western Digital PATA + ALI Enclosure

Western Digital PATA + VIA based Motherboard

In Windows 2000 & XP, the big drive patch solves this problem. If the motherboard fails to detect >137GB, the 2K/XP PATA IDE driver will do so instead. AUTOCHK runs after the IDE driver detects 48 bit LBA. Misbehaving external drive enclosures need to be powered off and on until 48 bit LBA gets detected properly. I enable the big drive patch on ALL systems so I no longer see this problem in motherboard chipsets.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\atapi\Parameters]
"EnableBigLba"=dword:00000001

Rumor has it that XP SP2 slipstream is the first Windows installer that is 48 bit LBA ready. You may install a lower OS as long as the drive is empty so that the initial CHKDSK has no files above 137GB to destroy and all the install files are certain to show up below 137GB until the big drive patch can be enabled after which your system will function properly no matter where most files are placed. This also means that you can't reinstall a lower OS on a partly filled drive because the risk is too great that files will be allocated above 137GB during the install. Due to much data loss, I have found it best to stick with 120GB or less drives for booting. Installers will not damage >137GB data drives as long as you don't try to install to them. Windows 2000 SP4 slipstream is NOT 48 bit LBA ready.

If the Win98 Unofficial SP2 team is able to come up with a 48 bit LBA ESDI driver, it will need to be integrated into the CAB files to allow Windows 98 to be installed to >137GB drives. It's not a feature I require but it would make Windows 98 the second OS that will install to >137GB drives.

Share this post


Link to post
Share on other sites

I realize everyone is into the "137gb HDD barrier" right now, but has anyone done anything on "1gb ram limit" yet, is that on a back burner till this gets solved?

Share this post


Link to post
Share on other sites
Has eny one used the udma driver for dos and disable the windows one to solves this problem  "137gb HDD barrier" ??

"http://freedos.sourceforge.net/cgi-bin/freedos-lsm.cgi?q=f&a=base/udma2.lsm"

Please note that UDMA2 and all similar variants have been replaced by the newer XDMA:

XDMA DOS UATA/UDMA Hard Disk Driver v1.02 16-bit TSR for MS-DOS 5/6/7/8 +

Windows 3.1x/9x/ME allows up to 4 UATA/UDMA Hard Disks to run at full speed in

native DOS:

http://johnson.tmfc.net/freedos/xdma.html

XDMA 1.02 [30 KB]:

http://johnson.tmfc.net/freedos/file/xdma_102.zip

XDMA works ONLY with UATA/UDMA Hard Disks connected to motherboard built-in

UATA/UDMA controllers, NOT to 3rd party/add-on/proprietary controllers!

XDMA.SYS takes 1 KB of upper DOS RAM if loaded with DEVICEHIGH in CONFIG.SYS

(upper memory manager required in CONFIG.SYS). Example:

DEVICEHIGH=C:\UDMA\XDMA.SYS /O

To my knowledge this driver [and similar ones like UDMA2] only enable int 13h LBA [48-bit] support for large HDs with older BIOSes which don't recognize newer HDs hooked up to internal motherboard based (E)IDE/(U)ATA/(U)DMA HD controllers.

Basically, XDMA creates an interface between the BIOS and the HD controller in native [real] DOS mode.

I don't think it helps the HDs > 137 GB issue in Windows 98SE/ME.

As far as I can tell, no matter what native DOS based driver is loaded in memory, Windows will still "see" only 128 GB [or less], if ESDI_506.PDR [or similar 3rd party driver for AMD, SiS, FIC, VIA etc chipset driver] is not present.

I don't have an older mobo with int 13h non-compliant BIOS, so I can't test this.

Petr:

Do you have an old mobo to test XDMA?

Edit:

Older XDMA has been replaced with newer QDMA:

http://johnson.tmfc.net/freedos/qdma.html

Edited by MDGx

Share this post


Link to post
Share on other sites

Couldn't this take care of any and all problems?

$17 with free shipping at acortech.

IDE-CONTROLLER-B.jpg

http://www.acortech.com/.sc/ms/........

Creative I/O SY-SIL-133R Silicon Image ATA133 IDE RAID CARD

According to the manual it supports hard drives with sizes up to 131,072 TB. That's TB as in TeraByte.

Edited by Lunac

Share this post


Link to post
Share on other sites
Couldn't this take care of any and all problems?

$17 with free shipping at acortech.

IDE-CONTROLLER-B.jpg

http://www.acortech.com/.sc/ms/........

Creative I/O SY-SIL-133R Silicon Image ATA133 IDE RAID CARD

According to the manual it supports hard drives with sizes up to 131,072 TB. That's TB as in TeraByte.

hmmm... use an silicon image ata controller and have to say ... it works. ..but the flash bios support sucks bad... have to seek LOONG time in internet for an version which works on my socket 7 board... the only one which works for me was an very old without raid support... so be warned

Share this post


Link to post
Share on other sites

I have bought that NEWLink ATA 133 RAID – 2 Port RAID PCI Card at Maplin's store the other day.

Though I have paid £29.99 for it, I see it is way cheaper on the Net. Just £12 here.

I'll be telling you soon (sometimes within the next couple of weeks) whether I can boot and use my 200 GB Drive C to its full capacity with it.

I'll have to force myself thouroughly reading the doc first. Especially about the BIOS as I don't know yet how the BIOS will want to boot the computer from a drive plugged on that card (if it can at all).

Edit : Well I still haven't tried to install that card.

Edited by eidenk

Share this post


Link to post
Share on other sites

just a comment :

i search at this time to run MSDOS with WIN98 not running with big drives > 128 / 137 Go

on IDE ports or SiliconImage , HightPOint , Promise & .... that is similar

** no problem with some recent computers with & WIN2000 or WINXP & Win98 running normal with good drivers

( note : with WIN98 on failure mode or MSDOS big problem exist .... : dir /s --> sectors not found )

i am a little sorry because i use always old MSDOS softwares and i have sure problems with big drives

also i can install a special machine with the limitation jumper on the drives but ... why not the full capacity ?

-----------------------------------------------------------------------------------------------

informations : with FreeDos only ( not Win98 compatible !! ) no no no no no problem

have you informations for make a little drivers ( as functionnality on FreeDos kernel ) for using MSDOS & or WIN98 failure mode without problem ?

Pierre

Edited by F5BJR

Share this post


Link to post
Share on other sites

I know this topic is old but still very importanty since the capacity of disk drives are increasing fast...

I had to say this. This Rudolph R. Loew has spammed and hit every techie and support board out there. Its usually one or two posts about his patch, and a obligatory link to his site where it can be purchased. I have never seen such shameless self promotion. Its not $10, either. Boot manager is additional $5, which brings up to $15. For that money you could buy a ATA133 PCI IDE controller card. Which would solve any problems with device drivers, lack of BIOS support, and in a general way improve your system performance. No really, check out pricewatch.com, controller cards going for around $15 with free shipping.

I bet Petr talking about creating a free patch got him antsy. Nice scare tactics. I found the part about copyright issues particularly hilarious.

If any of the information you posted was obtained by examining my code, or a patched ESDI_506.PDR file, it could be considered an illegal disclosure of trade secrets. In addition, anyone who uses any such trade secrets to write Software could be found to be in violation of my Copyright even if they personally have not examined my Software.

I just wonder how many copyright laws "dear" Rudolph R. Loew broke, while working on his little hack. Heck, what about the patch as is? He's making profit from a hacked piece of software. One thing industry has demonstrated in the past is that they come down hard on profiteers. You make any money, in any way, from their product, you get hit.

I am a reverse-engineer, and as such I find this matter interesting. Where I am, there are laws *against* the prohibition of reverse-engineering, copyright is not really enforced at all, and as such once I have some time I'll be sure to take a look at Loew's solution. It's probably not going to be too interesting, as I already know what to expect... 32-bit internal LBA getting padded with an extra 2 bytes -> 48-bit LBA and existing commands -> extended commands...

Share this post


Link to post
Share on other sites
just a comment :

i search at this time to run MSDOS with WIN98 not running with big drives > 128 / 137 Go

on IDE ports or SiliconImage , HightPOint , Promise & .... that is similar

** no problem with some recent computers with & WIN2000 or WINXP & Win98 running normal with good drivers

( note : with WIN98 on failure mode or MSDOS big problem exist .... : dir /s --> sectors not found )

i am a little sorry because i use always old MSDOS softwares and i have sure problems with big drives

also i can install a special machine with the limitation jumper on the drives but ... why not the full capacity ?

-----------------------------------------------------------------------------------------------

informations : with FreeDos only ( not Win98 compatible !! ) no no no no no problem

have you informations for make a little drivers ( as functionnality on FreeDos kernel ) for using MSDOS & or WIN98 failure mode without problem ?

Pierre

I have used a 400GB Hitachi SATA disk with realmode dos 7.1(98se) and have not found any corrupt files. 290GB of the disk is used . I don't run scandisk and replaced it with chkdsk from the latest rom-dos (2005 version).

Share this post


Link to post
Share on other sites
I have used a 400GB Hitachi SATA disk with realmode dos 7.1(98se) and have not found any corrupt files. 290GB of the disk is used . I don't run scandisk and replaced it with chkdsk from the latest rom-dos (2005 version).
DOS 7.10 accesses the disk using the BIOS Int13x interface which uses 48-bit LBAs, but internally it uses 32-bit sector numbers. It should be good for disks up to 2 terabytes, the limit of FAT32.

The problem is with the Windows pmode driver directly accessing the hardware and only using the 28-bit LBA commands to the drive, truncating the upper 4 bits off the internal linear sector number.

I suppose if you run in the "compatibility mode" filesystem (which involves disk access via BIOS) it should be alright...

Share this post


Link to post
Share on other sites
It would take much time anyway. I have to find some easy way how to test what sector was *really* read/written because of possible sector wrapping or shifting.

Petr

Maybe some fellow coder here could make a simple testing utility which performs the following procedures:

1. Write to each sector on the drive its LBA number, starting from LBA sector 0 til the end of the drive.

2. Read each sector and compare value stored in it with the actual LBA value used to adress it (starting from LBA 0 till the last sector)

3. If wrapping is detected (adress and stored value for any sector are not equal) , repeat 1. and 2. but in the range from LBA 0 to the 1st few wrapped sectors ( this is to detect double/triple/... wrappings on very large drives )

Of course, using such a program will erase all data on the drive, but should be very usefull for extended compability testing ;)

Share this post


Link to post
Share on other sites
It would take much time anyway. I have to find some easy way how to test what sector was *really* read/written because of possible sector wrapping or shifting.

Petr

Maybe some fellow coder here could make a simple testing utility which performs the following procedures:

1. Write to each sector on the drive its LBA number, starting from LBA sector 0 til the end of the drive.

2. Read each sector and compare value stored in it with the actual LBA value used to adress it (starting from LBA 0 till the last sector)

3. If wrapping is detected (adress and stored value for any sector are not equal) , repeat 1. and 2. but in the range from LBA 0 to the 1st few wrapped sectors ( this is to detect double/triple/... wrappings on very large drives )

Of course, using such a program will erase all data on the drive, but should be very usefull for extended compability testing ;)

Which interface do you suggest for doing this? Direct hardware access? BIOS int13ext? DOS int25/26? ESDI_506.PDR (protectedmode) driver calls? A good idea, but how to implement it is the question.

Share this post


Link to post
Share on other sites
Which interface do you suggest for doing this? Direct hardware access? BIOS int13ext? DOS int25/26? ESDI_506.PDR (protectedmode) driver calls? A good idea, but how to implement it is the question.

Well, using all interfaces you mentioned can test compability of different PC/OS parts ;)

What i mean:

use direct hardware access to test the HDD controller;

then use BIOS INT13ex to test if BIOS itself supports properly LBA48;

then try DOS interfaces to test DOS-level compability;

and last, use Windows interface to test the actual drivers currently installed on your beloved OS ;)

btw. splitting this to few programs depending on the interface which each use would be fine too, if required.

P.S. I have very little experience coding on x86 platform, so correct me if I'm wrong ( almost all of my coding experience is on Apple 2 clones ;) )

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...