int0x13 utility for MS-DOS ;o)

[Alex Buell]

I recently bought a SATA controller for my old Pentium III box, and
plugged it in. Hooked up a 120GB SATA hard disk, booted up with MSDOS
6.22. Imagine my surprise when MSDOS FDISK refused to create a
partition larger than 503MB even though it was specifically told it
could use the large disk feature. Upgrading the SATA controller BIOS
made no different, it was still a maximum of 503MB.

MSDOS boots just fine, it just can't use partitions larger than 503MB
with that SATA disk and controller.

I have MSDOS correctly installed in a 2GB partition on a PATA disk
connected to the motherboard, so I know the problem isn't with the
motherboard's BIOS.

So, I wrote a tiny utility program in NASM to get the disk parameters
via the int 0x13 / AH = 8. The parameters it reporte are correct for
the hard disks connected to my PC's motherboard, but when it queried
the BIOS for the parameters of its SATA hard disk, it reported: 16
heads, 1022 cylinders and 63 sectors. Ah! That's why MSDOS couldn't
create partitions larger than 503MB!

I've told the manufacturers of the SATA that they need to fix their
BIOS - hopefully they might release an updated BIOS for the SIL3114
controller - fingers crossed. If they won't... I might have to fix it
myself, and that is NOT an easy job!

This utility also checks for the extended Int 0x13 / AH = 0x48 service
but I haven't written the code to print out the values yet - that'll
come as soon as I can find a PC that supports that.

You may find the utility along with its source code at
http://www.munted.org.uk/programming/int0x13.zip

[Richard Bonner]

Post by Alex Buell
I recently bought a SATA controller for my old Pentium III box, and
plugged it in. Hooked up a 120GB SATA hard disk, booted up with MSDOS
6.22. Imagine my surprise when MSDOS FDISK refused to create a
partition larger than 503MB even though it was specifically told it
could use the large disk feature. Upgrading the SATA controller BIOS
made no different, it was still a maximum of 503MB.
MSDOS boots just fine, it just can't use partitions larger than 503MB
with that SATA disk and controller.
I have MSDOS correctly installed in a 2GB partition on a PATA disk
connected to the motherboard, so I know the problem isn't with the
motherboard's BIOS.

(Snip)

Post by Alex Buell
Fearsome grindings.

*** Enable "LBA" in the CMOS. That will allow MS-DOS to make 2 GB
partitions. For larger partitions, upgrade to DR or Free DOS and enable
FAT 32.

Richard Bonner
http://www.chebucto.ca/~ak621/DOS/

[Alex Buell]

On Mon, 24 Mar 2008 12:55:25 +0000 (UTC), I waved a wand and this

Post by Richard Bonner

Post by Alex Buell
I have MSDOS correctly installed in a 2GB partition on a PATA disk
connected to the motherboard, so I know the problem isn't with the
motherboard's BIOS.

(Snip)

Post by Alex Buell
Fearsome grindings.

*** Enable "LBA" in the CMOS. That will allow MS-DOS to make 2 GB
partitions. For larger partitions, upgrade to DR or Free DOS and
enable FAT 32.

LBA is enabled on the mainboard BIOS. Perhaps there must be a way to
get into the SATA BIOS... I'll find out, thanks.

[Richard Bonner]

Post by Alex Buell
On Mon, 24 Mar 2008 12:55:25 +0000 (UTC), I waved a wand and this

Post by Richard Bonner

Post by Alex Buell
I have MSDOS correctly installed in a 2GB partition on a PATA disk
connected to the motherboard, so I know the problem isn't with the
motherboard's BIOS.

(Snip)

Post by Alex Buell
Fearsome grindings.

*** Enable "LBA" in the CMOS. That will allow MS-DOS to make 2 GB
partitions. For larger partitions, upgrade to DR or Free DOS and
enable FAT 32.

LBA is enabled on the mainboard BIOS. Perhaps there must be a way to
get into the SATA BIOS... I'll find out, thanks.
--
http://www.munted.org.uk
Fearsome grindings.

*** Interesting. If you care to experiment, boot DR-DOS from a floppy or
USB to see if it can do more than .5 GB partitions. Then try selecting
"FAT-32" in its FDISK program to see of it can do more than 2GB
partitions.

Richard Bonner
http://www.chebucto.ca/~ak621/DOS/

[Doors]

On Sun, 23 Mar 2008 08:38:48 +0000, Alex Buell

Post by Alex Buell
I recently bought a SATA controller for my old Pentium III box, and
plugged it in. Hooked up a 120GB SATA hard disk, booted up with MSDOS
6.22. Imagine my surprise when MSDOS FDISK refused to create a
partition larger than 503MB even though it was specifically told it
could use the large disk feature. Upgrading the SATA controller BIOS
made no different, it was still a maximum of 503MB.
MSDOS boots just fine, it just can't use partitions larger than 503MB
with that SATA disk and controller.
I have MSDOS correctly installed in a 2GB partition on a PATA disk
connected to the motherboard, so I know the problem isn't with the
motherboard's BIOS.
So, I wrote a tiny utility program in NASM to get the disk parameters
via the int 0x13 / AH = 8. The parameters it reporte are correct for
the hard disks connected to my PC's motherboard, but when it queried
the BIOS for the parameters of its SATA hard disk, it reported: 16
heads, 1022 cylinders and 63 sectors. Ah! That's why MSDOS couldn't
create partitions larger than 503MB!

The card supports Fn4x family just fine, Dos doesn't.

If you can work in nasm then you can get around this pretty easy.

For a general guideline grab RBIL (Ralf Brown INterrupt list.)

If you are comfortable in NASM then use the following outline.

Write a TSR for dos using
int21 Fn 31 TSR (AH=31, DX=(Program size / 16)+1)

Intercept Int13 with Int21 Fn 35 to get old and Fn25 to take over.

When called check dl for 0x81 (Or whatever number it is.)
If it is not then jump to old Int13 witgh parameters intact.

if it is though, the fun begins.

First you will need a packet

;------------------------------------------------------------------
;| 00h BYTE packet size >=16 (10h) |
;| Packet sizes less than above shall be rejected |
;| with AH=01 and CF=1 |
;|-------------------------------------------------------------------|
;| 01h BYTE reserved (0) |
;|-------------------------------------------------------------------|
;| 02h BYTE number of blocks to transfer (max 127 - 07Fh) |
;| >=128(80h) shall be rejected with CF=1 & AH=01 |
;| unless =255(FFh) then use count at 18h |
;|-------------------------------------------------------------------|
;| 03h WORD reserved byte do not use |
;|-------------------------------------------------------------------|
;| 04h DWORD -> 32-bit transfer buffer (XFERSEG:XFEROFS) |
;| If this =FFFF:FFFF then use 64-Bit mode at 10h |
;|-------------------------------------------------------------------|
;| 08h QWORD starting abs block number: non-LBA devices, use |
;| LBA=(((C1*H0)+H1)*S0)+S1-1 |
;| C1 = SELECTED CYLINDER |
;| H0 = TOTAL NUMBER OF HEADS (MAX + 1) |
;| H1 = SELECTED HEAD NUMBER |
;| S0 = MAX SECTOR NUMBER |
;| S1 = SELECTED SECTOR NUMBER |
;| We only use 32-Bits of this 64-Bit number though |
;|-------------------------------------------------------------------|
;| 10h QWORD 64-bit flat address of Transfer address buffer |
;| used if DWORD at 04h is FFFFh:FFFFh |
;|-------------------------------------------------------------------|
;| 18 DWORD Total blocks to transfer when byte at 2 = FFh |
;|-------------------------------------------------------------------|
;| 1C DWORD Reserved and shall be 0 |
;---------------------------------------------------------------------

Its address will go in DS:SI which means saving allthe registers first.

Now dos only uses CHS format so all you need to do is change
chs info into LBA (See:08h above) for most reads and writes
and plug the values into the packet and send it off.

For Fn08 though it is different. It will needto made into a Fn48
For that you will need a 0x48 byte buffer not the packet space.
Upon return from Fn48 it will have the following format.

00h WORD (call) size of buffer
02h WORD information flags (If 0x40 set then CHS is max)
04h DWORD number of physical cylinders on drive
08h DWORD number of physical heads on drive
0Ch DWORD number of physical sectors per track
10h QWORD total number of sectors on drive
18h WORD bytes per sector

There is more but this is all you need for this.

Now you just transfer the Fn48 info to Fn08 format
and return it to dos.

When ending be sure to replace the registers as appropriate
and issue an Iret to end the interrupt.

Look at the code in bt168 on http://ata.freedoors.org It will be better
layed out soon but most of the info is already there.

The bt168 code is a predos module to add drive ports before dos loads.
It uses no interrupts and returns the ports to previous state on exit.

runs spinrite, NDD, diskedit and other tools.

Post by Alex Buell
I've told the manufacturers of the SATA that they need to fix their
BIOS - hopefully they might release an updated BIOS for the SIL3114
controller - fingers crossed. If they won't... I might have to fix it
myself, and that is NOT an easy job!

See above outline. I've done this myself, it's not that hard.

Post by Alex Buell
This utility also checks for the extended Int 0x13 / AH = 0x48 service
but I haven't written the code to print out the values yet - that'll
come as soon as I can find a PC that supports that.

Most pIII motherboards support atleast the basic Fn4x calls.

Look at http://www.t13.org for EDD stuff or read RBIL.
My bt168 implements Fn0x & most Fn4x calls using the hardware direct.

Have fun.

P.S. - You might also look at portread it dumps values from hardware.
Written in pascal, source on sight.

Post by Alex Buell
You may find the utility along with its source code at
http://www.munted.org.uk/programming/int0x13.zip

--
Doors - Dont look at the future in a window.
Walk to a door - Open it, and go there.

http://www.freedoors.org
http://ata.freedoors.org

http://baencd.freedoors.org

***@mefreedoors.org
mailto:***@mefreedoors.org

[Alex Buell]

On Tue, 25 Mar 2008 10:00:24 -0800, I waved a wand and this message

Post by Doors

Post by Alex Buell
So, I wrote a tiny utility program in NASM to get the disk parameters
via the int 0x13 / AH = 8. The parameters it reporte are correct for
the hard disks connected to my PC's motherboard, but when it queried
the BIOS for the parameters of its SATA hard disk, it reported: 16
heads, 1022 cylinders and 63 sectors. Ah! That's why MSDOS couldn't
create partitions larger than 503MB!

The card supports Fn4x family just fine, Dos doesn't.

What makes you think the SIL3114 card supports Int 0x13 / AH = 0x48
calls? My int0x13 utility reports it doesn't.

Regards,
Alex

[Doors]

On Wed, 26 Mar 2008 19:16:18 +0000, Alex Buell

Post by Alex Buell
On Tue, 25 Mar 2008 10:00:24 -0800, I waved a wand and this message

Post by Doors

Post by Alex Buell
So, I wrote a tiny utility program in NASM to get the disk parameters
via the int 0x13 / AH = 8. The parameters it reporte are correct for
the hard disks connected to my PC's motherboard, but when it queried
the BIOS for the parameters of its SATA hard disk, it reported: 16
heads, 1022 cylinders and 63 sectors. Ah! That's why MSDOS couldn't
create partitions larger than 503MB!

The card supports Fn4x family just fine, Dos doesn't.

What makes you think the SIL3114 card supports Int 0x13 / AH = 0x48
calls? My int0x13 utility reports it doesn't.

Experience with several different vendors of cards.
Also in order to properly serve SATA, the extended functions are needed.

Did you printout the AH register on the fail?
Look at the Success/Fail values of AH

This is a common Assembly troubleshooting step.
It saves me so much trouble it's not funny.

Try looking at lines 101 & 119 of int0x13.asm

At line 101

---

; Is ah = 0x48 / int 0x13 installed?
mov dl, [Drive]
mov bx, 0x55aa
mov ah, 0x41
int 0x21

jb .fail3
jmp .succeed3
---

you called

---
From RBIL
--------D-2141-------------------------------
INT 21 - DOS 2+ - "UNLINK" - DELETE FILE
AH = 41h
DS:DX -> ASCIZ filename (no wildcards, but see notes)
CL = attribute mask for deletion (server call only, see notes)
Return: CF clear if successful
AX destroyed (DOS 3.3) AL seems to be drive of deleted file
CF set on error
AX = error code (02h,03h,05h) (see #01680 at AH=59h/BX=0000h)
---
Note value of AH and compare to range for Int13 Fn41

Try

---
; Is ah = 0x48 / int 0x13 installed?
mov dl, [Drive]
mov bx, 0x55aa
mov ah, 0x41
int 0x13 <------------------------------------

jb .fail3
jmp .succeed3
---

and again at 119

---
; Check out ah = 0x48 / int 0x13
mov dl, [Drive]
mov si, DPB ; Drive Parameters Block
mov word [si], 0x42
mov ah, 0x48
int 0x21

jb .fail2
jmp .succeed2
---

Try

---
; Check out ah = 0x48 / int 0x13
mov dl, [Drive]
mov si, DPB ; Drive Parameters Block
mov word [si], 0x42
mov ah, 0x48
int 0x13 <------------------------

jb .fail2
jmp .succeed2

---



I always have my functions print out values on error until I have
assured my self I am doing it right.


A word of advise on choosing instructions.
Choose the most clear for your intent.
If you are using C/C++ let the compiler choose.
If you are doing my hand then I would suggest in this kind of case
instead of JB which implies a compare of two things, use JC instead
which is a clear test of the carry flag.

While JB maybe the same from the processor side of things,
the sourcecode is intended for people to read and people
are not as literal as compilers so you will have some people
looking for what you are comparing before the int as opposed
to checking the carry flag from the int you just fiished.

Assembly is a pain in the ^&^)*$&^&ss and it so detail oriented
that it is ridiculous beyond reason.

You don't even want to know how times I completely messed
up my preboot code before I got it as right as it is.

Keep trying and you will succeed in the end.
--
Doors - Dont look at the future in a window.
Walk to a door - Open it, and go there.

http://www.freedoors.org
http://ata.freedoors.org

http://baencd.freedoors.org

***@mefreedoors.org
mailto:***@mefreedoors.org

[Alex Buell]

On Wed, 26 Mar 2008 18:21:18 -0800, I waved a wand and this message

Post by Doors

Post by Alex Buell
What makes you think the SIL3114 card supports Int 0x13 / AH = 0x48
calls? My int0x13 utility reports it doesn't.

Experience with several different vendors of cards.
Also in order to properly serve SATA, the extended functions are needed.
Did you printout the AH register on the fail?
Look at the Success/Fail values of AH
This is a common Assembly troubleshooting step.
It saves me so much trouble it's not funny.

Oh, I've been using int 0x21 instead of int 0x13. Haha... Thanks!

[Alex Buell]

On Thu, 27 Mar 2008 07:36:57 +0000, I waved a wand and this message

Post by Alex Buell

Post by Doors
This is a common Assembly troubleshooting step.
It saves me so much trouble it's not funny.

Oh, I've been using int 0x21 instead of int 0x13. Haha... Thanks!

New version of int0x13.zip now uploaded. Thanks for your input, it
works perfectly now.

[Alex Buell]

On Wed, 26 Mar 2008 18:21:18 -0800, I waved a wand and this message

Post by Alex Buell

Post by Doors
The card supports Fn4x family just fine, Dos doesn't.

What makes you think the SIL3114 card supports Int 0x13 / AH = 0x48
calls? My int0x13 utility reports it doesn't.

Ok, now that I fixed my utility, it does now show the DPB for the
0x13 / AH = 0x48 extensions. Unfortunately I'm 100% sure the SIL3114
BIOS is wrong. It's still reporting the wrong parameters.

On the bright side, my mainboard's PATA BIOS is 100% correct ;o)

[Doors]

On Thu, 27 Mar 2008 10:45:23 +0000, Alex Buell

Post by Alex Buell
On Wed, 26 Mar 2008 18:21:18 -0800, I waved a wand and this message

Post by Alex Buell

Post by Doors
The card supports Fn4x family just fine, Dos doesn't.

What makes you think the SIL3114 card supports Int 0x13 / AH = 0x48
calls? My int0x13 utility reports it doesn't.

Ok, now that I fixed my utility, it does now show the DPB for the
0x13 / AH = 0x48 extensions. Unfortunately I'm 100% sure the SIL3114
BIOS is wrong. It's still reporting the wrong parameters.

Did you check the flag for maxed CHS values?

If it is set then everything will be max for CHS which is 8Gb.

Post by Alex Buell
On the bright side, my mainboard's PATA BIOS is 100% correct ;o)

--
Doors - Dont look at the future in a window.
Walk to a door - Open it, and go there.

http://www.freedoors.org
http://ata.freedoors.org

http://baencd.freedoors.org

***@mefreedoors.org
mailto:***@mefreedoors.org

[Alex Buell]

On Thu, 27 Mar 2008 20:35:46 -0800, I waved a wand and this message

Post by Doors

Post by Alex Buell
Ok, now that I fixed my utility, it does now show the DPB for the
0x13 / AH = 0x48 extensions. Unfortunately I'm 100% sure the SIL3114
BIOS is wrong. It's still reporting the wrong parameters.

Did you check the flag for maxed CHS values?
If it is set then everything will be max for CHS which is 8Gb.

Do you mean bit 6 of the int 0x13 / AH = 0x48 extensions information
flag?

[Eric P.]

Post by Alex Buell
On Thu, 27 Mar 2008 20:35:46 -0800, I waved a wand and this message

Post by Doors

Post by Alex Buell
Ok, now that I fixed my utility, it does now show the DPB for the
0x13 / AH = 0x48 extensions. Unfortunately I'm 100% sure the SIL3114
BIOS is wrong. It's still reporting the wrong parameters.

Did you check the flag for maxed CHS values?
If it is set then everything will be max for CHS which is 8Gb.

Do you mean bit 6 of the int 0x13 / AH = 0x48 extensions information
flag?

In the past, from the early nineties, I had a lot of interest in the
IDE/ATA harddisk specifications.
All specs can be found on Internet like at http://www.t13.org/

I forgot a lot getting older in the mean time but when glancing over the
messages in this newsgroup I think you maybe trying to find something
that isn't there anymore.
All relevant info about the disk is stored on the disk itself and can be
obtained by executing the ATA Identify Device command and reading the
infobytes.

Int 13h is something of the far past apart from reading the first 8GB.

Below part of a quite old discussion about harddisk size limits I found
on Internet.

<QUOTE>
Hard drives over 8.4 GB are supposed to report their geometry as
16383/16/63.
This in effect means that the `geometry' is obsolete, and the total disk
size can no longer be computed from the geometry, but is found in the
LBA capacity field returned by the IDENTIFY command.
Hard drives over 137.4 GB are supposed to report an LBA capacity of
0xfffffff = 268435455 sectors (137438952960 bytes).
Now the actual disk size is found in the new 48-capacity field.
</QUOTE>

Below some output in Dos from small assembler programs I made at the
time to study ATA, running on my old computer I use.
AMD Athlon XP 2400+, MSI-6330 K7T Turbo2, 1GB Ram

Output from IDEDEV.com:
Master Port: 01F0h
Model: HDS728080PLAT20 SN: PFD210S2RZBBPE
Rev: PF2OA2AA LBA Capacity: 76.69GB
CHS Default: 16383 * 16 * 63 = 8063.0MB

Master Port: 0170h
Model: IOMEGAZIP 100 ATAPI SN:
Rev: 14.A

Slave Port: 0170h
Model: CREATIVEDVD-ROM DVD1242E SN:
Rev: BC101

Output from CHK13EXT.com:
INT13H Fixed Disk Extensions Available EDD-1.1

If I'm wrong in thinking what you are trying, sorry!

[Alex Buell]

On Fri, 28 Mar 2008 20:57:27 +0100, I waved a wand and this message
magically appears in front of Eric P.:

[ snip ]

Post by Eric P.
INT13H Fixed Disk Extensions Available EDD-1.1
If I'm wrong in thinking what you are trying, sorry!

No, this is exactly what I was looking for! Thank you, this will be
quite invaluable!

[Eric P.]

Post by Alex Buell
On Fri, 28 Mar 2008 20:57:27 +0100, I waved a wand and this message
[ snip ]

Post by Eric P.
INT13H Fixed Disk Extensions Available EDD-1.1
If I'm wrong in thinking what you are trying, sorry!

No, this is exactly what I was looking for! Thank you, this will be
quite invaluable!

The little program CHK13EXT.com uses INT 13H AX=4100H, BX=55AAH while
DX=0080 the first hard disk.

IDEDEV.com probes some ports for an ATA disk and if found issues the ATA
Identify Device call to obtain info, as the system does on startup.
From all the info the program shows only a little bit.
You will see that on all later ATA disks only 8GB is given in CHS for
compatibility and to make using INT 13H below 8GB possible while
starting up.

[Alex Buell]

On Fri, 28 Mar 2008 20:57:27 +0100, I waved a wand and this message

Post by Eric P.
<QUOTE>
Hard drives over 8.4 GB are supposed to report their geometry as
16383/16/63.
This in effect means that the `geometry' is obsolete, and the total
disk size can no longer be computed from the geometry, but is found
in the LBA capacity field returned by the IDENTIFY command.
Hard drives over 137.4 GB are supposed to report an LBA capacity of
0xfffffff = 268435455 sectors (137438952960 bytes).
Now the actual disk size is found in the new 48-capacity field.
</QUOTE>

The odd thing is that on my mainboard the disks are reported as:
CHS = 1024 * 255 * 63, whilst the SATA controller reports CHS = 1022 *
16 * 63 for its disk - this with the AH = 8 / int 0x13 call.

Is that even a valid combination?

[Eric P.]

Post by Alex Buell
On Fri, 28 Mar 2008 20:57:27 +0100, I waved a wand and this message

Post by Eric P.
<QUOTE>
Hard drives over 8.4 GB are supposed to report their geometry as
16383/16/63.
This in effect means that the `geometry' is obsolete, and the total
disk size can no longer be computed from the geometry, but is found
in the LBA capacity field returned by the IDENTIFY command.
Hard drives over 137.4 GB are supposed to report an LBA capacity of
0xfffffff = 268435455 sectors (137438952960 bytes).
Now the actual disk size is found in the new 48-capacity field.
</QUOTE>

CHS = 1024 * 255 * 63, whilst the SATA controller reports CHS = 1022 *
16 * 63 for its disk - this with the AH = 8 / int 0x13 call.
Is that even a valid combination?

To see it's valid according the later (S)ATA specs I would have to study
the papers at the t13 website.
Maybe it's all that it is really needed to satisfy (compatibility)
requirements during startup.
The disk is not accessed later via INT 13H anyway.

[Doors]

On Fri, 28 Mar 2008 09:28:38 +0000, Alex Buell

Post by Alex Buell
On Thu, 27 Mar 2008 20:35:46 -0800, I waved a wand and this message

Post by Doors

Post by Alex Buell
Ok, now that I fixed my utility, it does now show the DPB for the
0x13 / AH = 0x48 extensions. Unfortunately I'm 100% sure the SIL3114
BIOS is wrong. It's still reporting the wrong parameters.

Did you check the flag for maxed CHS values?
If it is set then everything will be max for CHS which is 8Gb.

Do you mean bit 6 of the int 0x13 / AH = 0x48 extensions information
flag?

Yes.
--
Doors - Dont look at the future in a window.
Walk to a door - Open it, and go there.

http://www.freedoors.org
http://ata.freedoors.org

http://baencd.freedoors.org

***@mefreedoors.org
mailto:***@mefreedoors.org