SCOUG Logo


Next Meeting: Sat, TBD
Meeting Directions


Be a Member
Join SCOUG

Navigation:


Help with Searching

20 Most Recent Documents
Search Archives
Index by date, title, author, category.


Features:

Mr. Know-It-All
Ink
Download!










SCOUG:

Home

Email Lists

SIGs (Internet, General Interest, Programming, Network, more..)

Online Chats

Business

Past Presentations

Credits

Submissions

Contact SCOUG

Copyright SCOUG



warp expowest
Pictures from Sept. 1999

The views expressed in articles on this site are those of their authors.

warptech
SCOUG was there!


Copyright 1998-2024, Southern California OS/2 User Group. ALL RIGHTS RESERVED.

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.

The Southern California OS/2 User Group
USA

SCOUG-HELP Mailing List Archives

Return to [ 21 | February | 2002 ]

<< Previous Message << >> Next Message >>


Date: Thu, 21 Feb 2002 21:13:29 PST7
From: Peter Skye <pskye@peterskye.com >
Reply-To: scoug-help@scoug.com
To: scoug-help@scoug.com
Subject: SCOUG-Help: Any limitation on hard drive size ?

Content Type: text/plain

=====================================================
If you are responding to someone asking for help who
may not be a member of this list, be sure to use the
REPLY TO ALL feature of your email program.
=====================================================

Steven Levine wrote:
>
> >This thread is about booting into the first 8 GB and then having access
> >to the entire drive after the drivers finally load.
>
> That's a rather indirect paraphase of:
>
>
> -- Are there any drive size limitations for machines running Warp 4 FP
> 10? I'm using the latest idedasd.exe plus daniS506.add.
>
> -- Any considerations for the motherboard connection or BIOS?

>
> which was your original question.

You took it in the bootup direction. All I want to do is find out if
there might be a problem with a big drive.

> >You said the booter-upper needs to use the same drive geometry that the
> >motherboard BIOS uses. I said I used LBA. You said that wasn't
> >sufficient because LBA wasn't used by my W4FP10.
>
> I said LBA wasn't used during booting.

So what? I've used the LBA setting for years and I've booted for
years. The CHS values aren't "hidden" by the LBA setting.

> >So what? While the booter-upper is running, it uses the motherboard BIOS
> >for disk access and thus couldn't care less what the drive "geometry" is
> >-- it just asks for data and the BIOS supplies it.
>
> It does too care. Think about how file locations are stored in directory
> entries and then consider the transformation of this number into something
> the BIOS understands.

It's been several years since I disassembled a BIOS, and I don't recall
what calls were supported -- absolute disk read/write or whatever -- but
if the BIOS "cared" there would be a heck of a lot of people who
couldn't boot since LBA is fairly prevalent.

> >After the booter-upper completes, there's an OS/2 driver running -- and I
> >already said that I'm using the latest idedasd.exe collection (plus
> >DANIS506.ADD).
>
> So?

So where is the failure point you're thinking about?

> >And then you say "but then there's auto mode". Auto mode is simply "auto
> >detection", at least over here. I don't have to use it, but if I tell my
> >motherboard BIOS to use "AUTO" then it runs some kinda check on the drive
> >and figures out what my settings would be if I did them manually.
>
> Depends on the drive and BIOS. Do you recall John's box that required
> manual setup because auto gave the wrong answers.

No. John who?

> >Whazzat got to do with my drivers? The info passed by the motherboard
> >BIOS to the OS (any OS) in some kinda control block in low memory is
>
> If you say so.
>
> >And your statement "As long as all the values agree" still has me
> >confused. Before the Warp 4 drivers load there's only _one_ set of
> >values, those in the motherboard BIOS. After the drivers load we then
>
> and the values in the boot records.

What boot records? Are you talking about the partition table?

> >expect to use the entire drive (160 GB or whatever it is) and the age of
> >the BIOS shouldn't make any difference at all since we aren't using the
>
> Sure it does. Read what Daniela has to say.

Where? I looked in Danis506.doc and didn't see anything.

> >IBMINT13.I13 driver (which I _think_ uses the motherboard BIOS for disk
> >access so, if used, you have the 8 GB restriction).
>
> I suspect you mean the 1K cylinder limitation which can be much less that
> 8GB.

10 bit field for cylinder number. Head and sector limitations too.

> >So, if my W4FP10+idedasd+danis506 does _not_ use the LBA "geometry" which
>
> What you have uses both LBA and CHS addressing. Because it used the right
> thing at the right time, you can access the full capacity of your drives.
> To my way of thinking there is no such thing as LBA "geometry."

Of course it uses both; without CHS it would break a lot of apps. And
LBA "geometry" is a perfectly valid description (geometry is a method of
mapping).

But lookee -- I still haven't got the slightest idea what problem you
foresee if I put in some 120 GB or 160 GB drives.

> >What exactly is the disk access capability in the WSeB-MCP-eCS version of
>
> These versions can use the Int13 extensions so they can boot OS/2 from
> anywhere on the drive as long as the BIOS supports the Int13 extensions.

Is this what you've been thinking about -- that OS/2 can now be above
the 10-bit cylinder limitation?

> BTW, is mistyped. It's OS2BOOT not OSLDR. OS2BOOT has the low-level disk
> IO routines that implement the HPFS mini-IFS.
>
> >to learn what size drives I can use (see the superunambiguous title of
>
> That was answered long ago. Refer back to the quote from Daniela's
> readme.

Mon 17:35 (-0800):

> Per the readme for the latest danis506:
> *** - supposed to work with drive capacities up to 2TiB
> (OS/2 ADD limit), tested with drives up to 100GB now

I'm talking about a system, not just Dani's excellent stuff. Steve
Carter answered the question about cabling (thanks Steve). I'm still
trying to figure out what dark cloud *you* foresee.

> >I know that. The booter-upper uses the motherboard BIOS, thus it can't
> >load anything that's past the 8 GB point.
>
> Wrong. Your booter upper can't. Anyone running a newish BIOS and
> WSeB/MCP/eCS can.

Steven, good buddy, long-time pal . . . I said the booter-upper "can't"
and you responded with "Wrong. Your booter upper can't."

One of us needs glasses here. If we both think it _can't_, how come I'm
"Wrong."? Just on general principles??

> >In other words, why won't an "old" BIOS work with big drives since,
> >except for booting, the BIOS isn't used?
>
> Not all, just some, won't work. YMMV and you will find out when you
> install the drive.

What causes some of them to not work? Is there some size threshhold
which breaks the interface? Is it a chipset problem? We're just
pushing bytes through ports and down wires here, so if there's a failure
it must be at an obvious point along the flowgram.

- Peter

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-help".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================


<< Previous Message << >> Next Message >>

Return to [ 21 | February | 2002 ]



The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA

Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS RESERVED.

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.