[Qemu-devel] Re: Qemu floppy emulation problems - partially solved

[Mike Nordell]

Derek Fawcus wrote:

> Well I was waiting to here back if the change I proposed had
> any positive effects,  since I'm not experiencing the problems
> it's supposed to address.
>
> However I've had no feedback,  so it's a bit difficult to tell
> if it's of help.

Sorry for the delay.

Let me first bring some good news: As of 15 hours ago, I fixed the final bug
of the hardware emulation part of the floppy that prevented it working
for/with NT5+ (Windows 2000 and later) guests. It's not in CVS as of this
writing, but I suspect it'll be shortly.

Now for the software problem, I'm sorry to say your patch didn't help. With
your patch (as applied and compiled in the bios binary image in CVS), NT
still believes the floppy only got 31 cylinders.

I have verified that direct modification of a BIOS image, appending the
max.cyl. and a zero to the originally placed diskette_param_table does make
NT work as expected re. floppy, in that it recognizes it as having 80
cylinders instead of the 31 cylinders it otherwise believes due to the
binary representation of the following "push ds". Obviously that overwrites
the leading two bytes of the int 17h handler, so while it makes NT floppy
handling work it breaks DOS - I couldn't even boot a DOS image with such a
modified BIOS image. Not good.

As the source code for NT isn't available, there is no way of really knowing
how, and where from NT grabs this data. I haven't (yet) checked with a real
BIOS to see if it too obeys the hard-coded offset efd2 for int 17h (which
here is the limiting factor for the diskette_param_table), but if it does NT
obviously must assemble this information from some other place since it
works on real h/w.

Could it be that this information, using a real BIOS, is first copied down
to the BIOS playground area (0040:xxxx), appends the extra knowledge (i.e.
maxtrack = 79) and then it points the 1e interrupt vector to this new place?

I think what's needed is an authorative answer from someone that really
knows either how a real BIOS behaves or how NT does this discovery in
detail, or close examination and/or empirical evidence from a real BIOS.

/Mike