From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J4QiJ-0002zk-IE for qemu-devel@nongnu.org; Mon, 17 Dec 2007 19:53:39 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J4QiG-0002wP-Lv for qemu-devel@nongnu.org; Mon, 17 Dec 2007 19:53:39 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J4QiG-0002w6-7S for qemu-devel@nongnu.org; Mon, 17 Dec 2007 19:53:36 -0500 Received: from mx12.roch.ny.frontiernet.net ([66.133.183.243]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J4QiF-0008HC-Vz for qemu-devel@nongnu.org; Mon, 17 Dec 2007 19:53:36 -0500 Received: from localhost (filter08.roch.ny.frontiernet.net [66.133.183.75]) by relay03.roc.ny.frontiernet.net (Postfix) with ESMTP id 1AD781952E9 for ; Tue, 18 Dec 2007 00:53:35 +0000 (UTC) Received: from relay03.roc.ny.frontiernet.net ([66.133.182.166]) by localhost (filter08.roch.ny.frontiernet.net [66.133.183.75]) (amavisd-new, port 10024) with LMTP id 60pP2+5ZRMjb for ; Tue, 18 Dec 2007 00:53:34 +0000 (UTC) Received: from fys (170-215-38-107.dsl2.kgm.az.frontiernet.net [170.215.38.107]) by relay03.roc.ny.frontiernet.net (Postfix) with ESMTP id 76C87195350 for ; Tue, 18 Dec 2007 00:53:34 +0000 (UTC) Message-ID: <007001c84110$73b4a580$01fea8c0@fys> From: "Benjamin David Lunt" References: <001301c84056$e0289420$01fea8c0@fys><20071217032811.GA17397@networkno.de> <1197902424.14391.48.camel@rapid> Subject: Re: [Qemu-devel] floppy disk Date: Mon, 17 Dec 2007 17:53:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit 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 ----- Original Message ----- From: "J. Mayer" To: Sent: Monday, December 17, 2007 7:40 AM Subject: Re: [Qemu-devel] floppy disk > > On Mon, 2007-12-17 at 03:28 +0000, Thiemo Seufer wrote: >> Benjamin David Lunt wrote: >> > Hi everyone, >> > >> > I only recently have started to use QEmu due to a request >> > on the alt.os.development usenet group. My OS was not working >> > on QEmu due to it would not recognize the (emulated) floppy. >> > >> > After a lot of testing, QEmu does not return the correct >> > values for a Sense Interrupt command and the Status 0 byte. >> > >> > After looking over fdc.cc, someone has placed a hack write >> > where it should return these values. >> > >> > I am just wondering if this hack is temporary or if it will >> > be committed as code. >> >> That's the current state of the code in CVS. > > This hack is terribly bugged and is likely to break all commands > status... > >> > For a more detailed description, QEmu returns the value >> > 0x20 while Bochs, VMware, and real hardware return the >> > values 0xC0, 0xC1, 0xC2, and 0xC3, for each drive 1 - 4 >> > respectively. > > The polling mode is not implemented (and is even emulated in real > hardware) and only exists for 8" drives compatibility, according to > Intel specification, then has no meaning when using other drives > formats. Any reasonable OS would then disable this feature with a > CONFIGURE command as it's pointless on any modern machine (all PCs, for > example). I only use it after reset to see if there are four interrupts waiting. If so, I go ahead with the floppy controller detection. Else, I assume no controller attached to this port. As soon as I receive the four interrupts, I send the configure command to disable polling. I don't think QEmu needs total polling support. Just the four interrupts at the first. I will look at your patch to see if this is what you have added. > But it can be easily added, implementing the missing internal "emulated > drive status change" register, as described in the 82078 datasheet. > >> > I am asking for more information on this subject. >> >> The interrupt status handling in QEMU's FDC emulation looks bogus >> to me, patches to fix it are welcome. :-) > > After taking a look to the specs and the code, it seems to me that the > greatest bug here is the hack added in the SENSE_INTERRUPT_STATUS > command answer. The 'SE' bit in status register 0 is set properly in > case of 'implied seek' without the hack. And, as far as I can see, not > all hardware do update this bit after read and write commands (Intel > 82078 does, NS and SMC superIOs do not, according to their datasheet), > so it should not hurt any OS not having it set after any READ or WRITE > command. > So, the hack is really more buggy than the previous code: > - the SE bit (0x20) should be set only when there have been a implied > seek for READ & WRITE command. This case is hopefully not the common > case, as OSes always try to do sequential reads/writes for performances > reasons, and is properly handled, at least in DMA transfer case. There's > a case to be checked in case of PIO transfers: the bit seems always set, > even if no implied seek was done, which is buggy. > - the SE bit is never set by some hardware on any READ & WRITE commands, > then any code that would rely on this bit to be set on those commands > won't run on real hardware and is broken. > - it breaks all other commands status cases > > One case that seems obviously not correct is that the > SENSE_INTERRUPT_STATUS should be treated as an invalid command when > there is no interrupt condition set. > > The following patch implements the polling mode and the invalid > SENSE_INTERRUPT_STATUS case. > Thanks. I will have a look at it. I will have to see if I can get the current CVS to compile on my WinXP box using MS VC. Thanks again, Ben