Date:	Sun, 7 Jan 2001 13:36:06 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Martin Str|mberg <ams AT ludd DOT luth DOT se>
cc:	DJGPP-WORKERS <djgpp-workers AT delorie DOT com>
Subject:	Re: df <-> df r:/
In-Reply-To:	<200101071038.LAA22854@father.ludd.luth.se>
Message-ID:	<Pine.SUN.3.91.1010107132440.25836B-100000@is>
MIME-Version:	1.0
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

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.

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?

- Raw text -