Mail Archives: djgpp/2001/02/06/17:42:52
In article <6480-Fri02Feb2001130222+0200-eliz AT is DOT elta DOT co DOT il>,
djgpp AT delorie DOT com wrote:
> > From: dcasale AT my-deja DOT com
> > Newsgroups: comp.os.msdos.djgpp
> > Date: Thu, 01 Feb 2001 21:31:03 GMT
> > >
> > > Int 13h, AH=42h is an EBIOS call. AFAIK, EBIOS is part of the IDE
> > > controller, not of the system BIOS. As such, it is much less
> > > standard, and might do all kinds of tricks that never show in
> > > normal DOS/Windows operation, because AFAIK most programs don't
> > > call these functions directly.
> > >
> > > In other words, you are well advised to avoid using them. (I
> > > don't even understand why did you need to go to low-level disk
> > > I/O functions instead of using normal file I/O.)
> >
> > I thought I mentioned why. I'm running under straight DOS, which
> > means I don't have any other way to access LFN's and other file
> > information which isn't available through standard file i/o calls.
>
> You could access the disk with the normal BIOS calls, not the EBIOS
> calls.
Unless there is a way to perform direct disk access to entire drives
larger than 8.4GB using standard BIOS calls -- and as far as I'm aware,
there isn't -- then I'm forced to use these calls. The standard BIOS
calls are limited to either 504MB or 8.4GB, depending on whether I've
got my BIOS set for CHS or LBA translation. Right?
> > In any case, I tried running this program under Windows. No
> > slowdown. I'm beginning to think that it's either CWSDPMI itself
> > or some strange interaction of my program with CWSDPMI.
>
> I don't think CWSDPMI has anything to do with this. You could try
> CWSDPR0 or PMODE, and see if that changes anything.
Will do.
Damon Casale, damon AT redshift DOT com
BIOS a little time, and sell us a little headache...
Sent via Deja.com
http://www.deja.com/
- Raw text -