[Open-graphics] Sample VGA translation code, for nanocontroller

[Mark]

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"?
>> (http://en.wikipedia.org/wiki/VGA)
> 
> 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.
> 
Hey, super!