qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Subject: Re: [Qemu-devel] VGA BIOS source code


From: Derek Fawcus
Subject: Re: Subject: Re: [Qemu-devel] VGA BIOS source code
Date: Tue, 1 Jun 2004 12:44:18 +0100

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]