On 3/17/06, James Richard Tyrer <[EMAIL PROTECTED]> wrote: > Timothy Miller wrote: > > On 3/17/06, James Richard Tyrer <[EMAIL PROTECTED]> wrote: > >> The extra RAMDAC bits are used for gamma and color correction. You > >> still have only 8 bits per color in memory. > > > > Understood. > > > >> The Philips 3xDAC has 10 bits per channel, and we are grounding the > >> 2 LSBs rather than connecting them to the FPGA. > > > > As I mentioned in another email, we simply haven't got the spare pins > > for it. > > Perhaps using LVDS driver chips (also to be un-populated on the standard > board) could be use to free up some pins. These would need to be > mounted very close to the FPGA > > Short search found Fairchild FIN1102 rated at 800 MB/s 3.3v supply would > accept 2.5v LVC input levels with no extra parts unless you wanted a > series termination resistor. Priced @ $1.20 (1K). Only two channel so > you would need 18 of them. Doesn't sound like a great idea, but it > would work.
Are you suggesting inserting an extra device in between the FPGA and the DAC? For a high-speed signal? And regarding using the LVDS pins, it's all or nothing. For high-speed signals, you really want point-to-point. We're doing badly enough routing them to two places. Also, you seem to be suggesting that we canibalize pins from the high-speed head to improve the low-speed head. What if you wanted to use both at the same time? Or are you saying you've identified some totally unused LVDS pins? > > > If it becomes REALLY important, we can do temporal modulation. > > I don't like this idea. Just MHO. Me neither. > > Tech Source and plenty of others have been doing it for ages with > > medical LCD displays at 60Hz. > > Interesting but ... I think that gamma correction/color matching > software works by loading a palate. And the same would be the case here. Rather than just spitting the 10 bits out, we'd run it through some extra logic. Nevertheless, I agree that it's a bad idea. > > One of the design requirements is that OGA should be very good for > > 90% or more of desktop users. Very few are going to be overly > > concerned about gamma correction at all, let alone how many bits of > > precision on the DAC. > > Yes, you are correct on this. The only real market for fine control of > gamma and color is pre-press color work. Perhaps most of those people > still use Macs. :-) Yes, but wouldn't we like them to all move over to Linux? :) > > I'm not, by any means, saying you don't have a valid point. But I am > > trying to determine how critical this is for most users and see how > > we could possibly solve the problem given the hardware constraints > > we have. > > OTOH, if this hardware were available, then Linux color matching > software could easily be changed to support it. Gamma correction > doesn't really work well with only 8 bits. Oh, I know. You end up seeing bad contour lines in darker pixels. It's bad enough WITHOUT gamma correction throwing away some of your luma levels. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
