From: Martin Str|mberg <ams AT ludd DOT luth DOT se>
Message-Id: <200101071222.NAA23273@father.ludd.luth.se>
Subject: Re: df <-> df r:/
In-Reply-To: <Pine.SUN.3.91.1010107132440.25836B-100000@is> from Eli Zaretskii at "Jan 7, 2001 01:36:06 pm"
To: djgpp-workers AT delorie DOT com
Date: Sun, 7 Jan 2001 13:22:30 +0100 (MET)
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

According to Eli Zaretskii:
> 
> On Sun, 7 Jan 2001, Martin Str|mberg wrote:
> 
> > For a CDROM I get status = 256, dev_status = 912. For a DVD-ROM I get
> > status = 768, dev_status = 1940, unless I previously had a CDROM in
> > the drive. In that case I get status = 256, dev_status = 1940!
> > 
> > For an audio CD I get status = 768, dev_status = 17296, unless I'm
> > very quick with df. Then I get 256, dev_status = 912.
> > 
> > The first thing that should be adjusted is "status == 0x100" above to
> > "( status & 0x100 )".
> 
> Hmm... that doesn't look right.  RBIL says:
> 
>    Bitfields for device request status:
>    Bit(s)  Description     (Table 02596)
>     15     error
>     14-11  reserved
>     10     ??? set by DOS kernel on entry to some driver calls
>     9      busy
>     8      done (may be clear on return under European MS-DOS 4.0)
>     7-0    error code if bit 15 set (see #02598)
> 
> So 768 (= 0x300) means that bit 9, the BUSY bit is set.  Why should we 
> take that as a sign of success?  Note that this would also let audio CDs 
> through, which we don't want to report as data disks.

If the audio disk isn't playing, it comes through anyway. But it's
labelled as "Audio CD" so I don't think it's a big problem.

> It certainly seems wrong to ignore bit 15 and bits 0-7, because that's 
> how errors present themselves.
> 
> Why is the BUSY bit set?  Did you wait until the drive LED went off,
> after you inserted the disk, before running the tests?

I sure did. But stooopid WINDOZE tries to launch a DVD player as soon
I insert a DVD-ROM, that fails to start because I use to high a
resolution on the screen.

But I don't understand why we shouldn't report busy drives?


Right,

						MartinS