What is what I think I need to do:

Horizontal counter counts from 0-799 before resetting. Once it reaches its terminal count of 799 it will assert the count enable of my vertical counter which will move from 0-1 thus moving me to the next row below. I have 4 comparators setup that look at where my counters are: hSync will be high from 0-655 and 751-799 while vSync will be high from 0-488 and 491-524. Now I have 4 comparators that also look at my counters and will be hi only during my active region (this is what I will use to actually paint my screen) and hSync for this will be from 0-639 and vSync for this will be from 0-479.

Now if my understanding is correct I can look at each pixel like a coordinate system so if I wanted to paint pixel[103,402] (where pixel[x,y] and x is my horizontal and y is my vertical) with say black I would use the comparators to check if its in that region and if so send the proper signals to my RGB pins to display black or whatever color I choose.

Maybe I am making this overly complicated?

 

That's not how it's done.

How would you paint "HELLO WORLD!" on the screen?

 

have the pixel pattern displaying "HELLO WORLD!" in one color of pixels while the rest of the pixels are colored something different. It seems that there is something fundamental that I am missing here and I am not able to find any sort of non-ambiguous answers as to how I go about doing this.

 

With your scheme you would need a quadrillion amount of comparators to display anything.

 

Then it appears that I am hopelessly lost thus giving up for this evening.

 

Yes. You really need to rethink your scheme.

 

You have a color "depth" of 3 bits per pixel (R,G,B on or off).

Have you thought about a frame buffer? e.g. storing the bits to be displayed in memory, which your counter then continually spits out. The memory can then be modified by some other process. Using this method, your routine doesn't need to be re-written if you decide not to have a border, for example.

 

have the pixel pattern displaying "HELLO WORLD!" in one color of pixels while the rest of the pixels are colored something different. It seems that there is something fundamental that I am missing here and I am not able to find any sort of non-ambiguous answers as to how I go about doing this.

But where does this pixel pattern come from?

The usual method, for a graphics display, is to have a region of memory that is used to hold the pixel data. This region is generally known as a "frame buffer". For your approach, namely with three 1-bit values for each color, you can use three frame buffers, one for each color. The old TI-Pro computer worked this way and referred to each buffer as a "graphics plane".

Some other part of the system writes the data to the frame buffers. The display driver merely reads what is there.

 

What is what I think I need to do:

....

Now if my understanding is correct I can look at each pixel like a coordinate system so if I wanted to paint pixel[103,402] (where pixel[x,y] and x is my horizontal and y is my vertical) with say black I would use the comparators to check if its in that region and if so send the proper signals to my RGB pins to display black or whatever color I choose.

Maybe I am making this overly complicated?

Yes you are. Forget about the comparators. What you need is to just pait the image you want to display as a bit map in memory, and then shift out each triplit of bits for each pixel you are scanning. For example, if you only want a dot in the middle of the screen, then you would set the memory at (MAX_HORZ/2), (MAX_VERT/2) to the color you want, ie (RGB= 1,0,0) and all other memory triplits to (0,0,0). Then as you begin a scan, grap each bit from you bitmap memory and shift it out to the RGB output, one triplit for each pixel you scan.

I use the term 'triplit' to describe the 3 bits that make up each pixel, as I don't know the correct term.

 

I was successful in implementing my methodology of using comparators to paint specific pixels different colors on the screen. Turns out I had a few wires crossed that was causing my output to be skewed.

Here is what I have done.

Two 16-bit counters that are continually counting. First counter is for hSync that will count until it reaches 799 - upon reaching that value it asserts the reset switch as well as asserting the CE on my secondary counter which counts all the way to 524 and will then reset. I have sets of comparators that will look at my counters and will tell both hSync and vSync when to be on or off depending on what the value is in the counters. I have also done this for my active region. I am looking at my screen as an x and y coordinate system:

active region is high while: 0 < x < 639 AND 0 < y < 479.

I ANDed this together with my hSync and vSync signals and am sending the signals to my rgbColor decoder and I am able to successfully paint the screen.

Now the next part of my assignment is to make blocks fall at random intervals. I am planning on using a LFSR to come up with random values, but the problem at the moment is when to send the signals to tell the blocks to fall.

 

You keep changing the goal!

We can't give you good advice or critique your approach if we have no idea where you are headed! It is beginning to sound like you are being asked to design a logic circuit that is very, very specific and constrained in what it can do. That's fine and that may obviate the need or even desirability of taking a general approach. But if that's the case, we need to know what the goal at the end of the rainbow is otherwise there is no way we can tell if the next step that you haven't told us about is going to be completely incompatible with something that has already been done up to this point.

 

I was successful in implementing my methodology of using comparators to paint specific pixels different colors on the screen. Turns out I had a few wires crossed that was causing my output to be skewed.

Here is what I have done.

Two 16-bit counters that are continually counting. First counter is for hSync that will count until it reaches 799 - upon reaching that value it asserts the reset switch as well as asserting the CE on my secondary counter which counts all the way to 524 and will then reset. I have sets of comparators that will look at my counters and will tell both hSync and vSync when to be on or off depending on what the value is in the counters. I have also done this for my active region. I am looking at my screen as an x and y coordinate system:

active region is high while: 0 < x < 639 AND 0 < y < 479.

I ANDed this together with my hSync and vSync signals and am sending the signals to my rgbColor decoder and I am able to successfully paint the screen.

Now the next part of my assignment is to make blocks fall at random intervals. I am planning on using a LFSR to come up with random values, but the problem at the moment is when to send the signals to tell the blocks to fall.

I understand what you've done. Other than using a bitmap memory, I don't have a good suggestion. If you only need to display a limited number of blocks, then you can define the x and y coordinates of the blocks and use a comparator to find the pixels to displa the blocks. You can order the blocks so they can be shifted and compared each time you find a match, and just shift the blocks to your comparator till they are all displayed.

Years ago, I worked on a text display that worked somewhat like this. Each letter to be displayed was converted to it's pix-map and loaded into a comparator and shifted after each compare. Something like that, it's been 25 years ago

 

I was successful in implementing my methodology of using comparators to paint specific pixels different colors on the screen. Turns out I had a few wires crossed that was causing my output to be skewed.

Here is what I have done.

Two 16-bit counters that are continually counting. First counter is for hSync that will count until it reaches 799 - upon reaching that value it asserts the reset switch as well as asserting the CE on my secondary counter which counts all the way to 524 and will then reset. I have sets of comparators that will look at my counters and will tell both hSync and vSync when to be on or off depending on what the value is in the counters. I have also done this for my active region. I am looking at my screen as an x and y coordinate system:

active region is high while: 0 < x < 639 AND 0 < y < 479.

I ANDed this together with my hSync and vSync signals and am sending the signals to my rgbColor decoder and I am able to successfully paint the screen.

Now the next part of my assignment is to make blocks fall at random intervals. I am planning on using a LFSR to come up with random values, but the problem at the moment is when to send the signals to tell the blocks to fall.

Can you post an image of your current schematic to perform this action?

You should have a way to clock the colors out from a linear block of memory. That way, the random blocks can be written to memory in a parallel process to the screen being drawn. Attempting to do both at the same time with the same logic can cause "tearing" or display jitter do to very small timing changes.

If you set up your clock for pixel rate, Hsync, and Vsync rate, then adding the link to pull the pixel color area from memory should be a simple change of the source of pixel data.

Your method may work, but what happens when the next assignment is to draw a Mandelbrot set on the display? Without a framebuffer, you'd need a calculation unit for each cell built into the display hardware, and you would run out of Logic rather quickly.

Another downfall of your current method is upgrading to 4 bits of color per pixel requires a top-down re-design.

 

Can you post an image of your current schematic to perform this action?

You should have a way to clock the colors out from a linear block of memory. That way, the random blocks can be written to memory in a parallel process to the screen being drawn. Attempting to do both at the same time with the same logic can cause "tearing" or display jitter do to very small timing changes.

If you set up your clock for pixel rate, Hsync, and Vsync rate, then adding the link to pull the pixel color area from memory should be a simple change of the source of pixel data.

Your method may work, but what happens when the next assignment is to draw a Mandelbrot set on the display? Without a framebuffer, you'd need a calculation unit for each cell built into the display hardware, and you would run out of Logic rather quickly.

Another downfall of your current method is upgrading to 4 bits of color per pixel requires a top-down re-design.

I will post the schematic (well what I have working so far) of my vga controller and the inside look of one of my symbols.

Here is my schematic with my other symbols. As you can tell by the names they are pretty straight forward: hSyncCounter contains a 16-bit counter that has an AND gate that will assert a signal when it hits 799 to reset the counter.

This is one of my comparators that I use to check and see where the counter is. While these arguments are satisfied H(15:0) < 16'h0280 and V(15:0) < 16'h01E0 (H(15:0) is the count coming from the horizontal counter and V(15:0) is the count coming from the vertical counter) it will send a high signal that the count is in the "active region".

It's it actually all fairly straight forward.


And a response to WBahn that was only but a small portion of my assignment. Instead of making a new topic I continued to post in the thread - thought it would be better to do that rather than spam the forums.

 

Do you see a way you could use clk*Hsync to "count" through a separate memory bitmap of colors for the pixel out? Think just blue/black for now.

Then decide what needs to be changed to read 3 bits for each color from memory for the outputs (active region AND memaddr for color).

Once that is done, any future changes, such as a triple border, drawing text, etc. can be done by modifying the memory the output reads for outputting the pixels.