Jump to content

160GB HDD on Win98, and with no BIOS support


osRe

Recommended Posts

So glad you FINALLY gave the specific model# of HDD. My brother bought the EXACT SAME ONE in 2008 "open box" sale.

Western Digital Caviar Blue SE. From the Documentation (2079-001026.pdf):

137 GB Barrier

The previous standard for the IDE/ATA interface uses 28-bit

addressing, which cannot recognize more than 137.4 GB of storage.

To overcome this capacity barrier, hard drives higher than this

capacity have adopted a 48-bit addressing system which can be

supported in newer computer systems with updated controller chips,

BIOS codes, and operating system service packs.

• Windows 98SE and Me require the use of a 48-bit LBA supported

controller card to fully recognize higher capacity hard drives.

You do not have a 48-bit Controller.
32 GB Barrier

Some BIOSs released before June 1999 stall with drives larger than

32 GB. If you are installing such a hard drive and your system stalls

before floppy or hard drive boot can take place, your system BIOS

may be incompatible with this drive. Follow these instructions only if

your system stalls when adding a drive larger than 32 GB.

Recommended Solution: Obtain a BIOS upgrade from your system

or motherboard manufacturer.

Interim Solution:

1. Jumper the hard drive to your desired configuration per the

instructions in section 2 of this guide.

2. Use the Data Lifeguard Tools software to access full hard drive

capacity. To run Data Lifeguard Tools:

a. Boot from the Data Lifeguard Tools CD.

b. Follow the setup instructions for your hard drive.

Do you think this may imply a DDO? I think so...
Alternate Jumper Settings

Some older computer systems have difficulty detecting large capacity

hard drives. If your system locks up after the installation of your new

hard drive, try an alternate jumper setting to resolve this issue. For

detailed information on alternate jumper settings, visit our website at

support.wdc.com.

And the Picture is there...

You're going to use HDAT2?

BEFORE JUMPING THE GUN, TRY THE DOCUMENTATION FIRST!!!! I got all of it for my brother. YOU TAKE THE RISK OF HOSING YOUR HDD!!!

MB/MiB/GB/GiB Calculator to help understand. BTW, I have a Compaq EVO here with a BIOS limitation and it does "weird" 240-head instead of the "standard" 255-head so even a 40GB HDD had to be WIPED to start over. I just got a WD1600BB (similar) that "hits the wall" I will test the WD Tools (DDO) on it to see if it will function correctly.

PLEASE NOTE that a DDO does NOT correct the BIOS, it simply "enhances" it and DOES NOT overcome the Win9x 48-bit LBA problem - MUST PATCH THE OS.

Edited by submix8c
Link to comment
Share on other sites


There is a similar thingy for WD drives:
They just mention various limitations, but I don't think there's a WD tool to set it, but...

...but:

http://wdc.custhelp.com/app/answers/detail/a_id/936/~/operating-system-and-bios-limitations---137-gb,-32-gb,-8.4-gb

If you had setup your drive using the Data Lifeguard Tools 11 option, Set Hard Drive Size and the system BIOS is displaying the size of your drive as ...

jaclaz

Link to comment
Share on other sites

jaclaz: Oops. :) I only read the part about 137GB. I wonder if WD's tool is effective for larger capacities, but in a way HDAT2 seems like a nicer tool.

submix: Thanks for all the help. I know it's the 48-bit vs 28-bit issue. I looked for jumper solutions too, but only found mention of a 32GB clamp for WD. I'm not fond of the idea of DDO. MBR dependent, possible translation issues later on, etc.

But for size clamping, setting the HPA with HDAT2 did the trick. There's no risk as far as I can tell. HPA and DCO are tweaked with standard ATA commands, and it's reversible. I just set it multiple times on two computers to see how different values are detected by both BIOSes.

Now, just for the sake of completeness, I'll do some high-LBA tests in plain DOS. :)

My conclusion so far: for 28-bit BIOSes + Win98, HPA (possibly also DCO) clamping seems like the cleanest option if you don't mind the lost space.

Edited by shae
Link to comment
Share on other sites

Hmmm. haven't yet tried it (the WD tools). If HDAT2 works, then fine.

BTW, the CD referred to (in the quote) is the v11 as jaclaz stated. And apparently is not a DDO. Still, I will ALSO try the DDO (to get full size) as well as the CD ("clamp").

edit - don't expect me to "test" very quickly. You could do the same. I gave links to the actual WD DDO and jaclaz (confirmed by me) has given the name/version of the WD Software for "clamping". And (see jaclaz comment below) you're kind of adding to the confusion with such a statement.

Edited by submix8c
Link to comment
Share on other sites

But for size clamping, setting the HPA with HDAT2 did the trick. There's no risk as far as I can tell. HPA and DCO are tweaked with standard ATA commands, and it's reversible. I just set it multiple times on two computers to see how different values are detected by both BIOSes.

What I am clearly missing is, since you have NO issues with BIOS (i.e. the thingy, if I got it rightly, boots normally) what is the issue with simply leaving the "rest of the disk" UNpartitioned? (or possibly using a partition ID that Win 9x surely cannot use/access (like the 0x07 NTFS or one of the 0x8x Linux ones)?

jaclaz

Link to comment
Share on other sites

What I am clearly missing is, since you have NO issues with BIOS (i.e. the thingy, if I got it rightly, boots normally) what is the issue with simply leaving the "rest of the disk" UNpartitioned? (or possibly using a partition ID that Win 9x surely cannot use/access (like the 0x07 NTFS or one of the 0x8x Linux ones)?
That's how I did it initially (Win98 partition within BIOS size, extra FAT partitions all within <137GB, NTFS in the end), but what rleow brought up makes sense. Some FAT partitions are outside the the BIOS detected 8GB size. Some things may try to write there before Windows loads its native drivers, particularly if there's software installed there. That might lead to corruption. My vague understanding is that this isn't a problem with XP which loads its native drivers early.

It would be interesting to check what happens when writing above BIOS size but below 137GB, but that's for another time, and the findings may not be generic.

Edited by shae
Link to comment
Share on other sites

What I am clearly missing is, since you have NO issues with BIOS (i.e. the thingy, if I got it rightly, boots normally) what is the issue with simply leaving the "rest of the disk" UNpartitioned? (or possibly using a partition ID that Win 9x surely cannot use/access (like the 0x07 NTFS or one of the 0x8x Linux ones)?
That's how I did it initially (Win98 partition within BIOS size, extra FAT partitions all within <137GB, NTFS in the end), but what rleow brought up makes sense. Some FAT partitions are outside the the BIOS detected 8GB size. Some things may try to write there before Windows loads its native drivers, particularly if there's software installed there. That might lead to corruption. My vague understanding is that this isn't a problem with XP which loads its native drivers early.

It would be interesting to check what happens when writing above BIOS size but below 137GB, but that's for another time, and the findings may not be generic.

Well, then call me "dense" but I confirm not understanding.

As I see it there are three main "zones" (rounded/simplified)

  1. 0<=x<8 Gb
  2. 8<=x<137 Gb
  3. 137 Gb <x

If the issue is with "pure CHS", *anything* using CHS (and not LBA) to access zones #2 and #3 is a potential issue.

If the issue is with lba-28/48 bit, *anything* using LBA 28 to access zone #3 is a potential issue.

There could be THREE additional issues, i.e. partitions/volumes not entirely inside a given zone, i.e. :

  1. partition starting inside zone #1 BUT ending in zone #2
  2. partition starting inside zone #1 BUT ending in zone #3
  3. partition starting inside zone #2 BUT ending in zone #3

but let us exclude this since you are smart enough to NOT create this kind of "cross-border" partitions :).

Now if you "limit" the disk to only zone #1 size everything is fine, but (and still if I get it right what you are doing have done) if you "limit" it to only zones #1 and #2, the only additional safeguard (when compared to making only visible to DOS/Win9x partition types) is that you cannot, by mistake, create a partition crossing the border between zones #2 and #3.

Am I missing something? :unsure:

More explicitly, what is the expected difference (possible issues) between (simplified):

  1. a 160 Gb hard disk with a CHS compatible 8 Gb partition and another one 137-8=129 Gb in size and rest of the space unpartitioned/unallocated
  2. a 160 Gb hard disk with a CHS compatible 8 Gb partition and another one 137-8=129 Gb in size and rest of the hard disk made unaccessible through HPA or similar
  3. a 160 Gb hard disk with a CHS compatible 8 Gb partition and another one 137-8=129 Gb in size and rest of the hard disk with a NTFS partiion 160-137=23 Gb in size

The way I understand it, what rloew wrote is:

  1. to be on the "safe" side, you NEED to use a DDO to have no issue with zone #2
  2. my DDO not only will fix issue in zone #2 but will also allow to use zone #3

Which I still read as:

  1. without a DDO you should limit the disk to 8 GB (zone #1 ONLY) whatever way you like, i.e. both through leaving further space unallocated or using it for partitions not recognized by DOS or using a HPA method or hardware "clamp" if available.
  2. with a "normal" DDO you should limit the disk to 137 GB (zone #1 and #2) whatever way you like, i.e. both through leaving further space unallocated or using it for partitions not recognized by DOS or using a HPA method or hardware "clamp" if available.
  3. with a "special" DDO you could avoid any limit and have all three zones available

jaclaz

Link to comment
Share on other sites

To point out, BTW, the APPARENT limit, with the UPDATED BIOS, is the variant#2 and "not a hacked" one.

The Compaq EVO limit (apparently) is seeing the 160GB = 137,328mb (not MiB?) according to the BIOS at Boot (using conversion link = 127.9GiB-Rnd). Also bear in mind that (as I said) the Compaq EVO uses that "strange" Translation so many of older Compaq/HP used (and could be "fooled" by the value it's reporting - could BE MiB).

So the "upper limit" of the UPDATED BIOS are rather confusing (based on "investigation). I still suggest you check into that BIOS if it's the correct one for your MoBo (if it's not already installed). That "8mb" thing mentioned is confusing the heck out of me also. There are also (as I said) a NUMBER of variations of the "ASUS P2B" - You need to look at the MoBo to see the EXACT version or get a tool that will tell you. The BIOS String will also help (for a potential and maybe unnecessary BIOS upgrade).

Call me silly, but I won't mess with a PC until I know EXACTLY what the MoBo is... (find Everest Home Edition - good enough for yours...)

Link to comment
Share on other sites

@submix8,

maybe you are making it more difficult than needed :).

CHS limits are EASY to calculate.

If the BIOS sees the device as having a 255/63 geometry, latest CHS accessible sector is:

1024*255*63=16,450,560 sectors * 512 = 8,422,686,720 bytes

if the BIOS sees the device as having 240/63 geometry, then:

1024*240*63=15,482,880 sectors * 512 = 7,927,234,560

LBA limits have nothing to do with CHS, nor with geometry seen by the BIOS (obviously).

Again it is simply mathematics.

A 28 bit number can be at it's max 268,435,455 (28 ones one after the other), you can verify this also with calc.exe:

1111111111111111111111111111=268,435,455

and, since LBA is measured as "offset" (i.e. starting from 0), this gives exactly 268,435,455+1=268,435,456 "indexable" sectors * 512 =

137,438,953,472 bytes.

Unless there is a bug in the BIOS, these are the exact limits

jaclaz

Link to comment
Share on other sites

Misunderstanding....

From what I had "found" on the "latest BIOS" the posts found claimed "120gb" which I had found "odd".

The other "oddity" was by how the Compaq BIOS' "see" a HDD. Yes, I DID have to "wipe" (zero the first+n-Sectors - insurance) when I had put a 40gb from another PC (using the 255) due to the "way" it provided the Addressing (using 240). The pre-installed XP wouldn't boot (naturally) after being "swapped in" (ran fine in the "other" PC). I DID say that I wasn't sure if it was "odd" in that it wasn't giving an accurate value (or WAS it?). It seems it was, just using a different "translation" scheme (as some Compaqs have ABSOLUTELY been know to do - older Phoenix BIOS).

Fine... the Compaq is irrelevant BUT the "latest BIOS" thing was a bit odd, since the BIOS is (apparently) an Award v4.51PG (not known to do weird stuff). The 255-head thingy should apply here AND provide EXACTLY what your numbers provide. So... 8gb? Appears to be an i440BX Chipset...

Link to comment
Share on other sites

submix8c, thanks for DDO link. I'm not comfortable with the idea of DDOs. Maybe if there were a generic one that could be loaded from AUTOEXEC.BAT or CONFIG.SYS, rather than MBR. But even then it's somewhat worrying.

More specifics on the mobo and HDD: mobo rev 1.10. But the differences are likely in things CPU voltage support, etc., rather than anything pertinent here. HDD-wise, the only extra info there is is the non-documented suffix of the model (stuff like -00JJD0), which I could check if you're interested.

Appears that a 32/64GB limit exists (maybe 120gb)?
128GB/137GB is the BIOS limit.
Have you actually used the External HDD on it? IOW, does it HAVE a "controller" in the enclosure (which BYPASSES the BIOS)?
I used the external HDD. It's not used for booting, and it's on a controller card.

But rloew brought up a good point. Some write actions can be done before Windows booting completes, and those might use BIOS functions. Even if the OS partition fits within the BIOS detected size, I actually do have an additional software partition that doesn't. If only the BIOS treated the HDD as 128GB, or even 10-20GB, that'd be enough, but 8GB is very borderline.

Too bad there's no 128GB clamp jumper on the drive. I might solve the problem by doing more HDD rotations than I anticipated. :-/

Then I disabled the detection on that IDE channel completely and windows during bootup detect the drive (<137GB) and I was able to use it.
For a boot drive?!

Nope, not for a boot drive.

Link to comment
Share on other sites

Way too many posts to quote individually.

With a full 28-Bit BIOS, there is no need to clamp as the BIOS will only report 137GB (or less). There is a legacy 28-Bit Capacity Field in the Drive's Information Data separate from the 48-Bit Capacity field. Clamping is only needed if the BIOS crashes during Boot.

Capacity limiting Jumpers set an initial Clamp without setting a permanent HPA.

Set the 28-Bit HPA to Clamp. Unclamping requires that the 48-Bit HPA be set.

Some old DDOs shifted Sectors making the Drive unuseable without the DDO active. This is what gave DDOs a bad name. My DDO does not shift Sectors so the Drive can be moved to a newer Computer and used without activating the DDO.

The Limitations and solutions are as follows:

~8GB, CHS Limit, LBA DDO

~32GB, BIOS Overflow Bug, Clamp Drive and use unclamping DDO

~64GB, BIOS Overflow Bug, Clamp Drive and use unclamping DDO

136.9GB, BIOS Overflow Bug, Clamp Drive and use unclamping 48-Bit DDO

137.4GB, 28-Bit Limit, 48-Bit DDO

2TiB, 32-Bit Limit, Extended 48-Bit DDO

These limits apply to DOS, Windows Boot, Windows Safe Mode, and Windows Compatability Mode.

Windows 9x Limits:

137.4GB, 28-Bit Limit, High Capacity Disk Patch, Raid Driver, or IAA

2TiB, 32-Bit Limit, Terabyte Plus Package

If the BIOS Limits are not resolved, the following rules apply:

1. The Boot Partition and all other DOS/Windows accessible Partitions, on ALL Drives, must lie entirely within the BIOS supported area.

2. Logical Partitions, on ALL Drives, that are Non-DOS must start within the BIOS supported area, but may extend beyond if they are used by OSes that are safe from BIOS issues.

3. Non-DOS Primary Partitions can be anywhere.

The only exception to #1 is a Partition that starts within the BIOS supported area, is never used for Installed Programs or Temporaries, is never used in DOS, never referred to during Boot and is never used in Safe Mode or if the Drive is in compatability mode. If the 137.4GB Limit is exceeded, the Windows Driver Patch is still required.

I have all four DDOs and the two Windows Driver Patches. All support 2TiB. The last DDO and Driver Patch listed support 512TiB or more.

Edited by rloew
Link to comment
Share on other sites

jaclaz, I want more than 8GB, of course. :) And I don't like the idea of DDO. Even more so when I don't know what it does exactly. And being MBR based.

The HPA/DCO clamp allows me to use 137GB safely.

The other option one could consider is loading an AUTOEXEC.BAT/CONFIG.SYS utility to disallow writes to certain partitions. In DOS I used to use a small COM utility that made HDDs write protected. But that may've been limited to certain int 21h or int 13h functions.

But all of the above assumes writing at (BIOS_size < n < 137GB) leads to corruption. Maybe it is not necessarily so? Even a failure with an error (and no write) could be a useable for the limited cases Windows might attempt to write there during early boot.

As for relying on CHS limit-aligned partitions, that seems unsafe to me. It's difficult to tell what all the involved pieces of code do, and even slightly off is just as bad.

Regarding the max sectors for 137GB afflicted BIOSes, looking at the behavior of two BIOSes, one based around Award 4.51, the other around a 48-bit capable Award 6.0, it seems it's not 2^28 but (2^20) * (2^8 - 1).

submix, I don't think the 8GB detection is about the chipset/controller, but about the BIOS. I also saw 8GB (with HPA set to 2^28 or a little below) on a different chipset with a 48-bit BIOS. I guess they fallback to CHS.

Regarding P2B BIOSes, I'm using the latest ("beta") since it was needed in the past for something or another. There are no different BIOSes for different hardware revisions, but there are for different mobo variants (P2B-F, etc.).

Edited by shae
Link to comment
Share on other sites

A DDO is not an option for more than 8GiB, unless you intend to Patch the BIOS itself.

A DDO could be loaded from DOS but it leaves a vulnerable period before the DDO is loaded. Also it would prevent DOS from enumerating the Drives properly or setting them to the correct mode.

I haven't checked if CHS Reads or Writes wrap around at 8GB, but if they do corruption is a certainty if a write occurs. Even a bad Read can cause problems.

If the Reads or Writes fail, the intended operations will not occur and corruption can occur in the case of a Partiton that Overlaps the limit.

The limit for full 28-Bit BIOSes is 2^28 but some BIOSes round down the actual size.

Link to comment
Share on other sites

jaclaz, I want more than 8GB, of course. :) And I don't like the idea of DDO. Even more so when I don't know what it does exactly. And being MBR based.

Yes, I have understood that :).

The HPA/DCO clamp allows me to use 137GB safely.

BUT what I have understood is that the zone #2 (between 8Gb and 137 GB) is NOT "completely safe" without a DDO. (this was the scope of my post, making sure that I got that right)

and though still not yet completley clear to me, rloew's last post (again as I read it) confirms this. :unsure:

(2^20) * (2^8 - 1)=267,386,880

that is NOT the 28 bit LBA it may be the limit in your specific BIOS (it is a bug in the BIOS, not the LBA 28 limit, that's why I talked of buggy bioses, if you prefer BIOSes not fully compliant to ATA specifications before ATA-6).

http://www.seagate.com/support/kb/disc/tp/137gb.pdf

Prior to ATA-6, the ATA interface defined commands capable of addressing 28 bits worth of

LBAs. Because of this foundation, the early ATA interfaces are said to use 28-bit Addressing. In binary (base 2) this is 1111111111111111111111111111. In hexadecimal notation this is

FFFFFFFh. In ordinary decimal notation it is 268,435,455. If each LBA is 512 bytes then this

represents a maximum addressable capacity of 137,438,952,960 bytes or 137GB.

ATA-6 defines 48-bit Addressing and opens a new higher limit that will carry storage capacities

far into the future towards a theoretical maximum of 144 petabytes.

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...