8051 to DVI interface?

The monitors I develop are multi format. The H&V timings for DVI are equivalent to VGA timings. Regardless of the display type.

Thanks, I hoped this would be the reason. This makes it quite likely that digital-only interfaced monitors will work at much lower frequencies than 60-70 Hz, perhaps out of spec. (One reason to prefer lower frequencies is to have the RAM consume less power). I still wonder why the strive for faster TFT-s, they now specify 8 mS response times, what's that about? I doubt we can see the difference between 30 and 8 mS... But then may be the test conditions are such that 8 mS is 10 to 90% and the tails are much longer and can be seen at lower speeds, I never dug into that.

Dimiter

Graphics, animation, video.

Oh yes we certainly can. Especially when it is repetetive.

Finding LCDs at one time with response times sufficient for real time stereo dispalys was a pain. Easier now.

Especially if it is something moving fast across the screen.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
              GNU H8 & mailing list info
             For those web sites you hate

I am having trouble reconciling the above with the previous claim that "no analog DVI interface for monitors exists."

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.

There is no such thing as an analog-digital anything. If you are having trouble understanding that then go read the DVI spec again. It is simpy VGA piggybacked on a DVI connector. . It is NOT DVI.

So blow it.

test over.

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)

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

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
              GNU H8 & mailing list info
             For those web sites you hate

This may, or may not help.

Resepct is a good thing. I don't take to people calling me a liar. Or expecting me to complete some test of theirs.

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 .

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.

You do not appear to have read the thread. Nobody mentioned Microsoft, Linux, C++. We are talking about an 8051 and some custom hardware.

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.

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.

You do not appear to have read the thread. Nobody mentioned Microsoft, Linux, C++. We are talking about an 8051 and some custom hardware.

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

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

-----------------------------------------

white paper covering white LEDs

to communicate

100 times faster , with a human .

start with 30 . Change the image

as you create the software , to make

the image , most intuitive .

---------------

Imagination is more important than knowledge ...

You cant do nuttin , only talk and write .

I am an expert on ultra high speed serial . TMDS is obviously advert's , because you must minimize all transistions , and increase all data rates , as a ratio. And differential , rejects absorbed noise on the line . Any strong noise will add to both wires and cancel in the transformer .

Everything today , is Run Length Limited , because its so good . Your HDD and USB and FireWire use it .

So its all hype .

I will be creating a new USB , bi-direction mode at 10 Giga Bits/sec . It needs new hardware . USB hi-speed can be up'd to 800 .

I think you will succeed , if you assume the DVI-d ppl are lying to cover up a very simple digital system . Its just mostly Lum' and less color . and sending increments , then a full ref frame occasionaly . But why do you need to send a full Ref frame , unless you think it will lose "sync' !!

And DescreteCosTransform is also Hype . There is a simple , common sense way to compress video , all you need is the desire and some hands on , and any one can beat MPEG .

First ill do O.S. , then DVD ( MPG-2) ...JPG

Another technobabble troll hiding behind google groups.

Ian

....

Considering you are driving this display from a 8051 microcontroller.

Do you really need to store full 24 bit colour information? How many colours do you need? Will you be displaying images like photos?

I would consider using at most 8 bits for colour information or 9 to make it easier to process on video side. Then you only need 3 bit DACs or your own R/2R ladders for analog o/p, you can choose how to make the palette of colours. Effectively what 24bit colour codes are represented by the

8/9 bits stored. Weighting of R/2R ladder to be a summing point of different levels is a crude way to do it.

Remember 8 bits for 256 colours is actually about the full COUNT of colours on most windows systems (when not displaying images).

Storing the timing information in RAM is inefficient and will greatly increase the size of RAM required. Let alone the processing you will need to do.

For example a typical VGA timing format, XGA - 1024 x 768 will be suitably larger but I don't have the figures at hand:-

Pixel Clock 25.175MHz Line Frequency 31.469kHz Frame Freuency 59.94 Hz

Line is 800 pixels total Active 640 pixels Blanking 160 pixels (front/back porch & sync time)

Frame is 525 lines total Active 480 lines Blanking 45 lines (front/back porch & sync time)

Therefore a full 'pixel' memory map of VGA is

800 x 525 pixels = 420000 pixels for 32 bit 'pixels' = 1680000 bytes (1.602 MB)

Active Video is 640 x 480 pixels = 307200 pixels for 32 bit 'pixels' = 1228800 bytes (1.172 MB)

So roughly 430kB is used just to store blanking information.

For 1024 x 768 the data size is roughly increased by the ratio of the active dimensions

e.g. (1024 / 640) * 800 = 1280 approx pixels per line (768 / 480) * 525 = 840 approx lines per frame

Giving total memory as

1280 * 840 * 4 = 4300800 bytes (4.1MB)

So your data storage (and hence address counters) is getting large and probably starting to get unweildy for your 8051 with its 64kB memory map.

Simpler solution is PLD with pixel, line and address counter inside to deal with the timing and addressing memory. I would consider a device to take

8bit data and convert to 24 bit data (some lines may be fixed low or high) to pass to DACs and encoder chips.

At simplest level you could use 3:2:3 encoding for RGB in the 8 bit data. These bits become the MSb of each RGB with remaining bits of the 24bit data fixed at 0.

At the most complex you use a pallette of 256 colours and a wide LUT to convert at pixel clock rate into a 24bit value, which is what a lot of graphics and image processing systems have been doing for many years. Even this can be done in PLD/FPGA with 3 x 256 x 8bit tables if the PLD/FPGA has enough size.

But you will probably never need full 24bit unless you are displaying photo quality stills, as you will never have the processing power to run video through your 8051.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
              GNU H8 & mailing list info
             For those web sites you hate

It's indeed unfortunate that anal-retentive net nannies, like you, have such a problem with so-called trolls hiding behind google groups. That really wouldn't be a problem if pu__ies like you had a real life.