Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
11/06/08 21:57
Read: times


 
Msg Score: +1
 +1 Good Answer/Helpful
#159857 - Back to basics
Responding to: ???'s previous message
IF it wants pixel-by-pixel data, along with Hsync and Vsync, then it's just like a CRT. They make triple RAMDAC's just for this purpose. You have to program the RAMDAC to interpret the input data into a value to be projected on the R, G, and B pins, and, of course, the sync. Some RAMDAC's, though none of those that I've used, provide internal timing logic to produce the sync pulses, or, perhaps, it's more easily understood as being a set of timing logic with the triple RAMDAC built in.

The basic principle is to design a single synchronized timeline which you time with whatever logic you have to produce the pixels and the sync pulses in the correct sequence and at a rate that meets the spec's for the display. It's quite a large circuit, but not difficult to understand. The scheme that you describe, i.e. "no onboard RAM and requires vertical and horizontal synch pulses, a "dotclock" and 6 bit wide RGB data for each of the three colors very fast (6Mhz or so)" is quite reminiscent of an early VGA, though those operated at a considerably higher pixel rate.

You have a frame time, which is the time during which you're required to complete the entire sequence. You have a vertical blanking interval, though it may be quite short, even nonexistent, since LCD's don't need retrace time. You have a horizontal blanking interval, though that, too may be very short or absent. What remains is the active display time, all of which must be properly positioned with respect to those annoying sync pulses. Normally, the sync pulses happen at a time when the display is not active, i.e. "blanked." That may not be the case with your display. I suspect, however, that it was intended to be driven in place of a CRT, so I'd recommend you look at the types of circuits commonly used to drive RGB CRT's, such as the early, simple VGA's.

The RAMDAC has three memory arrays in it, each of which is driven by the data, probably 8-bits, and each of which has to be programmed to produce a 6-bit, in your case, but also in the early VGA's, value corresponding to the 8-bit value sent to it from the refresh memory, which is cycled synchronously with the sync timing and driven by the pixel clock. The result is that, while you produce 18-bit color, you only have 256 choices of color for each pixel, since that's the width, typically of the refresh memory.

The timing logic that produces the sync pulses also produces the addresses to the refresh memory, on a pixel-by-pixel basis, and appropriately skewed with respect to the required pixel arrival time, so things can propagate through the refresh RAM, character-generator ROM or RAMDAC, to the display. Early VGA's used a character generator as well as a refresh memory for text applications, dividing the pixel clock by the pixel-per-character rate in order to develop the characters in their display. You'll probably want to do that as well, unless you intend to draw each character in software.

It's worth noting that those early VGA's to which I keep referring were formatted 640x480 in full graphics mode. You might find it quite informative to have a look at whatever data you can find on the www with regard to them and their design and application.

If you can't buy a suitable LSI, e.g. MC6845 with which to do this "thing," then perhaps programmable logic offers a solution for you. If you don't need the full 6 bits of color resolution per channel, perhaps the programmable logic will enable you to form a DAC using an R-2R ladder. It was done that way on the earlier EGA's. Quite a number of programmable logic demo boards have such DAC's on board, so it shouldn't be hard to figure out how they did it. You can buy commercial R-2R ladders in single resistor arrays, so keeping them relatively noise-free will be easier than with discretes.

A mid-sized CPLD, e.g. XC2C256, or a small FPGA, e.g. XC3S150 or thereabouts should be quite suitable, and you can build in your own MCU, in the form of a PicoBlaze, or two, or three, to do the "heavy lifting" i.e. data transport.

If you do a bit of research, you can probably find a suitable way to accomplish what you want without too much pain. I doubt you'll be "off and running" with the somewhat feeble explanation I've offered here.

Good Luck!

RE


List of 12 messages in thread
TopicAuthorDate
How do you drive a RGB color LCD display?            01/01/70 00:00      
   Look for processors or display controllers            01/01/70 00:00      
   Search?            01/01/70 00:00      
   Epson            01/01/70 00:00      
   Thanks            01/01/70 00:00      
   Back to basics            01/01/70 00:00      
      Richard, you flooded Bert's connection...            01/01/70 00:00      
         It's not as easy as one might think            01/01/70 00:00      
            ready-made device            01/01/70 00:00      
            buy an evaluation board            01/01/70 00:00      
               a quick peek into the code library            01/01/70 00:00      
                  That's what I would recommend            01/01/70 00:00      

Back to Subject List