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
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
end else begin
end else if (!draw_busy) begin
end // reset
to: end else draw_cmd_tx <= 1'b0; // !draw_busy
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.
...
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.
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
The '_patched.zip' version has all the fixes.
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.
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: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?
- ena_stop_y, and
- stop_ypos
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.
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.
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.
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.