Date: Sun, 7 Jan 2001 13:36:06 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Martin Str|mberg cc: DJGPP-WORKERS Subject: Re: df <-> df r:/ In-Reply-To: <200101071038.LAA22854@father.ludd.luth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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?