From: craigm on
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

"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

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



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



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/>