[syslinux] MEMDISK issue with OptiPlex GX280,620

[Gene Cumm]

On Tue, Jan 25, 2011 at 22:32, Shao Miller <Shao.Miller at yrdsb.edu.on.ca> wrote:
> On 1/25/2011 22:07, Gene Cumm wrote:
>>
>> One part, yes.  I've got an E6400 with A14 that still "lost the last
>> drive".
>>
>> Loading from a USB flash drive (my build at 558087b):
>>
>> INT 13 08: Success, count = 2, BPT = 0000:0000
>> INT 13 DL80:
>>  AH08: CF0 BL00 DL02
>>  AH15: CF0 AH03
>>  AH41: CF0 BXaa55 AH21 DH00
>> BDA drive 80? 1, total count: 2
>> Press a key to continue...
>> INT 13 DL81:
>>  AH08: CF0 BL00 DL02
>>  AH15: CF0 AH03
>>  AH41: CF0 BXaa55 AH30 DH00
>> BDA drive 81? 1, total count: 2
>> Press a key to continue...
>> INT 13 DL82:
>>  AH08: CF0 BL00 DL02
>>  AH15: CF0 AH01
>>  AH41: CF0 BX55aa AH01 DH00
>> BDA drive 82? 0, total count: 2
>> Press a key to continue...
>>
>> The results on DL=83h through FFh are identical to 82h.
>
> D'oh!  I'm assuming you're using the merged version.  That really doesn't

Yes, referenced the commit at the top of current git master.

> seem right at all.  Why would their BIOS report CF == 0 ("success"), AH ==
> 01h ("floppy drive type") for DL >= 82h ?

Something else as a validity check (either 01h or we're missing something else)?

> Then there's the matter of AH == 08h and AH == 41h returning CF == 0.
>
> It looks as though they've a "standard response" for AH == 08h, likely based
> on (DL & 80h) ("hard drive class").  I'm not 100% sure how we could approach
> this, as apparently some BIOSes give weird things in their DL response.

I saw that too about DL.  Do we need to "reset the bus" after INT13h
AH08h or AH15h with AH01h and/or AH00h, even if we're successful?

> I guess we could add to AH == 41h to check (BX != 0xAA55).  If extensions
> aren't present, we can discard the relevance of the function's "success."

I'm guessing that's an indicator or extensions being present for a
given drive.  I agree that should probably go in.

> Are you already intended to patch or not?  (Duplication of effort avoidance
> co-ordination. :) )

Nothing yet.  I'm just trying to make a better image to test with as
I've still got FreeDOS crashing before obtaining a prompt.

Gotta love data.  Reading Ralf's list more.  INT13h AH08h should
return AH=0.  It might be nice to see the "present" value inline in
the debug build (at least until we can nail down what's going on).  It
may be necessary to set AL and CX for AH15h to FFh and FFFFh
respectively.

Unless we could somehow pull out the source code of this BIOS (and
others), I have a feeling there may be yet more to this puzzle that
has yet to be revealed.  I hope they didn't go too far off from what's
in RB's list.

-- 
-Gene