Subject: Re: VGA BIOS source code

[Bob Barry]

Does anyone know of any patches for bcc?

Not patches, but latest source (Dev86src-0.16.15.tar.gz) is available at
http://www.cix.co.uk/~mayday.

[Bartosz Fabianowski]

Alright, after digging into QEMU's graphics card emulation and into the
VGA BIOS source, I came to a few conclusions:

a) SDD 6.53 is doing something utterly wrong. It switches the graphics
card into a banked graphics mode (it specifically requests banked and
not LFB) and then simply "forgets" to switch banks. I checked and
double-checked, there is simply no call to the bank switching function.
I guess this also means the problem with SDD 6.53 can't be fixed by
tinkering with QEMU and/or the BIOS.

c) The fact that SDD does something wrong doesn't mean that only SDD is
at fault if graphics modes don't work as advertised. The entire VESA VBE
implementation is rather broken, shaky and incomplete.

b) The way the graphics card is emulated by QEMU (and Bochs and plex86
for that matter) is totally inefficient, error-prone and overly
complicated. The card's logic is split between a few C files (vl.c,
hw/vga.c) that get compiled and executed natively and a bunch of C files
containing heaps of x86 assembly that get compiled into a VGA BIOS. The
host emulator and the BIOS work together in a very complicated way and
it is never obvious why a certain function is implemented in the BIOS or
on the host.

d) Finally, as a conclusion from a) to c), I believe it would be best to
ditch the entire VGA BIOS and implement all functions of the graphics
card in C, natively, inside QEMU. This will be more efficient and less
error prone. Now, I haven't seen the patches mentioned by Fabrice that
emulate a CLGD54xx. But I certainly hope it is all native and not a
half-native half-emulated solution like the current one.

- Bartosz

[Kyle Hayes]

Post by Bartosz Fabianowski
Alright, after digging into QEMU's graphics card emulation and into the
a) SDD 6.53 is doing something utterly wrong. [snip]
c) [snip] The entire VESA VBE
implementation is rather broken, shaky and incomplete.
b) The way the graphics card is emulated by QEMU (and Bochs and plex86
for that matter) is totally inefficient, error-prone and overly
complicated. [snip]

Is there a reasons for the a c b ordering?

I think you are probably a little harsh on this code. It may be far from
perfect, but it does (mostly) work.

Post by Bartosz Fabianowski
d) Finally, as a conclusion from a) to c), I believe it would be best to
ditch the entire VGA BIOS and implement all functions of the graphics
card in C, natively, inside QEMU. This will be more efficient and less
error prone. Now, I haven't seen the patches mentioned by Fabrice that
emulate a CLGD54xx. But I certainly hope it is all native and not a
half-native half-emulated solution like the current one.

Getting something in place that pretends to be a known chipset and that can
act like a dumb framebuffer would probably help. That seems to be the
direction that Fabrice and Co. are going.

The Cirrus Logic chipset sounds like a good one for this.

Best,
Kyle

[Bartosz Fabianowski]

Post by Kyle Hayes
Is there a reasons for the a c b ordering?

No ;)

Post by Kyle Hayes
I think you are probably a little harsh on this code. It may be far from
perfect, but it does (mostly) work.

Yes, it does work. Maybe I was a bit harsh in my wording after wasting a
day on it, sorry.

Post by Kyle Hayes
Getting something in place that pretends to be a known chipset and that can
act like a dumb framebuffer would probably help. That seems to be the
direction that Fabrice and Co. are going.

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.

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.
It would be a windows driver that acts as a dumb stub and forwards every
request to the dumb side. Since it would be designed from the ground up
only for QEMU, it could be limited in its functionality to really only
being a frame buffer and nothing else. This would probably accelerate
the emulation quite a bit.

- Bartosz

[Fabrice Bellard]

Post by Bartosz Fabianowski

Post by Kyle Hayes
Is there a reasons for the a c b ordering?

No ;)

Post by Kyle Hayes
I think you are probably a little harsh on this code. It may be
far from perfect, but it does (mostly) work.

Yes, it does work. Maybe I was a bit harsh in my wording after
wasting a day on it, sorry.

Yes, and if you think about it longer, you will see the benefit of the
Bochs VESA VBE layer. It is one of the simplest implementation
you can think of.

The VMware driver idea is just an extension of it to add some
acceleration primitives, and of course it is much more complicated.
Adding real hardware support (such as a Cirrus Logic VGA card) will also
be more complicated than the Bochs VESA VBE layer.

Post by Bartosz Fabianowski
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. It would be a windows driver that acts as a dumb stub and
forwards every request to the dumb side. Since it would be designed
from the ground up only for QEMU, it could be limited in its
functionality to really only being a frame buffer and nothing else.
This would probably accelerate the emulation quite a bit.

It is already done for NT (read the faq), at least for a linear frame
buffer.

Fabrice.

[Derek Fawcus]

Post by Bartosz Fabianowski
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).

Post by Bartosz Fabianowski
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).

Post by Bartosz Fabianowski
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

[Bartosz Fabianowski]

Post by Derek Fawcus
Well the VMware 'chip' interface is documented, you could implement
it, however I doubt they'd be happy for you to use their drivers.

Actually, I wonder how happy Cirrus Logic will be if people use their
reference manuals to implement a GD54xx emulation. Clearly, each manual
states right at the beginning that you are not allowed to use it as a
basis for manufacturing or selling anything, unless you have written
permission from them. QEMU is not being sold by anybody AFAIK, but the
question whether writing an emulator is manufacturing an item (a
software item) still remains.

- Bartosz

[John R. Hogerhuis]

I'm not a lawyer, and anyone who worries about such things should talk
to one, but as far as reference docs go:

If they haven't patented some trickiness in their interface, and you
haven't signed an NDA, and it's not a trade secret (it ain't if the
document is freely downloadable) then there is probably very little to
worry about other than upsetting them enough to stop giving out info in
the future (which would be bad in the bigger picture for Linux). But I
don't see how software emulation of their chip is going to impact their
hardware sales in any obvious way.

Copyright infringement is the only thing one would really have to worry
about, and unless you are redistributing the document I'm not sure how
that would come into play.

-- John.

Post by Bartosz Fabianowski

Post by Derek Fawcus
Well the VMware 'chip' interface is documented, you could implement
it, however I doubt they'd be happy for you to use their drivers.

Actually, I wonder how happy Cirrus Logic will be if people use their
reference manuals to implement a GD54xx emulation. Clearly, each manual
states right at the beginning that you are not allowed to use it as a
basis for manufacturing or selling anything, unless you have written
permission from them. QEMU is not being sold by anybody AFAIK, but the
question whether writing an emulator is manufacturing an item (a
software item) still remains.
- Bartosz
_______________________________________________
Qemu-devel mailing list
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Derek Fawcus]

Post by John R. Hogerhuis
Copyright infringement is the only thing one would really have to worry
about, and unless you are redistributing the document I'm not sure how
that would come into play.

Cirrus sold off the video stuff to another company years ago - Conexant?
So I don't know if Cirrus still hold the copyright on the manuals , or
if they were passed over to that other company.

DF

[Hetz Ben Hamo]

Post by Bartosz Fabianowski
Actually, I wonder how happy Cirrus Logic will be if people use their
reference manuals to implement a GD54xx emulation. Clearly, each manual
states right at the beginning that you are not allowed to use it as a
basis for manufacturing or selling anything, unless you have written
permission from them. QEMU is not being sold by anybody AFAIK, but the
question whether writing an emulator is manufacturing an item (a
software item) still remains.

Cirrus Logic has ditched the graphics market long time ago (after ATI
has signed big contracts with Intel, HP and Compaq for using ATI chips
on those vendors's motherboards) and they're now on the business of
Linux/embedded and Windows/Embedded.

See: http://www.cirrus.com/en/products/

I hardly think that emulating a 5+ years chip would make them angry.
After all, it's a free publicity for them (and zero work, all drivers
are already outside)..

Thanks,
Hetz

[Jan Fabianowski]

Post by Hetz Ben Hamo
I hardly think that emulating a 5+ years chip would make them angry.
After all, it's a free publicity for them (and zero work, all drivers
are already outside)..

The technical types at Cirrus most likely don't care and might actually
be happy if their work from five years ago lives on. The people I was
thinking about are the legal types. Those people tend to think in very
strange ways that I never really understand. I wouldn't be surprised if
for some weird reason some Cirrus Logic lawyer actually would mind. I am
quite curious as to what the legal situation is, but I don't have the
money to ask a lawyer ;).

- Bartosz

[Johannes Schindelin]

Hi,

Post by Jan Fabianowski
The technical types at Cirrus most likely don't care and might actually
be happy if their work from five years ago lives on. The people I was
thinking about are the legal types. Those people tend to think in very
strange ways that I never really understand.

Actually, they are very easy to understand (especially the ones working in
USA): Let them think $$$ and they go berserk. (Not like a perl programmer
who thinks about such lovely things as variables, derefs and eol when
seeing a single dollar...)

Okay, now seriously: even if they would sell your grandma for half a buck,
those types have to be silenced. They can be such a PITA (see SCO vs.
everybody else; they just don't shut up). Maybe we should ask groklaw?

Ciao,
Dscho

[Bartosz Fabianowski]

Post by Johannes Schindelin
Maybe we should ask groklaw?

Maybe we should ask Cirrus Logic first? Plain out and simple explain
what QEMU, what it needs a graphics card emulation for and that the
CL-GD54xx series is very well suited for this. Though most people think
Cirrus will not mind if such an emulation is based on their docs, having
a written permission from Cirrus Logic is even better.

- Bartosz

[Daniel Serpell]

Post by Derek Fawcus

Post by Bartosz Fabianowski
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
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

I browsed the leo site, but couldn't find the manuals for the '3x
series, only 542x and 5446. Where you found them?

Thanks,

Daniel.

[Derek Fawcus]

Post by Daniel Serpell
I browsed the leo site, but couldn't find the manuals for the '3x
series, only 542x and 5446. Where you found them?

They are described in the '4x manuals. Look for gd544xtrm.pdf

DF

[Daniel Serpell]

Post by Derek Fawcus

Post by Daniel Serpell
I browsed the leo site, but couldn't find the manuals for the '3x
series, only 542x and 5446. Where you found them?

They are described in the '4x manuals. Look for gd544xtrm.pdf

Thanks, I see now :-)

I was browsing the x.org driver sources and none of the cirrus
logic chips has any XVideo or Render acceleration. The only
supported operations are Screen to Screen Copy and Solid Fill
(driver is really tiny).

Also, in the X sources is the vmware driver, with full docs,
so perhaps it's easy to write a compatible layer (so, vmware
driver can be used in the host).

Daniel.

[Vladimir N. Oleynik]

Fabrice.

Post by Fabrice Bellard
The VMware driver idea is just an extension of it to add some
acceleration primitives, and of course it is much more complicated.

The Vmware driver more simples of Bocsh VBE really.
The Bochs VBE have banking video memory and used standart VGA registers
for control.
The Vmware chip have framebufer only, don`t control by VGA-registers
and its "acceleration primitives" may be switch off by capatibiles mask
(to 0).
But Vmware chip is PCI only.

Post by Fabrice Bellard
Adding real hardware support (such as a Cirrus Logic VGA card) will also
be more complicated than the Bochs VESA VBE layer.

The Cirrus Logic chips have very very hard logic for emulation:
very many bits tangled expressions :-(


--w
vodz