Jump to content

160GB HDD on Win98, and with no BIOS support


osRe

Recommended Posts

http://dmp.free.fr/telecharg/flopimage/

Look for DLGMAKER.EXE - When run, it will create a WD DLG Diagnostics Disk (Version 2.8). This is the last known WD tool that makes a usable Overlay. I do NOT know if it will work with a HDD that size.

Couldn't reach that URL, but this looks like the same thing : http://web.archive.org/web/20030810121208/http://support.wdc.com/download/dlg/dlgmaker.exe

Well, there is a virtual clamp jumper available. Seagate Tools for DOS gives you the ability to set any clamp size you wish. Just temporarily put the drive in a machine that can handle the current/native size, and run the tools from there. Note, this feature is not available in the MS Windows version of the tools.

There is a similar thingy for WD drives:

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

jaclaz

Thanks, Jaclaz.

Cool, another tool for the toolbox. This one's for MS Windows.

Well, there is a virtual clamp jumper available. Seagate Tools for DOS gives you the ability...
That's what I thought about. I don't know if Seagate Tools will work for a WD, but HDAT2 should. I'll try it in a while. Any idea if it's better to limit through setting the HPA or DCO (assuming both will affect BIOS detection)?

AFAIK, the Seagate tools will work with any brand of HD.

The first picture (HPA) looks like the one you need. Setting the User size should do the trick.

the BIOS is (apparently) an Award v4.51PG (not known to do weird stuff).

Ummm ... isn't that the infamous version number that almost always meant a 32GB limit bug, beyond which the BIOS would fail to boot?

Joe.

Edited by jds
Link to comment
Share on other sites


rloew, any idea if there's a problem when the extended partition is larger than the clamped disk size (whether in DOS, Win98 or WinXP), or when an NTFS partition crosses it? It could be interesting keeping an NTFS partition in the area hidden by HPA, for rare special uses. The drive I clamped the size on loaded fine in XP, with the NTFS partition that spans beyond the clamped drive size just being inaccessible. XP also wanted to chkdsk it on startup. The lower partitions seemed accessible as usual.

DOS loadable DDOs would be interesting for experimentation sometime. I might be worried about what happens write-wise before Win98 loads the native driver, but what could happen before loading something in AUTOEXEC or CONFIG? It also seems practically 100% controllable.

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)
Oh, I see. I believe it's safe. Why wouldn't it be? It's both within the BIOS detected size and the Win98 supported size.
(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

In that case, I wonder how common it is. I see it on two ASUS mobos, one of them 48-bit capable.
The first picture (HPA) looks like the one you need. Setting the User size should do the trick.
Yes, I already did. Next one to clamp a drive in this thread should try DCO, to see if there's any difference. :)
Link to comment
Share on other sites

Oh, I see. I believe it's safe. Why wouldn't it be? It's both within the BIOS detected size and the Win98 supported size.

But not in the DOS one, according to:

A DDO is not an option with Windows 9x. It is a necessity.

Any operations by DOS or Windows, before the Driver is loaded, to Drives other than C: can fail. In particular if you do any installations to other Drives that need to be updated on the next boot, they are likely to be done by WININIT in DOS mode.

This is the part that I am trying to make as clear as possible (zone #2).

jaclaz

Link to comment
Share on other sites

the BIOS is (apparently) an Award v4.51PG (not known to do weird stuff).

Ummm ... isn't that the infamous version number that almost always meant a 32GB limit bug, beyond which the BIOS would fail to boot?

I've never seen (and I've disassembled/reassembled and stripped/recycled quite a number) of that "version" - every one of them went at LEAST up to the 64g-limit and generally had a "patch" for the 132g-limit. It all depends on the MoBo/ChipSet. For example, I have used "patched" on Tyan boards many times (Via Chipsets). The "Base BIOS" (eg 4.51PG) is not necessarily the "problem" - Take note of people actually REQUESTING that "BIOS" for their MoBo's - just THAT is totally... NOT! Pull one of them apart with a Utility ("editor") and you' ll see what I mean. ;)

Please note THAT is what the OP has (and supports up to the "highest limit").

@rloew - Thx for details all in one place. :thumbup

Edited by submix8c
Link to comment
Share on other sites

the BIOS is (apparently) an Award v4.51PG (not known to do weird stuff).

Ummm ... isn't that the infamous version number that almost always meant a 32GB limit bug, beyond which the BIOS would fail to boot?

I've never seen (and I've disassembled/reassembled and stripped/recycled quite a number) of that "version" - every one of them went at LEAST up to the 64g-limit and generally had a "patch" for the 132g-limit. It all depends on the MoBo/ChipSet. For example, I have used "patched" on Tyan boards many times (Via Chipsets). The "Base BIOS" (eg 4.51PG) is not necessarily the "problem" - Take note of people actually REQUESTING that "BIOS" for their MoBo's - just THAT is totally... NOT! Pull one of them apart with a Utility ("editor") and you' ll see what I mean. ;)

Please note THAT is what the OP has (and supports up to the "highest limit").

@rloew - Thx for details all in one place. :thumbup

Wow! They say YMMV, and they're right!

I've had several different MB with version 4.51PG, including my recently decommissioned P2, and every one was completely different and every one had the bug! But I was aware that some MB with this version number are OK. I actually wrote some tools to extract and repack the different code modules within these BIOS (that's why I can say each of these with apparently the same version number were in fact quite different) and on the P2, located and patched the faulty code for 32GB and 64GB - painful!. So that's why your "not known to do weird stuff" comment caught my eye.

Joe.

Link to comment
Share on other sites

rloew, any idea if there's a problem when the extended partition is larger than the clamped disk size (whether in DOS, Win98 or WinXP), or when an NTFS partition crosses it? It could be interesting keeping an NTFS partition in the area hidden by HPA, for rare special uses. The drive I clamped the size on loaded fine in XP, with the NTFS partition that spans beyond the clamped drive size just being inaccessible. XP also wanted to chkdsk it on startup. The lower partitions seemed accessible as usual.

As long as the last Partition on the Drive starts below the clamp and is non-dos, you are OK. Of course that won't be true for the OS that actually uses it.

DOS loadable DDOs would be interesting for experimentation sometime. I might be worried about what happens write-wise before Win98 loads the native driver, but what could happen before loading something in AUTOEXEC or CONFIG? It also seems practically 100% controllable.

Enumeration occurs before CONFIG.SYS so you must start the last Partition in the BIOS readable area.

I'm not sure but DOS might mark the partitions as CHS when LBA accesses fail when using a CHS only (8GB) BIOS.

To be 100% controllable you must make sure that no program or installer changes AUTOEXEC.BAT or CONFIG.SYS. In addition you must insure that all Files or Programs referenced are safely within the BIOS readable area. Recopying the files or defragging may move them.

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)
Oh, I see. I believe it's safe. Why wouldn't it be? It's both within the BIOS detected size and the Win98 supported size.

I thought the BIOS detected size was 8GB. Zone #2 is the area ABOVE the BIOS Detected size.

I've had several different MB with version 4.51PG, including my recently decommissioned P2, and every one was completely different and every one had the bug! But I was aware that some MB with this version number are OK. I actually wrote some tools to extract and repack the different code modules within these BIOS (that's why I can say each of these with apparently the same version number were in fact quite different) and on the P2, located and patched the faulty code for 32GB and 64GB - painful!. So that's why your "not known to do weird stuff" comment caught my eye.

That version seems to cover a range of BIOSes, with and without those limits. I have also unpacked and packed some of these BIOSes and modified them. My Tyan S1590 Motherboard now supports 2 TiB Hard Drives. Some EPIA motherboards say they support 2TiB and even report sizes up to 2TiB but don't actually work. A one byte Patch fixed them.

The only way to know for sure is to use a program like my free 48BITLBA.EXE test program.

Link to comment
Share on other sites

OK... followup.

The BIOS absolutely has to support 48-bit LBA. No known DDO's (except maybe rloew's, which I do not have so can't say) can overcome this since this is an entirely different bit-scheme. Some DDO's do not allow for booting to anything other than the HDD and some you have to enter with special keys to change to another device outside of the BIOS order. The first type is absolutely useless since you're stuck with HDD only. Some actually create an additional first Primary Partition that's booted to first (reducing the number of Primaries you can allocate). Using a DDO creates headaches when using e.g. XOSL or BootIt-NG since they require using the MBR to boot from first (BootIt-NG also uses a small partition). Worse, some DDO's are a PITA to remove at a later date AND appear to only be good for the "up to" 48Bit-LBA barrier.

An alternative of "patching" the BIOS to support 48-bit LBA probably don't exist - good luck with that (Controller is a limiting factor?).

It appears that the only option is to "limit" the HDD to the maximum the BIOS supports (non-48BitLBA) as you've done OR use rloew's DDO (note stipulation of Boot Devices above), since others apparently (and I haven't tried them yet AND have I believe most/all of them) don't support it and/or "suck up" a First Partition.

Done!

Link to comment
Share on other sites

OK... followup.

The BIOS absolutely has to support 48-bit LBA. No known DDO's (except maybe rloew's, which I do not have so can't say) can overcome this since this is an entirely different bit-scheme. Some DDO's do not allow for booting to anything other than the HDD and some you have to enter with special keys to change to another device outside of the BIOS order. The first type is absolutely useless since you're stuck with HDD only. Some actually create an additional first Primary Partition that's booted to first (reducing the number of Primaries you can allocate). Using a DDO creates headaches when using e.g. XOSL or BootIt-NG since they require using the MBR to boot from first (BootIt-NG also uses a small partition). Worse, some DDO's are a PITA to remove at a later date AND appear to only be good for the "up to" 48Bit-LBA barrier.

An alternative of "patching" the BIOS to support 48-bit LBA probably don't exist - good luck with that (Controller is a limiting factor?).

It appears that the only option is to "limit" the HDD to the maximum the BIOS supports (non-48BitLBA) as you've done OR use rloew's DDO (note stipulation of Boot Devices above), since others apparently (and I haven't tried them yet AND have I believe most/all of them) don't support it and/or "suck up" a First Partition.

Done!

My DDO allows you to choose to insert a Floppy Disk which can be booted from, with the DDO active.

If you are booting from multiple drives the DDO can be placed in each one.

I probably could customize the DDO to run with XOSL or Bootit-NG or almost anything else. It is fairly small and does not use a secondary MBR Table.

Removal is not hard, but is unnecessary as it automatically drops out if placed in a Computer that does not need it's support.

Link to comment
Share on other sites

My DDO allows you to choose to insert a Floppy Disk which can be booted from, with the DDO active.

If you are booting from multiple drives the DDO can be placed in each one.

I probably could customize the DDO to run with XOSL or Bootit-NG or almost anything else. It is fairly small and does not use a secondary MBR Table.

Removal is not hard, but is unnecessary as it automatically drops out if placed in a Computer that does not need it's support.

That's good! The intent of the query/comment got an answer.

What about CD/DVD, USB, etc? My understanding of a DDO (even if just in the MBR) indicates that this code is NECESSARY in order to properly translate the LBA. My research indicated that one of them allowed for the Code to be "inserted" so that any CD/DVD booted would properly recognize it, as well as Floppy.

It seems that somewhere the BIOS code would be best "overlayed" to provide proper support (provided the Controller could deal with it?).

I guess I must be missing something. :unsure: It's been a while since I used a DDO (MBR-style).

note: not trying to pry proprietary info from you... I have no desire to write a MBR code. also, comment about "boot loaders" due to finding article about "how to" with xosl.

Link to comment
Share on other sites

What about CD/DVD, USB, etc? My understanding of a DDO (even if just in the MBR) indicates that this code is NECESSARY in order to properly translate the LBA. My research indicated that one of them allowed for the Code to be "inserted" so that any CD/DVD booted would properly recognize it, as well as Floppy.

CD/DVD and USB use different code in the BIOS, so their issues are different. To access a Hard Drive from a Bootable CD/DVD or Bootable USB, my DDO can be installed on it.

Making a CD Boot Option from my Hard Disk DDO would have complicated it significantly as CD Emulation support would have to be added.

It seems that somewhere the BIOS code would be best "overlayed" to provide proper support (provided the Controller could deal with it?).

I'm not sure what you are saying. It is possible to overlay the BIOS in the shadow RAM but this would be unique to each BIOS.

I guess I must be missing something. :unsure: It's been a while since I used a DDO (MBR-style).

I do have an IO.SYS based mini-DDO I use on my Laptop that supports one Hard Drive in a fixed controller. It is not MBR based.

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