SCOUG-HELP Mailing List Archives
Return to [ 21 |
February |
2002 ]
<< Previous Message <<
>> Next Message >>
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.
|