[Open-graphics] Sample VGA translation code, for nanocontroller
Timothy Normand Miller
theosib at gmail.com
Wed Sep 5 11:41:13 EDT 2007
On 9/5/07, Patrick McNamara <wpmcnamara at yahoo.com> wrote:
> Timothy Normand Miller wrote:
> > But I also would like to see an analysis that suggests something will
> > be terribly hurt by us having slow performance in VGA mode.
> My underlying concern is that regardless of how much we may wish VGA
> compatibility didn't exist, not only does it have to, it will be the
> first thing a "user" sees when using an open graphics based card on an
> x86 system. The last thing we want it for the first impression to be
> "Boy this sucks..."
Certainly. But what I usually see when I boot up is a blurry scaled
image that's out of proportion. I wouldn't mind if the monitor were
being driven at its native resolution with the VGA stuff integer
scaled and centered on the screen.
> We certainly need to have a reasonable update rate in both text and
> graphics VGA mode since x86 systems will use these modes during OS installs.
Sure, but it doesn't even have to be 60fps.
> Whether we like it or not, the VGA interface will be the first
> experience with an open graphics based card for the majority of the end
Agreed. We shouldn't do a crappy implementation. Let's see if we can
make something that looks even better.
> > My suggestion is to check for PCI requests only at those points where
> > we have no pending requests. We can check for a significant number of
> > them. We can do that between every pair of characters when
> > translating 80x25. Then between frames, we can poll a few thousand
> > times before going to the next.
> Hmmm. I think I have missed something somewhere. What exactly does
> the nano controller have to handle during a PCI transaction?
One situation has to do with VGA graphics mode where the memory
accesses are not simple reads and writes. There's other logic
involved that makes them do more. The other has to do with the fact
that both the nanocontroller and PCI are competing for access to
graphics memory. So we gate memory access through the nanocontroller.
Normally the nanocontroller wouldn't be involved. Usually, PCI is
connected (more) directly to the memory system. But we need to make
it switchable so that PCI accesses are queued and wait ready for the
nanocontroller to process them. We could queue up a good number of
writes, while reads would have to be queued singly.
Timothy Normand Miller
Open Graphics Project
More information about the Open-graphics