Page 29 of 41
Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards
Posted: Tue Apr 09, 2013 2:18 pm
by 8BIT
I see your problem. I don't recall issues with fat lines but I will dust off my AVR video project and test those same coordinates to see.
A better alternative, which I have been noodling out, may be to split the slope processing into 4 groups (right now its only two - slope up or slope down). The new groups would be positive slope with DX > DY, positive slope with DX<= DY, negative slope with DX>DY, and neg slope with DX<=DY. That way will be faster as each interation through the loop results in 1 point being plotted. The lines should also be thinner! The downside is a little heavier processing up front (1 division) but the end result should be worth it unless you draw a lot of very short sloped lines.
I will test the current method on the AVR and let you know the results. Thanks for your help and sorry for all the frustrations I'm sure your having.
Daryl
Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards
Posted: Tue Apr 09, 2013 2:51 pm
by ElEctric_EyE
No frustration here, no timetable either so it's all good. I enjoy the troubleshooting aspect. Looking forward to your code! Also, I would be grateful if you would see if you get the same results on your AVR project. I have this nagging feeling it's something I'm doing wrong.
Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards
Posted: Tue Apr 09, 2013 5:02 pm
by 8BIT
It might be helpful to plot some lines of various slopes to verify if the issue is confined to one region.
Try
0,240 (common start point
to:
50, 0 (steep + slope)
240,0 (45 + degree)
640, 160 (low + slope)
640, 400 (low - slope)
240, 480 (45 - slope)
50, 480 (steep - slope)
You could also run a loop stepping x from 0 to 640 by 20's using y=0 and y=480 and use 320,240 as the origin.
Then step y from 0 to 480 by 20's with x=0 and x=640 with the same origin to cover the everything.
It might prove useful in the debugging.
Daryl
Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards
Posted: Wed Apr 10, 2013 4:55 am
by 8BIT
No frustration here, no timetable either so it's all good. I enjoy the troubleshooting aspect. Looking forward to your code! Also, I would be grateful if you would see if you get the same results on your AVR project. I have this nagging feeling it's something I'm doing wrong.
Just dusted off the AVR project. I set up a line from 5,0 to 319, 199 (max display size) but it is not drawing correctly at all. Looks more like 319, 80. I will need to take some time to see what I messed up. I know this worked on my SBC-3.
Guess I didn't quite test the AVR thoroughly enough.
Will keep you informed.
Daryl
Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards
Posted: Wed Apr 10, 2013 11:23 am
by ElEctric_EyE
Just dusted off the AVR project. I set up a line from 5,0 to 319, 199 (max display size) but it is not drawing correctly at all. Looks more like 319, 80. I will need to take some time to see what I messed up. I know this worked on my SBC-3...
When you say it worked on your SBC-3, did you notice the issue with double wide pixels?
Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards
Posted: Wed Apr 10, 2013 12:15 pm
by 8BIT
When you say it worked on your SBC-3, did you notice the issue with double wide pixels?
There were no noticable issues with the lines at all. I did not use the optimization method I added to you code. My first post of the line drawing code was taken directly from the SBC-3 drawing routine.
Daryl
Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards
Posted: Wed Apr 10, 2013 2:40 pm
by ElEctric_EyE
Ok, I went back to that one did a few basic changes to some of the branches and made a
video where the program plots lines from the center and does a radar sweep. You can see some error creep in on the right side. I did this for a speed reference. When the timer
was active for plotting 1 line from (319,239) to (0,0) it took 7,278,210 cycles.
Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards
Posted: Wed Apr 10, 2013 9:09 pm
by ElEctric_EyE
Aha! I found an error.
There are 3 times in your original code, without optimizations, an LSR is done before modifying the DX & DY variables on lines 17,31,80. Removing these, got rid of the errors. So the radar sweep results in a solid screen now. Also, it's abit faster. I removed the check for when DX or DY was zero as well.
Next step is to replace all the JSR PLTPXL and insert the actual plot code.
Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards
Posted: Wed Apr 10, 2013 10:37 pm
by ElEctric_EyE
...A better alternative, which I have been noodling out, may be to split the slope processing into 4 groups (right now its only two - slope up or slope down). The new groups would be positive slope with DX > DY, positive slope with DX<= DY, negative slope with DX>DY, and neg slope with DX<=DY. That way will be faster as each interation through the loop results in 1 point being plotted...
This is going to be the way to go I think as well.
There's an error plotting a single line from (319,239) to (320,0), it only shifts to the right at the very last pixel, so doing an LSR for DY might work in this case. Also I tried (320,0) to (319,239) with the same result.
Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards
Posted: Thu Apr 11, 2013 2:25 pm
by 8BIT
I have created and tested the new line drawing routine. This is using QuickBASIC. I placed my line next to the line generated by the built-in QB LINE function and they look almost identical accross a wide range of slopes.
I am attaching the source. The next step will be convert this to assembly. It does require 1 division which will always be a positive fraction, i.e. 200/245 or 2/630. The best way to do this in my mind is to make this a 32 bit number divided by a 16 bit number. We essentially multiply the top number by 65536 then do the division. The 16 bit result is the fractional value. This value gets added to an intermediate variable and a carry indicated time to adjust the lesser axis plot point (hope that makes sense).
Daryl
Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards
Posted: Thu Apr 11, 2013 11:14 pm
by ElEctric_EyE
Multiplying by 65536 would not be a problem in the .b core but the fraction would slow things down...
Back when I was trying to do lines in Verilog, I was trying to implement Bresenham because it works with integers only. Arlet got pretty far with his implementation that drew multiple lines from a single point. One thing I have considered is experimenting with Verilog to write the coordinates straight to RAM... Anyway, this is the most optimized one, near the bottom of the
wiki page, for 1 slope:
Code: Select all
plotLine(x0,y0, x1,y1)
dx=x1-x0
dy=y1-y0
D = 2*dy - dx
plot(x0,y0)
y=y0
for x from x0+1 to x1
if D > 0
y = y+1
plot(x,y)
D = D + (2*dy-2*dx)
else
plot(x,y)
D = D + (2*dy)
Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards
Posted: Fri Apr 12, 2013 12:40 am
by 8BIT
Multiplying by 65536 would not be a problem in the .b core but the fraction would slow things down...
Back when I was trying to do lines in Verilog, I was trying to implement Bresenham because it works with integers only. Arlet got pretty far with his implementation that drew multiple lines from a single point. One thing I have considered is experimenting with Verilog to write the coordinates straight to RAM... Anyway, this is the most optimized one, near the bottom of the
wiki page, for 1 slope:
Code: Select all
plotLine(x0,y0, x1,y1)
dx=x1-x0
dy=y1-y0
D = 2*dy - dx
plot(x0,y0)
y=y0
for x from x0+1 to x1
if D > 0
y = y+1
plot(x,y)
D = D + (2*dy-2*dx)
else
plot(x,y)
D = D + (2*dy)
This should be easier to implement and faster too.
Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards
Posted: Fri Apr 12, 2013 1:37 am
by ElEctric_EyE
This should be easier to implement and faster too.
This is great then!
You could work on this algorithm and hopefully for your benefit as well!
As for me, I would like to tackle the Verilog, realizing the project speed will take a big hit with this extra burden of a hardware line plotter. If I'm successful with the Veriog, the cpu speed should match the pixel clock @ at least 25MHz, but hopefully 50MHz. This would be something worth comparing against your software running on the present 100MHz .b core.

Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards
Posted: Fri Apr 12, 2013 10:19 pm
by ElEctric_EyE
I don't know why I struggled months ago when I was first attempting Bresenham. Maybe I was trying to implement one of the unoptimized formula's. But it only took me an hour to get the example on the wiki to work, outputting the correct coordinates. I'll have to add a 'LOAD' input signal to this module, and an output 'DONE' signal, which will go to set one of the unused cpu flag bits. So far this is a separate module not part of the project yet, and I still have to add checks for the other slopes. This implementation uses 75 slice registers, 117 slice LUTs and 55 LUT FF pairs. Each pixel coordinate takes 2 cycles:
Code: Select all
module LineGen ( input clk,
output reg [9:0] X = 0,
output reg [8:0] Y = 0
);
reg [9:0] x0;
reg [8:0] y0;
reg [9:0] x1;
reg [8:0] y1;
reg [9:0] dx;
reg [8:0] dy;
reg [16:0] D;
reg [2:0] state;
parameter LOAD = 0, CALC1 = 1, CALC2 = 2, PLOT = 3;
always @(posedge clk) begin
state <= LOAD;
case (state)
LOAD:
state <= CALC1;
CALC1:
state <= CALC2;
CALC2:
state <= PLOT;
PLOT:
if ( x0+1 <= x1 )
state <= CALC2;
else
state <= LOAD;
endcase
end
always @(posedge clk) begin
case (state)
LOAD:
begin
x0 <= 0;
y0 <= 1;
x1 <= 6;
y1 <= 4;
end
CALC1:
begin
X <= x0;
Y <= y0;
dx <= x1 - x0;
dy <= y1 - y0;
D <= y1*2 - y0*2 - x1 + x0;
end
CALC2:
if ( D[16] == 0 ) begin
x0 <= x0 + 1;
y0 <= y0 + 1;
D <= D + dy*2 - dx*2;
end
else begin
x0 <= x0 + 1;
D <= D + dy*2;
end
PLOT:
begin
X <= x0;
Y <= y0;
end
endcase
end
endmodule
EDIT: Fixed the detect when D goes negative. Seems to work only when DX>DY.
Re: Concept & Design of 3.3V Parallel 16-bit VGA Boards
Posted: Sat Apr 13, 2013 2:30 am
by 8BIT
Very cool. I read in the WIKI that flipping the x & y coordinated before input then flipping them back on output is used in hardware frequently. That would essential flip DX and DY.
I have not started any code for the software approach. My weekend is full but will try to squeeze in some code time too.
Daryl