Date   : Sun, 04 Nov 2012 21:09:02 -0600
From   : jules.richardson99@... (Jules Richardson)
Subject: 6502 timing and zero-page instructions

On 11/02/2012 11:49 AM, Ed Spittles wrote:
> Thanks for spotting that Jules - I've updated the page.

No prob! If the last-modified date for the page is right, nobody's spotted 
it in a long time ;-) I've not noticed any others yet - although every scan 
of every 6502 instruction table out there seems to be quite low quality, so 
when it comes to cycle counts the number 5 looks rather like the number 6 
in many cases :-( I'll have to throw some stuff at the simulator...

JOOI, is the statement about the program counter "Once it has the op code, 
it increments the program counter by the length of the operand, if any" 
(from the same web page) correct from a machine point of view? I'd expect 
the CPU to increment PC once prior to an opcode or operand fetch, i.e. for 
a 16-bit operand:

   increment PC
   fetch opcode at mem location [PC]
   increment PC
   fetch 1st opcode byte at mem location [PC]
   increment PC
   fetch 2st opcode byte at mem location [PC]

... rather than the implied (at least to me!):

   increment PC
   fetch opcode at mem location [PC]
   increment PC by 2
   fetch 1st opcode byte at mem location [PC - 1]
   fetch 2st opcode byte at mem location [PC]

Of course from the programmer's point of view the end result is identical 
(which is perhaps all that the web page is concerned about), but the first 
seems to more likely at the logic level.

> We can verify the NMOS 6502 timings with a URL like this:
> http://visual6502.org/JSSim/expert.html?graphics=f&logmore=sync&steps=40&a=0&r=0&d=25252525252525

Aha, silly question related to the above about the program counter, but 
presumably given the PC pre-increment that the 6502 seems to do on a memory 
fetch, the interrupt and reset vectors stored at 0xfffc and 0xfffe have to 
be 1 byte less than their true location?

I just noticed that the simulator referenced in the above link has PC as 
0x0000 at reset, even though the first instruction fetch then occurs at 
0x0000 - given the pre-increment, I'd expect PC to be 0xffff. Simulator 
feature, or am I missing something? (once running it does what I'd expect, 
of course - it's just the "pre-running" display value that I *think* is wrong)

cheers

Jules