On Saturday 26 August 2006 01:10, Jon Smirl wrote:
> On Fri, 25 Aug 2006 23:49:01 +0000, mykrowatt wrote:
> >    I didn't see this message earlier.
> >    Tim and I have been discussing support for fixed-frequency displays
> >    off-line, trying to whittle down the on-chip logic to the absolute
>
> Where are fixed frequency displays being used? I haven't seen one since
> around 1996 or so and that was on a Sun system.

I'm as bemused as you about the issue.  I've seen *one* fixed frequency 
monitor, and that was sitting on a shelf at Snell & Wilcox 
(http://www.snellwilcox.com/).  Admittedly it was plugged into a real-time 
HDTV compositing system with 64 GB of RAM at the time... can you even buy 
them any more?

In addition, my suggestion of, 'Borrow your friend's multisync for long enough 
to set up the card's PROM for your super-duper fixed-frequency monitor,' 
seems to be completely unacceptable for some reason.

I've said it before, I'll say it again: an inordinate amount of time seems to 
be being spent putting in features that the _vast_ majority of users of TRV10 
will _never_ need.  Embedded systems developers will either have the PROM 
pre-programmed, or will eliminate the PROM entirely (possibly by emulating 
it).  Users of OGC1 or other TRV10-based cards will either have a multisync 
monitor, be able to borrow one, ask their vendor to pre-program the card, or 
be able to log into their computer over serial/SSH/VNC/some other remote 
login protocol.

Having said that, chaining onto the end of the SPI bus is the most reasonable 
solution I've heard so far.  I'd suggest a PIC + serial port as the tidiest 
solution, requiring the following components:

- 9-pin female DB9 connector
- MAX233 (or similar RS232 level-shifter/line driver)
- 8-bit PIC
- 5-pin SPI connector
- a couple of decoupling caps (probably a couple of 0.1 uF ceramics would do)

You could probably fit the entire thing inside a 9-pin DB9 housing without 
breaking a sweat.  If anyone's interested, I'll make up a PCB layout & a 
proper BOM for this, or a very similar circuit using an FTDI USB-RS232 
converter chip.  Usage would be as follows: before turning on the card, 
pre-program the PIC with the memory image wanted using the RS232 (or USB) 
link.  Plug cable into card.  Power on card.  With some judicious use of 
diodes, you could probably get the PIC card to work as a standalone 
programmer for batch jobs, without needing to be connected by serial except 
for changing the desired memory image.

For vendor & factory use, it would be nice to be able to (re)configure the 
card without having to put it into a PCI slot and power it up.  Is there 
going to be any scope for this?  At the moment, how are you planning to have 
the factory image programmed into the ROM?  As you guys are probably aware, 
attention to manufacturing detail[1] can make or break an consumer 
electronics project.

Quick question for users of fixed-frequency monitors: how do you change your 
BIOS settings, seeing as the BIOS of every PC-compatible I've ever seen uses 
VGA?  I'm curious... I'm kind of assuming that you're not using PCs!

Peter :)


[1] If you look inside a recent Sony or Nokia phone you'll see that the 
circuit boards have components on one side almost exclusively.  Why?  They 
could pack the circuits in much closer if they put parts on both.  Reason: a 
second run through the solder paste stencil, populate, reflow process takes 
time.  The saving from avoiding a second assembly sequence easily outweighs 
the cost of a larger PCB.

-- 
Fisher Society publicity officer            http://tinyurl.com/o39w2
CUSBC novices, match and league secretary   http://tinyurl.com/mwrc9
Quake II build tools maintainer             http://tinyurl.com/fkldd

v2sw6YShw7$ln5pr6ck3ma8u6/8Lw3+2m0l7Ci6e4+8t4Eb8Aen5+6g6Pa2Xs5MSr5p4
  hackerkey.com

Attachment: pgpqNVeWO25Es.pgp
Description: PGP signature

_______________________________________________
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