From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G8CaZ-0005li-MN for qemu-devel@nongnu.org; Wed, 02 Aug 2006 05:00:27 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G8CaW-0005iM-MZ for qemu-devel@nongnu.org; Wed, 02 Aug 2006 05:00:27 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G8CaW-0005iI-Cy for qemu-devel@nongnu.org; Wed, 02 Aug 2006 05:00:24 -0400 Received: from [80.12.242.1] (helo=smtp-msa-out19.orange.fr) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G8Cda-0006aZ-S6 for qemu-devel@nongnu.org; Wed, 02 Aug 2006 05:03:35 -0400 Received: from [192.168.1.101] (AMontpellier-251-1-22-162.w81-251.abo.wanadoo.fr [81.251.208.162]) by mwinf1902.orange.fr (SMTP Server) with ESMTP id 180E41C00085 for ; Wed, 2 Aug 2006 11:00:22 +0200 (CEST) Message-ID: <44D069A7.5020503@bellard.org> Date: Wed, 02 Aug 2006 11:00:23 +0200 From: Fabrice Bellard MIME-Version: 1.0 Subject: Re: [Qemu-devel] How to Simulate hardware that counts scanlines? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 The next release of QEMU is likely to have cycle exact emulation and delivery of interrupts in the middle of a basic block. Regards, Fabrice. Armistead, Jason wrote: > Steve Ellenoff wrote: > > >>You misunderstand, I have no control over the running program. I didn't >>write it, I don't have source code, and I surely wouldn't have used a >>polling mechanism for determining the vblank as you suggested. > > >>My problem is that I wish to run this program through qemu. I've made a >>bunch of hardware specific additions to qemu to emulate the specific >>hardware this program runs on. I'm just not sure the best way to simulate >>the scanline counting the hardware does. > > >>Seems nobody here has any ideas either, which is kind of hard to believe. I > > >>don't know if this would work, but one idea I had was to divide up the gui >>timer into 260 slices (that's the # of scanlines the hardware expects), and > > >>simply update the hardware register that counts the scanlines this way. > > >>Does anyone thing that's the way to go, or if there's a better way? > > > As I see it, one of the problems in Steve's scenario is that QEMU does > dynamic translations based on blocks of code, and the interrupts or changes > to emulated hardware state are delivered only at the end of the execution of > an entire basic block. While this might be adequate for an operating system > which cares for the most part very little about real world timing, it may > not be sufficient for every case where you want to do an emulation of a > processor in an embedded device or a curious non-standard PC like Steve's. > > I think that's why the game system emulators MAME and MESS are perhaps more > akin to what he's wanting to do, in that they are able to deliver interrupts > in exactly the same way as the real CPU sees them i.e. at the end of > execution of the current instruction, and they consider instruction > execution timing to maintain an accurate internal time base, independent > from what the real world outside is doing. > > On most modern fast PC CPUs, they can easily emulate the older arcade game > or computer system hardware with plenty of horsepower to spare, and so it > appears realtime, synchronised via RDTSC or similar. I guess if you ran > them on an underperforming PC like an old 486 or early Pentium, you may see > things go at less than real speed. > > Maybe I'm totally off the mark, but at least that's how I read the QEMU docs > relating to hardware interrupts > > http://www.qemu.org/qemu-tech.html#SEC18 > > and the preceding sections about the way instruction blocks are translated > and executed. > > I'm sure Fabrice and others can shoot me down if needs be ... > > Cheers > > Jason > > > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > >