I dug this up from he web while doing a search. I wonder if this was
ever solved. I have never tried to use a mono adapter or VGA adapter in
a system with AGP. I realize this is a old posting.
From: Thomas Block
Sent: Tuesday, December 17, 1996 2:03 PM
To: Baxter, Brent; Rasmussen, Norm
Cc: Comins, Todd; Epler, John; Thomas Block
Subject: PPB inability to separate VGA/MONO cycles
Brent and Norm -
This email message is about a current limitation with the PCI-PCI Bridge
(PPB) that will be inherited by AGP chipsets as they implement PPBs to
front-end the AGP bus. Further, the ramifications of this problem are
heightened for the AGP PPB case relative to a generic PPB. Finally, I
present a proposal for maintaining current PC compatibility in the
AGP/PPB.
As you are probably aware, the evolution of MDA-CGA-EGA-VGA resulted in
the ability of VGA and monochrome controllers to coexist in a PC. In
fact, this coexistence is used extensively today for debugging: main
application running through (S)VGA controller and debugger (SOFT-ICE,
CodeView, etc.) running through monochrome adapter.
The memory and I/O resource split is as follows: 3Bx I/O to mono,
3Cx-3Dx I/O to VGA, B0000-B7FFF memory to mono, A0000-AFFFF and
B8000-BFFFF memory to VGA. However, having said that, let me also say
that VGA can do mono emulation and does that emulation through 3Bx and
B0000-B7FFF. (VGA mono emulation is done when the VGA controller
ascertains that there is not a mono adapter in the system, and the user
requests mono text mode 7.)
The mono adapter (which lives behind subtractive decoders on the ISA
bus) hard decodes 3Bx and B0000-B7FFF. The VGA has two decode control
registers, one for I/O, the other for memory. They are:
I/O: 3C2 (write) / 3CC (read) bit 0, if 0 decode 3Bx, if 1 decode
3Dx (power-on default is 0)
Memory: GR6 (3CE index 6, 3CF data) bits 3:2
00b: decode A0000-BFFFF (power-on default)
01b: decode A0000-AFFFF
10b: decode B0000-B7FFF
11b: decode B8000-BFFFF
The PPB, through its VGA Enable bit, absolutely decodes 3Bx-3Dx and
A0000-BFFFF. Therefore, in today’s systems, if a VGA exists behind a
PPB, concurrent monochrome access (through subtractive decoder to ISA
bus) is not possible. There is no protocol to redirect master aborts of
mono cycles back upstream so they can be picked up by the subtractive
decoder.
I do not think this is a big problem for generic PCI PPBs since the user
that wishes to do monochrome monitor debugging is probably on bus 0 with
his VGA, or at least can relocate his VGA there. The only problem might
be a “video-down” implementation that is behind a PPB (do any of these
exist?). Since PPBs have been around for several years now and this
limitation is just now being understood, I think it is fair to say that
the generic PCI PPB case is not a problem.
However, with AGP/PPB, there are several problems. Given that the AGP
graphics device is also the only VGA device (a proposition that I think
will be true for most AGP systems), then the AGP/PPB (as currently
designed) will break concurrent monochrome display adapter access. This
will be a big problem for many people, not the least of which will be
all of the AGP video vendors that will be trying to debug their
software. It is true that there are other debug configurations, such as
serial port link to another system, etc., but I would estimate that most
people are very reliant on monochrome debug capability. Another
possible multi-monitor debug environment would be another VGA, but this
would only be applicable to those AGP vendors that have a non-SVGA
accelerator implementation and certainly would not work for debugging
AGP/VGA. I think the lack of monochrome debug access is probably the
biggest problem.
As I see it, if the AGP/PPB has the VGA Enable bit enabled, it can have
three different implementations regarding mono cycles: absolute decode
of all mono cycles (current PPB capability), absolute rejection of all
mono cycles, or dynamic decode/reject of all mono cycles (i.e.,
shadow/snoop the AGP/VGA 3C2/3CC and GR6 registers). I believe that the
last implementation (shadow/snoop the VGA decode registers) is the only
one which will guarantee complete PC compatibility. The problem with
the first implementation (absolute decode) is detailed above (i.e., no
concurrent monochrome access).
There are two potential problems with the second implementation choice
(absolute rejection of all mono cycles). All of today’s VGA
implementations utilize a derivation of the original IBM/Quadtel VGA
core and core BIOS. The power-on value of the VGA core 3C2/3CC register
bit 0 is 0, meaning that the VGA chip initializes as a monochrome
decoder, not a VGA decoder. There is quite a bit of code in the VGA
BIOS that ascertains the existence of a monochrome adapter and flips the
3C2/3CC bit 0 state in the process. Not allowing monochrome cycles to
reach the AGP/VGA core, when it is prepared to receive them, may very
well break VGA BIOS initialization and/or subsequent mode sets. (I will
try to get more data on what exactly will happen in this case.) The
second problem with an AGP/PPB doing absolute rejection of mono cycles
is that VGA modes 7 (text) and F (graphics) will not work, since they
are driven by 3Bx cycles. Obviously, VGA test programs (such as DMU,
etc.) will fail. Many graphics and system vendors incorporate these
tests into their qualification processes. Both of these problems have
the potential to force video vendors to rewrite their VGA BIOS. Since
the goal of AGP is to piggy-back on today’s current PCI configuration
scheme in order to achieve minimal system re-work, an implementation of
AGP/PPB that forces VGA BIOS changes would be counter to that goal.
The only correct choice, in my view, would be for the AGP/PPB chipset
implementation to shadow the 3C2/3CC bit 0 and the GR6 bits 3:2. If the
VGA Enable bit is set, then all accesses to the aforementioned bits
should be snooped and the shadow registers updated accordingly. The PPB
VGA decoder (3Bx-3Dx, A0000-BFFFF) should be modified to act on the
state of the 3C2/3CC and GR6 shadow registers. If AGP is going to allow
the VGA component, it should implement it fully in the interest of
compatibility.
Number Nine has experience with this particular VGA decode problem. An
early implementation of our Imagine Series 128-bit accelerator utilized
an ISA bridge to which we connected an external VGA chip. We could not
meet the PCI decode latencies for VGA in that configuration and thus had
to implement shadow registers (3C2/3CC, GR6) in the host bus interface.
I hope you will consider this request for an AGP/PPB design
clarification and make sure that the appropriate chipset design groups
understand the problem. Please let me know if I can provide any further
information.
Thanks, Tom
Thomas Block
Number Nine Visual Technology Corporation
18 Hartwell Ave.
Lexington, MA 02173
617-674-8666
xxxxx@nine.com
http://www.nine.com http:</http:>
Jamey Kirby
StorageCraft, inc.
www.storagecraft.com http:</http:>
xxxxx@storagecraft.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
There is a problem with video drivers and DS