On 9/5/07, Mark <[EMAIL PROTECTED]> wrote: > 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.
What had been the orginal plan, but with DMA also needing high-level control, we thought it would be nice to combine them. > Is it feasible to reconfigure the Spartan when switching between modes > (i.e., from legacy VGA to 3D)? No. Besides, we're pretending this is an ASIC so that we can turn it into an ASIC later. > It's my understanding that the Spartan 3 > supports partial reconfiguration, for whatever that's worth. We weren't able to do it. > 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). True. > >> 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? What I mean is that if we can program the nanocontroller to support 80x25, we can make it do other modes too. > 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? ;) Typically, we'd try DDC first to find out the monitor's preferred resolution. If that fails, we pick a standard mode like [EMAIL PROTECTED] > 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. It supports whatever you want, as long as you can fit the instructions into its program file. > In either case, this seems like a lot of effort to run DOS with > super-sharp fonts at 1920x1200. I wouldn't bother with anything special here. > 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? Like I say, not all monitors scale or scale well. > >> 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?), No, but we can efficiently fetch slices into the scratch memory. > 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. Since the translation process would be a background loop, basically, its performance isn't all that important. It's only an issue with respect to memory access and any overhead it imposes for that. And even then, it's not so bad. Remember that VGA was originally designed for 8MHz ISA, and it was reasonably usable even then. We'll beat the heck out of that for sure. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
