[Open-graphics] Sample VGA translation code, for nanocontroller
mark at jarvin.net
Wed Sep 5 16:03:25 EDT 2007
Timothy Normand Miller wrote:
> On 9/5/07, Mark <mark at jarvin.net> wrote:
>> What VGA graphics modes will this card support? Will the "planar"
>> mode(s?) be supported (whatever that means)? What about "programming
>> tricks" to get "704×528, 736×552, 768×576, and even 800×600"?
> If we support some of it, we'll probably be able to support all of it.
> With the hardware in place, we can improve the microcode over time.
I guess what I'm driving at is questioning whether or not the
nanocontroller is really the best approach for providing legacy VGA
support. If there's a reasonable subset of VGA that can be implemented
cheaply and easily in hardware, maybe that's a simpler approach
all-around. It seems from what I've read about VGA so far that it was
designed from the ground up to be cheaply implemented in custom
hardware. It's all counters, table lookups, and bit masking, right? I
mean, if they could do it in 1987, surely a modern FPGA can handle it
easily -- though maybe not if it's emulated via a RISC processor.
Is it feasible to reconfigure the Spartan when switching between modes
(i.e., from legacy VGA to 3D)? It's my understanding that the Spartan 3
supports partial reconfiguration, for whatever that's worth. That's
obviously not a solution for the ASIC, but the ASIC is likely to be
constrained in very different ways anyhow (e.g., there's no "oh, no! no
hard multipliers" on the ASIC front).
>> What about VGA text modes? Will anything besides 80x25 be supported?
> I don't see why not.
How about because it's easier not to and it's (possibly/arguably) not
important to support other modes? I mean, who am I to say that that's
actually the case? Still, it's a nagging suspicion. Am I alone here?
>> When we talk about VGA compatibility, do we just mean wrt the PC-adapter
>> interface or do we also mean wrt the adapter-monitor interface?
> We're not talking about signalling HERE. In fact, we're breaking the
> link between framebuffer and video. We can run the monitor at any res
> we like while the host thinks we're being completely VGA compliant
> with the video.
Right... one /could/ run the monitor at any resolution while looking
VGA-compliant to the host, but wouldn't the host have to first configure
the adapter to run that non-compliant resolution? Or would this be a
dip-switch thing? ;)
Besides, one can do so only if there's hardware built into the video
card to support it. I thought it was being argued in the past that the
nanocontroller had to have certain features to support scaling, but it
seems like you're saying that scaling is possible because the
nanocontroller is present and supports certain features.
In either case, this seems like a lot of effort to run DOS with
super-sharp fonts at 1920x1200. Besides, why scale on the video card
when the monitor will scale it for you anyway? *Especially* if you need
extra complexity in the video card and drivers to support it?
>> It seems to me, perhaps due to my own ignorance, that talking about
>> "legacy VGA compatibility" is pretty vague. Could we hammer out a list
>> of precisely what modes we want to support, maybe with a
>> required/desired kind of ranking for each bullet?
> For Linux, we need 80x25. For Windows, we need that and 640x480x16,
> and maybe 320x400x256.
Okay, so what's actually required to support those modes? It seems to
me that you just need a few small memories (could they fit in BRAMs?),
some counters, and a simple datapath involving bit-masking operations.
I suppose you need a separate datapath for each mode, but each datapath
is simple (i.e., I presume it's fast & cheap). I may be out to lunch,
but it sounds to me like a RISC processor is simply not well suited to
this because it can't deal effectively with the memory accesses and it
forces a lot of sequentiality into the process that isn't really there.
Granted, I'm not the expert, but that's my perception.
>> Am I right in assuming that developers hoping to work with OGD1 will
>> need a free 64-bit PCI-X slot?
> Well, it would work in that slot, but I did all my stuff in a regular
> PC at 33MHz. Note that while the 64-bit extension is there and hooked
> up to the XP10, our PCI controller doesn't support it. The extension
> is there for OTHER experimenters to use. We don't really need it.
More information about the Open-graphics