From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BV7hL-0007mW-Bt for qemu-devel@nongnu.org; Tue, 01 Jun 2004 07:44:51 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BV7hJ-0007lW-Gc for qemu-devel@nongnu.org; Tue, 01 Jun 2004 07:44:49 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BV7hJ-0007lO-Cj for qemu-devel@nongnu.org; Tue, 01 Jun 2004 07:44:49 -0400 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BV7gs-0003J5-9x for qemu-devel@nongnu.org; Tue, 01 Jun 2004 07:44:22 -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 i51BiI1P005861 for ; Tue, 1 Jun 2004 13:44:19 +0200 (MEST) Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id MAA29588 for qemu-devel@nongnu.org; Tue, 1 Jun 2004 12:44:18 +0100 (BST) Date: Tue, 1 Jun 2004 12:44:18 +0100 From: Derek Fawcus Subject: Re: Subject: Re: [Qemu-devel] VGA BIOS source code Message-ID: <20040601124418.E25801@edinburgh.cisco.com> References: <200405312200.03734.bobb@absamail.co.za> <40BB92D1.6040508@fabianowski.de> <200405312114.08329.kyle@silverbeach.net> <40BC18B6.9040300@fabianowski.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <40BC18B6.9040300@fabianowski.de>; from bartosz@fabianowski.de on Tue, Jun 01, 2004 at 07:48:38AM +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 Tue, Jun 01, 2004 at 07:48:38AM +0200, Bartosz Fabianowski wrote: > That seems like a good idea. Though if you are pretending to be some > particular chip set, you should be prepared to emulate the most weird > register settings that drivers could set for that chip set. So if the > goal is to reach close to 100% compatibility, I fear a substantial > subset of the entire spec for the chosen subset will have to be implemented. and that's the reason to try and pick a simple chip... The good thing about the Cirrus chips, is that (ignoring the Laguna family - '62/'64/'65) the TrueColour ('2x) and Alpine ('3x/'4x/'80) are all basically variations on a theme. So one should be able to take the work provided for the non PCI version (a '2x or '30 I guess), and update it to be a simple PCI version. Then (if desired) one could morph it into later chips (video windows etc). >>From a quick glance at the datasheets and tech refs, it looks as if the '34 or '36 is the one to target - being early PCI supporting versions and supporting 4M of video memory (i.e. 1024x768 @ 24 bit). They do contain a BitBLT, but it's a relatively simple 2 operand (16 operations) version, and may actually be the same op's as supported by X/Windows - need to check. I'm not sure, but I guess the '36 is the one to target, as removing the ISA and VL-bus of the '34 may make things simpler. But the '36 BitBLT is slightly more capable (more support at 24/32 bpp, and seems to hang off a FIFO). But it may be that the '34 canonly to 1024x768 @ 16bpp. Mind the other complexity (some may think it an advantage) is that the '36 has byte swapping PCI windows (think PPC support). > Since my main interest is in running Windows inside QEMU, I could also > envision adding another driver later, similar to what is done in VMWare. Well the VMware 'chip' interface is documented, you could implement it, however I doubt they'd be happy for you to use their drivers. DF