Re: int 0x13 utility
- From: João Jerónimo <spamtrap@xxxxxxxxxx>
- Date: Sat, 29 Mar 2008 15:07:31 +0000
Wolfgang Kern wrote:
JJ "João Jerónimo" asked:
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?
You will encounter I/O-permission issues if you try this on windoze
or in a winDOS-box.
Do this, what?
What does windows have to do with the discussion? Of course you cannot call
the BIOS if you want to write a disk driver for windows, because windows
runs in 32-bit Protected Mode, but the BIOS runs in 16-bit Real Mode, and
relies on RM segment arithmetic, default operant/address sizes, stack sizes
and memory addressing limits. A PC running in Real Mode can only access 1MB
of memory and have no support for paging, so basically can't call the BIOS
unless you return to Real Mode, or use Virtual 8086 Mode.
Read Intel docs for details on differences between RM and PM execution
environments:
http://www.intel.com/design/pentium4/documentation.htm#manuals
My first disk-editor ran on DOS 3.0, and had its
own HD-routines, so bypassing all limits from DOS and BIOS int13.
Yes, but regular DOS programs that use file I/O typically use DOS system
calls. This means that it's limited by the routines DOS relies on for disk
access.
For example, DOS-based operating systems usually rely on BIOS disk I/O
routines. So if, for example, this routines are limited to 8GB, of course
DOS disk I/O will be limited to this size, and the same holds true for DOS
file I/O.
Physical CHS addressing allows a limit of some Gigabytes. However, the
original IBM PC BIOS uses some rather stupid bit fields to pack the CHS
addresses. This stupid bit fields make CHS addressing unnecessarily limited
to 503MB when used through the BIOS. However, BIOS developers eventually
created a custom CHS addressing that maps virtual addresses to physical
ones. This virtual addressing (and mapping) allows up to 8GB.
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..)]
Although User Mode programs in PM-based operating systems don't access the
hardware directly because they are forbidden to do so (there's a general
protection fault that notifies the OS is they try to do so), proper DOS
programs were supposed and encouraged to do DHA if they needed it.
However, "normal"/"portable" programs did not do so. I'm not sure, but I
think really no one was doing file I/O directly even on DOS (exception
perhaps for defrag and so): they used kernel's filing calls instead.
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.
If you don't want to run your PM32 OS on old PCs, you can even drop CHS
support completely, because LBA uses linear addresses to access the hard
drive. For example, if you want to address the 654th sector of your hard
drive, you can refer to LBA sector number 653 (because LBA is zero based,
that is, the very first sector of your hard drive has number 0, just like
your RAM memory). However, you you use CHS addressing, you'll have to
compute three numbers to build the address. This addresses would depend
upon the physical geometry of the disk.
JJ
.
- Follow-Ups:
- Re: int 0x13 utility
- From: Wolfgang Kern
- Re: int 0x13 utility
- References:
- int 0x13 utility
- From: Alex Buell
- Re: int 0x13 utility
- From: João Jerónimo
- Re: int 0x13 utility
- From: Alex Buell
- Re: int 0x13 utility
- From: João Jerónimo
- Re: int 0x13 utility
- From: Wolfgang Kern
- Re: int 0x13 utility
- From: João Jerónimo
- Re: int 0x13 utility
- From: Wolfgang Kern
- int 0x13 utility
- Prev by Date: Re: int 0x13 utility
- Next by Date: Re: int 0x13 utility
- Previous by thread: Re: int 0x13 utility
- Next by thread: Re: int 0x13 utility
- Index(es):
Relevant Pages
|