On 9/4/07, Patrick McNamara <[EMAIL PROTECTED]> wrote: > > It doesn't actually have to do constant conversion for anything but text > modes, and then > only when the text changes. I'm still not sure how we handle blinking > other than run the controller in a busy loop.
Ok, yes, in the graphics mode, we could indeed have it do the translation immediately when pixels are written. But for that matter, we could do the same in text mode. Reads would have no special overhead, while writes might back up in the queue a bit, but so what. > > Exactly. When I finish my example program, you'll see what I have in mind. > > > > Something like this: > http://www.supersecret.org/~mcnamara/fbconvertprogram.txt Yes. Well, I think. It's kinda late, so I don't have the brain power to really dig into assembly code right now, but probably. :) > > There is no VGA memory. It's all a trick. Some portion of our rather > > large graphics memory is set aside and mapped into A000 or whereever > > for VGA (text mode or graphics mode or whatever). Some other portion > > is set aside for a translated version of the image. The video > > controller is programmed to scan the second one. The nano controller > > is programmed to read the first one and translate it into pixels for > > the second. > > > From the card perspective yes. From the system perspective, VGA memory > is a 64k contiguous block mapped at physical address 0x000A0000. Based > on the Linux kernel documentation, it is legal to program the old ISA > DMA controller to target the VGA memory space. That means that in VGA > mode we have to be capable of accepting host initiated. Though since it > is host initiated and not card initiated, I don't think we care. To us > it just looks like a big stream of reads or writes. You're talking about 3rd-party DMA, which we don't care about. > > I can't think of a situation where we'd want to do VGA and 3D at the same > > time. > > > > I've got one sitting on my desk right now: VMWare, or Xen, or your > favorite virtualization. Ok, so that was kind of a contrived example > since they don't have to have it. My point was more that just because > you and I can't come up with a reason doesn't mean there isn't one. :) If you're running multiple virtual machines, only one is actually in control over the physical graphics device. Or none are and something else is in control of it. > > The nanocontroller has a shifter that takes an operand indicating the > > amount to shift. > > > > Anyhow, there's absolutely no reason why the VGA hardware should be > > fast. It just has to be _correct_. There needs to be some image on > > the screen that contains something recognizable as the pixels you > > would see on a regular VGA card. But they don't have to fill the > > screen, be as large, or whatever. > > > > > Actually, I'm thinking that it may be most efficient to actual > instantiate most of the VGA pipeline in hardware similar to the > multiplier and only have the nanocontroller handle the final conversion > of the color space or font to bitmap. Or maybe not, but it is worth > thinking about whether it is more efficient to implement the hardware > for a "general purpose" processor to emulate a fixed hardware pipeline, > or to just implement the pipeline and make the processor much simpler. When we were thinking about VGA alone, it made sense to design dedicated hardware. When we were thinking about DMA alone, it made sense to design dedicated hardware. But with them being mutually exclusive, there's a chance that we have a net win on logic area by designing something more general purpose that can be programmed to do either. Plus, now we can fix bugs in them more easily in the field. For that matter, we could hide GPU bugs behind it. -- 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)
