-------------- Original message ----------------------
From: "Timothy Miller" <[EMAIL PROTECTED]>

> That isn't to say that we won't cater to the long tail.  It's just
> that we'll have to do it on a case-by-case basis.  The SPI PROM can be
> programmed in sectors.  How about we reserve a sector for custom video
> info?  And provide a tool that you can use to program that sector with
> custom startup video settings?  We program our BIOS/firmware to check
> that sector and configure the video controller properly on boot.

   That's a very interesting thought.  From previous discussions, I'd expected 
that there would be no specific provision in OGD1 for custom video modes, other 
than the possibility of revising the Verilog code to do it.
   This line of thinking sounds like it could be worth developing further.  
What would the "tool" be like?  Would it be a piece of hardware, or a 
configuration program?  If it's a piece of hardware, one possible 
implementation is a stand-alone board with 120 or so jumpers and the shift 
registers to scan them; the obvious interface for a chain of shift registers is 
SPI.  That could simply tail onto the EEPROM's SPI chain.  All it would take on 
the main board is an empty site for a 6-pin header: power, ground, and the 4 
SPI pins.  The Tool board could be plugged in with a ribbon cable.  Then, if 
the FPGA reads past the end of the EEPROM and gets something back other than 
FF, it knows the Tool board is plugged in, and proceeds to read it and set the 
video mode.
   Since the Tool under this scenario is a stand-alone product, and not part of 
any OGD or OGC board, it could be sold under its own part number, and be 
permanently installed in any system that requires it.  Maximum flexibility for 
the end user.  It wouldn't even be tied to PCI graphics boards; it could be 
compatible with any graphics board that uses a TRV10 or an FPGA emulation of 
it.  In fact, the Tool board would be so generic, it could be used to configure 
products that have nothing to do with graphics.
   Should we start talking about an "OGT1"?  Should there be a little header on 
OGD1 to permit plugging extra devices onto the end of the SPI chain?  (I really 
hesitate to think about any changes to OGD1 now, but an SPI header might be put 
on the features list for a possible OGD2.)
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)

Reply via email to