6502.org

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.

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

It does correct the problem. 486,231 cycles with your optimizations and 15,787,440 cycels without. Everything looks good! 1) Everything that used to be 256 bytes in the 6502, is now 65536 bytes in the 65O16.x. So it follows that branches can go half this in either direction as you have pointed out, i.e. 32K.
2) I've never used the BIT command when I've programmed the 6502. These opcodes remain untested in the .b core, but it won't be difficult to put them to the test!

BTW, I've been thinking, there should be a pixel counter for the circle routine (in software). This would then lead to a more fair speed test for the same pixel count against the line drawing routine.

ok, Line16.d.asm is on its way. I will make the new test optimization without BIT (the end result will be the same).

Look for it on the next hour.

Daryl

Here's line16.d.asm

The optimization is updated. There are also two other versions commented out that can be used if the stated conditions are true. I also fixed the branching to remove excess JMP instructions.

Next would be to use more accumulators inside the loops to increase speed.

Daryl

FYI, the drawing routine basically subtracts the start and end X & Y points to derive the difference between them, or slope steps (DX & DY). It uses DX & DY as an (now 16 bit) increment value to IX & IY (16 bits too). If after adding either IX or IY carry, then X1 and/or Y1 are incremented/decremented and the new point is plotted. As you can see, since DX in your example is only about 630, it takes about 100 interrations of adding 630 to IX to before it carries and the next point gets plotted. By multiplying DX and DY by 2 (left shift) until they get close to 65,535 without going over, we can reduce the # of iterrations needed to produce the carry. My first optimization shifts left until bit 15 is set in either DX or DY. That caused the degraded line as a carry happens almost every time. The latest optimization shifts DX and DY left until bit 14 is set in either. Now there will be a two or three iterrations before a carry happens. I hope this reduces the degrading while keeping the cycle counts lower.

Ok, testing version 'D' without the 'BIT' optimizations. 741,374 cycles!
Testing with the 2nd BIT optimization active: 741,257 cycles.
Testing with the 1st BIT optimization active: 741,308 cycles.
They all look the same... We'll have to see if the degredation is tolerable when the lines are moving. Daryl, thanks for your hard work!

Hmmm.... I will do some more research as to why the degredation occurs.

Daryl

I have to redo the tests because there are 2 places in your code where the DX/DY optimizations are made. I only was working with 1 and ignoring the other. Sorry!

Although it didn't change the looks of the line, cycles went down to 741140. I'm going to start optimizing from my end now. Here is the new line plot, version 'E'. I've chosen the fastest of your dx/dy optimizations and they're being utilized both times in your routine. First I'll replace the JSR for plot pixel. This is the biggest improvement.

I've halted my optimizations...
This morning I plotted a circle with the lines. Replaced 2 of the lines with 1 vertical and 1 horizontal to make sure they work. They did... But the line error was more noticeable plotted against the circle. Looks like the lines were too thick up against the circle.

I decided to go back to ground zero, to when Daryl's Bresenham line routine first worked, and then double check all the additions to the line plotting code 1 step at a time and one thing is evident at first glance: There is no check for when DX=0 or DY=0 after the original.

Are you saying that even with the optimize sections commented out, you are getting distorted lines?

I removed the those checks for DX=0 and DY=0 as it was already being done and was redundant. if DX is 0, then its a vertical line. DY=0 is a horizontal line. Both get tested for and jump to the optimized code, therefore, testing for either inside the sloped-line code was a waste.

At CONT, I store DX and then BEQ VERT. Right above NHZ, I BEQ HORZ after calculating DY. Hope that clears that up.

I'm still scratching my head over the why the optimization results in degraded lines. I plan to dump some test code when I get time to see what's happening.

Daryl

That's correct. I just now reloaded 'Line16.e.asm', commented out the DX&DY optimize code and the error is still there. I'm not exactly sure what this means, but I think it would be better for me to go backwards and compare version '.d' then '.c' etc. instead of starting from ground zero like I originally thought.

I must have dumped something along the way. I will also look over the old files for something wrong.

thanks

Daryl

I went back and looked at the original pic when I first had success. I must have been so excited I didn't notice the error, so your optimizing is good to go.
With the circle plotted along with some diagonal lines crossing it, I can see it looks like for every single horizontal pixel that should be plotted, it is plotting 2, side by side.

EDIT: The error is nothing like I was experiencing here, just double wide horizontal: