From: craigm on 17 Feb 2007 07:40 Paul Carpenter wrote: > On Saturday, in article > <1OWdnYyu8dug1EvY4p2dnA(a)giganews.com> invalid(a)example.com > "Guy Macon" wrote: > >>nappy wrote: >> >>>"Guy Macon" <http://www.guymacon.com/> wrote... >>> >>>> Tell me, what does the "A" in "DVI-A" stand for? >>> >>>As you know the A stands for ANALOG. >> >>I am having trouble reconciling the above with the previous >>claim that "no analog DVI interface for monitors exists." > > He is looking from a different perspective:- > > You are looking the DVI connector spec for COMMERCIAL monitors (VESA) > Which have analog and digital interface on same connector. > > He is ONLY thinking about what you would see as the DVI pins. (DVI only) > >>>You can find the timings for generating vga, svga, xga, >>>sxga, uxga anywhere on the web. >> >>That's not an answer to the question I asked. > > Once you have time for line, frame, active and resolution, you can work it > out. > > e.g. dot clock is basically H pixels in H active time > line time divided by dot clock gives pixel counts per line > Non-active periods gives you relative position of active to whole > line > > Similarly V timings give you total number of lines and position > of active lines to vertical blanking and whole frame > This may, or may not help. http://www.ramelectronics.net/html/DVI_info.html
From: nappy on 17 Feb 2007 09:15 "CBFalconer" <cbfalconer(a)yahoo.com> wrote in message news:45D65B0D.9B1C9996(a)yahoo.com... > nappy wrote: >> "Guy Macon" <invalid(a)example.com> wrote in message >> > ... snip ... >>> >>> That's not an answer to the question I asked. >> >> I answered your question. It was a silly childish attempt at some >> kind of test. My displays are running in military aircraft all >> over the world. Not Mattell. > > Cool down. There is some sort of misunderstanding going on. Guy > is a long term reputable contributor to c.a.e. You also appear to > be knowledgeable and helpful. > Resepct is a good thing. I don't take to people calling me a liar. Or expecting me to complete some test of theirs. > -- > <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt> > <http://www.securityfocus.com/columnists/423> > > "A man who is right every time is not likely to do very much." > -- Francis Crick, co-discover of DNA > "There is nothing more amazing than stupidity in action." > -- Thomas Matthews > >
From: werty on 17 Feb 2007 21:01 In the middle of the stream with old s/w and hardware . But for $10 and cleverness , you can go 100 times faster , yet use the same bandwidth . That is if you are not shut out by Microsoft or Linux or C++ . I will place many white LEDs in a matrix , and place white paper "notes" and images over the LEDs . Its a true GUI , on a budget . When i need to send text , i will key log the text , and send it by pressing one of the keys next to the LED. I will use a $50 ucPROS.com ATMEL USB mcu EVB . To make it send RS232 is trivial , needs no explanation . One can record all the Linux command line , commands and send them in proper order , as if you were a PRO . You can hook it up to a PS-2 port ( K.B. ) and operate WXP like a pro , for the 200KB of stored key strokes and sequences inside the $50 wonder box . Now you will complain , it will take C++ , 2 years to code .... It can be done in Forth in hours . This is just one of my projects , that will be done in parallel , because i will use no existing software to "slow" me down . I will rewrite the USB [device] s/w to send full duplex , and obsolete OTG and Host . i'll hand it out free . Its actually quite fast and simply , because the USB team was after fame or fortune , so they had to make it look wizardly difficult . But i need no money , i know how easy high speed serial really is . And that makes it even easier to explain to others . I have many EVBs to test h/w and run OpCodes and familiarize myself with ARM 7 and 9 . I will create a free OpSys to stuff in the Ninetendo DS Lite . It has potential , and I/O pins and WiFi and USB . And to drive large LCD's and copy DVD movies i'll use a GP2X game box . Software is easy and fast , if you want it to be .
From: Guy Macon on 18 Feb 2007 00:41 werty wrote: >But for $10 and cleverness , you can go 100 >times faster , yet use the same bandwidth . >I will place many white LEDs in a matrix , >and place white paper "notes" and images >over the LEDs . That's a set of indicators, not a display. Indicators are a great solution if the information to be displayed is binary and known beforehand, but dispays are more appropriate for arbitrary text and graphics. >That is if you are not shut out by Microsoft >or Linux or C++. You do not appear to have read the thread. Nobody mentioned Microsoft, Linux, C++. We are talking about an 8051 and some custom hardware. >Now you will complain , it will take C++ , 2 years >to code... It can be done in Forth in hours . You obviously are not familiar with the fact that I have been an advocate of FORTH for embedded systems for many years. That being said, it doesn't help to tell fibs about how fast C++ coders can finish a job. The good ones are very fast indeed. BTW, Usenet posts are usually single spaced. Guy Macon <http://www.guymacon.com/>
From: Guy Macon on 18 Feb 2007 00:44
CBFalconer wrote: > >nappy wrote: > >> "Guy Macon" <invalid(a)example.com> wrote in message >> >... snip ... >>> >>> That's not an answer to the question I asked. >> >> I answered your question. It was a silly childish attempt at some >> kind of test. My displays are running in military aircraft all >> over the world. Not Mattell. > >Cool down. There is some sort of misunderstanding going on. Guy >is a long term reputable contributor to c.a.e. You also appear to >be knowledgeable and helpful. My apologies to "nappy" if my words came across as I suspect they did judging from his response. I really would like answers to my questions from someone with experience in developing displays. By the way, I strongly suspect that there are more aircraft flying that contain parts that I designed than contain parts he designed, but that is purely a function of the fact that aircraft have many more hydraulic actuators than they have custom digital displays, not a metric of engineering prowess. Getting back to the design; here is where I am so far: Even a 100 Mips 8051 isn't fast enough to directly generate 1024 x 768 video at 60Hz refresh. It looks like a counter clocking the address lines of a SRAM will get me the video signal as parallel data, and that I can turn the same data to VGA with some DACS and to DVI with some sort of encoder. 32 data bits seems like it will do the job, 8 for each color and the rest for synch, resetting the counter, etc. Two banks will allow the 8051 to modify the undisplayed bank with no particular time constraints -- a good thing considering the bank switching and byte selection needed to fill a 32 bit by 1 megabyte SRAM with a 8 bit by 64K microcontroller. Guy Macon <http://www.guymacon.com/> |