From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CFYXi-0004X2-GM for qemu-devel@nongnu.org; Thu, 07 Oct 2004 09:42:50 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CFYXh-0004WL-9o for qemu-devel@nongnu.org; Thu, 07 Oct 2004 09:42:49 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CFYXh-0004WI-2t for qemu-devel@nongnu.org; Thu, 07 Oct 2004 09:42:49 -0400 Received: from [81.228.11.111] (helo=av5-1-sn1.fre.skanova.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CFYQj-00073x-9B for qemu-devel@nongnu.org; Thu, 07 Oct 2004 09:35:37 -0400 Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av5-1-sn1.fre.skanova.net (Postfix) with ESMTP id 1A79937E42 for ; Thu, 7 Oct 2004 15:35:36 +0200 (CEST) Received: from putte2k (h151n2fls306o994.telia.com [81.225.243.151]) by smtp3-2-sn1.fre.skanova.net (Postfix) with SMTP id EA61037E53 for ; Thu, 7 Oct 2004 15:35:35 +0200 (CEST) Message-ID: <000701c4ac72$c3d482f0$0401a8c0@putte2k> From: "Mike Nordell" Date: Thu, 7 Oct 2004 15:37:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: Qemu floppy emulation problems - partially solved Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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