Re: int 0x13 utility
- From: "Wolfgang Kern" <spamtrap@xxxxxxxxxx>
- Date: Sun, 30 Mar 2008 13:53:33 +0200
JJ "João Jerónimo" wrote:
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?call
What does windows have to do with the discussion? Of course you cannot
the BIOS if you want to write a disk driver for windows, because windowssizes
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
and memory addressing limits. A PC running in Real Mode can only access1MB
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.
That's what I mean. DOS-executables running in a windoze-DOS-box can
access I/O if the Os grants permission (ie:'LOCK', Admin-rights...).
I disassembled sblaster.com used in my DOS-box of win98se, it direct
hooks interrupt 66/67h and rd/wr from ports e000h... without problems.
Read Intel docs for details on differences between RM and PM execution
environments:
http://www.intel.com/design/pentium4/documentation.htm#manuals
thanks, I'm with AMD and know the difference since a while ... :)
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.
yes.
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.
sure.
Physical CHS addressing allows a limit of some Gigabytes. However, thelimited
original IBM PC BIOS uses some rather stupid bit fields to pack the CHS
addresses. This stupid bit fields make CHS addressing unnecessarily
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.
yeah.
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.
Right, the topic says int13 ....
But utility programs like format,defrag,wipe-clean,diskedit,partit ...
all need to override the given limits from INT13/OS and usually got
their own routines to direct access the hardware.
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.
Yes.
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.
Almost right, except that disk geometry is a fiction on modern HDs anyway
and old CHS-disks wont do much when accessed via LBA.
The reason for why I keep my CHS-funtions is just to be able for hardware
upgrades (copy users data from old CHS-drives to a new machine).
__
wolfgang
.
- Follow-Ups:
- Re: int 0x13 utility
- From: Bob Masta
- 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
- Re: int 0x13 utility
- From: João Jerónimo
- 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
|