6502.org

Great!

Yes, I believe it's fixed. Shifting out a value of $000F works as expected and sets the Carry flag. Time to move on! I will update Github.

EDIT: So now that the pseudo-timer value and plotting is functional. A quick test needs to be made to set the reset bit on the timer, then do a typical delay loop. Then read value and compare real and expected results!

I have just enough energy left to paste the code for those that would count the expected cycles for the cpu that is running @ 100MHz.

Ok so this 'Delay Loop' is at least 65536x65536 cycles:

As a very rough calculation: That's 4 billion, times 5 cycles for the inner loop. 20 billion cycles divided by 100 million hertz is 200 seconds.

Ok, that's too much value for the left of the decimal! I've re-thought the accuracy issue of this counter and I think I will use the A0 address line to decode in a second consecutive address that will read 4 more decimal places to the right (another 16-bit hex number). Also, I will loose the second's digit counter.
By doing this I can have 8 decimal places to the right of the decimal in order to be cycle accurate @100MHz. So the counter will look like '0.xxxxxxxx seconds'.

It's intriguing to me for a computer to know how fast it is.

By Tues I should be done with the timer, and finally be able to test the direct translation of Daryl's Bresenham Circle Algorithm. I was looking over it today. It is very nice and clean.
I would like to start testing, by using the JSR's to jump to the plot routine. Then another test without the JSR's and insert the plot routine itself for every JSR and spec the timing difference. We know every cycle counts and eliminating the JSR's is only a starting point. I have 15 other accumulators at my disposal, to maximize speed!

Alright I got it working, now I have to subtract the cycles necessary to hold the counter, i.e. LDA #$4000, STA $C00000000.
Arlet, since this question involves a derivative of your core, for instruction 'INY', this is a 2 cycle instruction? DECODE, then REG?

Yes. Cycle times of my core are exactly the same as the NMOS 6502.

Ok. I realized I can't easily compensate for the cycles added by the opcodes necessary for halting the counter because I don't have decimal mode. So for the 'true' value one must subtract 6 cycles. I thought about starting the counter at .99999994, but I added logic that does not allow the counter to rollover, instead of adding a rollover flag...

Anyway, I did some real world speed tests, characters are 8x8 pixels (times posted always adjusted):

For plotting a solid cursor @(320,240) - 14.09uS.
For plotting a solid cursor @(632,472) - 14.09uS.
For plotting a '#' @ - 14.31uS.
For clearing 640x480 pixels - 55.88mS. (So my earlier ballpark estimate of 32 fps was abit off as this calculates to 18fps)

How big are the cursors and '#' characters ? Do you have the code posted somewhere ?

They're 8x8... You mean the software?

Yes, the software. So, at 100 MHz, that's 1409 cycles, or 22 cycles per pixel.

Ok, I started on the Bresenham circle, so you will see the incompleteness for that subroutine.

Line 25064 is the start.
Line 25182 is the PLTCHR routine.

You can save an instruction in the inner loop by initializing Y to 8, and using DEY, BNE instead of INY, CPY #7, BNE

Yes, that's how I initially had it, but the characters were mirrored, so I'll have to do some serious rearranging of the character pixel data!

Ah, I see, the STYic instruction uses Y. I missed that. But yes, if you mirror the character data it should work.