CBFalconer wrote: ....
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.
.....
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.
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.
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.
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.
