RE: PPB inability to separate VGA/MONO cycles

["Thomas C. Block" <thomas_block@nine.com>]

Hi John -

Thanks for your comments.  I'll try to find Serge and query him about this.

I'll let you know how this turns out.

Tom



----------
From:  John R Pierce[SMTP:pierce@hogranch.com]
Sent:  Tuesday, December 17, 1996 6:39 PM
To:  Thomas C. Block
Subject:  Re: PPB inability to separate VGA/MONO cycles

hmm. comments. yeah.

I know a lot of folks who'd be somewhat upset about losing their mono cards. 
Me, I debug with wdeb386 still [old dogs, new tricks, and all that], so I'm
into the serial port thing.  I use Procomm macros to automate lots of things
and actually prefer running the debugger from a window on my development system
rather than a dedicated mono monitor so I can cut and paste stuff from it,
etc... 

I don't know ANYONE using codeview anymore, but SoftICE is, of course, quite
popular.  It might be a cool thing to come up with a way of sticking some
reasonably generic video board (maybe a S3 Trio/V?) into a PCI slot and using a
softICE driver that would access it in linear graphics mode rather than VGA
mode.  Mono monitors are getting hard to come by.  One advantage of this is it
could be used to support a higher resolution debug screen, like 1024x768 could
give a reasonable 128 x 64 lines of 8x12 fonts or so.  I'm sure most kernel
level software developers wouldn't mind having to use something as generic and
reasonably cheap as a Trio/V card instead of the old mono cards... VGA 14"
monitors are certainly cheap enough these days.

anyways, if you hope to sway the AGP implementation of this stuff, you'd better
get a handle on someone at Intel who has the power to actually DO something and
lean hard on them...  One name I can think who actually can affect things there
is Serge Rutman (at IAL, somewheres in Santa Clara, CA) but I can't seem to
find his email address (I had it when I was at Diamond, but I guess I didn't
keep it).

-jrp

----------
From: Thomas C. Block <thomas_block@nine.com>
To: 'Albanese, Lane' <lalbane@scs.philips.com>; 'Bennett, Kendall'
<KendallB@scitechsoft.com>; 'Decker, Brian (3)' <Brian_Decker@dell.com>;
'Pierce, John' <pierce@hogranch.com>; 'Soneira, Ray' <rsoneira@displaymate.com>
Subject: FW: PPB inability to separate VGA/MONO cycles
Date: Tuesday, December 17, 1996 2:22 PM

Video guys -

I sent the attached email to the Intel AGP folks detailing a problem with
VGA/Mono decode in the AGP chipset.  I'd be interested in any comments you all
might have about this.  Please feel free to distribute to other interested
parties who may have an opinion.

Thanks in advance, 

Tom



----------
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
thomas_block@nine.com
http://www.nine.com

----------

¦dQ