6502.org

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:

No, don't spend your time yet. I will go to ISim now and resolve this, now I'm thinking it's an optical illusion or something.

Here's a pic of what I'm seeing though:

This pic more clearly shows the problem I'm having.
The coordinates of the line on the left is (0,0) to (100,101). The other is (10,0) to (110,100). Is this the correct action of your algorithm?

EDIT: I should've pointed out that this is the version 'E' with the DX&DY optimizations commented out.
Interesting, I just uncommented the optimizations. The second pic is the 1 optimization that was fastest. Same result with the other 2 optimizations.