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.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Pretty cool indeed.

_________________
Michael A.

I implemented 2 write only offset registers:

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).

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

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

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

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

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

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

_________________
Please visit my website -> https://sbc.rictor.org/

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.


How?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

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!

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

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

_________________
Please visit my website -> https://sbc.rictor.org/

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.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

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

_________________
Please visit my website -> https://sbc.rictor.org/

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

_________________
Please visit my website -> https://sbc.rictor.org/

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

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

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.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

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

_________________
Please visit my website -> https://sbc.rictor.org/