From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CFbxQ-0004xx-RY for qemu-devel@nongnu.org; Thu, 07 Oct 2004 13:21:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CFbxP-0004x0-VC for qemu-devel@nongnu.org; Thu, 07 Oct 2004 13:21:36 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CFbxP-0004wn-QH for qemu-devel@nongnu.org; Thu, 07 Oct 2004 13:21:35 -0400 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CFbqM-0007tn-NA for qemu-devel@nongnu.org; Thu, 07 Oct 2004 13:14:18 -0400 Received: from cisco.com (edinburgh.cisco.com [144.254.112.76]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i97HDDV8017005 for ; Thu, 7 Oct 2004 19:13:14 +0200 (MEST) Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id SAA15069 for qemu-devel@nongnu.org; Thu, 7 Oct 2004 18:13:15 +0100 (BST) Date: Thu, 7 Oct 2004 18:13:15 +0100 From: Derek Fawcus Subject: Re: [Qemu-devel] Re: Qemu floppy emulation problems - partially solved Message-ID: <20041007181315.A25879@edinburgh.cisco.com> References: <000701c4ac72$c3d482f0$0401a8c0@putte2k> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <000701c4ac72$c3d482f0$0401a8c0@putte2k>; from tamlin@algonet.se on Thu, Oct 07, 2004 at 03:37:05PM +0200 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 On Thu, Oct 07, 2004 at 03:37:05PM +0200, Mike Nordell wrote: > > 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. OK. But Fabrice changed a few things. The patch as I did it also altered the use of the table as presented in two different APIs. So does it make any difference if you use the BIOS image I posted, or does that also fail to help? > 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? Certainly. But then we'd expect the change as Fabrice merged it to work. DF