[comp.graphics] Request: Video output circuit design help needed

robbin@resrch.MoliEnergy.BC.CA (Robbin W. Johnson) (01/14/89)

I am looking for information and/or help on how to design a video
display driver.  I have a 1 bit deep display memory and I want to end-up
with a circuit that will shift this out to a monitor.  The design will
generate the pixel stream and the horizontal and vertical sync pulses
along with any signal level shifting necessary (I believe this to be all
I will need, please correct me if I am wrong.)

What I would like to end up with is something closely resembling the
original Blit, but I doubt that Messrs. Pike or Locanthi would be able
to (or even want to) send me some of their hardware design secrets :-)

[I am doing this mostly as an exercise to see if I still have it in me
to design and build such a beast and because I find the Blit to be a
rather fascinating concept.  Please no "just use a 6845" or "why not a
7220?" replies.  I have looked at these and other, newer chips and they
do not interest me.]

The design will be implemented using PALs, shift registers and binary
counters.  I already have a design for the RAM dual-port circuit.  What
I need is help designing everything that deals with the raster image
after the CPU has put it into memory.  I am hoping to end up with a
display on the order of 1024 X 768.

In addition I need to find out a few facts about monitors.  Is a 60 Hz.
display capable of displaying more lines if you run it at only 30 Hz.?
Can you up the pixel clock and feed more pixels per scan line?  Does all
this require surgery on the display's sweep circuitry or is there such a
thing as a magic, self compensating circuit?  It seems to me that a
25Mhz display is capable of displaying more that 720 X 3XX(?) pixels,
especially if you go from 60 (or 50) to 30 Hz refresh.  I suppose that
there are limits based upon the phosphor's particle size and/or the
electron beam size.

I guess what I really need is a "Video Designer's Cookbook."  Anyone
know of such an animal?

Any and all help would be greatly appreciated.

Robbin W. Johnson
-- 
Robbin Johnson					...!ubc-cs!van-bc!resrch!robbin
robbin@MoliEnergy.BC.CA				...!uunet!/

tomg@hpcvlx.HP.COM (Thomas J. Gilg) (01/17/89)

RJ> I am looking for information and/or help on how to design a video
RJ> display driver.  I have a 1 bit deep display memory and I want to end-up
RJ> with a circuit that will shift this out to a monitor.  The design will
RJ> generate the pixel stream and the horizontal and vertical sync pulses
RJ> along with any signal level shifting necessary (I believe this to be all
RJ> I will need, please correct me if I am wrong.)

RJ> ...........................  Please no "just use a 6845" or "why not a
RJ> 7220?" replies.  I have looked at these and other, newer chips and they
RJ> do not interest me.]

You are going to have a challange here.  Usually, a controller chip 
provides atleast two sets of controls:

    1. Video Sync Lines
    2. Shift register downloading and timing

There are a large number of timing parameters that someone must generate.
Read on.

RJ> The design will be implemented using PALs, shift registers and binary
RJ> counters.  I already have a design for the RAM dual-port circuit.  What
RJ> I need is help designing everything that deals with the raster image
RJ> after the CPU has put it into memory.  I am hoping to end up with a
RJ> display on the order of 1024 X 768.

I would suggest going with atleast 16-bit wide downloads to the shift
registers if your going 1024x768 or above.  That way, your access rate
to memory will be 1/16 the pixel rate.

RJ> In addition I need to find out a few facts about monitors.  Is a 60 Hz.
RJ> display capable of displaying more lines if you run it at only 30 Hz.?

I think that once a monitor is set at 30 Hz or 60 Hz, your stuck.
What can be changed is the way you feed the monitor.   You can opt
to feed it ONE image every frame, or two interlaced images every
two frames. 

RJ> Can you up the pixel clock and feed more pixels per scan line?  Does all
RJ> this require surgery on the display's sweep circuitry or is there such a
RJ> thing as a magic, self compensating circuit? 

If you have a fancy controller, I don't see why not, but the pain may not
be worth it.  What you do while the scan line is ACTIVE is up to you
( i.e., feed it all the pixels you want ( see beam size comment ) ).  The
critical thing is that you observe the fact that the scan line will only
be active for a certain fixed amount of time, and that you have certain
sync parameters to consider.  I don't know hpow multi-sync monitors
play here ??  Any multi-sync experts ??

RJ> It seems to me that a
RJ> 25Mhz display is capable of displaying more that 720 X 3XX(?) pixels,
RJ> especially if you go from 60 (or 50) to 30 Hz refresh.  I suppose that
RJ> there are limits based upon the phosphor's particle size and/or the
RJ> electron beam size.

Here are some specs for a 1280x1024 monitor I know of.  Remember, someone
must keep track of all these milli-seconds ( i.e., your pixel stream
IS NOT a continuous flow of un-interrupted bits ),

  Timing ( kinda rounded off in some cases - roughly RS-343A specs ):

  Horiz. sweep freq:  63.3  Khz     Vert. Frame Rate:     60.0   Hz ( non-int)
         period:      15.8  us            active period:  16.17  ms
         front porch:   .41 us            blanking:         .505 ms
         sync width:   1.7  us            period          16.7   ms
         back porch:   1.85 us            front porch     47.4   us
         active scan: 18.8  us            sync width:     47.4   us
         blanking:     4.5  us            back porch:    410.5   us

Usually, the whole timing mess grinds down to finding your base clock
rate so that all the above timing figures work out as integer multiples
of it ( e.g., vert. front porch is equal to 3 scan lines ).  Then whatever
resolution works out is what you get.  Usually, I find that you get some
specs such as above, work forward to find the resulting resolution, gripe
that its too weird ( 1258 X 1013 ), work backwards and change some of your
initial parameters, making sure to stay within the specs, etc.....

Good luck !!

   Thomas Gilg
tomg%hp-pcd@hplabs