Mail Archives: djgpp-workers/2001/01/07/07:22:37
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
- Raw text -