From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C2C1U-00042v-A0 for qemu-devel@nongnu.org; Tue, 31 Aug 2004 13:02:20 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C2C1S-00042C-0d for qemu-devel@nongnu.org; Tue, 31 Aug 2004 13:02:19 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C2C1R-000422-Ut for qemu-devel@nongnu.org; Tue, 31 Aug 2004 13:02:17 -0400 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1C2BwS-0002wR-Bu for qemu-devel@nongnu.org; Tue, 31 Aug 2004 12:57:08 -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 i7VGtbTO020032 for ; Tue, 31 Aug 2004 18:55:37 +0200 (MEST) Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id RAA09962 for qemu-devel@nongnu.org; Tue, 31 Aug 2004 17:55:36 +0100 (BST) Date: Tue, 31 Aug 2004 17:55:36 +0100 From: Derek Fawcus Subject: Re: [Qemu-devel] Re: Qemu floppy emulation problems - partially solved Message-ID: <20040831175536.A29557@edinburgh.cisco.com> References: <001301c48538$f9e406b0$0401a8c0@putte2k> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <001301c48538$f9e406b0$0401a8c0@putte2k>; from tamlin@algonet.se on Wed, Aug 18, 2004 at 05:35:19PM +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 Wed, Aug 18, 2004 at 05:35:19PM +0200, Mike Nordell wrote: > Johannes Martin wrote: > > 1. diskette_param_table in rombios.c from Bochs is too short. It neeed two > more bytes, else e.g. NT believes the floppy only got 31 cylinders (the code > following the table begins with "push ds", 0x1e, and that just happens to be > "maximum track" NT expects). Append: > db 79 > db 0 > > This is obvious if looking at the registry value > HKLM\HARDWARE\DESCRIPTION\System\MultifunctionAdapter\x\DiskController\y\Flo > ppyDiskPeripheral\0\Configuration Data. > > (x, y was 5 and 0 respectively on a real machine, but you might experience > local fluctuations) > > Compare the last two bytes from a real system (working) with a non-working > QEMU-installed system. Well that would seem to be an error in the NT code, or we're triggering something in the NT code which makes it seem to think there should be a larger table. The original table was only 11 bytes (as in the Bochs BIOS), you can look at the interrupt list to see. It seems there is an enhancement that adds an additional 3 bytes. However from the layout of the BIOS, it looks as if there is no room to expand the table in place, one'll have to have the param table pointer (int 1e) point somewhere else. Anyway, I hacked something up if you want to try... The diff is at http://www.employees.org/~dfawcus/rombios.c-diff, and the rom image is at http://www.employees.org/~dfawcus/bios.bin I've not tried your other diffs yet. DF Format of diskette parameter table: Offset Size Description (Table 01264) 00h BYTE first specify byte bits 7-4: step rate (Fh=2ms,Eh=4ms,Dh=6ms,etc.) bits 3-0: head unload time (0Fh = 240 ms) 01h BYTE second specify byte bits 7-1: head load time (01h = 4 ms) bit 0: non-DMA mode (always 0) Note: The DOS boot sector sets the head load time to 15ms, however, one should retry the operation on failure 02h BYTE delay until motor turned off (in clock ticks) 03h BYTE bytes per sector (00h = 128, 01h = 256, 02h = 512, 03h = 1024) 04h BYTE sectors per track (maximum if different for different tracks) 05h BYTE length of gap between sectors (2Ah for 5.25", 1Bh for 3.5") 06h BYTE data length (ignored if bytes-per-sector field nonzero) 07h BYTE gap length when formatting (50h for 5.25", 6Ch for 3.5") 08h BYTE format filler byte (default F6h) 09h BYTE head settle time in milliseconds 0Ah BYTE motor start time in 1/8 seconds ---IBM SurePath BIOS--- 0Bh BYTE maximum track number 0Ch BYTE data transfer rate 0Dh BYTE drive type in CMOS