FPGA VGA Controller for 8-bit computer

[BrianHG]

Sorry to do this again nockieboy, but here is a FIFO update.  It is the same as the last, but now has full proper 'System Verilog' compliant lexicon.

When doing the next 2 geometry modules, we will switch over to the style in the attached 'FIFO_3word_0_latency.sv.txt'.
Changing the current geopetry_xy_plotter.sv is optional as it functions, however, there arent many changes to be done.

[nockieboy]

Please insert and test this final version 3.0 of my 'FIFO_3word_0_latency.sv'.  Let me know if it works.

It works. 

[nockieboy]

Sorry to do this again nockieboy, but here is a FIFO update.  It is the same as the last, but now has full proper 'System Verilog' compliant lexicon.

That one works as well.   

[nockieboy]

I'm having REAL trouble trying to get this triangle drawing function off the ground.

I have modified the drawFilledTriangle function in the attached Geo.bas file to include the setup and it should draw two lines simultaneously, even if one line isn't fully complete or goes on forever there should be TWO lines, but I'm getting nothing. Nowt. Zip. Nada. 

[BrianHG]

Code: [Select]

      Rem Reached the End
      If (x1 = x(1) And y1 = y(1) And x2 = x(2) And y2 = y(2)) Then
      is_done = TRUE
      Else
      is_done = FALSE
      End If
Hehehe, you are expecting both lines to end at the same time.  This will usually never happen at it's not what you are supposed to do.

Step #1 Loop line gen #1 once.

(Perform steps #2,3,4 only if Line #1 y begin and y end arent the same value.)
Step #2, setup your raster_Y for loop counter
Step #3, lets draw only the tallest line, line #1 until it reaches that raster_Y position, ie, loop line gen #1 until it's current Y position = raster_Y position.
Step #4, wait for keypress & next raster_Y position.

Step #5, do a normal finish of line gen #1.

Once this is done, test that no matter the angle of the line in your triangle_fill command, each time you press a key at the key-press, the drawn line on the screen advances vertically by 1 pixel.  This means if the line is at an odd angle from left to right, after each key press, the line should plot multiple pixels on the X axis, but only travel 1 pixel on the Y axis.

Once done, we will add a line gen #2.

[nockieboy]

Hehehe, you are expecting both lines to end at the same time.  This will usually never happen at it's not what you are supposed to do.

Well no, not really - I suspected the condition would never be true as the lines would most likely be different lengths, but what I did expect was to see parts of lines drawn or an infinite line (or two).  Instead, I'm getting nothing at all.  I've removed all references to line #2 in the loop now and I'm still getting nothing drawn.   I've tried with different combinations as I thought perhaps the first line should be tending towards x(2) y(2) instead, and using corresponding dx2, dy2, magic2 and errd2, but still nothing.

[BrianHG]

Where is your drawing.asm file?

[nockieboy]

Where is your drawing.asm file?

It's going to be something silly, isn't it? 

[BrianHG]

Here you go.  This is the beginning you should have come up with.

You will need to compile.

I did not do the triangle edges sorting as you last coded didn't do it right.  The if() weren't taken into proper account.

Next step.  Recreate the sort, though, in my provided drawing.asm, I already sorted the points.

Then, modify my code to draw to 1 vertical line at a time, for linegen 1 only.
Then do lines 1&2, swapping to 1&3 at the right time.
The fill in the raster void.

This is basic stuff since I setup the linegens for you to address each one.

[nockieboy]

I did not do the triangle edges sorting as you last coded didn't do it right.  The if() weren't taken into proper account.

Next step.  Recreate the sort, though, in my provided drawing.asm, I already sorted the points.

Okay, that's sorted.  I had made a syntax mistake in the IF conditionals - not being used to Free BASIC and all. 

Then, modify my code to draw to 1 vertical line at a time, for linegen 1 only.
Then do lines 1&2, swapping to 1&3 at the right time.

Right, I think I've got this far successfully.  Latest code attached.

The fill in the raster void.

This bit I'm having trouble with.  I can fill the first half of the triangle, but I'm getting errors.  As for the second half, well, no chance.  Everything I've tried just comes out completely wrong.

[BrianHG]

Arrrrrrrgggggg,  What did you do? ? ? ? ? ?
Nooooooooooooo.....
OMG...... ? run_duallinegen_num ?  Why?

I've erased what you did and provided the next step.  You need to fill in the rest...

[nockieboy]

Arrrrrrrgggggg,  What did you do? ? ? ? ? ?
Nooooooooooooo.....
OMG...... ? run_duallinegen_num ?  Why?

I've erased what you did and provided the next step.  You need to fill in the rest...

Didn't want to mess up the original function, so I created a new one then forgot to swap it for the old one when I posted the code. 

Okay, so I'm not sure about where/how I should be filling the triangle now.  It looks like I need to draw a horizontal line between line 0 and line 1 for every raster_Y_pos step, right?  I've been playing around with the code and have the first half filling, but can't seem to get the second half to fill without major errors in the fills.

[BrianHG]

Arrrrrggggg, I give up...
How many times will you be drawing that line every-time Bresenham algorithm is being called?
This is what you were supposed to place inbetween the 2 REM comments I inserted in the last geo.bas.
Here you go:

Now, see if you can work out why the blue triangle is messed up.  I don't think it's my code I just entered.

[nockieboy]

Now, see if you can work out why the blue triangle is messed up.  I don't think it's my code I just entered.

No, it was the point ordering.  I had a brain fart when I wrote it and messed up the first condition for y0 >= y1 >= y2.



Full Geo.bas attached.

[BrianHG]

Ok, test a few new triangles with different orders to points 1,2,3.

Maybe the same triangle, 1 after the other with the same points, but in a different order with a different color to make sure the new triangles perfectly overlap with one another in geo.bas.

The 1 thing I didn't do in the code was:

   For raster_Y_pos = ya(0) to yb(0)
.....
   Next raster_Y_pos

Should only be executed if the height of ya(0) to yb(0) was greater than 2.  And before the FOR loop, I should have begun the lines just as after the loop, I finished the lines.  The for loop should have also been written like this:
   For raster_Y_pos = ya(0)+1 to yb(0)-1

This way, when you have a triangle height > 2. you only raster fill the void inside, not the tip and bottom peaks which are already drawn by the LineGen itself.

It is your choice if you now want to approach the verilog and put in this triangle fill first, or, we will do the pixel writer and Z80 interface so you will see a picture when testing the triangle fill.


Now the way this geo.bas code is written should carry easy over to our existing System Verilog as it is nothing more than the old line generator with an array selection for 3 lines, each being run one at a time until the line is finished or reaches a defined raster Y coordinate.

[gcewing]

This way, when you have a triangle height > 2. you only raster fill the void inside, not the tip and bottom peaks which are already drawn by the LineGen itself.

I don't understand why this is an issue. For filling a triangle, line generators shouldn't be drawing *any* pixels themselves. They should only be figuring out where the raster lines to be filled start and end.

[nockieboy]

Ok, test a few new triangles with different orders to points 1,2,3.

Maybe the same triangle, 1 after the other with the same points, but in a different order with a different color to make sure the new triangles perfectly overlap with one another in geo.bas.

 

The 1 thing I didn't do in the code was:

   For raster_Y_pos = ya(0) to yb(0)
.....
   Next raster_Y_pos

Should only be executed if the height of ya(0) to yb(0) was greater than 2.

Okay, have added a check in before the for...next loop. 

And before the FOR loop, I should have begun the lines just as after the loop, I finished the lines.

Sorry, I don't follow.. 

It is your choice if you now want to approach the verilog and put in this triangle fill first, or, we will do the pixel writer and Z80 interface so you will see a picture when testing the triangle fill.

I'm all for seeing results, so shall we start on the pixel writer and interface?  I can then test the line function straight away, in theory.

Now the way this geo.bas code is written should carry easy over to our existing System Verilog as it is nothing more than the old line generator with an array selection for 3 lines, each being run one at a time until the line is finished or reaches a defined raster Y coordinate.

I'll take your word for that.  Updated Geo.bas attached.

[FenTiger]

Just a suggestion: test some pathological cases too, such as

• two, or all three, points being the same
• two, or all three, points sharing an X or Y coordinate
• all three points being perfectly co-linear

I wondered briefly about the case where one or more points is outside the visible screen, too, but I think you're best off just forbidding this and punting the responsibility for this case onto software.

[BrianHG]

The 1 thing I didn't do in the code was:

   For raster_Y_pos = ya(0) to yb(0)
.....
   Next raster_Y_pos

Should only be executed if the height of ya(0) to yb(0) was greater than 2.

Okay, have added a check in before the for...next loop. 

And before the FOR loop, I should have begun the lines just as after the loop, I finished the lines.

Sorry, I don't follow.. 

It is your choice if you now want to approach the verilog and put in this triangle fill first, or, we will do the pixel writer and Z80 interface so you will see a picture when testing the triangle fill.

I'm all for seeing results, so shall we start on the pixel writer and interface?  I can then test the line function straight away, in theory.

Now the way this geo.bas code is written should carry easy over to our existing System Verilog as it is nothing more than the old line generator with an array selection for 3 lines, each being run one at a time until the line is finished or reaches a defined raster Y coordinate.

I'll take your word for that.  Updated Geo.bas attached.

You got most of it right, just add these 2 lines before your if() like this:

Code: [Select]

   run_linegen_num ( 0, ya(0)+1, color_val ) : Rem finish the triangle's first line
   run_linegen_num ( 1, ya(0)+1, color_val ) : Rem finish the triangle's third line

If ( yb(0) - ya(0) > 2) Then

   For raster_Y_pos = ya(0)+1 to yb(0)-1

This begins the linegens #1&#2 on the first raster position and brings them up to the second, or, ends the lines..
And my mistake at the end:

Code: [Select]

   run_linegen_num ( 0, yb(0)+1, color_val ) : Rem finish the triangle's first line
   run_linegen_num ( 2, yb(0)+1, color_val ) : Rem finish the triangle's third line
-1 should always worke since Y position would never go there under normal circumstances.  But we will be supporting coordinates from -2048 to 2047, adding 1 to the Y end point ensures the line tries to finish drawing.

[BrianHG]

Just a suggestion: test some pathological cases too, such as

• two, or all three, points being the same
• two, or all three, points sharing an X or Y coordinate
• all three points being perfectly co-linear

I wondered briefly about the case where one or more points is outside the visible screen, too, but I think you're best off just forbidding this and punting the responsibility for this case onto software.

These tests are good for optimization where we stop the lineGens from pulling triple duty.  These checks will be added in Verilog.

The raster filler already doesn't execute if there are no free void pixels in-between the lines except occasionally on shear angles with triangle just above 3 lines tall.  A few pixel points at 1 face edge may be written twice.  For now, we are not touching this 1 optimization where we seek the smallest 2 coordinates inside a completed raster Y coordinate after the lingen has passed that Y raster position.

Off screen raster fills will be tested and skipped, but, the line gens will still operate to off screen coordinates so a triangle can be shifted/animated off the screen and still retain it's shape.

[BrianHG]

Ok, next onto 2 additions to the geometry_xy_plotter.sv.

1- Get the reset input working.  Reset to a bunch of defaults please.
2- Get the 'draw_busy' input working.

The 'draw_busy' should pause then entire 'geometry_xy_plotter.sv' unit whenever it's 'draw_cmd_tx' is high, except for reset condition.

Next, we will make a new simulation project called xy_plot_2_pixel_address.  This .sv module will accept the 36 bit 'draw_cmd' and 'draw_cmd_rdy'.  It will work out the memory write/read addresses from the x/y coordinates with base memory address, bytes per width of image, and bits per pixel settings.  It will send the memory address with which bits in that 16 bit word will be changed with read & write color to the next module.

Last module project.  This one pixel_2_ram, which takes the address from the previous module and reads/modifies appropriate bits/writes the 16 bit memory which will get sent to a new 'Data_mux_geo' (I'll prepare this one) which will have a third 16 bit read/write port.

[gcewing]

I have updated my Python code. It no longer uses inner loops to increment the x coordinates, although the setup now requires some integer divisions.

It also handles sides sloped in either direction, so it does not need any particular ordering of the x coordinates.

Code: [Select]

def fill_triangle(screen, x0, y0, x1, y1, x2):
    # Fills a flat-bottomed triangle with apex at (x0, y0) and
    # lower vertices at (x1, y1), (x2, y1). Assumes y0 < y1.
   
    xL = xR = x0
    y = y0
    dy = y1 - y0
    dxL, deL = divmod(x1 - x0, dy)
    dxR, deR = divmod(x2 - x0, dy)
    if dxL < 0:
        deL = -deL
    if dxR < 0:
        deR = -deR
    eL = eR = 0
    n = dy
    while n > 0:
        fill_raster_line(screen, xL, xR, y)
        xL += dxL
        eL += deL
        if eL > 0:
            if dxL < 0:
                xL -= 1
            else:
                xL += 1
            eL -= dy
        xR += dxR
        eR += deR
        if eR > 0:
            if dxR < 0:
                xR -= 1
            else:
                xR += 1
            eR -= dy
        y += 1
        n -= 1

def fill_raster_line(screen, x0, x1, y):
    x = x0
    n = x1 - x0 + 1
    while n > 0:
        draw_pixel(screen, x, y)
        x += 1
        n -= 1

def draw_pixel(screen, x, y):
    screen[y][x] = '*'

#----------------------- Testing -------------------------

def test(x0, y0, x1, y1, x2):
    screen = [[' '] * 79 for y in range(23)]
    fill_triangle(screen, x0, y0, x1, y1, x2)
    for row in screen:
        print(''.join(row))

test(50, 5, 10, 20, 60)
test(50, 5, 10, 20, 40)
test(30, 5, 40, 20, 60)


[nockieboy]

1- Get the reset input working.  Reset to a bunch of defaults please.

Here's what I've done:

Code: [Select]

always @(posedge clk or posedge reset) begin

    if (reset) begin    // reset to defaults
       
        // reset coordinate registers
        for ( integer i = 0; i < 4; i++ ) begin
            x[i]  <= { 12'b0 };
            y[i]  <= { 12'b0 };
        end
        max_x     <= 12'b0;
        max_y     <= 12'b0;

        // reset draw command registers
        draw_cmd_func        <= 4'b0;
        draw_cmd_data_color  <= 8'b0;
        draw_cmd_data_word_Y <= 12'b0;
        draw_cmd_data_word_X <= 12'b0;
        draw_cmd_tx          <= 1'b0;

        // reset geometry sequencer controls
        geo_shape     <= 4'b0;
        geo_fill      <= 1'b0;
        geo_mask      <= 1'b0;
        geo_paste     <= 1'b0;
        geo_run       <= 1'b0;
        geo_color     <= 8'b0;
       
        // reset geometry counters
        geo_x         <= 12'b0;
        geo_y         <= 12'b0;
        geo_xdir      <= 12'b0;
        geo_ydir      <= 12'b0;
        geo_sub_func1 <= 4'b0;
        geo_sub_func2 <= 4'b0;
        dx            <= 12'b0;
        dy            <= 12'b0;
        errd          <= 12'b0;

    end else begin

         if (cmd_ready && ~geo_run ) begin...
Hopefully that's all okay?

[nockieboy]

2- Get the 'draw_busy' input working.

The 'draw_busy' should pause then entire 'geometry_xy_plotter.sv' unit whenever it's 'draw_cmd_tx' is high, except for reset condition.

Done.  I've just changed this line to include a !draw_busy check:

if ( cmd_ready && ~geo_run && !draw_busy ) begin

... and this one...

end else if ( geo_run && !draw_busy ) begin

Here's a simulation:

[BrianHG]

Looks Ok, code update pls.