FPGA VGA Controller for 8-bit computer

[BrianHG]

Your 2 pictures, are they a comparison between the old geometry unit's line gen and the new one, correct?
Ok, it looks like either what you said is true or just the pixel_write command may not be going high.
Though, the line being generated is still being fully generated, just not all the dots plotted on the screen.

Also:

Code: [Select]

last_run <= run ;

    if ( !draw_busy ) begin // draw_busy must be LOW or the line generator won't run

        if ( !run && ( latch_aX != aX || latch_aY != aY || latch_bX != bX || latch_bY != bY ) ) begin

Should be:

Code: [Select]

    if ( !draw_busy ) begin // draw_busy must be LOW or the line generator won't run

last_run <= run ;

        if ( !run && ( latch_aX != aX || latch_aY != aY || latch_bX != bX || latch_bY != bY ) ) begin

When the 'draw_busy' is high, everything must stop.
If fact, to be safe, I would also change line 205 in the geometry unit from:

Code: [Select]

    end else begin

to:

Code: [Select]

    end else if (!draw_busy) begin

Then down at line 430 change:

Code: [Select]

    end // reset
to:

Code: [Select]

    end else draw_cmd_tx <= 1'b0;  // !draw_busy

All the other '!draw_busy's inside the bulk should no longer be needed.
I will need to wait a few hours before I could investigate with a proper simulation.

[nockieboy]

Your 2 pictures, are they a comparison between the old geometry unit's line gen and the new one, correct?

Yes indeed.

Ok, it looks like either what you said is true or just the pixel_write command may not be going high.
Though, the line being generated is still being fully generated, just not all the dots plotted on the screen.

...

All the other '!draw_busy's inside the bulk should no longer be needed.
I will need to wait a few hours before I could investigate with a proper simulation.

Thanks.  I've made the changes you suggested and tried again, but have exactly the same output.   

[BrianHG]

Oh yes, something has gone completely haywire.
Take a look at this simulation with the integrated pixelwriter module.
Old geo xy plotter:

New geo xy_plotter:


As you can see, in the second sim, all the pixels are still being generated, but, pixels are being driven right through even though pixel_writer has told the geometry unit it was busy, so, STOP!

I've also attached all the needed sim files.
Geo_Writer = original linegen.
Geo_Writer_v2 = new linegen.
(Inside here, 'geo3.vwf' has the reference good simulation, 'geo3_v2.vwf' is the code you are working & simulating with)
pixel_writer = The 2 Geo_Writers require this to simulate.

All 3 projects are in the 1 attached Geo_Writer_V2.zip file.

I can only debug the code in a few hours from now, though, you can now see whats happening and take a crack at it yourself.

[BrianHG]

  You have edited and changed an older version of geometry_xy_plotter.sv when you added the new linegen into it... 

Take a look at line 74 in the 'geometry_xy_plotter.sv' on your new linegen and take a look a line 74 in the last working version of the project.

This includes the address_generator...

Ok, I fixed and updated everything.
ALSO, take a close look at all the changes I've done to your Y-stop-ing function.  It latched things at start it shouldn't have and also would never recover from a stop if I left things the way they were.

Remember, you are taking new sources from this .zip
geometry_xy_plotter.sv
line_generator.sv
pixel_address_generator.sv
and
line_generator.sv

[BrianHG]

Now, how did I debug that one.

Flipping between the 2 simulations in quartus with the View & Zoom aligned, I saw this:

Zoom on old image was set to 340ns to 590ns.
Zoom on new image was set to 350ns to 600ns.

This was done sine the new code takes 1 additional clock before it starts drawing, so that 10ns offset aligns the output...



The green faded background was the good functioning algorithm.  The red arrow points to the draw_busy where the old code halted the output 'draw_cmd_rdy' immediately while the new code kept it high for 1 clock.

So, I knew that 'draw_cmd_rdy' should be searched for in both code revisions and that since in the working code it had an immediate effect, it also probably was something in a line of combinational code.

[BrianHG]

Place dates & revision numbers with a bug patch list at the top of each of your verilog cores...

[nockieboy]

You have edited and changed an older version of geometry_xy_plotter.sv when you added the new linegen into it... 

Take a look at line 74 in the 'geometry_xy_plotter.sv' on your new linegen and take a look a line 74 in the last working version of the project.

This includes the address_generator...

Ok, I fixed and updated everything.
ALSO, take a close look at all the changes I've done to your Y-stop-ing function.  It latched things at start it shouldn't have and also would never recover from a stop if I left things the way they were.

Remember, you are taking new sources from this .zip
geometry_xy_plotter.sv
line_generator.sv
pixel_address_generator.sv
and
line_generator.sv

Uhh... darnit.    This is what happens when I have three different versions of the same file in the main project and different test projects. 

Right, so I missed the '!draw_busy` in the combinational logic (the wire assignment) in the geo_xy_plotter module on line 74.  I've been going round in circles trying to find the new code you're talking about, though... or even the fixed code... looks like the zip file has the last working code and my faulty code, rather than the fixed code?

[BrianHG]

The '_patched.zip' version has all the fixes.

[nockieboy]

The '_patched.zip' version has all the fixes.

   It's been a long week.. 



Works now. Will do some more testing tomorrow with more lines, but it's not likely to do anything different as all dx/dy directions are catered for in that square already.  Also, yes, schoolboy error with the ypos latching... 

[BrianHG]

You need to proceed and simulate in these steps to make you life possible:

First, worry about getting a single line generator working and simulating in place of the original one.  DONE!

Next worry about getting the linegen to recognize that the beginning and ending coordinates are on the same point bypassing everything else and just drawing the dot. Simulate and test this one.

Then worry about controlling the linegens to step/advance a Y coordinate at a time with pre-sorted coordinates coming from the Z80. Next task...

Then worry about wiring 3 of them together and controlling them with pre-sorted coordinates from the Z80.

Then worry about enabling the fill.

Then worry about sorting the coordinates to the 3 triangles in the geometry unit.

Then worry about making the linegens process all other shapes except ellipses.

[nockieboy]

Is this output good for a single pixel?

[BrianHG]

Do something like 5 of them to test.
Just add a few write pixel commands with a different color each, all adjacent.

When testing on the Z80, just place 2-4 dots on the screen in different places by different colors.

Then go onto the next stage.
The controlled Y position rasterizer.

[nockieboy]

The individual pixels are drawing fine. 

Now for the next step.  This has me thinking as it's not as straightforward as inserting the line_generator module was.

I have two inputs to the line_generator:

• ena_stop_y, and
• stop_ypos

Setting ena_stop_y HIGH tells the line_generator to stop on the specified Y-coordinate (set by stop_ypos as a 12-bit value).  Now, the FreeBasic version loops through every Y value from top to bottom, so that a raster fill line can be drawn between the two new points.  I'm wondering - wouldn't it be beneficial to be able to tell the line_generator to just stop on every new Y-value when it increments to it, instead of (or as well as being able to) stop at a specified Y-coordinate?

[BrianHG]

The individual pixels are drawing fine. 

Now for the next step.  This has me thinking as it's not as straightforward as inserting the line_generator module was.

I have two inputs to the line_generator:

• ena_stop_y, and
• stop_ypos

Setting ena_stop_y HIGH tells the line_generator to stop on the specified Y-coordinate (set by stop_ypos as a 12-bit value).  Now, the FreeBasic version loops through every Y value from top to bottom, so that a raster fill line can be drawn between the two new points.  I'm wondering - wouldn't it be beneficial to be able to tell the line_generator to just stop on every new Y-value when it increments to it, instead of (or as well as being able to) stop at a specified Y-coordinate?

What happens when the shorter face of the triangle ends and the new line begins there.
I guess it's your choice.
It sounds like it may be easier.
Ok, let's give it a try.

New rule on the Y stop input, whenever it's HIGH, on any Y increment, the line drawing engine will stop and wait for the Y_stop to go low.  The output Y_stopped will be high during this time.

Let's see what happens.


Also, for your multiplot of single pixel lines, please show me the simulation.

[nockieboy]

What happens when the shorter face of the triangle ends and the new line begins there.

The line_generator should show line_complete as well as the y_stop flag?

I guess it's your choice.
It sounds like it may be easier.
Ok, let's give it a try.

New rule on the Y stop input, whenever it's HIGH, on any Y increment, the line drawing engine will stop and wait for the Y_stop to go low.  The output Y_stopped will be high during this time.

Let's see what happens.

Will have a go at this tomorrow. 

Also, for your multiplot of single pixel lines, please show me the simulation.

Ah, forgot to add that!  Here it is:

[BrianHG]

Arrrg, all those wasted clock cycles...

Ok, I see there is a lot of cleanup work to do in the goemetry_xy_plotter.sv, lines 316...348, and, flush out lines 359...428.

Check back here before you start, I'll do a major overhaul getting rid of all that obsolete junk.

Just continue to work, I'll see if I can find time to clean up the obsolete junk tomorrow.

[nockieboy]

Two images below - both draw a diagonal line from 1,1 to 5,5.  The first image is without y_stop.  The second is with y_stop on for a pixel.

It looks like it's working, but I'm finding these simulation results hard to interpret, so you'll probably pick up on some problems. 

[BrianHG]

Why not try wiring the Y-stopped output inverted back to the Y-stop input and see if there is a 1 clock cycle pause every Y increment.

Then try a stretched horizontal line at 22.5 degrees and see if the Y-stoppin only occurs once every 2 pixels for 1 clock.

You may disconnect the 'writer' section and go back just to the geo simulation to see things more clearly.

[nockieboy]

Why not try wiring the Y-stopped output inverted back to the Y-stop input and see if there is a 1 clock cycle pause every Y increment.

Then try a stretched horizontal line at 22.5 degrees and see if the Y-stoppin only occurs once every 2 pixels for 1 clock.

Okay, have done that - here's the output:

First image is 1,1 to 5,5 with the re-wired Y-stop output, as specified.



Second image is 1,1 to 10,5 (22.5 degree angle), as specified.

[BrianHG]

How can the 'draw_cmd_rdy' be ready when the Y_stopped is stopped?

I guess I need to also see the 'Stop_on_next_Y_increment' input to help decipher things.

[nockieboy]

How can the 'draw_cmd_rdy' be ready when the Y_stopped is stopped?

I guess I need to also see the 'Stop_on_next_Y_increment' input to help decipher things.

I won't be able to re-run the simulation until tomorrow now, but here's the source for geo_xy_plotter.sv.  Line #163 is where the 'stop_on_next_Y_increment' input is set - it's just the y_stopped output inverted, as you specified previously.

Actually, for it to be inverted, does !y_stopped work in that context, or should it be ~y_stopped?

[nockieboy]

Updated simulation with ena_stop_y signal shown (this is the signal to the line_generator module).

[BrianHG]

Ok, I've attached a version of the project with an enable/disable for the pixel_writer.

Take a look at the 'y_stop_1,1-10,5.png'.
The Y stop is cycling, but, you are always sending out 'pixel_cmd_rdy'.
When stopped, the pixel command shouldn't be ready.

Also, in 'point_1,1-1,1.png', there shouldn't be any delayed clock cycles.
A number of things need to be patched to correct this.  I guess I'll handle this one as we want to see this working really soon.

[nockieboy]

A number of things need to be patched to correct this.  I guess I'll handle this one as we want to see this working really soon.

Uh, sorry.  No rush, I know you're busy. 

[BrianHG]

Ok, a bunch of patches have been made.
Take a look at 'Line-1,1-10,5_ystop.png'.
I fixed your 'pixel_cmd_ready'.

Also take a look at 'point_1,1-1,1.png', notice lack of additional delays when passing pixels through.

I also removed the additional clock cycles when the line begins when drawing a line as well.

No more box, or box-fill command as a removed a heap of junk from the code & once we have the 3 linegens in the code, you will be able to sequence them to generate the box/boxfill command as well as any 4 point / 4 face polygons.

Before this, you need to re-test the new attached project's line command, with and without the Y_stopped feature.  Once verified, we will add 2 additional linegens and generate your first triangle.