int 0x13 utility

On Sun, 23 Mar 2008 08:45:10 -0700 (PDT), I waved a wand and this
message magically appears in front of Rugxulo:

> On Mar 22, 10:30 am, Alex Buell  <spamt...@crayne.org> wrote: 
>
> Maybe their FDISK doesn't support SATA? The only one I know of that
> for sure does is SPFDISK:

I'm very sure it's the int 0x13 calls that makes FDISK thinks the
maximum is 503MB...
--
http://www.munted.org.uk

Fearsome grindings.

Alex Buell wrote: 
>
> That is *exactly* what I've been saying - I even emailed Silicon Images
> about their BIOS; they might fix it or I might have to patch it myself
> to put out the right numbers.

You won't still be able to access past 8GB only with CHS.

JJ

On Wed, 26 Mar 2008 02:38:35 +0000, I waved a wand and this message
magically appears in front of João Jerónimo:
 
>
> You won't still be able to access past 8GB only with CHS.

That's not a problem, nothing older than Windows XP needs more than
8GB!
--
http://www.munted.org.uk

Fearsome grindings.

JJ "João Jerónimo" wrote:

> Alex Buell wrote: 
 

> You won't still be able to access past 8GB only with CHS.

Yes INT13 CHS is somehow weird because it truncates/merges the
available hardware opportunities (28 bits) into three bytes.
16*255*4096 = 1671168 sectors (= 7.96875 GB), not to mention
that ye olde DOS often limit sectors to 63 and add the two gained
bits to the cylinder count, IMHO anyway a useless detour because
the hardware must be fed with recalculated data then.

Older BIOS has even a limit of <2GB and very old HDC can only
access <512 MB with CHS ...
But if you write your own HD-driver, the physical CHS-limit is:
16 heads, 255 sectors, 65536 tracks(cylinders), and this gives
us 267386880 sectors (= 127.5 GB).
So if the the hardware can handle it then it works almost like LBA28
(max= 128 GB), ...except for the unconvenient calculation needs.

__
wolfgang

Wolfgang Kern wrote:
> But if you write your own HD-driver, the physical CHS-limit is:
> 16 heads, 255 sectors, 65536 tracks(cylinders), and this gives
> us 267386880 sectors (= 127.5 GB).
> So if the the hardware can handle it then it works almost like LBA28
> (max= 128 GB), ...except for the unconvenient calculation needs.

But is this a DOS or a BIOS level driver?

JJ

Alex Buell wrote: 
>
> That's not a problem, nothing older than Windows XP needs more than
> 8GB!

If you want to have multimedia content and alike, I'll be for sure usefull
to have more than 8GB, even without windows xp...

And... You are going to waste most of your 120 Ggigabytes, so!

JJ

Am Wed, 26 Mar 2008 23:39:22 +0000 schrieb João Jerónimo:

> Wolfgang Kern wrote: 
>
> But is this a DOS or a BIOS level driver?

If you write the driver for DOS it´s a DOS-driver, else if you write
it for your own OS maybe you can call it BIOS-driver?

Dirk

On Tue, 25 Mar 2008 17:11:21 +0000, I waved a wand and this message
magically appears in front of Alex Buell:
 
>
> I'm only doing this for a challenge, and to see if I can squeeze it
> just under 2k.

http://www.munted.org.uk/programming/int0x13.zip now has newer version
that correctly handles int 0x13 / AH = 0x48 extensions.
--
http://www.munted.org.uk

Fearsome grindings.

JJ "João Jerónimo" asked:

> Wolfgang Kern wrote: 

> But is this a DOS or a BIOS level driver?

You will encounter I/O-permission issues if you try this on windoze
or in a winDOS-box. My first disk-editor ran on DOS 3.0, and had its
own HD-routines, so bypassing all limits from DOS and BIOS int13.

All it did:
temporary replace HD-IRQ vectors (just to not confuse DOS)
fill the HDC-registers as desired (incl. command-byte as the last)
wait for acknowledge
read or write sector(s)
[find all required details in RBIL-ports (01F0../0170..)]

I kept this very rare now used CHS functions in my PM32 Os, just for
the opportunity to read from old drives when they become replaced.
__
wolfgang

João Jerónimo wrote:
> Alex Buell wrote: 
>
> If you access a HD using BIOS w/CHS, you'll never access past 8GB. If the
> BIOS' (or driver's) routines don't support the more recent CHS feature tha
t
> allows it to map "big" disks to a virtual CHS geometry, you'll be even mor
e
> limited.
>
> As someone pointed already, it's pretty likely that MS-DOS 6.22 does not
> support LBA routines, so it'll use CHS (which implies a maximum of 8GB). I
f
> the SATA BIOS does not support the virtual mapping I mentioned above in
> it's CHS-based routines, then you'll be even more limited (I think it's th
e
> case).
>

Not just "pretty likely".  LBA support was added in Windows 95 OSR2,
which I believe is MS-DOS 7.10.

-hpa