[Qemu-devel] Re: Re: NE2K PCI and Windows 98SE & Cirrus Logic

[Qemu-devel] Re: Re: NE2K PCI and Windows 98SE & Cirrus Logic

[Mike Nordell]

Leigh Dyer wrote:

> I can also confirm that the 4Mb video RAM patch committed a couple of
> hours ago fixes the Cirrus Logic video with Win2k - it detected the
> card at install and seems to be running quite happily with the
> standard driver that ships with Win2k.

Ah, wonderful! I just tested and can confirm it too. No more slow VGA! :-)

I'm still curious why 32MB is claimed in the pci_register_io_region call,
even that it only has got 4MB. But besides that non-critical issue I'm happy
with it, and am starting to support the standpoint that -pci could be the
default soon.

/Mike

Re: [Qemu-devel] Re: Re: NE2K PCI and Windows 98SE & Cirrus Logic

[Antony T Curtis]

On Tue, 2004-06-08 at 09:18, Mike Nordell wrote:
> Leigh Dyer wrote:
> 
> > I can also confirm that the 4Mb video RAM patch committed a couple of
> > hours ago fixes the Cirrus Logic video with Win2k - it detected the
> > card at install and seems to be running quite happily with the
> > standard driver that ships with Win2k.
> 
> Ah, wonderful! I just tested and can confirm it too. No more slow VGA! :-)

I am still having problems with WinXP ... it appears to be trying to to
vram to vram color-expand pattern bitblts starting from the first byte
after the end of the current display (ie 800x600x16bit, src =
0x000ea600)
However, when I examine these bytes, they are always zero - which I
think is partly to blame for the display problems I am having.

To correct this, I have to turn off all acceleration.

-- 
Antony T Curtis <antony.t.curtis@ntlworld.com>

Re: [Qemu-devel] Re: Re: NE2K PCI and Windows 98SE & Cirrus Logic

[Derek Fawcus]

On Tue, Jun 08, 2004 at 10:15:05AM +0100, Antony T Curtis wrote:
> I am still having problems with WinXP ... it appears to be trying to to
> vram to vram color-expand pattern bitblts starting from the first byte
> after the end of the current display

... and this is why I was suggesting a simple BitBLT capable chip,  so
as to prevent the OS from trying to do the above.

It may we as well to limit the reported VRAM to the smallest allowed
size large enougth to hold the frame buffer,  again to try and limit
the OS attempts to utilise off screen memory.

> To correct this, I have to turn off all acceleration.

Actually that should in a lot of situations be faster than trying to
emulate the BitBLT.

DF

Re: [Qemu-devel] Re: Re: NE2K PCI and Windows 98SE & Cirrus Logic

[Fabrice Bellard]

Derek Fawcus wrote:
> On Tue, Jun 08, 2004 at 10:15:05AM +0100, Antony T Curtis wrote:
> 
>>I am still having problems with WinXP ... it appears to be trying to to
>>vram to vram color-expand pattern bitblts starting from the first byte
>>after the end of the current display
> 
> 
> ... and this is why I was suggesting a simple BitBLT capable chip,  so
> as to prevent the OS from trying to do the above.

5446 _is_ a simple BitBLT capable chip. IMHO, it will be difficult to 
find a simpler PCI chip.

The only drawback I see in this chip is that it has some ISA legacy 
which complicates a bit the VGA memory access. In particular, the mode 4 
and mode 5 will accur a serious performance loss if they are ever used. 
Moreover, Windows does not use the separate 16 MB data region for the 
bitblt data, which will also slow down a bit the optimized version of 
the driver (I want to suppress the memory callback functions in the most 
common cases).

SIS6326 would be better in that respect. Now, thanks to the work done to 
integrate the Cirrus VGA driver, the QEMU VGA subsystem is more generic 
so anyone is free to add new VGA cards :-)

Fabrice.

Re: [Qemu-devel] Re: Re: NE2K PCI and Windows 98SE & Cirrus Logic

[Fabrice Bellard]

Antony T Curtis wrote:
> On Tue, 2004-06-08 at 09:18, Mike Nordell wrote:
> 
>>Leigh Dyer wrote:
>>
>>
>>>I can also confirm that the 4Mb video RAM patch committed a couple of
>>>hours ago fixes the Cirrus Logic video with Win2k - it detected the
>>>card at install and seems to be running quite happily with the
>>>standard driver that ships with Win2k.
>>
>>Ah, wonderful! I just tested and can confirm it too. No more slow VGA! :-)
> 
> 
> I am still having problems with WinXP ... it appears to be trying to to
> vram to vram color-expand pattern bitblts starting from the first byte
> after the end of the current display (ie 800x600x16bit, src =
> 0x000ea600)
> However, when I examine these bytes, they are always zero - which I
> think is partly to blame for the display problems I am having.
> 
> To correct this, I have to turn off all acceleration.

It seems to be a bug in the Windows NT Cirrus driver. It uses pattern 
fill for solid fill (as on a 5430), but it does not initialize the 
pattern buffer correctly. I made a kludge in the device emulation by 
initializing the VGA memory to 0xff at boot time.

A possible explanation of that problem is that NT does not recognize the 
VGA card as a true 5446. It may use some undocumented register to do the 
device probing instead of the PCI device ID.

For example, I spent a long time to find that NT uses SR15 to probe the 
memory size (it was a bug indicated by early users...).

Fabrice.

Re: [Qemu-devel] Re: Re: NE2K PCI and Windows 98SE & Cirrus Logic

[Derek Fawcus]

On Tue, Jun 08, 2004 at 10:18:22AM +0200, Mike Nordell wrote:
> I'm still curious why 32MB is claimed in the pci_register_io_region call,
> even that it only has got 4MB.

Because that what's the hardware does - actually,  from memory I thought
this family only claimed 16M.

The reason for the larger size is given in the datasheet - it's multiple
mapped copies of the RAM so as top have automatic byteswapping.  So something
to beware of if this device is used under the PPC emulation.

DF

Re: [Qemu-devel] Re: Re: NE2K PCI and Windows 98SE & Cirrus Logic

[Fabrice Bellard]

Derek Fawcus wrote:
> On Tue, Jun 08, 2004 at 10:18:22AM +0200, Mike Nordell wrote:
> 
>>I'm still curious why 32MB is claimed in the pci_register_io_region call,
>>even that it only has got 4MB.
> 
> 
> Because that what's the hardware does - actually,  from memory I thought
> this family only claimed 16M.
> 
> The reason for the larger size is given in the datasheet - it's multiple
> mapped copies of the RAM so as top have automatic byteswapping.  So something
> to beware of if this device is used under the PPC emulation.

32M is correct: 16M are mapped for the frame buffer in various 
endiannesses and 16M for the bitblt engine data access (in 5446 rev B).

Fabrice.