«

Hi,

I was wondering if anyone has any experience programming a VGA controller using the DE1 or DE2 board to draw lines or shapes. This is a project that my professor proposed and I was wondering how hard this actually is.

Thanks

On 01/09/2013 05:39 AM, wrote:
> Hi,
>
> I was wondering if anyone has any experience programming a VGA controller using the DE1 or DE2 board to draw lines or shapes. This is a project that my professor proposed and I was wondering how hard this actually is.
>
> Thanks
>
Your board documentation will probably give you some hints on how to get
started. Essentially, you have to generate 5 signals hsync, vsync an RGB
signals.

For the basic 640 x 480 mode you may be ok with a 25 MHz clock. An
horizontal counter counting 0 to 799 and a vertical counter counting 0
to 525 give the basic coordinates.

You output hsync when hcounter is between 0 an 95, and output vsync when
vcounter is between 0 and 1. You provide your information on the R, G
and B lines when the horizontal counter is between 96+16 and 96+16+640
and the vertical counter between 2+10 and 2+10+480. Have a look at basic
timing diagrams available on the web.

Pere

Thanks for the reply Pere. One more question: Is there be a difference between a VGA controller and a VGA controller with hardware acceleration? If there is what is the difference?

On 01/11/2013 05:56 AM, KAY wrote:
> Thanks for the reply Pere. One more question: Is there be a difference between a VGA controller and a VGA controller with hardware acceleration? If there is what is the difference?
>

There may be some semantics issues here, but let's say there is a huge
difference. A VGA controller simply maps bits (pixels) stored in some
kind of memory onto the 5 signals of the VGA interface. Hardware
acceleration means computing those bits (pixels) efficiently from a set
of primitives (lines, polygons...).

Pere

o pere o wrote:
> On 01/09/2013 05:39 AM, wrote:
>> Hi,
>>
>> I was wondering if anyone has any experience programming a VGA
>> controller using the DE1 or DE2 board to draw lines or shapes. This is
>> a project that my professor proposed and I was wondering how hard this
>> actually is.
>>
>> Thanks
>>
> Your board documentation will probably give you some hints on how to get
> started. Essentially, you have to generate 5 signals hsync, vsync an RGB
> signals.
>
> For the basic 640 x 480 mode you may be ok with a 25 MHz clock. An
> horizontal counter counting 0 to 799 and a vertical counter counting 0
> to 525 give the basic coordinates.
>
> You output hsync when hcounter is between 0 an 95, and output vsync when
> vcounter is between 0 and 1. You provide your information on the R, G
> and B lines when the horizontal counter is between 96+16 and 96+16+640
> and the vertical counter between 2+10 and 2+10+480. Have a look at basic
> timing diagrams available on the web.
>
> Pere

Pere has talked about generating the video scan, but usually a harder
issue is managing a frame buffer. For simple line drawing it is also
possible to work without a frame buffer by using logic to determine
whether a given pixel falls on a line. Very early video games like
Pong had no frame buffer. For general drawing, however the frame
buffer actually makes life easier as it allows unlimited numbers of
drawing objects.

Video display requires reading the frame buffer in advance of the
output raster, incorporating a FIFO to avoid requiring the external
RAM buffer to be read synchronously to the frame.

Typically the frame buffer is structured as having a separate read/write
port for "processor" or "graphics enginge" access for drawing. Strictly
speaking a graphics engine does not need to read the frame buffer for
creating new objects, but most graphics engines incorporate the ability
to copy regions of the screen to another area (Google for "bitblt").

All in all the difficulty of this project probably hinges on the ease
of use of any available external memory controller.

-- Gabor

On Friday, 11 January 2013 07:27:42 UTC-8, GaborSzakacs wrote:
> o pere o wrote:
>
>
> >> Hi,
>
> >>
>
> >> I was wondering if anyone has any experience programming a VGA
>
> >> controller using the DE1 or DE2 board to draw lines or shapes. This is
>
> >> a project that my professor proposed and I was wondering how hard this
>
> >> actually is.
>
> >>
>
> >> Thanks
>
> >>
>
> > Your board documentation will probably give you some hints on how to get
>
> > started. Essentially, you have to generate 5 signals hsync, vsync an RGB
>
> > signals.
>
> >
>
> > For the basic 640 x 480 mode you may be ok with a 25 MHz clock. An
>
> > horizontal counter counting 0 to 799 and a vertical counter counting 0
>
> > to 525 give the basic coordinates.
>
> >
>
> > You output hsync when hcounter is between 0 an 95, and output vsync when
>
> > vcounter is between 0 and 1. You provide your information on the R, G
>
> > and B lines when the horizontal counter is between 96+16 and 96+16+640
>
> > and the vertical counter between 2+10 and 2+10+480. Have a look at basic
>
> > timing diagrams available on the web.
>
> >
>
> > Pere
>
>
>
> Pere has talked about generating the video scan, but usually a harder
>
> issue is managing a frame buffer. For simple line drawing it is also
>
> possible to work without a frame buffer by using logic to determine
>
> whether a given pixel falls on a line. Very early video games like
>
> Pong had no frame buffer. For general drawing, however the frame
>
> buffer actually makes life easier as it allows unlimited numbers of
>
> drawing objects.
>
>
>
> Video display requires reading the frame buffer in advance of the
>
> output raster, incorporating a FIFO to avoid requiring the external
>
> RAM buffer to be read synchronously to the frame.
>
>
>
> Typically the frame buffer is structured as having a separate read/write
>
> port for "processor" or "graphics enginge" access for drawing. Strictly
>
> speaking a graphics engine does not need to read the frame buffer for
>
> creating new objects, but most graphics engines incorporate the ability
>
> to copy regions of the screen to another area (Google for "bitblt").
>
>
>
> All in all the difficulty of this project probably hinges on the ease
>
> of use of any available external memory controller.
>
>
>
> -- Gabor

Thanks Gabor and Pere for your inputs! I think I have a better idea of the work necessary for the line drawing project.

How does this sound?
-using the 514K SRAM for the frame buffer.
-having a graphics controller(with Direct memory access) that will take a start and end pixel location, and a command from the CPU> With a write command say '01' this will store the data into memory

Right now, to my understanding without this "graphics controller" the CPU would be writing directly to the memory(which is rather slow) and by implementing this graphics controller the speed of the process will be increased significantly.

Does this make sense?

Thanks in advance.

In comp.lang.vhdl,
KAY <> wrote:
>
> Thanks Gabor and Pere for your inputs! I think I have a better idea of
> the work necessary for the line drawing project.
>
> How does this sound?
> -using the 514K SRAM for the frame buffer.
> -having a graphics controller(with Direct memory access) that will take
> a start and end pixel location, and a command from the CPU> With a
> write command say '01' this will store the data into memory
>
> Right now, to my understanding without this "graphics controller" the
> CPU would be writing directly to the memory(which is rather slow) and
> by implementing this graphics controller the speed of the process will
> be increased significantly.
>
> Does this make sense?

Yes, a line drawing primitive is a good start. For inspiration, you
could read some datasheets and user manuals for old graphics
controllers like the HD63484 and AM95C60. Maybe you can have a look
at newer controllers, but I suspect they are far too complex and
documentation may not be fully available.



--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

All theoretical chemistry is really physics; and all theoretical chemists
know it.
-- Richard P. Feynman