Concept & Design of 3.3V Parallel 16-bit VGA Boards

[ElEctric_EyE]

Here are the speed comparisons for the Concentric circle fill (239 circles), showing the speed of the original code on top, the use of 4 65O16.b accumulators in the middle, then 6 accumulators plus some help from Arlet in the final optimization of the software. The number of cycles can be seen to the lower left of each pic.

[MichaelM]

Pretty cool indeed.

[ElEctric_EyE]

Arlet wrote:

A useful feature in your hardware may be to add a programmable offset in your address calculation. This would allow you to set the origin of the circle at the beginning of the plot routine, and then the rest of the routine can just plot around (0,0) without having to keep track of the offsets.

I implemented 2 write only offset registers:

Code: Select all

always @(posedge clk) begin
	if (osetCS && cpuWE && !cpuAB[0])
		osetREGL <= cpuDO;
	if (osetCS && cpuWE && cpuAB[0])
		osetREGH <= cpuDO;
end
	
always @* begin									//optimize the videoRAM address for plotting (X,Y) in the (LSB,MSB) for indirect indexed
	cpuABopt [20:19] <= 0;						//bank bits
	cpuABopt [18:10] <= cpuAB [24:16] + osetREGH;		//Y[8:0]
	cpuABopt [9:0] <= cpuAB [9:0] + osetREGL;			//X[9:0]
end

It's not working correctly now, but currently I am resetting the pixel counters used for the SyncRAM address in the HVSync module at 639 for X and 479 for Y. When I try resetting X at 1023 and Y at 511, it fails the speed constraint. Running smartExplorer. Timing score was 162, so it should fit... Then I'll try plotting again @ (0,0) with offset of (320,240).

[ElEctric_EyE]

After 16 runs, the best timing score it could do was 84.

I don't think offsets would be useful for lines though. I'll work on that next

[ElEctric_EyE]

Daryl, stupid question but what variables get plotted in your Bresenham line? IX and IY?

[8BIT]

ElEctric_EyE wrote:

Daryl, stupid question but what variables get plotted in your Bresenham line? IX and IY?

No, its not stupid. My graphics module overlapped several variables. In the code I gave back on page 22, the X1,Y1 variables are the ones that get plotted. IX&IY are used as the fractional portion and DX,DY are used as the increment value.

As a quick speed enhancement, you could shift both DX and DY left until the msb of either is 1, this will reduce the loop interations. (If this point is not clear, let me know and I will expand my explanation).

If you need any more help, just ask!

Daryl

[ElEctric_EyE]

Thanks!

I believe I got it by blind luck! It plotted a line from (400,100) to (150,250).

It's far from complete though.

8BIT wrote:

...As a quick speed enhancement, you could shift both DX and DY left until the msb of either is 1, this will reduce the loop interations...

How?

[ElEctric_EyE]

I'm pretty confident it's working. In this pic I plotted 4 lines with the 4 different possible slopes:
1) (5,0) to (635,480)
2) (640,475) to (0,5)
3) (635,0) to (5,480)
4) (0,475) to (640,5)

It's pretty slow though... Time for optimizations!

[8BIT]

ElEctric_EyE wrote:

Thanks!

I believe I got it by blind luck! It plotted a line from (400,100) to (150,250).

It's far from complete though.

8BIT wrote:

...As a quick speed enhancement, you could shift both DX and DY left until the msb of either is 1, this will reduce the loop interations...

How?

I'll work on this...give me 2 days though...full plate right now.

Glad to see its is at least working...optimizations will be straight forward.

Daryl

[ElEctric_EyE]

No rush at all, it'll be a week before I post again...

I need a rest as well. Had too many iced coffees today and I'm burnt out, but happy I've reached my goal.
I think my earlier attempt at Bresenham lines in Verilog helped me in knowing what to look for in your code. I shouldn't have said it was blind luck. Maybe, blind luck with one eye open.

[8BIT]

I cleaned up the code some and made a few adjustments. Still need to do the optimize on dx,dy but I want to make sure this still works first.

Give it a try when you find time. Also, I'm not really sure this can be called Bresenham Line drawing as I created the code myself.

File removed - found an error - see next post

Daryl

[8BIT]

I found and corrected an error in the first post. This post also includes the optimizations to reduce loop cycles.

The next step, if this still works, is to convert it to use multiple accumulators like the circle code.

Will await your test results. In the mean time, enjoy your break!!!

Daryl

[ElEctric_EyE]

Cool, I'll try it out tonight. Thanks!

[ElEctric_EyE]

Ok, finally had a chance to plug your code in...
First, As65 has an issue with 'bcc loop1' on line 48, loop1 is undefined. I assumed it was 'bcc loop2' and went forward with testing the speed with the same 4 lines as before with 32+million cycles, whew that's alot!

Looks like DX and DY are skewed for the first 2 lines: (5,0) to (635,480) & (640,475) to (0,5). However the speed is way down to 4+million cycles.

EDIT:I had found 1 'BRA' opcode that the .b core doesn't have but As65 will translate it to a $0080 opcode value, which is undefined. I just now saw a second one and changed them to a 'JMP'. Retesting...

The first 2 lines are still skewed. Now for the lines with the coordinates that have been plotted correctly, they are "sloppier" although cycles for the routine are way down to 444013.

Since I modified your code, I should paste an update so we are on the same page.

[8BIT]

The BCC loop1 was correct. I somehow erased the loop1 label. It has been added back. That should fix the skewed lines. The sloppy lines might be a byproduct of my optimization. There are two sections with comments " dx,dy optimization." Try commenting these sections out to see if the sloppiness goes away. Cycles will increase again, but I have another possible option to fix that.

Two questions about the .b core.

1) Can you do branching (bcc, bne, etc) beyond 128 bytes now?

I have several places where there is this type of code:

bne label1
jmp label 2
label1 next opcode

because label 2 was just beyond the +/- 128 byte window.

2) Does the BIT command now place bit15 and bit14 in the N an V flags?

If the optimizations are causing the sloppieness, I might be able to use the BIT command to improve it.

Will await your further tests.

Daryl